Firstly for all the previous things they have done, for example their lack of driver support for free operating systems which is why Linus said this, their lack of Free Software drivers, their tight lockdown on proprietary technologies like PhysX that hurts portability and hurts non-Nvidia users and finally default collection of telemetry data is a highly unethical practice and the inclusion of the extra code to do it can only hurt stability and performance and increase driver size. Go ahead and downvote me to hell, I'm not bothered, go ahead and buy Nvidia chips, I will avoid Nvida like the plague till the day I die.
> Firstly for all the previous things they have done, for example their lack of driver support for free operating systems which is why Linus said this
It is not Nvidia's job to prop up the desktop linux ecosystem. It's wise not to invest time in that ecosystem, as far as I can tell. It's got an ongoing history of disappointing its customers and vendors over and over. And we get good enough computational support ever business or individual out there, Nvidia GPUs are still preferred for clustering.
> I will avoid Nvida like the plague till the day I die.
The way you talk makes it sound like it's a religious or political debate. You're mad that they don't support your demagogue or your shared values. Isn't Hacker News a place where we're supposed to keep politics at bay and focus on the technology?
NVIDIA could release documentation on their hardware that would make it easier for Nouveau developers to do their work, but they don't. Nobody is asking for free labor on a low-marketshare OS.
Unfortunately, Nvidia's proprietary drivers are excellent for features where the puck has been and not-so-excellent in features where the puck is going. See also Wayland support or switchable GPUs.
Been hearing about Wayland for a while wake me up when it's actually here.
Also there is no problem with switchable GPU's which is specific to nVIDIA anymore the Optimus chip is no longer used (and haven't been for a while) since Intels Iris came out it powered a single generation of mobile GPUs and was a hack even on Windows.
Unlikely to happen without major business motivation/incentives to do so. Right now outside that small community, nobody really cares if it's open source or not as long as it works well and it does.
Personally I think that the HN response of, "We flag politics" is really just a blind for not discussing sensitive topics like racism, sexism, and human rights in a larger sense.
But that won't stop me from trying to fairly apply the policy to the free software people who are utterly convinced that serving their agenda is a net good rather than a lifestyle choice.
CUDA only exists because Nvidia is attempting to pretend OpenCL, Vulkan, and DX12 don't exist [1]. These require hardware scheduling on the GPU to switch shaders. Rather then dedicated X amount of chip hardware to Y shader for Z ms.
It should be noted for GPGPU compute Nvidia is not the correct choice. AMD RX 480 has 5.8TFLOPS @$200 ($37/TFLOP) vs Nvidia GTX1080 8.9TFLOPS @$600 ($67/TFLOP). In reality you should be doing GPU programming in OpenCL so you are GPU agnostic. You can switch vendors or platforms seamlessly (in most cases if you avoid proprietary extensions) even target AMD64, ARM, and POWER8/9 hardware.
That being said I own a boat load of Nvidia stock because their marketing is excellent. Really marketing is all 80% of people pay attention too. CUDA has some great marketing around it. In reality CUDA is slower then OpenCL (on Nvidia's platforms even) and no easier to work in.
It's worth pointing out that ROCm is basically AMD's answer to CUDA. Similar programming model and everything.
Let's hope it gets picked up by machine learning frameworks etc., because this market badly needs the competition, as your comparison of per-dollar raw performance numbers shows.
I agree with your point about avoiding vendor lockins, something I experienced for myself with MATLAB. I also happened to buy a RX 480 recently, so I'm happy to hear it's good for GPGPU.
But I'm curious in how the FLOPS on these cards were measured. For example one concern I have is that presumably these two cards have slightly different levels of parallelism. So it may be more or less difficult to extract the full performance from a particular card due to parallelism overhead. Then there's driver overhead, ease of programming, etc.
Where F is # of FPU front ends (SIMD and scalar). This is wrong because scalar math often is slower then SIMD, and compute kernels rarely run on the scalar pipeline.
Where Hz is the well.. the clock rate, inverse to get cycles per second. This is wrong because stalls happen, memory transfers, cache misses etc. It is also wrong because the clock rate is throttled and you are not always at Maximum boost clock.
Then multiply by 2 for FMA (fused multiply add). This is wrong because well not every operation is a one cycle FMA. Division can be many (>100). Also scalar pipelines don't have FMA.
Ultimately all vendors use the same crappy calculation so we are comparing apples to apples. Just rotten apples to rotten apples. It gives you a good ideal circumstance you can optimize towards but never actually attain.
There is difference in job scheduling between AMD and Nvidia. So if you want to optimize your OpenCL applications you can do it only for one of them or do it twice.
Sample applies to integer math, long double math and so on.
They've had the best 3D drivers on Linux for years. There were issues with Optimus and Ion but IIRC a lot of it was legal and issues with Linux's driver infra back then meant it required far more effort than it was worth at the time.
Their drivers might work, but saying to users "here, load this giant blob with a history of privesc bugs into your kernel" isn't what I'd call "supporting Linux".
Meanwhile, AMD are active contributors to Mesa and DRM, which benefits everyone.
I wish they'd open things up too, but it's there prerogative, and Linux repesents a minuscule share of their market. The fact that they support it in the way they do today is surprising.