AMD's OpenCL Allows GPU Code To Run On X86 CPUs 176
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."
Nice (Score:5, Interesting)
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...
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
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.
Re:Isn't there a fundamental problem... (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:Optimization (Score:2, Interesting)
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.
Expect more of this in the near future (Score:1, Interesting)
Note that this OpenCL implementation works for CPU only. GPU support is forthcoming.
However, we know that Mac OSX (Snow Leopard) will soon be shipping with an OpenCL implementation.
I think we can expect full OpenCL (CPU & GPU) support from Intel, ATI/AMD, and nVidia sooner rather than later.
Re:Isn't there a fundamental problem... (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: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.
UniversCL (Score:2, Interesting)
Re:Expect more of this in the near future (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 from large numbers of commodity processors), but on a single machine, the heterogeneous support gains you little; CUDA's focus on the GPU often means the GPU does more work than an OpenCL program using both GPU and one or two CPU cores.
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.
Re:Nice (Score:2, Interesting)
That's hilarious. Maybe you should quit buying nvidia hardware, then.
Maybe I should be a little clearer: you should have quit buying nvidia hardware in September of 2008 [phoronix.com] , because hardware acceleration for video on Linux has been available since then, with the official AMD/ATI driver.
Re:Isn't there a fundamental problem... (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:Isn't there a fundamental problem... (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:2, Interesting)
As a related aside to this, how long before GPU's include a form of audio processing as well. We want to offload radiosity effects to video cards. GPGPU is one way, although specialized support for this that utilizes the graphics card's inherent knowledge of object positioning might be somewhat preferable
At the same time it might be beneficial to consider a similar, but slightly more general problem. Radiosity utilizes reflectivity "textures" to calculate final light levels. One could easilly imagine applying audio reflectivity textures to objects, and simulating the reflections of sound to produce the final sound. Thus if the player is standing on the other side of a large audio absorptive object from the sound source the sound would be muffled. If a sound occurred in a large cavern-style area with appropriate sound textures it would inherently echo. Clearly there are some substantial similaries between the two, although of course the differences are also significant. Never the less, it seems reasonably possible to design a GPU hardware addition that is capable of performing the calculations for either, no?
Re:Intel counters with CPU+GPU on a chip (Score:3, Interesting)
Comment removed (Score:3, Interesting)
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!