Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

AMD's OpenCL Allows GPU Code To Run On X86 CPUs

timothy posted more than 5 years ago | from the now-that's-something-like dept.

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

cancel ×

176 comments

Sorry! There are no comments related to the filter you selected.

Nice (5, Interesting)

clarkn0va (807617) | more than 5 years ago | (#28975447)

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 (2, Funny)

Anonymous Coward | more than 5 years ago | (#28975603)

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 (5, Informative)

clarkn0va (807617) | more than 5 years ago | (#28975703)

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. [slashdot.org]

Re:Nice (1, Insightful)

Anonymous Coward | more than 5 years ago | (#28976309)

No you shouldn't, this way you got +5 interesting AND +5 informative ;)

Re:Nice (5, Informative)

MostAwesomeDude (980382) | more than 5 years ago | (#28976311)

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:Nice (3, Insightful)

Briareos (21163) | more than 5 years ago | (#28976495)

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)

Re:Nice (0)

Anonymous Coward | more than 5 years ago | (#28976489)

Umm...what netbooks have 1080p resolution that would make this essential?

Re:Nice (1, Insightful)

Anonymous Coward | more than 5 years ago | (#28977401)

Wai any netbook that has a DVI, VGA or HDMI port that is connected to a widescreen monitor, silly!

Re:Nice (0)

Anonymous Coward | more than 5 years ago | (#28976731)

The Radeon R700 chip already supports H.264/MPEG-4 AVC decoding on hardware.

Re:Nice (2, Insightful)

Bootarn (970788) | more than 5 years ago | (#28977153)

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 (-1, Troll)

infaustus (936456) | more than 5 years ago | (#28977231)

Your 1080p h264 files are probably just shitty upscales of low quality divx files some weeaboo downloaded off of Share.

Re:Nice (2, Interesting)

Anonymous Coward | more than 5 years ago | (#28978707)

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.

fp (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28975453)

trannies, get your ass-pussies ready!

Re:fp (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#28975651)

JEWBOMB!

Isn't there a fundamental problem... (1)

tjstork (137384) | more than 5 years ago | (#28975463)

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:Isn't there a fundamental problem... (1)

InsertWittyNameHere (1438813) | more than 5 years ago | (#28975639)

If it was a problem then it wouldn't have been worth it to have a separate GPU in the first place.

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:Isn't there a fundamental problem... (1)

Elshar (232380) | more than 5 years ago | (#28978685)

No, it'd still be worth it. Right now hardware acceleration (using the GPU to generate graphics) is done via sending instructions to the GPU which then do all the work of rendering the scene and sending out to your display.

What they're talking about is having the *CPU* render the scene, or at least part of it and then handing *THAT* off to the display.

The problem that the GP was talking about is that there's only so much BW available on the system bus and with alot of things going on, it's possible to max out that BW and actually cause a degradation of performance if it's not handled correctly.

Re:Isn't there a fundamental problem... (0)

Anonymous Coward | more than 5 years ago | (#28975665)

smaller problems are usually faster to run on CPU, while larger problems can be much faster to run on GPU. And programmer and the framework has to consider the trade-offs when deciding where to send the work load.

Re:Isn't there a fundamental problem... (2, Interesting)

Eddy Luten (1166889) | more than 5 years ago | (#28975709)

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:Isn't there a fundamental problem... (2, Interesting)

iluvcapra (782887) | more than 5 years ago | (#28976371)

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... (1)

apharmdq (219181) | more than 5 years ago | (#28977309)

Please elaborate. I've been using OpenAL for a long time now, and I've come to prefer it to any other audio API. It may be lower-level than most, but it's fast, robust, and cross-platform. (Of course, it depends on what you're developing for, but to say that it's a joke of an API, you imply that it's useless. From what I've seen in the industry, it seems to be gaining quite a bit of momentum.)

Re:Isn't there a fundamental problem... (4, Interesting)

iluvcapra (782887) | more than 5 years ago | (#28978205)

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:Isn't there a fundamental problem... (2, Informative)

ByOhTek (1181381) | more than 5 years ago | (#28975765)

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:Isn't there a fundamental problem... (2, Interesting)

kramulous (977841) | more than 5 years ago | (#28978765)

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... (2, Interesting)

schwaang (667808) | more than 5 years ago | (#28978799)

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... (4, Interesting)

sarkeizen (106737) | more than 5 years ago | (#28975977)

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.

Re:Isn't there a fundamental problem... (1)

tjstork (137384) | more than 5 years ago | (#28977077)

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 i

Not so much as the code but the data. If you have a giant array of stuff to crunch, then yeah, shipping it to the card makes sense. But if you have a lot of tiny chunks of data then, it may not make as much sense to ship it all over to the card. That same problem is really what haunts multicore designs as well - its like you can build a job scheduler that takes a list of jobs and have threads servicing it, but at some point, the overhead of having your thread wait to get a job is more than its worth and certainly the act of creating a thread is pretty expensive.

Re:Isn't there a fundamental problem... (1)

sarkeizen (106737) | more than 5 years ago | (#28978259)

I suppose it depends on what you mean by "lots of tiny chunks". Clearly doing a single "burst" transfer is better than lots of small ones but if you are still planning to process all these "chunks" of data at the same time then there's no reason why you couldn't just ship them all together and process them individually. Perhaps even from shared memory.

Unless of course we're taking about a bunch of chunks that are not going to be worked on simultaneously which goes back to my statement about the degree of parallelism that can be achieved being your chief worry.

Optimization (-1, Troll)

Aladrin (926209) | more than 5 years ago | (#28975477)

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-

Re:Optimization (5, Funny)

Shadow of Eternity (795165) | more than 5 years ago | (#28975547)

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

Re:Optimization (-1, Troll)

V!NCENT (1105021) | more than 5 years ago | (#28975873)

Is it realy that bad that when the load on your GPU is 100% that you can also use the CPU for the rest of the load? Moron!

Re:Optimization (3, Insightful)

jjoelc (1589361) | more than 5 years ago | (#28975623)

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.

Re:Optimization (4, Insightful)

Timothy Brownawell (627747) | more than 5 years ago | (#28975625)

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?

Re:Optimization (1)

raftpeople (844215) | more than 5 years ago | (#28977155)

The problem is typically with how you set up your data structures to solve the problem at hand. When I converted my CPU code to run on a GPU, I had to go through and re-work the problem. I changed the way my data was stored, which was previously optimized for CPU serial processing and caching etc. to something that matched the GPU's model of queuing up read requests of multiple adjacent words while previously read memory is being processed.

These types of changes aren't really optimizations the compiler can do.

Re:Optimization (1)

ThePhilips (752041) | more than 5 years ago | (#28977159)

It was already explained above. CPU and GPU are very different at handling things, meaning that top level algorithms used are very different.

Unless of course you can point at a compiler which can rethink and rewrite the program.

Re:Optimization (1)

ByOhTek (1181381) | more than 5 years ago | (#28975827)

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:Optimization (1)

russotto (537200) | more than 5 years ago | (#28976049)

Man, why did we ever stop using assembly?

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:Optimization (2, Interesting)

V!NCENT (1105021) | more than 5 years ago | (#28975857)

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

Re:Optimization (5, Insightful)

olsmeister (1488789) | more than 5 years ago | (#28975897)

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

Re:Optimization (1)

HomelessInLaJolla (1026842) | more than 5 years ago | (#28975989)

Insightful, funny, best post yet

Re:Optimization (4, Funny)

earnest murderer (888716) | more than 5 years ago | (#28976357)

The SX is for Sux!

Re:Optimization (1, Funny)

Anonymous Coward | more than 5 years ago | (#28978383)

I used to have a 486 40mhz DLC cpu from Texas Instruments. It didn't have a math co-processor... Can you believe it? A TI chip that couldn't do math!

We used to joke that DLC stood for:

Da Low Cost

Re:Optimization (1)

AcidPenguin9873 (911493) | more than 5 years ago | (#28977127)

And to take that one step further, both Intel and AMD are planning on integrating the GPU on-die in future products, just like the math coprocessor moved on-die 15-20 years ago.

The real benefit (4, Insightful)

HappySqurriel (1010623) | more than 5 years ago | (#28975585)

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?

Re:The real benefit (1)

V!NCENT (1105021) | more than 5 years ago | (#28975889)

Thank you _O_

Re:The real benefit (5, Funny)

Red Flayer (890720) | more than 5 years ago | (#28975949)

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.

Intel counters with CPU+GPU on a chip (5, Interesting)

fibrewire (1132953) | more than 5 years ago | (#28975591)

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 (3, Insightful)

avandesande (143899) | more than 5 years ago | (#28978045)

Microsoft wouldn't allow licensing dual cores on netbooks.

Makes sense (3, Interesting)

m.dillon (147925) | more than 5 years ago | (#28975687)

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:Makes sense (1)

shentino (1139071) | more than 5 years ago | (#28976337)

How do you handle translucency when you have a Z buffer?

Use both at the same time? (2, Interesting)

TejWC (758299) | more than 5 years ago | (#28975691)

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:Use both at the same time? (1)

jerep (794296) | more than 5 years ago | (#28976899)

I am pretty sure these are details for the implementation of OpenCL, not for client code. It is the very reason why libraries such as OpenGL/CL/AL/etc exists, so you don't have to worry about implementation details in your code.

From what I know of the spec, you would just create your kernel, feed it data, and execute it, the implementation will worry about sharing the work between the CPU and GPU to get optimal performance.

However, I don't think it would be optimal to have all 4 cores of the CPU running on parallel tasks when the GPU has dozens more processing cores dedicated for such tasks, the CPU will better be spent doing system tasks.

Re:Use both at the same time? (1, Informative)

Anonymous Coward | more than 5 years ago | (#28977017)

From what I know of the spec, you would just create your kernel, feed it data, and execute it, the implementation will worry about sharing the work between the CPU and GPU to get optimal performance.

No. Any individual OpenCL kernel runs solely on one device (be it CPU, GPU, or otherwise). If you want to run a kernel on multiple devices you must manually divide the work into multiple kernels and setup an OpenCL context on each device you wish to use.

DIDN'T APPLE COME UP WITH THIS ABOUT A YEAR AGO??? (0)

Anonymous Coward | more than 5 years ago | (#28975695)

This is old news, Apple has been touting this for a year now, not AMD.

Re:DIDN'T APPLE COME UP WITH THIS ABOUT A YEAR AGO (2, Informative)

TejWC (758299) | more than 5 years ago | (#28975793)

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:DIDN'T APPLE COME UP WITH THIS ABOUT A YEAR AGO (0, Informative)

Anonymous Coward | more than 5 years ago | (#28975921)

nVidia has had a full implementation of OpenCL out for months now.

Re:DIDN'T APPLE COME UP WITH THIS ABOUT A YEAR AGO (0)

Anonymous Coward | more than 5 years ago | (#28975963)

However, its beta and only accessible via the "OpenCL Early Access Program" which you have to apply for.

Re:DIDN'T APPLE COME UP WITH THIS ABOUT A YEAR AGO (0)

Runefox (905204) | more than 5 years ago | (#28976065)

No they haven't [nvidia.com] . Only as of last month have they had a release candidate for the developers-only crowd. I think you're thinking of CUDA, which is an nVidia-only technology similar to OpenCL, but differing in implementation (and I believe openness as well). Along with OpenCL, DirectX 11 is also bringing "Compute Shaders" into the DirectX model, making this kind of thing a requirement for a DX11 GPU.

Re:DIDN'T APPLE COME UP WITH THIS ABOUT A YEAR AGO (0)

Anonymous Coward | more than 5 years ago | (#28978011)

My bad, I forgot it was still for developers only. Although frankly it's so easy to become an nVidia "developer" that it may as well be called a public beta.

Re:DIDN'T APPLE COME UP WITH THIS ABOUT A YEAR AGO (1)

Sir_Sri (199544) | more than 5 years ago | (#28976013)

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.

CUDA is the reverse (0)

raftpeople (844215) | more than 5 years ago | (#28977289)

CUDA allows you to easily compile C code to run on the GPU, not the reverse.

Re:DIDN'T APPLE COME UP WITH THIS ABOUT A YEAR AGO (0)

Anonymous Coward | more than 5 years ago | (#28977361)

The PR freaks have always said CUDA could and would work where ever nvidia want, ie CPU or supercomputers. Look up the stanford uni "Computer Systems Colloquium - Winter 2008 - Scalable Parallel Programming with CUDA on Manycore GPUs (February 27, 2008) - (February 27, 2008) John Nickolls from NVIDIA ". Video should be on the net somewhere.

Overhyped (5, Informative)

TheRaven64 (641858) | more than 5 years ago | (#28975777)

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:Overhyped (1)

MemoryDragon (544441) | more than 5 years ago | (#28978313)

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.

I assume so OpenCL for ATI cards is heavens sent, since ATI seems to get nowhere with their custom shader language solutions, unlike NVidia which made heavy inroads with CUDA on the video codec front.
I am rather sick of having a powerhorse which rivals the best nvidia cards and yet all the codecs use CUDA for video coding acceleration!

Re:Overhyped (1)

caramelcarrot (778148) | more than 5 years ago | (#28978355)

Yeah, CUDA does this already as far as I know. Kernels you write in their version of restricted C can be transparently called as CPU code if you don't have an available physical CUDA device.

GPUs are dying - the cycle continues (2, Insightful)

realmolo (574068) | more than 5 years ago | (#28976029)

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 (3, Insightful)

Pentium100 (1240090) | more than 5 years ago | (#28976221)

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.

Re:GPUs are dying - the cycle continues (3, Insightful)

Khyber (864651) | more than 5 years ago | (#28976415)

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.

Re:GPUs are dying - the cycle continues (1)

MistrBlank (1183469) | more than 5 years ago | (#28976759)

Technology fail.

Re:GPUs are dying - the cycle continues (0)

Anonymous Coward | more than 5 years ago | (#28978713)

Technobabble advertising win.

Re:GPUs are dying - the cycle continues (1)

Eddy Luten (1166889) | more than 5 years ago | (#28976573)

CPUs are infamously bad at processing floating point operations, this is the reason that dedicated GPUs were invented in the first place. A graphics processor like the GTX 285 has 240 stream processors that are manufactured for processing floating point numbers but really bad at integer operations. A CPU like a Core 2 Quad has four cores that are really good at integer operations but requires CPU extensions like SSE to do high performance floating point operations.

Both Intel and AMD are currently manufacturing CPU/GPU hybrids that would kind of balance both these worlds: Larrabee [wikipedia.org] a GPU-like addon, AMD Fusion [wikipedia.org] an on-chip solution. We'll see what kind of API hell they will bring.

Re:GPUs are dying - the cycle continues (3, Interesting)

SpinyNorman (33776) | more than 5 years ago | (#28976591)

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.

Re:GPUs are dying - the cycle continues (1)

NoOneInParticular (221808) | more than 5 years ago | (#28978123)

Actually, ray tracing would be an area where a multi-core CPU would help. There's some progress, but in contrast with scanline rendering, ray tracing is very GPU unfriendly. So, for photo-realism, the future might still be with the CPU.

Not any time soon (4, Insightful)

Sycraft-fu (314770) | more than 5 years ago | (#28976755)

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.

Re:Not any time soon (1)

ShadowRangerRIT (1301549) | more than 5 years ago | (#28977217)

The question is why? Ideology should not make this determination. Assuming the current trajectories continue (or close enough to what we've seen so far), by the time the CPU can do what we want, the GPU will still be able to do it faster and with less waste. Energy costs aren't likely to drop in the next 50 years, and the GPU applications (e.g. 3D modelling/lighting) that we've done with a CPU based approach (ray tracing) usually require 10x the hardware. If one GPU (drawing, for example 200 watts) can do the work of 10 CPUs (each drawing 50 watts), you need to give a compelling, non-ideological reason for why the CPU is the better option. As the increasing number of GPGPU accelerated apps has shown, there are a lot of things that are better done with semi-specialized hardware. No, we don't need a special chip for every complex task, but at the same time it's ludicrous to ignore the advantages of specialization when you have so many tasks that benefit from it.

Re:Not any time soon (1)

Miseph (979059) | more than 5 years ago | (#28977541)

Simplicity and size. The less components we need, and the smaller they can be, the better. Ultimately, if programmers didn't NEED to split up their code to run on different processors, they wouldn't, because it just makes life harder. Having one chip that handles everything makes that so, and having an API that brings us closer to a place where that makes intuitive sense is a logical progression toward that end.

Re:Not any time soon (1)

darkwing_bmf (178021) | more than 5 years ago | (#28978677)

I don't think you understand. CPU transistor count is getting to the point where turning additional transistors into another general purpose core doesn't make as much sense as making a specialized graphics circuit with them on the same chip.

Re:GPUs are dying - the cycle continues (2, Informative)

ShadowRangerRIT (1301549) | more than 5 years ago | (#28976775)

There's only two ways to do that:

  1. Some of the cores are specialized in the same way that current GPUs are: You may lose some performance due to memory bottlenecks, but you'll still have the specialized circuitry for doing quick vectored floating point math.
  2. You throw out the current graphics model used in 99% of 3D applications, replacing it with ray tracing, and lose 90% of your performance in exchange for mostly unnoticeable improvements in the quality of the generated graphics.

Of course, you're reading this the wrong way. You think they are trying to replace GPUs with CPUs. They're really just trying to deal with the fact that some systems lack GPUs, and many systems with GPUs will have underutilized CPUs. GPGPU applications are using the specialized GPU hardware for a reason; falling back to CPU is for improved compatibility with low end systems and full hardware utilization on high end ones; it's not intended to get rid of the GPU (defined as any chip specializing in minimal branching, high throughput, vectorized floating point math).

Take a look at Folding@Home sometime. They have a CPU and GPU client. They are both trying to solve protein folding problems. The CPU, being good at integer math, looks at the problem as a discrete particle simulation. The GPU, being good at bursts of floating point math, models the system in a continuous way (see their site for a complete explanation). While the GPU results have a small margin for error (due to FP rounding), they're still one of the best clients from the perspective of advancing the field, because on similar value hardware (say, an recent Core2Duo vs. a 8800GTX) they solve similar problems 5-10x faster. If they could run the GPU specific code on a CPU it wouldn't do them any good; since the CPU is bad at that type of problem, they'd end up doing worse than running the correct client on the CPU. The CPU clients can double check the GPU results if needed, but the GPU is by far the fastest at sorting plausible from implausible results.

Re:GPUs are dying - the cycle continues (2, Funny)

Scott Francis[Mecham (336) | more than 5 years ago | (#28976869)

And so, the wheel [catb.org] starts another turn.

Re:GPUs are dying - the cycle continues (0)

Anonymous Coward | more than 5 years ago | (#28976875)

No, we won't. Not without massive speedups in the bus speed between ram and cpu. My card has 57.8 GB/sec transfer rates with a 256 bit bus. It also has 112 stream processors running at 600Mhz. This is just stock; I could overclock it for more performance. Using one or two cores simply could not match all 112, given that rasterized rendering is 'embarrassingly parallel'.

We won't see CPUs capable of that for a while.

Funny, cus this is about GPU ascendency. (1)

Chris Burke (6130) | more than 5 years ago | (#28977185)

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.

LOL. That's funny, because this is about exactly the opposite -- using the very impressive floating point number crunching power of the GPU to do the work that the CPU used to do. OpenCL is essentially an API for being able to use your GPU for general purpose computing. Not a way to use your CPU to do rendering (OpenGL already does that).

Your CPU, four cores and all, is a LOOOOOOONG way from being able to do what your graphics card does wrt 3d rendering. That's okay, the tradeoffs are different for something that's supposed to be able to run databases just as competently as finite element analysis. But for raw floating point throughput on embarassingly parallelizable tasks -- which the 3d rendering pipeline is, and thus why GPUs are optimized around it -- the GPU is miles ahead. Thus the motivation to use it instead of the 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.

Well you got that right at least, but the way it's going to happen is that you're still going to have a GPU, but it's going to be on the same piece of silicon as your CPU. Both Intel and AMD have combined CPU/GPU products in the pipe that are supposed to be released in 2011, meaning they have been in development for a number of years now.

Discrete graphics will live on for quite a while though in situations where low power is less important than performance. Both cpu and gpu having separate memory with their own memory controllers optimized for their needs is a big advantage over sharing a memory bus and memory controller. Not having to fit both functions within a single socket's TDP budget is another.

Eventually, the built-in UMA graphics may become good enough that it doesn't make sense to have a separate card. In the meantime, discreet graphics cards will live on, and the GPU in general ain't going anywhere -- it's only becoming even more important!

Who modded this insightful? (1)

Prien715 (251944) | more than 5 years ago | (#28977313)

If history tells us anything, it's quite the opposite. For years, graphics cards have been getting more and more cores and applications (especially games or anything 3D) have come to rely on them much more than the CPU. I remember playing Half-life 2 with a 5 year old processor and a new graphics card...and it worked pretty well.

The CPU folk, meanwhile, are being pretty useless. CPUs haven't gotten much faster in the past 5 years; they just add more cores. Which is fine from the perspective of a multiprocess OS, but the fact remains that some algorithms you can parallelize, others you can't...and a GPU with hundreds of cores is only going to be as fast at one of these as its fastest core.

We'll see. My bet is if Intel/AMD just keep dumping more cores in the processors, they'll risk becoming irrelevant as we'll have more processors than we know what to do with (see the SGI's Prism...which was terribly slow despite having dozens of processors.)

Re:GPUs are dying - the cycle continues (1)

johnthorensen (539527) | more than 5 years ago | (#28977391)

Except that GPU architecture is pretty different from that of a CPU. IANAE(xpert), but from what I understand the GPU is very, very, parallel compared to a CPU thanks to how easily parallelized most graphics problems are. Though CPUs are gaining more cores, I think that the difficulty in parallelizing many problems places a practical limit on the CPU's parallelism.

That's not to say though that a GPU-type parallel core can't be integrated into the CPU package, however. I believe NVIDIA is doing some of this?

Not exactly (1)

raftpeople (844215) | more than 5 years ago | (#28977411)

"Now that we have CPUs with literally more cores than we know what to do with,"

For many problems, multi-core CPU's aren't even close to having enough power, that's why all of the interest in utilizing the GPU processing power.

They are different ends of a spectrum: CPU generally=fast serial processing, GPU generally=slow serial, fast parallel. Some problems require fast serial processing, some require fast parallel processing and some are in between. Both are valuable tools and neither will replace the other, although merging them onto one chip with shared memory/cache would be great.

Re:GPUs are dying - the cycle continues (1)

youshotwhointhewhat (1613613) | more than 5 years ago | (#28978813)

You are fundamentally wrong for many reasons: 1) Highly data-parallel problems (like graphics) are always going to be solved faster on a GPU-like architecture. 2) GPUs are gaining processing power at a higher rate than CPUs. 3) Power/heat/cost for the number of CPUs needed to match the processing power of a GPU-based solution is always going to be worse. The mentality of one size fits all for processor architectures is what is actually dying.

What's the story? (2, Informative)

trigeek (662294) | more than 5 years ago | (#28976189)

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.

Expect more of this in the near future (1, Interesting)

Anonymous Coward | more than 5 years ago | (#28976305)

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:Expect more of this in the near future (2, Interesting)

ShadowRangerRIT (1301549) | more than 5 years ago | (#28976991)

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:Expect more of this in the near future (1)

UncleFluffy (164860) | more than 5 years ago | (#28977293)

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.

Do you have evidence for this statement? Code that you can share?

Re:Expect more of this in the near future (1)

Chris Burke (6130) | more than 5 years ago | (#28977513)

CUDA is the GLIDE of the GP-GPU movement. In the short term it may be highly attractive due to features, completeness, optimization, and so forth, and you'll see applications using it for this reason. In the long run it's a dead-end. Just like with rendering APIs, the winners will be one or both of the following: The open and cross-platform API, or the one Microsoft is creating.

gn44 (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#28976457)

head spinning and financial Playing so it's Most people into a for election, I sales and so on, there are exactly what you've It's best to try to avoid so as to the channel to sign GNAA (GAY NIGGER Bombshell hit visions going JUUGERNAUT EITHER faster, cheaper, [nero-online.org] community at time wholesome and prospects are world's Gay Nigger (7000+1400+700)*4 brilliant plan All our times have plainly states that as fittingly knows for sure what Wash off hands were taken over Indecision and copy a 17 Meg file bunch of gay negros in ratio of 5 to achievements that most people into a of the above [tuxedo.org], walk up to a play hot on the heels of study. [rice.edu] Wash off hands

Does OpenCL Make Parallel Programming Easy? (1)

Louis Savain (65843) | more than 5 years ago | (#28976753)

This is essentially what it comes down to. Does OpenCL make parallel programming of heterogeneous processors easy? The answer is no, of course, and the reason is not hard to understand. Multicore CPUs and GPUs are two incompatible approaches to parallel computing. The former is based on concurrent threads and MIMD (multiple instructions, multiple data) while the latter uses an SIMD (single instruction, multiple data) configuration. They are fundamentally different and no single interface will get around that fact. OpenCL (or CUDA) is really two languages in one. Programmers will have to frequently flip their mode of thinking in order to take effective advantage of both technologies and this is the primary reason that heterogeneous processors will be a pain to program. The other is multithreading, which, as we all know, is a royal pain in the arse in its own right.

Obviously what it needed is a new universal parallel software model, one that is supported by a single *homogeneous* processor architecture. Unfortunately for the major players, they have so much money and resources invested in last century's processor technologies that they are stuck in a rut of their own making. They are like the Titanic on a collision course with a monster iceberg. Unless the big players are willing and able to make an about-face in their thinking (can a Titanic turn on a dime?), I am afraid that the solution to the parallel programming crisis will have to come from elsewhere. A true maverick startup will eventually turn up and revolutionize the computer industry. And then there shall be weeping and gnashing of teeth among the old guard.

Read How to Solve the Parallel Programming Crisis [blogspot.com] if you're interested in an alternative approach to parallel computing.

Open Source OpenCL Compiler? (1)

onionman (975962) | more than 5 years ago | (#28976841)

So, where can one obtain an open source OpenCL compiler? (Or, to be more precise, an open source compiler which can take OpenCL compliant code and produce object code that will run on my GPU via the driver stack?)

UniversCL (2, Interesting)

phil_ps (1164071) | more than 5 years ago | (#28976865)

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 [github.com]

eD4! (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28977151)

Who cares? (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#28977213)

I *could* use a bicycle to commute miles to work, but there's no reason to since I already have a car.

Unsurprising (1)

SleepyHappyDoc (813919) | more than 5 years ago | (#28977517)

AMD obviously has a vested interest in making their scheme an industry standard, so of course they'd want to support Larrabee with their GPGPU stuff. Larrabee has x86 lineage (of some sort, I'm not clear on exactly what or how), so they'd have to have at least some x86 support to be able to use their scheme on Larrabee. It seems to me that if they were going to bake some x86 support in there, they may as well add regular CPUs in as well (if you already wrote 90% of it, why not write the other 10%?).

I don't really know anything about this kind of stuff, but this news strikes me as unsurprising, given the environment.

Download link please? (1, Funny)

Anonymous Coward | more than 5 years ago | (#28977551)

Where is the link to the source tarball?
Can't find it, just some more mumbo jumbo about delivering seameless integration with the goatse paradigm shift, blah, blah, etc.

Bah. The Amiga did it already. (1)

straponego (521991) | more than 5 years ago | (#28977741)

http://everything2.com/index.pl?node_id=1311164&displaytype=linkview&lastnode_id=1311164

Exactly the same thing.

I said EXACTLY!

[wanders off, muttering and picking bugs out of beard]

Undermining Larrabee? (1)

w0mprat (1317953) | more than 5 years ago | (#28978309)

Is AMD cleverly trying to undermine Intel's Larrabee threat? If this code can run abstracted enough that it doesn't matter what CPU/GPU is under the hood, this knocks out the main point of selling point larrabee: x86 code.

(Ars makes a similar point:)

the fact that Larrabee runs x86 will be irrelevant; so Intel had better be able to scale up Larrabee's performance

If AMD is working on a abstraction layer that lets OpenCL run on x86, could the reverse be in the works, having x86 code ported to run on CPU+GPGPU as one combined processing resource? AMD may be trying to make it's GPUs more like what Intel is trying to achieve with larrabee - a bridge between CPU and GPU -- yet Intel is originally trying to undermine the GPU as a unique processing platform.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?