9 ms·

"nVidia's history of not playing nicely with others": can you elaborate or mention an example? That aspect has escaped me thus far.

foota 6y ago
CUDA is probably the biggest thing here, also I don't think they open source much.
- rl3 6y ago
  >... also I don't think they open source much. You could say that: https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html
- shaklee3 6y ago
  This is increasingly becoming not true. See cutlass and the new release of cufftdx.
  - ris 6y ago
    These are both things that are unlikely to ever be able to run on anything other than nvidia hardware. It's hardly a mark in their favour over abusive lock-in practices.
    - shaklee3 6y ago
      Well, of course. They're written in cuda. Why would Nvidia try to write it in a language like opencl that even AMD is moving away from, and instead making fft/blas library calls? At least the source code is there if you wanted to port it.
      - ris 6y ago
        I think it's very clear that I wasn't commenting on what framework they choose to write their projects in, and you're rather deliberately missing my point.
        shaklee3 6y ago
        > These are both things that are unlikely to ever be able to run on anything other than nvidia hardware. I think it's very clear that the framework was important here. Because you were pointing out that they don't open source much, I pointed out that they do, then you nitpicked by saying it's cuda.
- tasty_freeze 6y ago
  I had no idea, so I just searched and found there are 201 repositories in their github: https://github.com/NVIDIA https://github.com/NVIDIA
  - asddubs 6y ago
    that's a pretty meaningless number without further context
    - tasty_freeze 6y ago
      The person I replied to said nvidia doesn't contribute much to open source. I pointed at their github repositories. If you care about the context, it is there, and there is no risk of me summarizing it unfairly.
      - andoriyu 6y ago
        Having some of your code in github isn't contributing to open source.
numakerg 6y ago
I recall the GeForce Partner Program raised some controversy, although I couldn't say whether or it was bad or good or why. There's also the issue with them refusing to open source Linux drivers. Supposedly this is because they throttle workstation GPUs to create a market for higher-end versions while reducing the manufacturing diversity, but I haven't heard a definitive source for this.
- bonzini 6y ago
  > they throttle workstation GPUs Not sure about this, but they definitely prevent the loading of drivers for GeForce cards if they detect a hypervisor (Quadro cards work). Nvidia claims that it's a bug, and that they're not fixing it only because GeForce cards are not sold to be run in virtual machines. At the very least it's a dubious claim since for a short time there was an arms race as workarounds were figured out and the next version of the driver would detect them... Of course it's market segmentation by obscurity so it only lasted a few weeks and it's trivial to work around, but still it's quite shady since there's absolutely no ill effect from the work around.
  - throwaway2048 6y ago
    It is absolutely not a bug, Disassembly of NVIDIA drivers shows that its looking for specific KVM signatures, and if you modify those signatures, magically it starts working again...
    - segfaultbuserr 6y ago
      Removing KVM signature is now the standard solution. But there's still a working driver patch to remove the virtualization check, it's available at here. * sk1080/nvidia-kvm-patcher: Fixes "Bug" in Nvidia Driver preventing "Unsupported Configurations" from being used on KVM https://github.com/sk1080/nvidia-kvm-patcher https://github.com/sk1080/nvidia-kvm-patcher
    - bonzini 6y ago
      Of course it's not a bug. :-)
AmericanChopper 6y ago
This sentiment comes entirely from their lack of open source drivers for Linux. It became pretty much a meme after a rant that Linus had about them in 2012.
9935c101ab17a66 6y ago
There was the apple gpu fiasco. Apple laptop GPUs were failing at an extraordinary rate in 2010-2011, and Apple were getting harangued in the media about it (which was justified). Apple eventually announced a program to cover replacement of the GPUs, but it was very delayed. I'm 100% convinced the delay was caused by Nvidia refusing to accept responsibility. When the program was released, in order to have the repair completed at no cost, your computer had to fail a very specific graphics diagnostic, and the failure would be linked to your serial number in Apple's repair CRM. At the time, no other apple repair program had this requirement — Don't get me wrong, it makes sense to use diagnostics to verify hardware issues, but they aren't the only tool you can use. I'm convinced Nvidia only would reimburse apple for computers that had a recorded failure of this specific test. Since 2014, apple has almost exclusively used AMD graphics cards in computers that do have discrete GPUs, and I don't think it's unreasonable to suggest this was motivated with their terrible experience with Nvidia. (I'm aware I'm not really backing this up with evidence, but I think the publicly available facts about the whole situation support this narrative)
- karlshea 6y ago
  That situation was also following Nvidia spoiling one of Steve Jobs' announcements even further back, so there was already a bit of bad blood.
  - 9935c101ab17a66 6y ago
    Good point, I had forgotten about that.
    - andoriyu 6y ago
      Which one was that?
- scarface74 6y ago
  Don't get me wrong, it makes sense to use diagnostics to verify hardware issues, but they aren't the only tool you can use. I'm convinced Nvidia only would reimburse apple for computers that had a recorded failure of this specific test. In 2010, Apple wasn’t exactly a beleaguered company. It wasn’t like NVidia not reimbursing Apple would break the bank. Apple should have repaired it just to protect its reputation. Jobs himself was famous for saying to high level employees that at a certain level of authority, you don’t get to make excuses.
awalton 6y ago
Google it maybe? Here's one example thread to pull at: why did Apple stop buying nVidia GPUs across their entire hardware line? EGLStreams is a recent pain in the ass. nVidia's infanticide of OpenCL with CUDA being another painful reminder that nVidia doesn't care about your software needs, just their own. It's really not hard to find a company that nVidia's pissed off with its dealings.
- rrss 6y ago
  If there was an infanticide of OpenCL, Apple (the original creator of OpenCL) was at least as responsible as Nvidia.
johnklos 6y ago
NVIDIA can compete based on the superior performance of their products, but that's not enough. They try to attempt lock-in by encouraging software writers to use CUDA and not use OpenCL. In many projects that support both, OpenCL and CUDA often give similar performance, and in some, OpenCL is faster than CUDA. So CUDA isn't about getting more performance - it's about excluding everything non-NVIDIA. I suspect that NVIDIA's gameplaying is what led to Apple deciding to not use NVIDIA in any Macs for the last several years.
- pjmlp 6y ago
  They don't need to do any lock-in when the choice is between plain old C with printf like debugging, and a set of programming languages able to target PTX, with out of the box support for C, C++, Fortran and several managed languages, and nice graphical debugging tools. C++ support only came to OpenCL after it was clear to Khronos that it was time to move beyond C only vision of the world, yet almost no one bothered to implement OpenCL 2.x, which is why OpenCL 3.0 is basically OpenCL 1.2 to make all those OEM compliant, and SYCL is now moving into an backend agnostic C++ stack. So the competition did not move a finger to make OpenCL eco-system beat CUDA tooling, Google did not cared one second to make OpenCL available on Android instead pushed for their own Renderscript C99 dialect, but it is easy to blame NVidia when competition isn't up to their stuff. Just like Apple, after creating OpenCL and offering it to Khronos, moved away from their own creation after disputes on how OpenCL roadmap should be managed. Ironically, just like with CUDA, Metal Compute happens to be multiple language aware and having a modern API.
  - cpgxiii 6y ago
    The problem with OpenCL, just like OpenGL, is that it relies on vendor support for essentially the full stack. That means if a single vendor doesn't support the feature, it's basically impossible to ship any code that uses that feature to arbitrary users. Nvidia lagging behind in its support for OpenCL 2.x was probably not explicitly stated as "let's sabotage this competing open standard by dragging our feet" but that was the result. AMD and Intel both put together OpenCL 2.x support, so clearly Nvidia could have finished their incomplete support but didn't. The fundamental failing Khronos made was repeating the GLSL mistake and not specifying a compiled IR that would decouple OpenCL kernel code from program execution. This was clearly known to be a mistake at the time, given ample evidence from CUDA and HLSL that an IR was possible and could greatly improve the developer experience.
thayne 6y ago
nVidia has a very long history of not getting along with Linux.
- disgruntledphd2 6y ago
  And now, hilariously enough, they have ended up with a lot of their growth coming from Linux-based systems. To be fair, I recently bought a new Thinkpad, and with Ubuntu 20.04 and Nvidia CUDA just worked, with absolutely no tuning (I didn't even need to set LD_LIBRARY_PATH, which I found pretty odd). So things seem to be improving, because there's money in it for Nvidia.
  - thayne 6y ago
    The Nouveau drivers have a throttled clock speed due to firmware signatures. And the proprietary drivers are complete mess on wayland, where most compositors and other GPU drivers use GBM, but Nvidia did their own thing and used EGLStreams. Maybe someday in the future the situation will improve, but historically, it hasn't been good.
AsyncAwait 6y ago
They have made it even more difficult for open-source to be able to reverse engineer their drivers with signed firmware blobs, push their own solution on Wayland, (ELStreams), over everyone else adopting GBM etc. - in short they refuse to cooperate in an official capacity. Both Intel and AMD do have an official FLOSS Linux driver and regularly work with the wider community.

foota 6y ago

CUDA is probably the biggest thing here, also I don't think they open source much.

rl3 6y ago
>... also I don't think they open source much. You could say that: https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html
shaklee3 6y ago
This is increasingly becoming not true. See cutlass and the new release of cufftdx.
- ris 6y ago
  These are both things that are unlikely to ever be able to run on anything other than nvidia hardware. It's hardly a mark in their favour over abusive lock-in practices.
  - shaklee3 6y ago
    Well, of course. They're written in cuda. Why would Nvidia try to write it in a language like opencl that even AMD is moving away from, and instead making fft/blas library calls? At least the source code is there if you wanted to port it.
    - ris 6y ago
      I think it's very clear that I wasn't commenting on what framework they choose to write their projects in, and you're rather deliberately missing my point.
      - shaklee3 6y ago
        > These are both things that are unlikely to ever be able to run on anything other than nvidia hardware. I think it's very clear that the framework was important here. Because you were pointing out that they don't open source much, I pointed out that they do, then you nitpicked by saying it's cuda.
tasty_freeze 6y ago
I had no idea, so I just searched and found there are 201 repositories in their github: https://github.com/NVIDIA https://github.com/NVIDIA
- asddubs 6y ago
  that's a pretty meaningless number without further context
  - tasty_freeze 6y ago
    The person I replied to said nvidia doesn't contribute much to open source. I pointed at their github repositories. If you care about the context, it is there, and there is no risk of me summarizing it unfairly.
    - andoriyu 6y ago
      Having some of your code in github isn't contributing to open source.

numakerg 6y ago

I recall the GeForce Partner Program raised some controversy, although I couldn't say whether or it was bad or good or why. There's also the issue with them refusing to open source Linux drivers. Supposedly this is because they throttle workstation GPUs to create a market for higher-end versions while reducing the manufacturing diversity, but I haven't heard a definitive source for this.

bonzini 6y ago
> they throttle workstation GPUs Not sure about this, but they definitely prevent the loading of drivers for GeForce cards if they detect a hypervisor (Quadro cards work). Nvidia claims that it's a bug, and that they're not fixing it only because GeForce cards are not sold to be run in virtual machines. At the very least it's a dubious claim since for a short time there was an arms race as workarounds were figured out and the next version of the driver would detect them... Of course it's market segmentation by obscurity so it only lasted a few weeks and it's trivial to work around, but still it's quite shady since there's absolutely no ill effect from the work around.
- throwaway2048 6y ago
  It is absolutely not a bug, Disassembly of NVIDIA drivers shows that its looking for specific KVM signatures, and if you modify those signatures, magically it starts working again...
  - segfaultbuserr 6y ago
    Removing KVM signature is now the standard solution. But there's still a working driver patch to remove the virtualization check, it's available at here. * sk1080/nvidia-kvm-patcher: Fixes "Bug" in Nvidia Driver preventing "Unsupported Configurations" from being used on KVM https://github.com/sk1080/nvidia-kvm-patcher https://github.com/sk1080/nvidia-kvm-patcher
  - bonzini 6y ago
    Of course it's not a bug. :-)

AmericanChopper 6y ago

This sentiment comes entirely from their lack of open source drivers for Linux. It became pretty much a meme after a rant that Linus had about them in 2012.

9935c101ab17a66 6y ago

There was the apple gpu fiasco. Apple laptop GPUs were failing at an extraordinary rate in 2010-2011, and Apple were getting harangued in the media about it (which was justified). Apple eventually announced a program to cover replacement of the GPUs, but it was very delayed. I'm 100% convinced the delay was caused by Nvidia refusing to accept responsibility. When the program was released, in order to have the repair completed at no cost, your computer had to fail a very specific graphics diagnostic, and the failure would be linked to your serial number in Apple's repair CRM. At the time, no other apple repair program had this requirement — Don't get me wrong, it makes sense to use diagnostics to verify hardware issues, but they aren't the only tool you can use. I'm convinced Nvidia only would reimburse apple for computers that had a recorded failure of this specific test. Since 2014, apple has almost exclusively used AMD graphics cards in computers that do have discrete GPUs, and I don't think it's unreasonable to suggest this was motivated with their terrible experience with Nvidia. (I'm aware I'm not really backing this up with evidence, but I think the publicly available facts about the whole situation support this narrative)

karlshea 6y ago
That situation was also following Nvidia spoiling one of Steve Jobs' announcements even further back, so there was already a bit of bad blood.
- 9935c101ab17a66 6y ago
  Good point, I had forgotten about that.
  - andoriyu 6y ago
    Which one was that?
scarface74 6y ago
Don't get me wrong, it makes sense to use diagnostics to verify hardware issues, but they aren't the only tool you can use. I'm convinced Nvidia only would reimburse apple for computers that had a recorded failure of this specific test. In 2010, Apple wasn’t exactly a beleaguered company. It wasn’t like NVidia not reimbursing Apple would break the bank. Apple should have repaired it just to protect its reputation. Jobs himself was famous for saying to high level employees that at a certain level of authority, you don’t get to make excuses.

awalton 6y ago

Google it maybe? Here's one example thread to pull at: why did Apple stop buying nVidia GPUs across their entire hardware line? EGLStreams is a recent pain in the ass. nVidia's infanticide of OpenCL with CUDA being another painful reminder that nVidia doesn't care about your software needs, just their own. It's really not hard to find a company that nVidia's pissed off with its dealings.

rrss 6y ago
If there was an infanticide of OpenCL, Apple (the original creator of OpenCL) was at least as responsible as Nvidia.

johnklos 6y ago

NVIDIA can compete based on the superior performance of their products, but that's not enough. They try to attempt lock-in by encouraging software writers to use CUDA and not use OpenCL. In many projects that support both, OpenCL and CUDA often give similar performance, and in some, OpenCL is faster than CUDA. So CUDA isn't about getting more performance - it's about excluding everything non-NVIDIA. I suspect that NVIDIA's gameplaying is what led to Apple deciding to not use NVIDIA in any Macs for the last several years.

pjmlp 6y ago
They don't need to do any lock-in when the choice is between plain old C with printf like debugging, and a set of programming languages able to target PTX, with out of the box support for C, C++, Fortran and several managed languages, and nice graphical debugging tools. C++ support only came to OpenCL after it was clear to Khronos that it was time to move beyond C only vision of the world, yet almost no one bothered to implement OpenCL 2.x, which is why OpenCL 3.0 is basically OpenCL 1.2 to make all those OEM compliant, and SYCL is now moving into an backend agnostic C++ stack. So the competition did not move a finger to make OpenCL eco-system beat CUDA tooling, Google did not cared one second to make OpenCL available on Android instead pushed for their own Renderscript C99 dialect, but it is easy to blame NVidia when competition isn't up to their stuff. Just like Apple, after creating OpenCL and offering it to Khronos, moved away from their own creation after disputes on how OpenCL roadmap should be managed. Ironically, just like with CUDA, Metal Compute happens to be multiple language aware and having a modern API.
- cpgxiii 6y ago
  The problem with OpenCL, just like OpenGL, is that it relies on vendor support for essentially the full stack. That means if a single vendor doesn't support the feature, it's basically impossible to ship any code that uses that feature to arbitrary users. Nvidia lagging behind in its support for OpenCL 2.x was probably not explicitly stated as "let's sabotage this competing open standard by dragging our feet" but that was the result. AMD and Intel both put together OpenCL 2.x support, so clearly Nvidia could have finished their incomplete support but didn't. The fundamental failing Khronos made was repeating the GLSL mistake and not specifying a compiled IR that would decouple OpenCL kernel code from program execution. This was clearly known to be a mistake at the time, given ample evidence from CUDA and HLSL that an IR was possible and could greatly improve the developer experience.

thayne 6y ago

nVidia has a very long history of not getting along with Linux.

disgruntledphd2 6y ago
And now, hilariously enough, they have ended up with a lot of their growth coming from Linux-based systems. To be fair, I recently bought a new Thinkpad, and with Ubuntu 20.04 and Nvidia CUDA just worked, with absolutely no tuning (I didn't even need to set LD_LIBRARY_PATH, which I found pretty odd). So things seem to be improving, because there's money in it for Nvidia.
- thayne 6y ago
  The Nouveau drivers have a throttled clock speed due to firmware signatures. And the proprietary drivers are complete mess on wayland, where most compositors and other GPU drivers use GBM, but Nvidia did their own thing and used EGLStreams. Maybe someday in the future the situation will improve, but historically, it hasn't been good.

AsyncAwait 6y ago

They have made it even more difficult for open-source to be able to reverse engineer their drivers with signed firmware blobs, push their own solution on Wayland, (ELStreams), over everyone else adopting GBM etc. - in short they refuse to cooperate in an official capacity. Both Intel and AMD do have an official FLOSS Linux driver and regularly work with the wider community.