Slashdot Mirror
Ask Slashdot: GPU of Choice For OpenCL On Linux?
Bram Stolk writes So, I am running GNU/Linux on a modern Haswell CPU, with an old Radeon HD5xxx from 2009. I'm pretty happy with the open source Gallium driver for 3D acceleration. But now I want to do some GPGPU development using OpenCL on this box, and the old GPU will no longer cut it. What do my fellow technophiles from Slashdot recommend as a replacement GPU? Go NVIDIA, go AMD, or just use the integrated Intel GPU instead? Bonus points for open sourced solutions. Performance not really important, but OpenCL driver maturity is.
AMD with the proprietary drivers is the OpenCL of choice for buttcoin miners.
Using the binary driver has been fine for me.
Not much more to say on the matter. ffmpeg + x264 make use of it nicely.
They're too busy with CUDA to give two shits about decent OpenCL performance.
That's why the HD Radeon series was the mining GPU of choice for Bitcoin.
Intel is your best bet for a mature open sourced opencl compatible GPU, if performance doesn't matter that is..
The future of GPU's is open standards. GPU's won't take off until all major vendors support the latest (OpenCL 2.0) standards
Here is the list of conformant products
https://www.khronos.org/conformance/adopters/conformant-products#opencl
I would go with an nVidia consumer card. They may be more expensive than the AMD ones. On the other hand, they offer CUDA and OpenCL support and are much faster.
For the newer ones (GTX9xxx) you will need to wait a little bit until the driver shipped with CUDA actually supports the cards though.
Nvidia only supports OpenCL as an aftertought, prefering as always to offer up their proprietary CUDA shit instead. So go for an AMD card.
I work in a lab that does CT image reconstruction (all gpgpu computing) as part of what we do. I've been the one to program it using OpenCL under Ubuntu (I insisted I use linux; windows was too infuriating) so I'll share my experience.
I have two Nvidia 780 GPUs in my machine (an Alienware Aurora R4) and getting everything running under linux was actually much smoother than my initial attempt to get OpenCL running under Windows 8, so I don't think you'll have too much trouble there. I use the binary blob from Nvidia and it has been pretty stable with the occasional driver crash for whatever reason (maybe once in a six month period, but things just restart and it's fine. It's usually my fault for writing shitty code). I personally really like this setup and the only thing that could make it better would be more GPUs and a great, solid open source driver.
I would say that if you're going to use Nvidia GPUs for GPGPU computing, consider learning CUDA. Syntactically it's very similar to OpenCL but the tools you have access to for debugging, profiling, and increasing performance as well as the overall stability of the programs seems to be much much better. I suppose we should expect that though from a proprietary language, on proprietary hardware, using a proprietary driver. I've heard that you can get better performance (read: speedups) using CUDA over OpenCL, but I've never tested that for myself, or seen proof firsthand.
I've learned OpenCL, and I like it's portability and openness, but I look at some of the stuff my friends can do with CUDA and I can't say that I'm not envious. Mainly what I'm referring to is Nvidia's NSight program, which can do OpenCL if you're willing to pay for the "pro" edition. Also, Nvidia GPUs are scalar based, so if much of you speedup would come from using OpenCL's vector structures, that won't happen on Nvidia GPUs the same way that it would on AMD. Programming might be more convenient, but performance will stay the same.
Hope that helps. Feel free to ask more questions.
Integrated graphics in your CPU will have a modest performance but stable and open source OpenCL driver. If it proves too slow for your particular project, you will be able to compare benchmarks and get the cheapest card that is fast enough to, say, run your animation at 60fps. If you are planning to distribute your code, you will anyway need several GPUs to test with.
Just curious. No flame bait. What do you need the 3D for? I have 3 screens and don't do anything 3D related. I just have the cheapest cards that I can find. I use NVidea as I like the nvidia-settings sofware.
I use three (differnt) cards. Each connected to a differnt monitor running in standard mode (no xinerame, no mirrors). Cheaper to have three cheap cards then one that could do all three easily. And by cheap I mean the cheapest that is available and for the connection that I need. Under 50EUR for 3 cards.
So I am curious what you need the 3D for.
Don't fight for your country, if your country does not fight for you.
Don't know about pure OpenCL. But... Intel, has over all well support and not too bad compared to windows counterpart drivers. It lacks OpenGL 4 features. It only uses OpenGL3. AMD has open source drivers, which mostly suck. Performance in games is rather bad. Same as synthetic tests. Many people report about rather good bitcoin performance. Proprietary drivers are a bit better on performance but worse on stability. Nvidia, has 2 types of drivers. Reverse engineered ones, which suck and blow when it comes to performance and binary ones. Nvidia with binary drivers has highest performance + stability in games. It's on pair with AMD on bitcoin stuff. In reality no one can say what is good for OpenCL in Linux, because there are no OpenCL apps in Linux. I am no Nvidia fanboy, but i am Nvidia user for a while. They are safest bet on quality/performance, but AMD may as well worth your while, especially if you are dev and don't mind reporting issue to kernel devs, etc.
newer hardware features (such as intra-warp shuffle and floating-point atomics) are not accessible
You can use inline PTX inside OpenCL code on a NVIDIA card. I use it for the popcnt instruction, which is named popc in PTX, since NVIDIA is too lame to implement OpenCL 1.2 support on their driver which would have that as standard even if the hardware has the instruction support for it.
I recommend the ocl-icd package to make it easy to switch OpenCL implementations on the fly. Also, download the Intel and AMD OpenCL runtimes which support CPU-based computation using SIMD instructions and multicore parallelism, and try them out as well as GPUs. You can then micro-benchmark your own algorithms on different vendor runtimes quite easily. I have found that the Intel OpenCL does a very decent job of auto-vectorization, so my scalar-based OpenCL code ran almost as fast as my hand-vectorized version that uses OpenCL vector intrinsics.
In my case, my image processing algorithms are more memory-bound and a recent 2.4 GHz mobile Intel quad-core outperforms my desktop NVIDIA GTX 760 on the same OpenCL code. Both of these trounce my c. 2010 Xeon E5530. I had no idea how much Intel SIMD performance has improved until I tried this and saw for myself. I think a big advantage is that the CPU doesn't have to transfer the large N-dimensional arrays back and forth over the PCIe bus, but can just get to computing immediately. This may not hold true for some algorithms that crank much longer on a small input or output array.
It is also important to realize that OpenCL parallelism won't save you from poor algorithm choices. You need to be open to experimentation and reevaluating your assumptions as you explore new problems. I work with Python, Numpy, and PyOpenCL so that I can focus on the math first, and then selectively replace the underlying algorithms with different implementations as needed. Being able to work at a high level of abstraction makes it so much easier to explore the math you want to perform, without writing a lot of low-level code that gets thrown away.
I have used 2 AMD cards programming OpenCl on Linux, a HD4650 and a HD7770. My 4650 card was obsoleted by the AMD proprietary drivers in 18 months, my HD7770 is being obsoleted (for new Linux and OpenCL support) by AMD as I write this, after about 2 years. This means if I want to keep doing OpenCl development, I have to use the old driver and old kernels, old xservers, and current version of OpenCl, etc.
I don't think think I will buy AMD again for this reason. Nvidia doesn't obsolete their cards anywhere near as quickly on Linux. If you buy a top of the line AMD card, you will probably get more than 2 years of support, but you lose even more money when it is obsoleted.
I will buy Nvidia next time, but only one of their new Maxwell chipsets or newer, but admittedly, that won't be a perfect solution either. Both solutions have major flaws. If you can afford to buy new GPU cards every 2 or 3years, go with AMD, otherwise, get Nvidia.
If you want to write modern OpenCL code and run it on a GPU, AMD is your only option.
In terms of performance, NVIDIA is actually the best. But they've been stuck at OpenCL 1.1 for years, while everyone else has long since moved to newer versions. Until (if) they add OpenCL 2.0 support, they'll be a bad choice.
Intel doesn't support running OpenCL on the GPU under Linux. See the chart at the end of https://software.intel.com/en-.... You can still write OpenCL programs, but you'll just be running them on your CPU.
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
Have a look at this talk, namely 8 min 30 seconds into the talk:
https://www.youtube.com/watch?...
The talk was given at the recent Linux Conf Australia (in New Zealand). It shows that AMD supports OpenCL 2.0, while Nvidia only support version 1.1 (released in 2010). I spoke to the speaker after his talk and he said Nvidia are basically dragging their heals with regard to supporting more recent versions. Nvidia also request unconvential features be put into the spec, and then never implement those features. Obvisouly Nvidia are doing well with their own CUDA language and seem to be trying to create a walled garden. It sounds like if you are going for openness and not for speed, then you could look at Intel or AMD (both support version 2.0).
I'm no serious parallel programmer, so I don't know how helpful this well be to you, but this might be of interest: 22-Way AMD/NVIDIA OpenCL Linux Benchmarks To Start Off 2015. Mike Larabel does some great work.
Lol.
Truth isn't Truth - Guliani
As for a particular model, if double-precision performance is important, go with a 7970 or 280x on theAMD side (or 7990 if you need dual-gpu in one slot). They did double-precision at 1/4th their single-precision rate, which is the best you're going to find at consumer-grade pricing -- even more-modern or more powerful cards have backed off on double-precision, so something like a 290x has almost 50% more shader ALUs than a 280x, and will perform better at single-precision workloads, but only does double-precision at a rate of 1/8th, so its actually slower in purely double-precision workloads. All of nVidia's consumer cards are in the ballpark of 1/8th to 1/16th rate too, except the GTX Titan Black, which did 1/3rd rate, but at $1500 is nearly Quadro pricing anyways.
If money is no object an AMD firepro 9100 is the workstation version of the 290x, and does double-precision at 1/2 single precision rate, and is the current best-of-both worlds, and will probably remain so for the remainder of the year, but its a 3-grand price tag or so.
Which company do you work for just out of curiosity?
That's really the question. Are you using the GPU for heavy-duty computing, or graphics, or...?
We've got money around here (we're a civilian-sector US gov't agency) using NVidia Tesla cards - in several servers, *two* of 'em - for heavy lifting with things like R. We do use the installable proprietary drives, and they work.
mark
While Intel may not officially support OpenCL on their GPUs under Linux, there is Beignet, the open source implementation: https://01.org/beignet