Slashdot Mirror
AMD's OpenCL Allows GPU Code To Run On X86 CPUs
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."
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.
I am literally 3000 tokens away from the chaotic crossbow --Stephen
Why would anyone ever want to do something well when they can fail at several things?
A bullet may have your name on it but splash damage is addressed "To whom it may concern."
Wouldn't the real benefit be that you wouldn't have to create two separate code-bases to create an application that both supported GPU optimization and could run naively on any system?
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...
Actually, this will provide more flexibility in their optimizations. There are some aspects that the CPU does very well, and there are others that the GPU handle well... being able to say "perform THIS function on the CPU and THAT one on the GPU, will free up resources on each chip. Utilizing the CPU for some functions will free up resources on the GPU, and vise-versa, allowing (theoretically) to optimize the performance of EACH one for a better overall experience.
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?
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
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.
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.
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.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
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.
I am TheRaven on Soylent News
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.
I suppose it really sucks to code in OpenCL and also take advantage of your CPU. It also really sucks that when you have an nVidia card and the code is made for ATI that you can still use it on your CPU. Seriously...
Here be signatures
Welcome back to the days of the math coprocessor....
It's difficult to actually figure out what you are talking about here..from what I see this article is about writing code to the AMD stream framework and have it target X86 (or AMD GPUs).
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.
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.
The OpenCL spec already allowed for running code on a CPU or a GPU. It's just registered as a different type of device. So basically, they are enabling compiling the OpenCL programming language to the x86? I don't really see the story, here.
Sometimes I doubt your committment to SparkleMotion!
The SX is for Sux!
Platform advocacy is like choosing a favorite severely developmentally disabled child.
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.
Don't blame me, I voted for Baltar.
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.
Hi, I am working on an OpenCL implementation sponsored by google summer of code. It is nearly done supporting the CPU and the Cell processor. This news has come to as a blow to me. I have struggled so much with my open source project and now a big company is going to come and trample all over me. boo hoo. http://github.com/pcpratts/gcc_opencl/tree/master
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.
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
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.
Don't blame me, I voted for Baltar.
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.
.
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, in which case there is no transfer penalty because there is no transfer. A limited case, but useful for sure.
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?
The enemies of Democracy are
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?
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.
.