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

381–390 of 415 posts

Re: Nvidia releases open-source GPU kernel modules

#381

Post by anthk »

native_samples wrote: post #326
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…

You mean, like Intel GPU drivers with just the libre free-as-in-freedom kernel and MESA? Blender? Krita? Cinelerra-CV? Darktable? ImageMagick? FFMPEG? KVM/Qemu? Most programming languages and frameworks? Clang/LLVM?

WTF are you talking about?

If any, science today it's made thanks to FLOSS software, propietary software it's the exception. And the trend it looking worse for propietary environments.

Money will come from support and integration, not for the software.

A complex, scientific related reproducible ad-hoc environment for Guix may cost a little more on a single PC than a a propietary OS license and setting up the rest for yourself, but you will be able to replicate that setup everywhere and forever and on a guaranteed basis that once your paper/experiment it's replicated, yo get the same environment no matter where and how. That's the difference.

Re: Nvidia releases open-source GPU kernel modules

#382

Post by olliej »

mjg59 wrote: post #53

1) This is unambiguously Good News 2) This is not upstreamable in its current form (nvidia admit this in their press release) 3) In an ideal world, nouveau (the open source driver for nvidia hardware) would be able to target this kernel code. Right now though there's no commitment for any sort of stable userland ABI, and that makes that difficult (moving to a new driver version may break interfaces that nouveau uses)…

(1) No, it's unambiguously "meh" news

Nvidia have merely moved their giant closed source drivers into "firmware" - they now have a 34Mb firmware image for the GPU, that would be more correctly called the real drivers. They have essentially created an open source GPL forwarding layer so that the non-GPL firmware gets access to GPL-only kernel APIs, that's it.

Re: Nvidia releases open-source GPU kernel modules

#384

Post by melvyn2 »

salawat wrote: post #143
kaladin-jasnah wrote: post #118

Earlier quoted context omitted.

This new driver targets GPUs with FALCON, and nouveau will be able to control it, as FALCON is GSP ( https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-R... ).

They're likely changing it because security researchers pwned FALCON. There is a way to leak the hash against which High Security mode FALCON compares the microcode for signature validation. So hopefully you'll forgive me if I maintain my skepticism over this being anything but Nvidia iterating to close a massive security defeat by redesigning their FALCON controller to mitigate the thorough pwning that's been achiev…

Reading the hash doesn’t sound like much of a flaw to me, could you elaborate or provide a link?

Re: Nvidia releases open-source GPU kernel modules

#385

Post by dralley »

urthor wrote: post #319
jjoonathan wrote: post #218

Earlier quoted context omitted.

It's fair to extrapolate because their strategic decisions will be based on extrapolations. NVIDIA had to overclock and hustle the current generation of cards and it's looking even worse for the next generation. Software was a moat when AMD was heavily resource constrained, but now they can afford the headcount to give chase. Between the chip shortage and crypto, there was plenty of noise on top of fundamentals, but…

NVIDIA is well, well ahead of AMD. NVIDIA's cards were faster than AMD's with the huge gap in transistor density that was the Samsung fab. Don't get excited for the AMD graphics division up in Canada.

>NVIDIA's cards were faster than AMD's with the huge gap in transistor density that was the Samsung fab.

They are roughly at par. AMD does better at lower resolutions because of their cache setup.

With the refreshed cards, AMD is slightly ahead.

Re: Nvidia releases open-source GPU kernel modules

#386

Post by RussianCow »

hoistbypetard wrote: post #354
adrian_b wrote: post #347

Earlier quoted context omitted.

All closed-source kernel modules and a part of the firmware blobs (those that are for devices which have communication interfaces, especially wireless interfaces, and which may access directly the memory space without being blocked by a MMU under the control of the OS kernel) are major security risks, because they might be controlled by an attacker, with no means of detection by the user. With a security-strengthened…

> With a security-strengthened operating system, or with a VM/container/sandbox, it is possible to ensure that any opaque user-space program is no security risk. In theory this may be true. But the particular opaque user-space program is talking to a driver authored by the same team. That driver is talking to hardware that has access to all of the memory in your computer. The odds are high that a userspace program ta…

I'm not sure why you were downvoted; this is 100% correct. Open source makes adding backdoors much more difficult, but I imagine GPU driver code is so complex that there are likely security flaws that even the entire open source community wouldn't catch. Yes, an open source driver is an improvement in many ways, but it certainly doesn't solve these problems because the attack surface is so gigantic.

Re: Nvidia releases open-source GPU kernel modules

#387

Post by pabs3 »

dannymi wrote: post #339
ZiiS wrote: post #310

Earlier quoted context omitted.

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

The carl firmware at https://github.com/chunkeey/carl9170fw should put that argument to rest. That is Wifi firmware source code for the Wifi I currently use. Easily changed likely means there's a physical knob somewhere that you could accidentially poke as a layperson. Not that you get a three year CS education, figure out how your distribution packages dependencies, install the correct embedded toolchain (good luck)…

Please note that the Debian firmware-linux-free package does not build carl9170fw from source. There is proper packaging (source package called carl9170fw, binary package will be firmware-carl9170) being worked on but it isn't completed yet:

https://bugs.debian.org/994625

Re: Nvidia releases open-source GPU kernel modules

#388

Post by dwaite »

adrian_b wrote: post #347
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…

All closed-source kernel modules and a part of the firmware blobs (those that are for devices which have communication interfaces, especially wireless interfaces, and which may access directly the memory space without being blocked by a MMU under the control of the OS kernel) are major security risks, because they might be controlled by an attacker, with no means of detection by the user. With a security-strengthened…

> With a security-strengthened operating system, or with a VM/container/sandbox, it is possible to ensure that any opaque user-space program is no security risk.

This is absolutely not true.

It is possible to restrict an opaque user-space program to the minimal set of permissions it requires.

In this particular case, the program needs to manipulate system hardware in undocumented ways, via vendor code which is extending the kernel.

Re: Nvidia releases open-source GPU kernel modules

#389

Post by chx »

chx wrote: post #167
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…

> I couldn't find any single GPU able to drive 3840x1600 without a fan > I don't game Let me help. https://www.ebay.com/itm/194948432276 that's a full DP 1.2 port in there https://www.techpowerup.com/gpu-specs/sapphire-ultimate-r7-2... so it'll drive 3840 x 1600 up to 108 Hz even without custom mode shenanigans.

Ps. I didn't know Newegg merchants are selling used stuff but here we are: https://www.newegg.com/sapphire-radeon-hd-7750-11202-03-40g/...

Re: Nvidia releases open-source GPU kernel modules

#390

Post by urthor »

dralley wrote: post #385
urthor wrote: post #319

Earlier quoted context omitted.

NVIDIA is well, well ahead of AMD. NVIDIA's cards were faster than AMD's with the huge gap in transistor density that was the Samsung fab. Don't get excited for the AMD graphics division up in Canada.

>NVIDIA's cards were faster than AMD's with the huge gap in transistor density that was the Samsung fab. They are roughly at par. AMD does better at lower resolutions because of their cache setup. With the refreshed cards, AMD is slightly ahead.

Keep in mind that is at a particular price point.

NVIDIA's top of the range chip is ahead of AMD's, and the 3080's SKU is at a lower binning point on the bell curve than the 6950's.

Hence NVIDIA would be able to maintain a performance per watt crown at the 6950's price point if it sold its highest bins cheaper.

Given the gap in transistor density, that is an exorbitant architectural delta.

Post reply on HN