EggXpert

It is not to beat a dead horse but CPU VS GPU always gets our attention.

 SGI Looking Forward Integrating GPUs into High-Performance Computing Platforms.

 When speed truly matters, put it in hardware. Actually only time will tell.

intelguy:

When speed truly matters, put it in hardware.

Still true, but on a whole new level.  In the mid 1970's, some coworkers of mine were writing an application on a minicomputer with writable control store that allowed them to create their own hardware level CPU instructions.  They implemented the most time consuming algorithm in a custom hardware instruction and cut the run time to a fraction.  Now we seem to be evolving entire subsystems devoted to number crunching along with the software standards to take advantage of them.

GPU acceleration became of interest to me back in May when I was researching video cards for my son's Adobe CS4 DVE build.  Does "General Purpose Computing on GPU's" refer to products like Adobe CS4's use of OpenGL on the GPU (as opposed to the CPU)?  Or Wolfram Research's use of OpenGL in their Mathematica product?  If so, then I would have to say the future is already here.

My take on CPU vs GPU from a previous post:

JavaBill:

In 1988 an IBM mainframe had 76 MIPS. Twenty years later, a core i7 @ 3.2GHZ has 1,000 times more MIPS sitting on your desktop.
http://www.hardocp.com/article.html?art=MTU3NiwsLGhlbnRodXNpYXN0
And yet, that pales in comparison to the gigaflop and even teraflop GPU's that are out these days. The age of the desktop teraflop is here, and it's not in the CPU, it's in the GPU.  And that is where OpenGL comes in.  If the 4870 wasn't OpenGL, I suspect it would be of no use to Maya for hardware acceleration of your tasks.  Long story short (I know, too late - that ship sailed a while ago), it all gets back to system requirements of the software bundle.

If I have the facts wrong or have misunderstood this CPU vs GPU subject, perhaps I could use some help getting it right,  However, more than a dead horse, it seems to me that CPU vs GPU has a practical application in picking parts for a computer system.  While you hardware types are probably miles ahead of me on this, I don't see how you could ever overclock a CPU enough to make up for the processing power of a hefty GPU.

JavaBill:

I don't see how you could ever overclock a CPU enough to make up for the processing power of a hefty GPU.

That depends entirely on how parallel the task is that you're processing.. If you're processing a task that is non-parallel and intra-dependent upon it's own results from the previous step, then the same thing can be said about a GPU.. No matter how high you clock the GPU, you'll never be able to meet the processing power of a CPU from 10 years ago..

Some algorithms and tasks simply cannot be made into "GPU" friendly land and instead of trying to cram a square peg through a circle hole, the algorithm or task needs to be completely reworked to be parallel, and it may turn out to not be as efficient as being non-parallel..

In reality, the real world lives in the middle grey area.. Where neither the CPU, nor the GPU is perfectly suited to all tasks..  In reality, you have tasks that can be entirely sequential and then in the next step switch to becoming a little more parallel, and in the next step switching completely over to being fully parallel..

The problem is, although in an ideal world you would use the GPU for all things that can be done parallel / shotgun style and the CPU for all things that are self-refrential,  tasks can go from being completely sequential to completely parallel in the blink of an eye.. Tracking a single asteroid floating across the screen is sequential, and then blowing it up into thousands of pieces instantly becomes a very parallel task.  So ideally, when things become parallel you should move them over to the GPU and when things on the GPU become sequential you should move them over to the CPU where they will be processed faster due to the higher clock speeds.. Problem is, the architectures are different, the microcode / assembly that they're compiled into is different, and the CPU and GPU are separated by a bus with very limited bandwidth.

Theoretically, the real solution to the problem is to build a massively parallel processor into a CPU and a high speed sequential processor into a GPU so that tasks can switch from being parallel to sequential and then back again without having to surf back and forth across a bus...  Hence, AMD Fusion..

Edit: For example of why sequential tasks on the GPU are so slow.. A GPU may have hundreds of shader cores, but if you've got an entirely sequential task, then only one out of those hundreds of shaders would be usable and since GPU shaders are clocked much lower than a CPU core, it would run much slower on a GPU..  You simply wouldn't be able to use the other shaders.. Some things can be made more parallel by tweaking the alogirthm, but some things simply can't.

Sidicas:

If you're processing a task that is non-parallel and intra-dependent upon it's own results...

I can see where a massively parallel architecture would not be any benefit for the inherently serial nature of some computing tasks.

Sidicas:

...parallel to sequential and then back again without having to surf back and forth across a bus...

And I can see where bus time would be a factor if you have to switch back and forth too much.  (That AMD Fusion concept sounds really cool.)

Sidicas:

...then only one out of those hundreds of shaders would be usable and since GPU shaders are clocked much lower than a CPU core, it would run much slower on a GPU.

Does that mean a 1/2 gigaflop GPU actually is a few hundred shaders that all add up to 1/2 gigaflop, as opposed to a 1/2 gigaflop being available in one stream?  I guess had been picturing it all in one stream to do a massive compute intensive task.

While that rearranges my thinking a bit, it still seems to me that the GPU would be a great place to farm out a compute intensive task while I (as the CPU) go off and do something else entirely different, and then come back to the GPU later to get the results.  I was thinking that was what the nVidia CUDA architecture (over simplified) was all about, maybe not.  However it is architected, it seems to help the render times in CS4.  In any case, I've got a lot more reading to do.

JavaBill:

Does that mean a 1/2 gigaflop GPU actually is a few hundred shaders that all add up to 1/2 gigaflop, as opposed to a 1/2 gigaflop being available in one stream?  I guess had been picturing it all in one stream to do a massive compute intensive task.

No, each shader is itself a stream processor.. A stream processor is just another fancy name for a shader.   So a few hundred shaders is a few hundred potential compute "streams" that could be running simultaneously. Generally speaking, you would run these "streams" to compute how light reflects on the object across hundreds of sample points. Often there are special textures called "bump maps" which basically scew the way light reflects off of the object at these surface points to give the illusion that there's depth to a completely flat surface.. For example, a tile floor on the ground in Half Life 2 is actually a completely flat, or sometimes slightly curved surface.. The bump map scews how light bounces off of it at certain points and then you have the illusion that the surface tiles have depth because the edges of the tiles reflect light differently than the center of the tile.. It's one of the many ways games "cheat" realitiy, but it's still far from perfect as light reflected off of these tiles do not go on to illumintae other objects as would happen in real life and would be rendered properly by a real ray-tracer..  The stream processors make a "pass" over the texture bump mapped floor and can compute exactly how much lighting to render at each point across the floor to make the floor tiles look like they have depth that it really does not. However, they don't actually go so far as to make complete traces of the rays of light as they bounce around as the hardware is just not fast enough for that.

The general goal of computer graphics is, the less "cheating" that's done, the more realistic things will look, and also the more computationally expensive it will be, but it's what people ultimately want.

Games still "cheat" like crazy to get that extra bit of quality with as little processing as possible and that's likely to be true well into the future. It's a "fool the eye" technique, but in most cases if you look closely enough at it, it just won't look realistic.. Especially if you know what you're looking for.

 

JavaBill:

While that rearranges my thinking a bit, it still seems to me that the GPU would be a great place to farm out a compute intensive task while I (as the CPU) go off and do something else entirely different, and then come back to the GPU later to get the results.  I was thinking that was what the nVidia CUDA architecture (over simplified) was all about, maybe not. 

That's exactly what it's for, and more.. OpenCL (not to be confused with OpenGL) does the same thing.. But the major selling point of these architectures is that in the end, you end up with a whole pile of raw data that can then be reprocessed / regurgitated instead of a rendered frame that you would traditionally get from a fixed pipeline which would be wiped every pass / frame. In other words, think of newer graphics cards as data being able to take "shortcuts" back into recomputation with other data instead of ending up at the end of the pipeline with nowhere to go except getting "flushed" (real term by the way) from the buffer / down the toilet when it's done with it... 

To use an analogy...  Graphics cards of yester-year with the fixed pipeline is just like an assembly line at a car manuf. plant..  They start at the beginning and when they get to the end you have your rendered frame..

Graphics cards of today and of the future, data may get half way through the assembly line,  and then depending on it's result, that data can go back and rebuild it's own assembly line and send itself back through it again.. Now take each asssembly line and multiply that by the number of shaders / stream processors and then consider that all the data in each assembly line can be combined with data in other assembly lines after they've reached certain points in their processing which, combined, may also go back and configure the assembly line to process the combined data and again send themselves through it..  

Gives you a better idea of how complex these graphics cards are becoming, but most of the really nasty stuff is handled by the architecture CUDA / OpenCL.. As long as your task is parallel, you let CUDA and OpenCL worry about the details of the assembly lines (each shader's work flow), that's what they're there for.

Nice article. Thanks fir the link.