5467555
story
Comments: 176 +- Technology: AMD's OpenCL Allows GPU Code To Run On X86 CPUs on Thursday August 06 2009, @12:38PM
background: url(//a.fsdn.com/sd/topics/topicgraphics3.gif); width:69px; height:62px;
graphics
background: url(//a.fsdn.com/sd/topics/topicsoftware.gif); width:65px; height:65px;
software
background: url(//a.fsdn.com/sd/topics/topicamd.gif); width:53px; height:53px;
amd
background: url(//a.fsdn.com/sd/topics/topichardware.gif); width:64px; height:55px;
hardware
eldavojohn writes "Two blog posts from AMD are causing a stir in the GPU community. AMD has created and released the industry's first OpenCL which allows developers to code against AMD's graphics API (normally only used for their GPUs) and run it on any x86 CPU. Now, as a developer, you can divide the workload between the two as you see fit instead of having to commit to either GPU or CPU. Ars has more details."
Related Stories
Necessity is a mother.
All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2010 Geeknet, Inc.
Nice (Score:5, Interesting)
Re: (Score:2, Funny)
Good on them. Now how about an API that allows me to run GPU code on the GPU? The day I can play 1080p mkvs from a netbook on AMD/ATI hardware is the day I'll quit buying nvidia.
*Head Explodes*
Re:Nice (Score:5, Informative)
Parent
Re:Nice (Score:5, Informative)
AMD/ATI only offers GPU-accelerated decoding and presentation through the XvBA API, which is only available to their enterprise and embedded customers. People seem to always forget that fglrx is for enterprise (FireGL) people first.
Wait for the officially supported open-source radeon drivers to get support for GPU-accelerated decoding, or (God forbid!) contribute some code. In particular, if somebody would write a VDPAU frontend for Gallium3D...
Parent
Re:Nice (Score:4, Insightful)
I suppose I could have been clearer. I'm talking about gpu decoding of HD video, conspicuously absent on AMD drivers in Linux, fully functional on NVIDIA.
Fixed that for you. Or does installing Linux somehow magically unsolder the video decoding part of AMD's GPUs?
np: Death Cab For Cutie - Information Travels Faster (The Photo Album)
Parent
Re:Nice (Score:5, Funny)
does installing Linux somehow magically unsolder the video decoding part of AMD's GPUs?
I'm not going to lie to you; I don't know the answer to that question, and I'm not about to make any assumptions.
Parent
Re: (Score:3, Interesting)
I thought the AMD guys are releasing the specs so the Linux guys can code pretty much any goodie they want? I don't know how high def on AMD is/isn't on Linux, but one of the reasons why I went AMD for my new PC was how well their "bang for the buck" has gotten. My 780V board played videos (and Bioshock surprisingly) smooth as butter until my PCIe card came in, which I couldn't believe supported H264, WMV9, DivX, MPG, and a few others right out of the box with no fiddling. All that and a gig of RAM on a 465
Re: (Score:3, Insightful)
Damn, you beat me to it!
The problem now is the lack of applications that enable end users to make benefit from having a powerful GPU. This will be the case until there's a standard API which works across multiple GPU architectures. Having both CUDA and OpenCL is one too many
Re:Nice (Score:4, Interesting)
look back about a year, since AMD opened up specs & docs, the radeon drivers have become very usable for everyday stuff (maybe not HD video, compiz or games), but the stability blows any prop driver i have ever used (nvidia or flgrx) right out of the water.
For years linux users/developers have been claiming that we don't want drivers we just want open specs (without NDAs) and "we" would do the hard work. Well AMD have opened specs but it turns out when i say "we" i mean just the 2 guys who can be bothers, fortunately these guys are pretty fucking awesome so development is coming along smoothly but still lags behind what prop drives offer (in terms of performance anyway). Perhaps readon does not meet your needs but they it is defiantly viable alternative to nvidia for many uses!
Parent
Isn't there a fundamental problem... (Score:2)
In that memory on the card is faster for the card GPU and memory on the CPU is faster than the CPU. Like, I know PC-Express speeds things up, but, is it that fast that you don't have to worry about the bottleneck of the system bus?
Re: (Score:2)
The GPU is there, now lets make it useful as often as possible. And if there is no GPU but two CPUs then with OpenCL we can use two the CPUs instead.
Re: (Score:2, Interesting)
IMO, the fundamental problem with OpenCL is the same as with OpenAL, which is that Operating System vendors don't provide a standard implementation as is done with OpenGL.
(Bus) speed isn't an issue as creating a CPU or GPU context requires a specific creation flag, so one would know what the target platform is.
Re: (Score:3, Interesting)
IMO, the fundamental problem with OpenCL is the same as with OpenAL, which is that Operating System vendors don't provide a standard implementation as is done with OpenGL.
It's still pretty early to say, though Apple provides an API for this with Snow Leopard. I don't know it OpenAL is a bad comparison or not, but as someone that does audio coding, OpenAL is the biggest joke of an API yet devised by man. OpenAL has little support because it's an awful and usless set of resources and features.
Re:Isn't there a fundamental problem... (Score:5, Interesting)
My main issues with OpenAL are that it is completely based around the concept of a "listener" interacting with sounds in "space." In other words, it's the OpenGL semantic applied to sound. I looked into it originally because I wanted something more system-independent than Apple's CoreAudio, but really OpenAL is just a videogame language, and it's focused completely around choreographing sounds for interactive emulation of space. OpenAL is hell if you want to apply a subjective effects aside from its pre-cooked spatial repertory, or even do something simple like build a mixer with busses.
In my line, film post-production, the users really don't want to control the "direction" and "distance" of a sound, they want to control the pan and reverb send of a sound; the language and the model is simply too high level for people who are used to setting their own EQ poles and their own pitch-shifts for doppler.... Most of the models OpenAL uses to create distance and direction sensations are pretty subjective, arbitrary, and not really based on current pychoacoustic modelling. It works to an extent, but it doesn't give a sound designer, of a videogame or anything else, the level of control over the environment they generally expect. It certainly doesn't give a videogame sound designer the level of control over presentation that OpenGL gives the modeller or shader developer.
Oh, and OpenAL doesn't support 96k, 24 bit audio, or 5.1 surround.
I admit I am not their target audeince, and I can see how OpenAL is sufficient for videogame developers, but it really is nothing more than sufficient, and unlike OpenGL, which universal enough that it can be used in system and productivity software, on computers, phones, and in renderfarms on everything from calendar software to animated movies, OpenAL is strictly for videogames only.
Parent
Re:Isn't there a fundamental problem... (Score:4, Insightful)
I admit I am not their target audeince, and I can see how OpenAL is sufficient for videogame developers, but it really is nothing more than sufficient, and unlike OpenGL, which universal enough that it can be used in system and productivity software, on computers, phones, and in renderfarms on everything from calendar software to animated movies, OpenAL is strictly for videogames only.
Um, yeah. I have only used it sparingly, but it has always been my understanding that OpenAL was a library for doing spatial audio, in particular for 3D games. I never got the impression that it was supposed to just be an arbitrary audio api. I never got the impression that it was supposed to be for anyone who wasn't specifically interested in spatial audio.
I mean there are plenty of other cross-platform sound libraries.
Is OpenAL seriously advertising itself as a general-purpose sound library akin to OpenGL these days? Is it suffering from feature/scope creep? Or is this just a case of picking the wrong tool for the job based on an understandable confusion regarding the OpenFoo nomenclature?
Parent
Re: (Score:3, Informative)
So, you store the data the GPU is working on in the card's memory, and the data the CPU is working on in system memory.
yes, it is relatively slow to move between the two, but not so much that the one time latency incurred will eliminate the benefits.
Re: (Score:3, Interesting)
I've found that an O(n^3) algorithm or less should be run on cpu. The overhead of moving to gpu memory is just too high. The gen2 pci is faster, but that just means I do #pragma omp parallel for and set the number of processors to 2.
The comparisons of gpu and cpu code are not fair. They talk about highly optimised code for the gpu but totally neglect the cpu code (only use a O2 with the gcc compiler and that's it). On a E5430 Xeon, intel compiler and well written code, an O(n^3) or less is faster.
Re: (Score:3, Informative)
Not at all absurd. I realise that the gpu is a compute workhorse. That's not the issue. It is the data transfer rate to and from the card. Transferring 3GiB takes quite a while. Pulling the results back takes a while also. That's what kills it. The cpu can get the work done in that time.
I'm using the cuda blas routines, examples from the sdk and those published as 'glorious almighty' codes. Everything that the card does is timed as it is all time to solution.
Re: (Score:3, Interesting)
Unless of course you have a device (like newer macbooks) with nvidia's mobile chipset, which shares system memory and can therefore take advantage of Zero-copy access [nvidia.com], in which case there is no transfer penalty because there is no transfer. A limited case, but useful for sure.
Re:Isn't there a fundamental problem... (Score:5, Interesting)
If your concern is shipping object code to a card to be processed may end up being so time consuming that it would not be worth it. Then I'd say that most examples of this kind of processing I've seen are doing some specific highly scalable task (e.g. MD5 hashing, portions of h264 decode). So clearly you have to do a cost/benefit like you would with any type of parallelization. That said, the cost of shipping code to the card is pretty small. So I would expect any reasonably repetitive task would afford some improvement. You're probably more worried about how well the code can be parallelized rather than the transfer cost.
Parent
The real benefit (Score:5, Insightful)
Re:The real benefit (Score:5, Funny)
Yes, that's the solution. Have your code run on any system, all too willing to be duped by street vendors, and blissfully unaware of the nefarious intentions of the guy waving candy from the back of the BUS.
Oh... you meant running code natively... I see.
Parent
Intel counters with CPU+GPU on a chip (Score:5, Interesting)
Ironically Intel announced that they are going to stop outsourcing their GPU's in Atom processors and include the gpu + cpu in one package, yet nobody knows what happened to the dual core Atom N270...
Re:Intel counters with CPU+GPU on a chip (Score:4, Insightful)
Microsoft wouldn't allow licensing dual cores on netbooks.
Parent
Re: (Score:3, Interesting)
Makes sense (Score:4, Interesting)
Things have been slowly moving in this directly already, since game makers have not been using available cpu horsepower very effectively. A little z-buffer magic and there is no reason why the object space couldn't be separated into completely independent processing streams.
-Matt
Re: (Score:2)
How do you handle translucency when you have a Z buffer?
Use both at the same time? (Score:2, Interesting)
I haven't read too much of OpenCL (just a few whitepapers and tutorials) but does anybody know if you can use both the GPU and CPU at the same time for the same kind of task. For example, in a single "kernel", I want it done 100 times, I can send 4 to the quad-core CPU and the rest to the GPU? If so, this would be a big win for AMD.
Overhyped (Score:5, Informative)
Having a separate compiler that doesn't integrate cleanly with the rest of your toolchain (i.e. uses a different intermediate representation preventing cross-module optimisations between C code and OpenCL) and doesn't integrate with the driver stack is very boring.
Oh, and the press release appears to be a lie:
AMD is the first to deliver a beta release of an OpenCL software development platform for x86-based CPUs
Somewhat surprising, given that OS X 10.6 betas have included an OpenCL SDK for x86 CPUs for several months prior to the date of the press release. Possibly they meant public beta.
Re: (Score:3, Informative)
Source: http://developer.amd.com/GPU/ATISTREAMSDKBETAPROGRAM/Pages/default.aspx [amd.com]
Being able to target both Windows and Linux is something outside Apple's platform scope.
GPUs are dying - the cycle continues (Score:3, Insightful)
Now that we have CPUs with literally more cores than we know what to do with, it makes sense to use those cores for graphics processing. I think that within a few years, we'll start seeing games that don't require a high-end graphics card- they'll just use a couple of the cores on your CPU. It makes sense, and is actually a good thing. Fewer discrete chips is better, as far as power consumption and heat, ease-of-programming and compatibility are concerned.
Re:GPUs are dying - the cycle continues (Score:4, Insightful)
A dedicated graphics processor will be faster than a general purpose processor. Yes, you could use an 8 core CPU for graphics, or you could use a 4 year old VGA. Guess which one is cheaper.
Parent
Re:GPUs are dying - the cycle continues (Score:4, Insightful)
Hey, my nVidia 9800GTX+ has over 120 processing cores of one form or another in one package..
Show me an Intel offering or AMD offering in the CPU market with similar numbers of cores in one package.
Parent
Re: (Score:2)
Technology fail.
Re:GPUs are dying - the cycle continues (Score:4, Interesting)
For some games that'll be true, but I think it'll be a long time, if ever, before we see a CPU that can compete with a high end GPU especially as the bar gets higher and higher - e.g. physics simulation , ray tracing...
Note that a GPU core/thread processor is way simpler than a general purpose CPU core and so MANY more can be fit on a die. Compare an x86 chip with maybe 4 cores with something like an NVidea Tesla (CUDA) card which starts with 128 thread processors and goes up to 960(!) in a 1U format card! I think there'll always be that 10-100 factor more cores in a high end GPU vs CPU and for apps that need that degree of paralellism/power the CPU will not be a substitute.
Parent
Not any time soon (Score:5, Insightful)
I agree that the eventual goal is everything on the CPU. After all, that is the great thing about a computer. You do everything in software, you don't need dedicated devices for each feature, you just need software. However, even as powerful as CPUs are, they are WAY behind what is needed to get the kind of graphics we do out of a GPU. At this point in time, dedicated hardware is still far ahead of what you can do with a CPU. So it is coming, but probably not for 10+ years.
Parent
Re: (Score:3, Informative)
There's only two ways to do that:
Of course, you're reading
What's the story? (Score:3, Informative)
UniversCL (Score:2, Interesting)
Re:Optimization (Score:5, Funny)
Why would anyone ever want to do something well when they can fail at several things?
Parent
Re: (Score:2, Insightful)
Re:Optimization (Score:5, Insightful)
So now programmers can write code that will work on either processor and will be optimized on neither. Brilliant. I'm sure this is somehow a great step forward.
-sigh-
Um, what? How does the existence of a compiler that generates x86 code prevent the existence of an optimizing compiler that generate GPU instructions?
Parent
Re: (Score:2)
Yeah, it's amazing how things that can generate executables on multiple platforms, things like C, are so amazingly slow.
Man, why did we ever stop using assembly?
Re: (Score:2)
For the kind of really high performance stuff OpenCL is targeted to, we didn't. Look at the low level code in GnuMP, for instance.
Re: (Score:2, Interesting)
Re:Optimization (Score:5, Insightful)
Parent
Re:Optimization (Score:5, Funny)
The SX is for Sux!
Parent
Re:DIDN'T APPLE COME UP WITH THIS ABOUT A YEAR AGO (Score:2, Informative)
Ok, I'll feed the troll (this time)
Anyway, Apple was one of the companies that first came up with the OpenCL standard. Apple worked with Khronos to make it a full standard. AMD is one of the first to publicly release a full implementation of OpenCL which is why this is big news.
Re: (Score:2)
This idea isn't new. CUDA allows you to execute your GPU code on the CPU. This is just AMD implenting OpenCl which afaik is sufficently new no one else has done this yet. I would have expected it to be another couple of months before we really saw NVIDIA and AMD start pushing OpenCL when they release new hardware. Obviously they're working on it already, it's just a matter of when anyone can do anything with it.
Re: (Score:3, Interesting)
I wouldn't be so sure on nVidia. They appear to think CUDA is a better system, and from what I've heard and seen, they're right. OpenCL appears to be more limited in scope and harder to optimize, partially due to OpenCL being written as a spec for abstract, heterogeneous hardware, while CUDA was written with the 8000+ series nVidia cards in mind. They'll probably eventually implement OpenCL, but I suspect it will take a back seat to CUDA.
OpenCL has advantages in larger systems (e.g. supercomputers built fr