I have a Turing card, so it's possible for me to switch from the "easy-way" to the new open driver. But I'm a little confused over the advantages and differences from the easy-way (or the hard-way for that matter). Is the new open driver in rpm-form in essence another "easy-way" option? Specifically, will automatically rebuild for kernel changes without a driver reinstall being necessary? The open driver rpms come from an opensuse repository, so does that mean that the newer 560 drivers might eventually be made an option - stepping around their unavailability via the old "easy-way"? If the new open driver rpms are installed, what is the OpenSUSE suggested way of obtaining the associated utilities, such as nvidia-settings? Do I specifically have to choose it, or will yast/zypper prefer the new open driver rpms for cards that support it? I think I read there might be some limitations with the new open driver - possibly it's better for wayland? Are there other questions I should be asking, but have overlooked? As a side note, I think the "hard-way" installer may choose the new open drivers if the card supports it - is that correct? If answers to the above are already written up somewhere, just point me to the link. Thanks, Michael
Hello, I'm using open-gpu as recommended by nvidia. In the Message; Subject : Nvidia: turing+ new open driver rpms versus? Message-ID : <202409190915.57206.michael@actrix.gen.nz> Date & Time: Thu, 19 Sep 2024 09:15:57 +1200 [MH] == Michael Hamilton <michael@actrix.gen.nz> has written: MH> I have a Turing card, so it's possible for me to switch from the MH> "easy-way" to the new open driver. I don't understand why openSUSE is limited to Turing. NVIDIA does not have such a limitation. [...] MH> Is the new open driver in rpm-form in essence another "easy-way" MH> option? Specifically, will automatically rebuild for kernel changes without MH> a driver reinstall being necessary? I imagine that the design is to update the nvidia kernel module in the dependency when updating the kernel. MH> The open driver rpms come from an opensuse repository, so does MH> that mean that the newer 560 drivers might eventually be made an MH> option - stepping around their unavailability via the old "easy-way"? The biggest factor is that NVIDIA is recommending the transition to open-gpu, and I think it will be up to NVIDIA to decide what form of provision will be used. MH> If the new open driver rpms are installed, what is the OpenSUSE MH> suggested way of obtaining the associated utilities, such as MH> nvidia-settings? At the moment, open-gpu only includes kernel-modules. In other words, you just need to change the kmp file to open-gpu, and install the other files as you have done in the past. MH> Do I specifically have to choose it, or will yast/zypper prefer MH> the new open driver rpms for cards that support it? I don't use zypper, so I'll leave it to someone else. MH> I think I read there might be some limitations with the new open MH> driver - possibly it's better for wayland? I've never felt like I was at my limit. I'm more worried about the changes in the kernel's support for the nvidia driver. MH> Are there other questions I should be asking, but have MH> overlooked? Sorry, I've got no idea. MH> As a side note, I think the "hard-way" installer may choose the MH> new open drivers if the card supports it - is that correct? I think that the hard way is easier to understand and prevents mistakes. Sometimes, there are people who install different drivers using the soft way. Best Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "To hire for skills, firms will need to implement robust and intentional changes in their hiring practices ― and change is hard." -- Employers don’t practice what they preach on skills-based hiring --
On Thursday 19 September 2024, Masaru Nomiya wrote:
Hello,
I'm using open-gpu as recommended by nvidia.
In the Message;
Subject : Nvidia: turing+ new open driver rpms versus? Message-ID : <202409190915.57206.michael@actrix.gen.nz> Date & Time: Thu, 19 Sep 2024 09:15:57 +1200
[MH] == Michael Hamilton <michael@actrix.gen.nz> has written:
MH> I have a Turing card, so it's possible for me to switch from the MH> "easy-way" to the new open driver.
I don't understand why openSUSE is limited to Turing. NVIDIA does not have such a limitation.
(2nd attempt to reply, forgot to reply to the list the first time.) It's not openSUSE that is limited, it's that the new Nvidia open driver only supports Turing and up. So people can't just change from the "easy-way" or "hard-way" unless they have the right hardware. I was clumsily trying to state that I fit the pre-requisites for making the switch :-)
[...] MH> Is the new open driver in rpm-form in essence another "easy-way" MH> option? Specifically, will automatically rebuild for kernel changes without MH> a driver reinstall being necessary?
I imagine that the design is to update the nvidia kernel module in the dependency when updating the kernel.
That's my guess too, but if the info is already out there, I'd rather not guess or spend too much time digging/experimenting to duplicate existing efforts.
MH> The open driver rpms come from an opensuse repository, so does MH> that mean that the newer 560 drivers might eventually be made an MH> option - stepping around their unavailability via the old "easy-way"?
The biggest factor is that NVIDIA is recommending the transition to open-gpu, and I think it will be up to NVIDIA to decide what form of provision will be used.
At the moment Nvidia seems to be the gatekeeper on their own zypper repo. I was asking if that can now be bypassed because OpenSUSE appears to be releasing the open-rpms directly in the normal TW repo.
MH> If the new open driver rpms are installed, what is the OpenSUSE MH> suggested way of obtaining the associated utilities, such as MH> nvidia-settings?
At the moment, open-gpu only includes kernel-modules.
In other words, you just need to change the kmp file to open-gpu, and install the other files as you have done in the past.
I may be wrong, but I think that may rpm break dependencies. So I was attempting to see what the best/official OpenSUSE approach might be.
MH> Do I specifically have to choose it, or will yast/zypper prefer MH> the new open driver rpms for cards that support it?
I don't use zypper, so I'll leave it to someone else.
I know I could go the hard-way, but the whole point of my email was to query around the new rpm-way and how it fits in - particularly with the old easy-way :-) Michael
Hello, In the Message; Subject : Re: Nvidia: turing+ new open driver rpms versus? Message-ID : <202409191339.06637.michael@actrix.gen.nz> Date & Time: Thu, 19 Sep 2024 13:39:06 +1200 [MH] == Michael Hamilton <michael@actrix.gen.nz> has written: MH> On Thursday 19 September 2024, Masaru Nomiya wrote: [...] MN> > I don't understand why openSUSE is limited to Turing. MN> > NVIDIA does not have such a limitation. MH> (2nd attempt to reply, forgot to reply to the list the first time.) Thanks. MH> It's not openSUSE that is limited, it's that the new Nvidia open driver MH> only supports Turing and up. ? Confirmed! Thanks. I have to apologize..... MH> So people can't just change from the MH> "easy-way" or "hard-way" unless they have the right hardware. I was MH> clumsily trying to state that I fit the pre-requisites for making the MH> switch :-) Ah, I understand. [...] MN> > I imagine that the design is to update the nvidia kernel module in the MN> > dependency when updating the kernel. MH> That's my guess too, but if the info is already out there, I'd rather not MH> guess or spend too much time digging/experimenting to duplicate MH> existing efforts. It's true that there is an official website for installing proprietary drivers, but there isn't one for open-gpu. Is there a reason for this...? [...] MH> At the moment Nvidia seems to be the gatekeeper on their own zypper MH> repo. I was asking if that can now be bypassed because OpenSUSE MH> appears to be releasing the open-rpms directly in the normal TW repo. You can avoid this by using YaST2, though? [...] MH> I may be wrong, but I think that may rpm break dependencies. So MH> I was attempting to see what the best/official OpenSUSE approach might MH> be. I don't use rpm files, so I have no idea. [...] MN> > I don't use zypper, so I'll leave it to someone else. MH> I know I could go the hard-way, but the whole point of my email was MH> to query around the new rpm-way and how it fits in - particularly MH> with the old easy-way :-) It's true that the way the open-gpu package is currently provided is a style that only those who understand it can use. But, if you look into it, NVIDIA only recently made it completely open (this July). But, I'm using it for quite a while...... (_ _? Anyway, many thanks. Best Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "During testing, Sakana found that its system began unexpectedly attempting to modify its own experiment code to extend the time it had to work on a problem." -- Research AI model unexpectedly attempts to modify its own code to extend runtime (ars TECHNICA) --
On Thu, Sep 19, 2024 at 12:16 AM Michael Hamilton <michael@actrix.gen.nz> wrote:
I have a Turing card, so it's possible for me to switch from the "easy-way" to the new open driver. But I'm a little confused over the advantages and differences from the easy-way (or the hard-way for that matter).
Is the new open driver in rpm-form in essence another "easy-way" option? Specifically, will automatically rebuild for kernel changes without a driver reinstall being necessary?
"Open" kernel driver is provided as a compiled (and signed) kernel module, it is not rebuilt on the end system. "Open" driver is not really more "open" than previous drivers. It simply pushed the closed source part into firmware (which is the reason why it is not supported for older cards - this driver is useless without matching firmware which is provided only for new models). And it lifted redistribution restrictions.
The open driver rpms come from an opensuse repository, so does that mean that the newer 560 drivers might eventually be made an option - stepping around their unavailability via the old "easy-way"?
This is just the kernel part. You still need the user space part and it is provided via NVIDIA (same redistribution restrictions as always). So, it makes no sense to provide 560 open drivers until 560 closed drivers are available via "old easy-way" with complete user space. You may look at the recent discussion on the factory list which mentions some problems integrating 555/560 drivers.
If the new open driver rpms are installed, what is the OpenSUSE suggested way of obtaining the associated utilities, such as nvidia-settings?
Same as before. But closed NVIDIA kernel package Recommends user part, so they are usually installed automatically. Open driver does not. I am not sure what happens during installation. Probably, it will default to the closed kernel module and you would need to manually select the open driver, removing the closed one.
Do I specifically have to choose it, or will yast/zypper prefer the new open driver rpms for cards that support it?
Good question. In the past the open driver has been often eagerly installed (due to a bug also on the systems with unsupported cards) so I assume during installation on a supported system open driver should be installed. If you already have the closed driver, you will need to manually replace it. Hmm ... if you have the NVIDIA repository defined during installation then I expect zypper to choose the closed driver (due to the way zypper breaks the tie when multiple packages provide the same capability). I cannot test it as I do not have matching hardware. If you have and do not yet have NVIDIA installed you may test what "zypper inr" suggests.
I think I read there might be some limitations with the new open driver - possibly it's better for wayland?
Are there other questions I should be asking, but have overlooked?
As a side note, I think the "hard-way" installer may choose the new open drivers if the card supports it - is that correct?
If answers to the above are already written up somewhere, just point me to the link.
Thanks, Michael
On Thursday 19 September 2024, Andrei Borzenkov wrote:
On Thu, Sep 19, 2024 at 12:16 AM Michael Hamilton <michael@actrix.gen.nz> wrote: ... "Open" driver is not really more "open" than previous drivers. It simply pushed the closed source part into firmware (which is the reason why it is not supported for older cards - this driver is useless without matching firmware which is provided only for new models). And it lifted redistribution restrictions. ... This is just the kernel part. You still need the user space part and it is provided via NVIDIA (same redistribution restrictions as always). So, it makes no sense to provide 560 open drivers until 560 closed drivers are available via "old easy-way" with complete user space. ...
Thanks for the good explanation. The new "open" rpms don't seem to offer me anything worth troubling over. I can rest "easy" for now.
On Thu, Sep 19, 2024 at 12:20 PM Michael Hamilton <michael@actrix.gen.nz> wrote:
The new "open" rpms don't seem to offer me anything worth troubling over.
Well, the closed driver has constant issues during updates (sometimes it is not rebuilt, sometimes the signing key is not updated, at least one user on forums reported that EFI NVRAM was filled with signing keys that were never removed). So, if your card is supported by the open driver it makes sense to use it from an administration point of view. If anything, it has smaller dependencies (it does not need development tools, kernel-devel, ...)
On 9/19/24 4:54 AM, Andrei Borzenkov wrote:
On Thu, Sep 19, 2024 at 12:20 PM Michael Hamilton <michael@actrix.gen.nz> wrote:
The new "open" rpms don't seem to offer me anything worth troubling over.
Well, the closed driver has constant issues during updates (sometimes it is not rebuilt, sometimes the signing key is not updated, at least one user on forums reported that EFI NVRAM was filled with signing keys that were never removed). So, if your card is supported by the open driver it makes sense to use it from an administration point of view. If anything, it has smaller dependencies (it does not need development tools, kernel-devel, ...)
That is a bonus. The tradeoff is always performance. If you can live with nouveau level performance, the open driver is fine, or you may as well not even worry with it, but if you bought your card (or laptop) because you need framer-per-second, there is no replacement for the closed source driver. Something as simple as compiz or plasma's DE make that painfully apparent. The same applies to AMD cards as well. (As we wait for the Linux 6.11 kernel to appear... though I am cautiously optimistic... the Nvidia diver will build as is with patches through kernel-6.10 and gcc-14 for G03 - G05. The only reported issues are with the latest Fedora - and that was a runtime, not a build issue) -- David C. Rankin, J.D.,P.E.
On Friday 20 September 2024, David C. Rankin wrote:
On 9/19/24 4:54 AM, Andrei Borzenkov wrote: ... That is a bonus. The tradeoff is always performance. If you can live with nouveau level performance, the open driver is fine, or you may as well not even worry with it, but if you bought your card (or laptop) because you need framer-per-second, there is no replacement for the closed source driver. ...
Just to be clear I was referring to the newer open driver from Nvidia, not the older open Nouveau (which is an independent effort separate from the new open driver direct from Nvidia). So there are several options for a driver install (for TW): 1) "Easy-way" for the Nvidia proprietary driver. 2) "Hard-way" which will automatically use the from-Nvidia open driver if the card supports it, otherwise it installs the Nvidia proprietary driver. (Only viable option for latest 560 driver.) 3) New OpenSUSE rpms for the from-Nvidia open-driver plus what ever else is needed (which is still a little unclear - probably need to try it and deal with any issues). 4) Older (not-from-Nvidia) open Nouveau driver. They all have their place depending on user requirements. Easy-way #1 currently suits me now, but once clarity is achieved I suspect #3 might best suit my needs. Michael
On 9/19/24 3:52 PM, Michael Hamilton wrote:
Just to be clear I was referring to the newer open driver from Nvidia, not the older open Nouveau (which is an independent effort separate from the new open driver direct from Nvidia). So there are several options for a driver install (for TW):
1) "Easy-way" for the Nvidia proprietary driver. 2) "Hard-way" which will automatically use the from-Nvidia open driver if the card supports it, otherwise it installs the Nvidia proprietary driver. (Only viable option for latest 560 driver.) 3) New OpenSUSE rpms for the from-Nvidia open-driver plus what ever else is needed (which is still a little unclear - probably need to try it and deal with any issues). 4) Older (not-from-Nvidia) open Nouveau driver.
They all have their place depending on user requirements. Easy-way #1 currently suits me now, but once clarity is achieved I suspect #3 might best suit my needs.
No worries Michael, I understood, I cobbled together a short chart I think is correct covering what chip architectures must, can or can't use the open-source driver: Nvidia Open-Source Driver Availability Open-Source Driver Only (AI chips): Blackwell Grace Hopper Either Open-Source or Proprietary (Graphics Cards): Ada Lovelace RTX 4... Ampere RTX 3... Turing RTX 2... and 16.. Hopper (AI chip) Proprietary Only (Graphics Cards): Pascal RTX 10.. Volta Titan Maxwell GeForce GTX9.. Kepler Geforce GTX7.. and GTX6.. Fermi GeForce GTX5.. and GTX4.. Tesla GeForce GT3.. and GT2.. For graphics cards that can use the open-source driver, performance should be fine. For those that can't use it -- it doesn't matter anyway... -- David C. Rankin, J.D.,P.E.
19.09.2024 23:52, Michael Hamilton wrote:
3) New OpenSUSE rpms for the from-Nvidia open-driver plus what ever else is needed (which is still a little unclear - probably need to try it and deal with any issues).
You need the same user space as with traditional proprietary driver. It can be installed from NVIDIA .run file skipping kernel part. User space became much more update-friendly, to my best knowledge it no more replaces system libraries but is installed side by side. NVIDIA says that 560 open driver should be on par with traditional driver. The plans are to only support open driver going forward, at least for new models. Also, being formally "open" allows NVIDIA drivers to use more kernel APIs than before, which will likely result in better drivers in the future.
Hello, Thanks for clear explanation, Andrei. I have a question. In the Message; Subject : Re: Nvidia: turing+ new open driver rpms versus? Message-ID : <CAA91j0XmuYqDMn=QV0cnbw3Hn=5XegDvsBiA_GwUcHSMRsinMQ@mail.gmail.com> Date & Time: Thu, 19 Sep 2024 10:29:02 +0300 [AB] == Andrei Borzenkov <arvidjaar@gmail.com> has written: AB> On Thu, Sep 19, 2024 at 12:16 AM Michael Hamilton <michael@actrix.gen.nz> wrote: [...] AB> "Open" driver is not really more "open" than previous drivers. It AB> simply pushed the closed source part into firmware (which is the AB> reason why it is not supported for older cards - this driver is AB> useless without matching firmware which is provided only for new AB> models). And it lifted redistribution restrictions. [...] But, this is about the start of open-gpu, right? In other words, the fact that nvidia went completely open in July is a different story, right? I understood that the completely opening in July was about opening up the development itself, like the kernel development, but am I wrong? What I fundamentally don't understand is what the difference is between the source code for proprietary driver kernel modules and the source code for open-gpu. Why is it necessary to make them different? Best Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "During testing, Sakana found that its system began unexpectedly attempting to modify its own experiment code to extend the time it had to work on a problem." -- Research AI model unexpectedly attempts to modify its own code to extend runtime (ars TECHNICA) --
participants (4)
-
Andrei Borzenkov -
David C. Rankin -
Masaru Nomiya -
Michael Hamilton