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."

Comments

Nice

[clarkn0va]

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.

Re:Nice

[clarkn0va]

I suppose I could have been clearer. I'm talking about gpu decoding of HD video, conspicuously absent on AMD hardware in Linux, fully functional on NVIDIA.

Re:Nice

[MostAwesomeDude]

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...

Re:Optimization

[Shadow of Eternity]

Why would anyone ever want to do something well when they can fail at several things?

Intel counters with CPU+GPU on a chip

[fibrewire]

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...

Overhyped

[TheRaven64]

Compiling OpenCL code as x86 is potentially interesting. There are two ways that make sense. One is as a front-end to your existing compiler toolchain (e.g. GCC or LLVM) so that you can write parts of your code in OpenCL and have them compiled to SSE (or whatever) code and inlined in the calling code on platforms without a programmable GPU. With this approach, you'd include both the OpenCL bytecode (which is JIT-compiled to the GPU's native instruction set by the driver) and the native binary and load the CPU-based version if OpenCL is not available. The other is in the driver stack, where something like Gallium (which has an OpenCL state tracker under development) will fall back to compiling to native CPU code if the GPU can't support the OpenCL program directly.

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:Optimization

[olsmeister]

Welcome back to the days of the math coprocessor....

Re:The real benefit

[Red Flayer]

to create an application that both supported GPU optimization and could run naively on any system?

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.