4 ms·

Nvidia’s position seems to be that Linux needs to grow up and provide a stable driver API and ABI, and stop claiming anyone is a “bad actor” just because they d

Nvidia’s position seems to be that Linux needs to grow up and provide a stable driver API and ABI, and stop claiming anyone is a “bad actor” just because they don’t want to put their drivers under the GPL, make them part of the Linux kernel source tree, and essentially give up control of them. I’m honestly surprised the major distros haven’t gotten together to do this, in a shared fork if necessary. It’s outright embarrassing that this attitude still infects the Linux project.

shmerl 8y ago
What's embarrassing, is Nvidia's inability to provide upstream driver themselves, or to allow nouveau which already exists, use all their hardware features[1]. Linux kernel has quality rules, and if Nvidia can't follow them, it's their problem. It should not be in the interest of Linux maintainers to accept any junk upstream. 1. https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-nvidia-linux-nouveau/998310-nouveau-persevered-in-2017-for-open-source-nvidia-but-2018-could-be-much-better?p=998316#post998316 https://www.phoronix.com/forums/forum/linux-graphics-x-org-d...
- eschaton 8y ago
  And Nvidia has rules around access to its intellectual property. If Linux can’t follow them, Linux doesn’t get Nvidia’s code.
  - shmerl 8y ago
    Nvidia can sit on their property all they want, and lose market share in result, while other GPU makers have no problem making open upstream drivers. That actually benefits everyone but Nvidia ;) In practice though, that's likely the least of their reasons not to open their driver. More probably, they just don't want to expose some embarrassing code mess or non compliant cheating in their graphics stack, as well as don't want to allow anyone decide how to use their GPUs without Nvidia dictating them. If they control accelerated driver - they can dictate and demand more money in some use cases from those who want a more permissive driver. All of that has very little to do with intellectual property and more with market manipulation.
ddevault 8y ago
This is perhaps the most important feature of Linux, and far from a problem. Nvidia needs to get over itself and put its driver in the upstream tree. AMD did it and it's been a huge success. Linux's unstable internal API and GPL'd nature has been a huge driving force behind the availablity of open source drivers. Hell, many distros with stable driver APIs like *BSD have Linux to thank for many of the drivers they have, because without Linux there never would have been open source drivers or specs in the first place. None of the distros are going to get behind your fork because all agree with Linux on this matter, rightfully so. Nvidia can fuck off with their proprietary crap, Linux has no intention of bending over for that garbage.
- janoc 8y ago
  Sorry, that's bollocks. AMD did not put their driver into the upstream tree! What is in that tree is the open source driver developed by volunteers, based on ATI specs. ATI/AMD still has their own proprietary, closed blob driver that is not in the tree - and which actually runs quite a bit faster than the open source one.
  - ddevault 8y ago
    $ cd ~/sources/linux/drivers/gpu/ $ git log . | grep "@amd.com" | wc -l 42418 $ cd ~/sources/mesa $ git log | grep "@amd.com" | wc -l 4817 >ATI/AMD still has their own proprietary, closed blob driver that is not in the tree - and which actually runs quite a bit faster than the open source one. It doesn't run faster, this is nonsense. I've personally met the AMDGPU driver developers and if you ask them they'll even tell you that basically no one needs AMDGPU Pro. It's not faster, this is bollucks.
    - microcolonel 8y ago
      To add to this, AFAIK there are two main reasons why they still have AMDGPU-PRO: it has the more compatible, better-performing OpenCL implementation (which you can run alongside Mesa, actually), and until recently it supported slightly different display features, and more compatibility profile functionality. As Mesa becomes more compatible with bizarre certified industrial applications and, and the upstream AMDGPU kernel driver enables more exotic display features, I suspect AMD might choose to just maintain Mesa for these GPUs.
microcolonel 8y ago
> Nvidia’s position seems to be that Linux needs to grow up and provide a stable driver API and ABI, and stop claiming anyone is a “bad actor” just because they don’t want to put their drivers under the GPL, make them part of the Linux kernel source tree, and essentially give up control of them. I’m honestly surprised the major distros haven’t gotten together to do this, in a shared fork if necessary. It’s outright embarrassing that this attitude still infects the Linux project. I don't find it embarrassing that Linux maintainers prefer to leave every line of code in the kernel up for improvement, rather than desperately replicating known misbehaviours until a new five-to-ten year waterfall release comes. AMD's drivers work great, I buy AMD because instead of getting upset that they don't get to call all the shots, they put in the work and make peace with the establishment. NVIDIA would rather throw a pathetic, childish tantrum and blame everyone else for their arrogant position which leaves their customers begging maintainers to comply and work on their own time to enrich NVIDIA.
- ciupicri 8y ago
  How does video playback acceleration work on AMD cards with VLC or mpv?
  - microcolonel 8y ago
    > How does video playback acceleration work on AMD cards with VLC or mpv? It works great in MPV, I don't use VLC so I can't comment on that. The major problem right now with video acceleration is that Chromium (or maybe it's my distribution's build of it) seems to have enabled VA-API acceleration, but the Mesa VA-API state tracker (I think, I'd be glad to be corrected on this) I think is missing the API that would tell Chromium which pixel format to expect the decoder's output in; so Chromium assumes that it'll be in a certain format which it turns out not to be, and this leads to hideous corruption. I suspect that if and when there is any significant amount of HEVC content on the web, this issue will probably be resolved by then. For now there are configuration parameters which can be used to work around the issue by disabling the pixel format Chromium defaults to, and do so just in chromium, but a fix (which will be in Mesa 19) is required for that configuration to work with Chromium (due to its unusual process naming). I have used the MJPEG UVD decoder through ffmpeg to decode my 4K webcam's output and it works a treat.

shmerl 8y ago

What's embarrassing, is Nvidia's inability to provide upstream driver themselves, or to allow nouveau which already exists, use all their hardware features[1]. Linux kernel has quality rules, and if Nvidia can't follow them, it's their problem. It should not be in the interest of Linux maintainers to accept any junk upstream. 1. https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-nvidia-linux-nouveau/998310-nouveau-persevered-in-2017-for-open-source-nvidia-but-2018-could-be-much-better?p=998316#post998316 https://www.phoronix.com/forums/forum/linux-graphics-x-org-d...

eschaton 8y ago
And Nvidia has rules around access to its intellectual property. If Linux can’t follow them, Linux doesn’t get Nvidia’s code.
- shmerl 8y ago
  Nvidia can sit on their property all they want, and lose market share in result, while other GPU makers have no problem making open upstream drivers. That actually benefits everyone but Nvidia ;) In practice though, that's likely the least of their reasons not to open their driver. More probably, they just don't want to expose some embarrassing code mess or non compliant cheating in their graphics stack, as well as don't want to allow anyone decide how to use their GPUs without Nvidia dictating them. If they control accelerated driver - they can dictate and demand more money in some use cases from those who want a more permissive driver. All of that has very little to do with intellectual property and more with market manipulation.

ddevault 8y ago

This is perhaps the most important feature of Linux, and far from a problem. Nvidia needs to get over itself and put its driver in the upstream tree. AMD did it and it's been a huge success. Linux's unstable internal API and GPL'd nature has been a huge driving force behind the availablity of open source drivers. Hell, many distros with stable driver APIs like *BSD have Linux to thank for many of the drivers they have, because without Linux there never would have been open source drivers or specs in the first place. None of the distros are going to get behind your fork because all agree with Linux on this matter, rightfully so. Nvidia can fuck off with their proprietary crap, Linux has no intention of bending over for that garbage.

janoc 8y ago
Sorry, that's bollocks. AMD did not put their driver into the upstream tree! What is in that tree is the open source driver developed by volunteers, based on ATI specs. ATI/AMD still has their own proprietary, closed blob driver that is not in the tree - and which actually runs quite a bit faster than the open source one.
- ddevault 8y ago
  $ cd ~/sources/linux/drivers/gpu/ $ git log . | grep "@amd.com" | wc -l 42418 $ cd ~/sources/mesa $ git log | grep "@amd.com" | wc -l 4817 >ATI/AMD still has their own proprietary, closed blob driver that is not in the tree - and which actually runs quite a bit faster than the open source one. It doesn't run faster, this is nonsense. I've personally met the AMDGPU driver developers and if you ask them they'll even tell you that basically no one needs AMDGPU Pro. It's not faster, this is bollucks.
  - microcolonel 8y ago
    To add to this, AFAIK there are two main reasons why they still have AMDGPU-PRO: it has the more compatible, better-performing OpenCL implementation (which you can run alongside Mesa, actually), and until recently it supported slightly different display features, and more compatibility profile functionality. As Mesa becomes more compatible with bizarre certified industrial applications and, and the upstream AMDGPU kernel driver enables more exotic display features, I suspect AMD might choose to just maintain Mesa for these GPUs.

microcolonel 8y ago

> Nvidia’s position seems to be that Linux needs to grow up and provide a stable driver API and ABI, and stop claiming anyone is a “bad actor” just because they don’t want to put their drivers under the GPL, make them part of the Linux kernel source tree, and essentially give up control of them. I’m honestly surprised the major distros haven’t gotten together to do this, in a shared fork if necessary. It’s outright embarrassing that this attitude still infects the Linux project. I don't find it embarrassing that Linux maintainers prefer to leave every line of code in the kernel up for improvement, rather than desperately replicating known misbehaviours until a new five-to-ten year waterfall release comes. AMD's drivers work great, I buy AMD because instead of getting upset that they don't get to call all the shots, they put in the work and make peace with the establishment. NVIDIA would rather throw a pathetic, childish tantrum and blame everyone else for their arrogant position which leaves their customers begging maintainers to comply and work on their own time to enrich NVIDIA.

ciupicri 8y ago
How does video playback acceleration work on AMD cards with VLC or mpv?
- microcolonel 8y ago
  > How does video playback acceleration work on AMD cards with VLC or mpv? It works great in MPV, I don't use VLC so I can't comment on that. The major problem right now with video acceleration is that Chromium (or maybe it's my distribution's build of it) seems to have enabled VA-API acceleration, but the Mesa VA-API state tracker (I think, I'd be glad to be corrected on this) I think is missing the API that would tell Chromium which pixel format to expect the decoder's output in; so Chromium assumes that it'll be in a certain format which it turns out not to be, and this leads to hideous corruption. I suspect that if and when there is any significant amount of HEVC content on the web, this issue will probably be resolved by then. For now there are configuration parameters which can be used to work around the issue by disabling the pixel format Chromium defaults to, and do so just in chromium, but a fix (which will be in Mesa 19) is required for that configuration to work with Chromium (due to its unusual process naming). I have used the MJPEG UVD decoder through ffmpeg to decode my 4K webcam's output and it works a treat.