Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nvidia releases open-source GPU kernel modules

developer.nvidia.com

Post reply on HN
Print view View original

321–330 of 415 posts

Re: Nvidia releases open-source GPU kernel modules

#321

Post by snvzz »

my123 wrote: post #289
kaladin-jasnah wrote: post #255

Earlier quoted context omitted.

> pay for enterprise vGPU For AMD the driver is difficult to find and poorly documented (and only available on ESXi unlike NVIDIA vGPU support for Xen, Hyper-V, KVM, Nutanix, and ESXi, etc.). At least the guest drivers don't have licensing issues unlike with NVIDIA IIUC.

And very few AMD GPUs even support it... (and good luck finding a remotely recent AMD GIM driver)

Plus the quality of the overall experience. And I understand NVIDIA is even worse re: GPU virtualization.

The end result is that it is unusable in practice. Very difficult and restricted to few CPUs/GPUs and very specific software chain.

Otherwise, it'd be open source, universally available and trivial to use.

The good news is that I understand this support is actually good on the Intel side, and Intel has promised that they will actually release competitive GPUs soon. Should this truly be the case, it will automatically make Intel the go-to for GPU virtualization, and might help motivate NVIDIA/AMD to stop segmenting re: GPU virtualization, ending this shitty situation.

Re: Nvidia releases open-source GPU kernel modules

#322

Post by snvzz »

KronisLV wrote: post #134
TacticalCoder wrote: post #104

Earlier quoted context omitted.

> I used and recommended ATI and INTEL for most of the people I could for a long time because of this. Same here but recently I somehow got a 3700X and there's no integrated GPU so I had to look for a GPU. I like my PC not just quiet but nearly silent, so a GPU with a fan was a big no-no. I couldn't find any single GPU able to drive 3840x1600 without a fan... Except for a NVidia one. Of course the proprietary Linux d…

If you want to stick with AMD and don't want to swap out the motherboard, then you'd probably just need to get an AMD CPU with on board graphics. The actual name of the CPU should help you find one that would work in that regard, for example, see this link which explains the naming suffixes: https://www.androidauthority.com/amd-cpu-guide-1222438/ In particular: X - Higher clocked desktop processor (what you got) G -…

I heard the rumor that, starting with Zen4, AMD will include an embedded GPU in each and every CPU using the new socket.

This will end this situation, and give a nice bump to AMD's market share in e.g. Valve's steam client statistics.

These days, the performance of the embedded GPUs is already pretty usable, even allowing for running heavy videogames on lowish settings. They've been increasing the performance considerably (30-60%) on each generation for several generations.

Re: Nvidia releases open-source GPU kernel modules

#323

Post by notpushkin »

ZiiS wrote: post #310
Out_of_Characte wrote: post #302

Earlier quoted context omitted.

No law or regulation that I know of specifies binary format.

The regulations specify they should not be easily changed. Distributing source makes it easier to change.

Unless you provide source code that builds reproducibly, and a detached signature that your hardware checks.

Re: Nvidia releases open-source GPU kernel modules

#324

Post by native_samples »

greggsy wrote: post #266
mort96 wrote: post #238

Earlier quoted context omitted.

Sadly, it's also not the actual GPU driver, just the kernel part; you still need their massive closed blob in userspace. Almost had me excited there for a moment.

Has any rationale been provided around the blob being closed? Is it licensed, or simply too too complicated to pick apart? Graphics is a complicated field, but the techniques could still be patented - surely their market status isn’t dependent on trade secrets?

Yes. Drivers represent enormous amounts of work and large parts of the overall development/IP effort in a GPU. Asking why nVidia don't open source it is like asking why they don't just open source the entire GPU. Answer: because then they'd have a much smaller and less valuable business, if they even had a business at all.

Re: Nvidia releases open-source GPU kernel modules

#325

Post by mort96 »

pjmlp wrote: post #305
hda2 wrote: post #301

Earlier quoted context omitted.

This small tirade of yours is arguing against a strawman. GP is likely referring to the userspace component of nvidia's driver, not the actual blob that gets loaded onto the gpu. If it is indeed true that you need to run proprietary userland code, then this open-source release is nothing but a way to circumvent the GPL issues that lead to nvidia's driver partially breaking in Linux 5.??. While not ideal, I like many…

Interesting, so they can do whatever they want, provided it runs as firmware.

My view is that nvidia's hardware can work however they want it to. FOSS firmware would be cool in the same way that FOSS hardware would be cool, but it's not something I expect. I also don't care that much whether the proprietary firmware is stored on on-board flash and programmed from the factory or if it's uploaded by my OS when the driver is loaded.

But I would prefer if the code I run in userspace or kernelspace is FOSS.

Re: Nvidia releases open-source GPU kernel modules

#326

Post by native_samples »

Humphrey wrote: post #265

I'm confused! Why would Nvidia want to keep any of this closed source. Surely they make money when people buy graphics cards, and having open source out-of-the-box graphics support in Linux would mean they would sell more graphics cards?

Drivers are a large part of the development costs of a GPU, just like how an operating system is a large part of the development cost of a general computer.

If nVidia open sourced all their drivers tomorrow the risk of some cheap Chinese shop making clones of their hardware and re-targeting the nVidia drivers to get lots of the features would be very high. It'd significantly reduce the value of what they'd built (to them).

Really, I don't get why so many Linux users ask questions like this. Most software is proprietary because it costs money to develop. This site we're talking on isn't open source. Windows isn't. macOS / iOS isn't. Games generally aren't. Google isn't. Azure/Bing aren't. Open source is the exception, not the norm.

Re: Nvidia releases open-source GPU kernel modules

#328

Post by lolcat_cowsay »

pixelmonkey wrote: post #75

> In this open-source release, support for GeForce and Workstation GPUs is alpha quality. GeForce and Workstation users can use this driver on Turing and NVIDIA Ampere architecture GPUs to run Linux desktops and use features such as multiple displays, G-SYNC, and NVIDIA RTX ray tracing in Vulkan and NVIDIA OptiX. Users can opt in using the kernel module parameter NVreg_EnableUnsupportedGpus as highlighted in the docu…

What about GTX 16xx users? I have a GTX 1650 which is based on Turing but doesn't have the new NVENC encoder, I wonder if the new OSS driver will support this GPU, if it has that RISCV chip that everyone's talking about.

Re: Nvidia releases open-source GPU kernel modules

#330

Post by loganberries »

MuffinFlavored wrote: post #231
Tuna-Fish wrote: post #214

Earlier quoted context omitted.

> What does "upstreamable" mean in this context? Is this good or bad? "Upstream" is the kernel source tree maintained by Linus (and friends). As Linux is open source, anyone can fork it for any reason, and a lot of people do. However, Linus still maintains the common base that people use to build on top of. "Upstreaming" is the process of getting your code included in these official releases. It's significant because…

> upstreaming it is considered extremely good are we assuming some sort of automatic testing will be added? unit testing? integration testing? sounds super hard to do for a driver. but... high quality code just being merged into master can still have bugs introduced in the future on accident, right? it's tests that usually makes it safe?

The kernel has bugs, all software has bugs.

But there are massive massive test suites run by hundreds of companies on linux-next. If you email off a stack of patches that breaks something, chances are you'll get emails back telling you which patch had the breaking change in.

Post reply on HN