GPGPU vs Multi-Core CPU

I'd like to say that over time, my role as a graphics programmer has slid more towards the systems programmer side. I've been finding myself on the spot to implement system level code more and more as time has progressed. I chalk it up to a general lack of understanding in the area by other programmers in the industry. As a graphics programmer, my job is to be, at some level, as systems programmer. Granted, the system is a GPU, and the interface is not really traditional, but in reality, I am more aware of performance, memory footprint, and data parallelism than 90% of my peers. For some time I just considered this the 'role' of the graphics programmer. But over time, I saw a very large difference between subsets of roles in graphics programmer tasks. In general, you can easily see a difference between a "Systems-Level graphics programmer" and an "Effects-Level graphics programmer." That is, one of them you run to when your artist needs a new shader effect for the water; The other you run to when 25:31 minutes into your simulation, you get a random memory related crash. Now, don't get me wrong, I enjoy the effects level work as much as anyone, there's a very large area there for research. I just prefer to slide towards architecture as opposed to maintenance. (IMHO you can do cooler stuff if you really understand the hardware.)

Because of this, I get really, really pissed when I hear someone talk about GPGPU vs MCCPU in an idiotic fashion.

The GPU is a specialized core. It has been designed to handle floating point computation and segmented, stream based processing. The reason GPUs get a massive speed improvement, is because they cut out a great deal of the fat that's required to have around when you're dealing with random access patterns. Instead, the GPU forces data type restrictions, memory access, and processing flow. It's really a very defined system, built to handle rasterization. As the hardware has gotten more powerful, programmers have asked for loosening of restrictions over data and processing, which has eventually lead to the GPGPU concept. To be fully explicit about my opinion on this fact : GPGPU is nothing more than a hack. It appeared as a 'nifty trick' that one could use the GPU to help out with other processing requests, and snowballed into a catch-phrase that all APIs and IHVs are molesting as though it were their date at a drunken prom party. If you really think about it, the whole thing started as a 'free' core. Programmers faced systems that had one CPU and one GPU. If they could offload work to the GPU, then they effectively were doing parallel processing, and since their games required a graphics card anyhow, they were guaranteed that their client system would have 2 cores to work with. And since GPUs are commonplace now-adays the cost-effectiveness of this massively powerful chip is available enough for the consumers to grasp.
To summarize, GPGPU is only around because programmers wanted to take advantage of an additional (specialized) core that was available to them. This larger media spin of "GPGPU will cure Cancer!" is idiotic, simply because the GPU cannot do the things that CPUs can.

Now, there are some things that GPUs are really great at. Namely filtering, rasterization, and Floating point operations. But really, we can cut a few of those things out.. It's no surprise that we've had CPU based rasterization for quite some time (and with CPU speeds increasing, multi-core versions should be popping up), so we can take that out of the GPU column. I would say that hardware wise, CPUs are as effecient at FPU ops as GPUs, just not in the batch view that GPUs are. If we consider this a comparison of GPGPU vs MCCPU wrt the types of tasks that you would want to parallelize, then it's worth saying that you'd need the freedom of FPU calculation that GPU doesn't offer; So, remove it from the GPU column.

What you're left with, is a nifty fast piece of filtering hardware.

So, let's cut the fat. Let's take the filtering chip and put it next to a number of CPUs that can handle the FPU computation, and let's throw a new software rasterizer (optimized for MCCPU) in the mix. What comes out of the blender is all the pro's of a GPGPU system, but the freedom of data manipulation and access of a MCCPU system.

To put it in a more illustrative term : You're running a marathon. You've got some awesome shoes that make you run super fast during any straight sections of road (the road must be reasonably flat, and can't curve more than a certain degree). To activate the shoes you need to tie both hands behind your back (wind resistance) and duct-tape your genitalia up (for safety..). At which point you can safely use the shoes. The downside is though, than when you're not running a straight road, the shoes cause you to slowdown by a factor of 50x. So, in order to run the race, you need to balance the number of straight roads with the amount of time it takes you to bind, and unbind yourself (fully, which includes removing the duct-tape...) against the time it takes you to just run the damn thing without the shoes.


In general, the GPU is a tool. It's made to rasterize data. That's what it should be used for.

Regardless of all the huff-and-puff; My guess is that at the end of the day, we will converge at a combination of MCCPU & GPGPUs (MCCPUGPGPU ?)

Say that 3 times fast.

~Main