Will OpenCL help displace GPGPU? (2012)
yosefk.com
yosefk.com
Yes, OpenCL is an API and shader language for GPGPU usage.
Yes, it is a competitor to CUDA.
No, CUDA is not the majority of GPGPU usage (although in 2012, 3+ years ago, this may have been true depending on who you spoke to), OpenCL now is.
No, CUDA and OpenCL competing is not an issue, as Nvidia is a founding member of Khronos's OpenCL committee, and Nvidia uses a merged compiler backend for all their shaders (including OpenCL and CUDA); neither API will produce better optimized binaries than the other on Nvidia hardware.
Yes, there are OpenCL implementations for CPUs: AMD and Nvidia's implementations both can be executed on x86 CPUs (useful for lock step full program debugging without needing to deal with the async nature of GPUs), Intel has one for x86, IBM has one for PPC/PPC64/Power.
Yes, there are OpenCL implementations for DSPs. That was already a thing in 2012. Sony/IBM has one for Cell SPEs.
Yes, GPUs are in fact highly parallel DSPs.
No, since 2012, Parallela nor P2012 ever took off.
No, OpenCL cannot displace GPGPU because that is like saying Electric will displace the Car. No, instead, we'll make cars that run on electricity instead of gasoline, ie, we'll be changing APIs to more universally supported ones.
Is GPGPU dying? 'Yes.' What is killing it? The march of technology into making EVERYTHING generic processing: floating point used to be a specialized application requiring an optional co-processor: it is now part of the CPU; SIMD used to be part of specialized DSPs, that, too, is now part of the CPU, and that part of the CPU becomes more complex every other generation or so; GPGPUs were merged on-die a few generations back and natively speak to the CPU's memory controller and socket bus as if they were just another core.
And merging GPGPUs on-die isn't even new, if we view them as just specialized highly parallel DSPs: MIPS and ARM SoCs have done this for like the past decade by including communications and audio processing DSPs in the package or on-die.
So, just like the FPU, and SIMD, GPGPUs as highly parallel DSPs are being merged into the CPU.
And, as a side note, you know what this looks like from the other side, a CPU becoming a highly parallel DSP? Intel's Xeon Phi series.
And, as another side note, since it is now a given that CPUs need to be able to do embarrassingly parallel tasks optimizedly, Intel is now tackling the fact that QPI is not scalable across a CCNUMA cluster like AMD's Hypertransport is, and is now moving to embed their Infiniband variant onto CPU and Phi dies, for native 40/100gbit on-die. There are already Xeon E5/E7s slated to have this on a post-LGA-2011-3 socket.
Disclaimer: I wrote DiabloMiner, that popular GPU Bitcoin miner everyone used until ASICs took over.
Nvidia still doesn't even support OpenCL 2.0 from two years ago. Surely if OpenCL was making significant gains they would be forced to support it, especially since Nvidia is far more popular in any kind of HPC setup with Tesla compared to FirePro?
Intel has had OpenCL 2.0 support since August 2014, and AMD since September 2014.
OpenCL 2.0's interesting features are shared virtual memory and generic memory space, which Nvidia hardware before Maxwell rev 2 may not be able to support, and Nvidia may have to wait until Pascal to support it (via the NvLink and unified memory feature set). Ergo, Nvidia may not have the hardware support to add OpenCL 2.0 yet.
OpenCL 2.1 is more of the interesting one because they are adopting a SPIR-V (Vulkan's IL representation)-based C++ subset, something Nvidia has been leading the charge on.
OpenCL 2.1 was finalized last month, so I don't expect drivers to support it properly until this time next year.
And as I said above, there is no performance difference between OpenCL and CUDA on Nvidia hardware; although, I should probably amend that with "as long as both versions of the code are sane."
I wish I was telling a joke, I've met a lot of "programmers" from academia that don't care if their code is horrible, or worse yet, returns a wrong answer during edge cases, they just want it to compile error free and produce results.
This intersects with the popular HN opinion of "if you're going to publish a scientific paper, you must also publish the exact code that processed your results, too."
OTOH the people that get my goat are the data scientists who only know single-threaded python code and rely on hadoop for parallel execution who insist on trampling CUDA code with race conditions and tons of within-warp branching and then complain to me that GPUs are not as good as they were told.
Nvidia hardware, for example, still has very poor performance on a wide range of situations, such as anything involving integers (ex: crypto); and it does not perform as well on no-op branch/loop skip detection in situations where the entire warp/wavefront chooses that branch; and, finally, double precision performance per watt and per dollar is generally better on AMD hardware, which is often used in certain physics models.
There are more computers on the Top 500 supercomputer list using AMD GPUs than Nvidia GPUs.
This isn't a "war" to be "won", Nvidia is a founding member of Khronos' OpenCL committee, along with AMD and Intel. They heavily participate in OpenCL and a lot of extensions and core features have been proposed by them and accepted. OpenCL is not owned by AMD, and Nvidia puts as much into OpenCL as AMD does.
Oh? According to http://www.top500.org/list/2015/11/ (aka "the Top 500 supercomputer list") ... I counted three with AMD GPUs and 70 with NVidia. So...?
I'd like to see numbers on that.
CUDA hits in Google: 24,000,000 OpenCL hits in Google: 1,000,000
I tried to use OpenCL a number of years ago and the drivers were brutal. CUDA just works.
The number of great libraries available for CUDA is huge, where as the OpenCL ecosystem is more expensive to participate in because those fundamental libraries are not available.
You will get more bang for your buck doing CUDA on Windows or Linux than OpenCL.
The problem with CUDA is vendor lock in. Requiring Nvidia hardware (and Nvidia binary drivers on Linux) is a no go for a lot of use cases.
If you need compute code that works on all platforms and all operating systems, OpenCL is your only choice.
Not really by what I can see. It's on the same chip but logically separated and not integrated as instructions of the CPU. There's also reasons to keep high power GPUs separate: cheap GDDR ram, high thermal output.