Ask Slashdot: GPU of Choice For OpenCL On Linux? 110
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.
fglrx sucks, but it sucks less in this case (Score:1)
AMD with the proprietary drivers is the OpenCL of choice for buttcoin miners.
Re: (Score:2)
troll
Re: (Score:2)
nVidia w/ binary driver works (Score:1)
Using the binary driver has been fine for me.
Not much more to say on the matter. ffmpeg + x264 make use of it nicely.
Re: (Score:2)
I'm with this guy, I've had nothing but nightmares from ATI historically, can't say I've given modern AMD a chance, but nVidia works so well I have little motivation to.
Re: (Score:3)
But now I have something to say on the matter: my Nvidia card is no longer supported (that 96.xx line of drivers). So, no proprietary driver for me.
You mean no new proprietary driver for you. The old one still exists. It didn't magically stop working because a new driver came out.
I don't play games and my machine is ok to even play video. I don't need to sacrifice anything except the things I already don't use (like desktop indexing).
You can install an indexed search tool on older Ubuntu versions. But regardless, if newer Ubuntu doesn't support older nVidia drivers, how is that nVidia's fault?
Wait, I just saw this:
And no, I can't go for a more recent distribution, like Ubuntu), because they decided my CPU is too old for them.
CPU without PAE? How quaint. Maybe you should join this millenium. But there are some non-PAE kernels for Ubuntu floating around out there, sometimes.
Re: (Score:2)
if newer Ubuntu doesn't support older nVidia drivers, how is that nVidia's fault?
Because the driver is binary and the card specs are closed?
Re: (Score:2)
Because the driver is binary and the card specs are closed?
So what, the drivers don't work with the new kernel or something?
Re: (Score:2)
Well, nothing lasts forever. I, too, hope that someday we will have nVidia cards with open drivers. My understanding is that their geforce line is too patent-encumbered for that to ever happen to them (they pretty much went full-Microsoft during the original Xbox era) but that they more or less own their mobile (as in handheld) GPUs outright, and if they ever become the basis for a desktop product, we might see an open version of those drivers. Nouveau is pretty much unusable for a lot of users, and useless
Re: (Score:2)
Not only that, but even when it does work it tends to break on dist-upgrade (or yum equivalent). Needs fiddling. Life is too short for that, that's the kind of crap I binned Windows for. Plus, the binary block tends to do things its own way whether or not that plays nicely with other components, not being subject to peer review and all.
Re: (Score:2)
It did stop working, as a matter of fact. It was being updated to work with recent kernels. Since they stopped support, no more updates; now I must use an old distro if I want to use it.
How old is that GPU, considering that the rpmfusion builds for fedora 21 support everything back to the Geforce 6xxx series. Perhaps it's time to upgrade the video card?
Re: (Score:2)
The card is an old but perfectly working Geforce 4 MX ( http://en.wikipedia.org/wiki/G... [wikipedia.org] ), fast enough fast for any desktop environment, for video (vlc, mplayer) and even for flashplayer (if I use version 10.3, which I won't, out of security concerns).
While the Geforce 4 MX's do accelerate MPEG2 video, most video these days is MPEG4/H264, you want at least a 7xxx series card to hardware accelerate that. If you've got AGP, then a 7950 GT is the best you can get.
I concede it's rather old (last updated 10 years ago), but it was very fast when new and now it still is a match for some onboard video.
No, it's not equal to some onboard video, unless that video is old. Even the motherboard graphics on this machine, a Nvidia 6150SE, is better. That 4MX is running around 500MFLOPS. A 6150SE runs around 850MFLOPS. An intel HD 4600 runs around 432GFLOPS. I can understand not wanting to just t
You're not going very far with nVidia (Score:4, Interesting)
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.
Re: You're not going very far with nVidia (Score:1)
http://www.phoronix.com/scan.php?page=article&item=nvidia_gtx980_opencl&num=1
Re: (Score:3)
I don't see any pop-ups?
Oh that's right, it's 2015 and the rest of us have blockers installed.
Noobs... (Score:2)
Lol.
Re: You're not going very far with nVidia (Score:2, Interesting)
The opencl performance on nvidia 900 series gpus is actually pretty good. They have finally come around.
Re: You're not going very far with nVidia (Score:4, Informative)
If you're fine with being stuck with OpenCL 1.1 while AMD has OpenCL 2.0 support sure. NVIDIA treats OpenCL like a bastard stepchild.
Re: You're not going very far with nVidia (Score:4, Informative)
Troll uh? Slashdot keeps getting dumber every month. C++ apologists, Apple apologists, NVIDIA apologists. Are you all dumbasses or has this turned into a cesspool of astroturfers and sycophants?
NVIDIA has removed OpenCL support from the debugger, has not updated their OpenCL from version 1.1 for years unlike either AMD or Intel which have had 1.2 and 2.0 releases since then. They removed OpenCL support from their standard Linux dev kit and it has to be installed separately. They want to push everyone into CUDA. They have someone from NVIDIA chairing the OpenCL Khronos committee but then again Microsoft also used to have a big presence in the HTML committee while delivering the worst standard compliant browser in the market.
Intel (Score:2)
Intel is your best bet for a mature open sourced opencl compatible GPU, if performance doesn't matter that is..
Re: (Score:2)
Future of GPU is Open Standards (Score:5, Informative)
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
Re: (Score:3)
I greatly prefer open standards as well. However, CUDA is considerably less painful to work in than OpenCL. NVIDIA has also demonstrated more commitment to capturing GPGPU business than AMD. For example, the first supercomputer on top500.org with AMD GPUs ranks in at 94th. In contrast, NVIDIA GPUs are used in the 2nd ranked supercomputer. Xeon Phi is gaining in popularity, but Intel wants you to work in CilkPlus not OpenCL.
That said, I believe the future is tight integration (i.e., cache coherence) bet
Re: (Score:2, Insightful)
I greatly prefer open standards as well. However, CUDA is considerably less painful to work in than OpenCL.
I'm not sure how you came to this conclusion. I ported a debayering algorithm form CUDA to OpenCL and as far as the kernel code was concerned, the only thing I even had to change was the expressions which retrieve the local and group IDs. The housekeeping code required on the host side is totally different and slightly more complicated for OpenCL, but it's worth the tradeoff in order to be able to run your GPU code on AMD and Intel cards as well as NVidia.
Re: (Score:1)
(I'm not the GP)
Well, among other things:
- CUDA is C++ish, OpenCL is (until now) C-ish. This has many implications, but no templates in OpenCL = pain, or macros. Macros = debugging pain.
- With CUDA, you can just compile the damn code, no need for all the dynamic compilation mess (ok, it's not a mess - but it is when you don't need it to be dynamic). The other way around it's possible that OpenCL is the better alternative, but I've not had to compile dynamically yet.
- This is more of a personal impression, b
Re: (Score:2)
CUDA is C++ish, OpenCL is (until now) C-ish.
To many, this could be considered an advantage.
Re: (Score:2)
and Intel cards as well
Why would you do this? Wouldn't you be better off using the CPU in this case?
Re: (Score:1)
And form talking to our researchers (Score:1)
Between a bit better language design and superior support and tools, CUDA is way easier to do your work in. We've 4 labs that use CUDA in one fashion or another, none that use OpenCL. A number have tried it (also tried lines like the Cell cards that IBM sold for awhile) but settled on CUDA as being the easiest in terms of development. Open standards are nice and all but they've got shit to do and never enough time to do it, so whatever works the easiest is a win for them.
On a different side of things, I've
Re: (Score:2)
FTFY.
Once captured, twice cry.
Re: (Score:2)
GPUs have been doing just fine since the '90's.
nVidia Consumer Card (Score:2, Interesting)
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.
Re: (Score:3)
...On Linux?
Re: (Score:3)
As long as you're all right with proprietary drivers, NVIDIA's Linux driver is quite solid. It needs to be, as it is used in all of their supercomputers.
Re: (Score:2)
Get back under your bridge... troll.
Re: (Score:3)
Thank you for your well-reasoned analysis of the problems with binary-only drivers on Linux, and why my misgivings about them arenot only unfounded but must be a case of arguing in bad faith. Your contribution to the discussion has enlightened us and enhanced the human condition.
Re: (Score:2)
they outperform windows on the same machine with binary drivers.
Re: (Score:1)
go with an nVidia
...On Linux?
Definitely.
Re: (Score:2)
I picked up an nVidia GTX 970 about a month ago, and though I had to tinker a little bit with Debian to get it up and running, after I got the newest drivers installed it's been running rock solid and I haven't noticed much of a difference in performance between Debian and Windows 7 (Maybe 4 more fps in a game on windows where the game is running with the fps in the 290s. This wasn't an ideal test though because the renderer on windows was DirectX 9, while on Linux it was OpenGL). To get it going in Jess
Re: (Score:2)
I own a laptop with an ATi graphics chipset and their drivers are absolute garbage. Their Linux driver causes visual artifacts all the time on a composited GUI, and the machine to crashes on shutdown one out of 5 times with fglrx dumping core causing the machine to never shut off (and potentially turn my laptop bag into a toaster oven x_x). I guess I'm going to return to the open source radeon drivers now that I can scratch my gaming itch on the desktop.
Your report just screams "I'm running an ancient kernel and distribution with an early, dodgy compositor." Try upgrading to current and report your results. To prove you're not a troll, post a bit of the oops message if you get a crash on an up to date system.
Re: (Score:2)
I second that. AMD sucks hard on linux compared to nVidia.
Seems easy enough. (Score:1)
Nvidia only supports OpenCL as an aftertought, prefering as always to offer up their proprietary CUDA shit instead. So go for an AMD card.
OpenCL for CT Image Reconstruction (Score:5, Informative)
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.
Re:OpenCL for CT Image Reconstruction (Score:4, Informative)
Don't ignore CPU-based OpenCL, consider Numpy (Score:3, Interesting)
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 ve
OpenCL for CT Image Reconstruction (Score:2)
Re: (Score:1)
Re: (Score:1)
Try what you have first (Score:3)
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.
Re: (Score:1)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Submitter here:
I don't need 3D as in the sense of rasterizing triangles in 3D space.
I need the GPU to do General Purpose computing, as clearly stated in the summary.
In my case: I need to do a massive amount of intersection tests between rays and AABBs.
Well... (Score:1)
AMD Obsoletes Its GPU Card Drivers Too Quickly (Score:1)
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 ne
Re: (Score:2)
The solution to this is to use the open source amd drivers.
Opencl on it is only just starting to become mature, but it is where all the future development really is and is plenty usable for many current tasks.
AMD is the only real option (Score:5, Informative)
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-... [intel.com]. You can still write OpenCL programs, but you'll just be running them on your CPU.
Re: (Score:1)
>> They've been stuck at OpenCL 1.1 for years
That's because their own API (CUDA) is far better and more developed.
AMD support more recent versions of OpenC (Score:3)
Have a look at this talk, namely 8 min 30 seconds into the talk:
https://www.youtube.com/watch?... [youtube.com]
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).
22-Way AMD/NVIDIA OpenCL Linux Benchmarks (Score:1)
Model: Radeon r9280x or 7970 (Score:3)
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.
What do you actually want to do with it? (Score:2)
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