Hacker News Reader

Comment by mud_dauber | Hacker News Reader

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

View on HN

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)

That situation was also following Nvidia spoiling one of Steve Jobs' announcements even further back, so there was already a bit of bad blood.

Good point, I had forgotten about that.

Which one was that?

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.

I do think Apple should have just undertaken the repairs much, much earlier. I do also think that it was incredibly complex situation, and my guess is Apple was flabbergasted that Nvidia initially wouldn't reimburse them for the failed parts. So, internally at apple, my guess is that it was about the 'principle' of the matter. They also probably recognized that if they started replacing the boards of their own volition without an agreement in place, they would never be able to get any compensation from nvidia at all.

Again, I agree with you, apple should have launched the program much, much earlier.

But, I mean, that's besides the point because this isn't a post about how Apple handled these failing GPUs, it's about Nvidia's inability to work with others.

While is was probably a factor, I believe it's also because NVIDIA refuses to let Apple modify their drivers to push their Metal API.

Apple also refuses to sign the kernel extension necessary for NVidia GPU drivers to run. NVidia had made a GPU driver for High Sierra, but literally a version later Apple locked down the kernel so that only signed drivers could be loaded. Anyone who was using Nvidia GPUs through, say, an external GPU box got screwed.

I had really hoped that the external GPU thing would takeoff, and give us a good option for gaming on Macs. I bought the dev kit, and it was nothing but a headache, which stopped working at High Sierra too, because they stopped supporting TB2. I'm bitter about it. It really seems like we ought to be "there" by now, but it's starting to look like it will just never be a thing.

> I'm 100% convinced the delay was caused by Nvidia refusing to accept responsibility.

To be fair, the issue was mainly caused by Apples form-over-function thermal design.

To best of my knowledge, Nvidia GPUs works just fine in all other laptops.

No. I had a laptop in 2010 that also suffered from this issue, and there were also PC GPUs affected.

Laptops were only affected en masse because they have far more heat-cool thermal cycles than the average desktop computer.

Discrete GPUs break all the time, customers are just used to it. Maybe it’s improving since GTX1xxx/RX4xx era but they were extremely unreliable when Apple was using them/industry was switching to RoHS compliant Pb free solders.

100% not true, my Dell Latitude at the time also died. There were major class action lawsuits at the time and basically all the manufacturers had to accept liability and fix them.

This issue was industry wide. RIP my XPS M1330.

> To best of my knowledge, Nvidia GPUs works just fine in all other laptops.

Nvidia bumpgate says hello.

It was reported that the problem was NVidia switching to lead free solder for their chip to motherboard connections but not also switching the potting material to one that had the same thermal expansion coefficient as the new solder.

That was a general problem when the industry switched to lead free solder, see also the Red Ring of Death on the Xbox 360.

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.

> 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.

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...

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

Of course it's not a bug. :-)

Not doubting that this is the case, but what's the reason for nVidia wanting to restrict use in virtual machines?

They don't want people using geforce cards in compute servers/clusters. It's artificial market segmentation since the workstation cards are higher margin. They want customers to pay the big bucks since hypervisor setups are basically only used in business and big budget settings.

Why does Intel cripple ECC and I/O virtualization [0] in high-end consumer desktop systems? Force people to buy Xeon, even if the performance is otherwise equivalent or higher for the use case. Why does Nvidia restrict virtualization? Force people to buy Quadro and Tesla.

> nVidia

FYI, a few years ago, nVidia has officially changed their name to "Nvidia"...

[0] IOMMU is not only a virtualization feature, it's also an important security feature to protect the host from DMA attacks of malicious peripherals (e.g. 1394, ExpressCard, Thunderbolt, USB 4). Fortunately Intel no longer cripples IOMMU (VT-D) since Skylake, but ECC is another story.

I believe it’s all caps.

http://international.download.nvidia.com/partnerforce-us/Bra...

I stand corrected. I also found a clarification from Wikipedia on the situation.

> "From the mid 90s to early-mid 2000s, stylized as nVIDIA with a large italicized lowercase "n" on products. Now officially written as NVIDIA, and stylized in the logo as nVIDIA with the lowercase "n" the same height as the uppercase "VIDIA".

True, but if isn't an acronym (correct me if I'm wrong) I am not going to use all caps. Because it feels like attention grabbing marketing BS to me.

"Fuck you, pay me". Nvidia explicitly forbids "datacenter usage" of their drivers outside of specific licensed-for-datacenter product stacks. (The only exception is for crypto mining, for some reason.) This isn't the only product segmentation in their lineup, either. CAD software optimizations are only available for Quadro cards and up, virtual GPUs are only available for GRID cards, etc. The same GPU they'll charge $600 to gamers for will often go for $3000 or more for businesses.

> The only exception is for crypto mining, for some reason.

I think this is because they were outcompeted by AMD in the GPU crypto days, so they didn't want to get in the way of that (nor were they likely to succeed in blocking this use).

> I recall the GeForce Partner Program raised some controversy, although I couldn't say whether or it was bad or good or why.

It was about NVidia wanting to make it so their 3rd party GPU partners, (EVGA, Asus etc.), could only sell their popular GPU brands with NVIDIA in them, so for AMD they'd have to come up with something customers are entirely unfamiliar with.

> here's also the issue with them refusing to open source Linux drivers.

It's not just that. AMD didn't open-source their original Linux driver, presumably there could have been some 3rd party licensing issues, but they wrote a new one that is open-source.

NVIDIA doesn't even let others write an open-source driver for them, they make it purposely difficult to reverse-engineer, sign their firmware that they only release with a massive delay and generally refuse to cooperate.

> It's not just that. AMD didn't open-source their original Linux driver, presumably there could have been some 3rd party licensing issues, but they wrote a new one that is open-source.

Even further than this, they created such a healthy environment for it that there are now two competing open source Vulkan drivers, and the third party one (RADV) is usually winning by a bit, and is now directly supported (with staff) by Valve.

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.

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.

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.

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

>... also I don't think they open source much.

You could say that: https://drewdevault.com/2017/10/26/Fuck-you-nvidia.html

This is increasingly becoming not true. See cutlass and the new release of cufftdx.

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.

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.

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.

> 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.

I had no idea, so I just searched and found there are 201 repositories in their github:

https://github.com/NVIDIA

that's a pretty meaningless number without further context

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.

Having some of your code in github isn't contributing to open source.

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

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.

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.

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.

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.

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.

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

Reply on news.ycombinator.com