Take the 2-minute tour ×

So I've always been under the impression that doing work on the GPU is always faster than on the CPU. Because of this, in OpenGL, I usually try to do intensive tasks in shaders so they get the speed boost from the GPU. However, now I'm starting to realize that some things simply work better on the CPU and actually perform worse on the GPU (particularly when a geometry shader is involved). For example, in a recent project I did involving procedurally generated terrain, I tried passing a grid of single triangles into a geometry shader, and tesselated each of these triangles into quads with 400 vertices whose height was determined by a noise function. This worked fine, and looked great, but easily maxed out the GPU with only 25 base triangles and caused a very slow framerate. I then discovered that tesselating on the CPU instead, and setting the height (using noise function) in the vertex shader was actually faster! This prompted me to question the benefits of using the GPU as much as possible...

So, I was wondering if someone could describe the general pros and cons of using the GPU vs CPU for intensive graphics tasks. I know this mainly comes down to what your trying to achieve, so if necessary, use the above scenario to discuss why the "CPU + vertex shader" was actually faster than doing everything in the geometry shader on the GPU. It's possible my hardware (newest macbook pro) isn't optomized well for the geometry shader (thus causing the slow framerate). Also, I read that the vertex shader is very good with parallelism, and would love a quick explanation of how this may have played a role in speeding up my procedural terrain. Any info/advice about CPU/GPU/shaders would be awesome!

share|improve this question

migrated from stackoverflow.com Jun 30 '11 at 6:40

This question came from our site for professional and enthusiast programmers.

You'll get much better help on gamedev.stackexchange.com . Hopefully someone will move it there for you –  TheLQ Jun 30 '11 at 1:12
From the description of your algorithm, it sounds like it re-generates the terrain every frame, which can't be that fast... –  tc. Jun 30 '11 at 1:56
Note that geometry shaders weren't that successful (i.e. fast) in early HW/driver implementations. The new tesselation shaders are supposed to perform better. You should check the www.opengl.org forums, or gamedev.SE, to get help with maximizing OpenGL performance. –  Macke Jun 30 '11 at 7:03
add comment

3 Answers

up vote 7 down vote accepted

This topic triggers an old debate of CPU vs GPU, and there are tons of documents and papers out there explaining the differences between these processors. But just to summarize a few things, remember that each processor was made for a specific task. GPUs dedicates more transistors to data processing, and from the memory usage point of view, CPU is optimized to have the smallest memory latency possible, while the GPU maximizes memory bandwidth for data transfer.

The very specialized design of this processors, forbids that all tasks/algorithms be implemented efficiently on GPU. The GPU is faster for problems that have a parallel nature and a high arithmetic intensity.

Your application seems to be essentially graphic related. I'll assume you understand the graphic's hardware and that you were able to do an implementation that rendered you a better performance on the GPU.

But since you didn't mentioned what's your GPU, we have a few things to discuss. The newest Macbook Pro's (13" and 15") have different GPUs (Intel and AMD), and one very important issue you need to be aware of is: does your GPU have dedicated or shared memory? You'll have to go in the specification of your video card to discover this information.

Previous versions of the Macbook Pro used NVIDIA GPUs, and I know that my 13" macbook uses shared memory. Shared memory means that the GPU doesn't have integrated memory chips and have to share the RAM for it's processing. This has a huge impact on the GPU performance, huge. Imagine that your GPU application requires loads of memory to do it's processing. Data transfers are much much slower on a GPU with shared memory. And this could be the root of your problem.

share|improve this answer
add comment

This depends on the hardware as well as how you're attempting to do things. OpenGL has its ups and downs and actually can perform quite well on a CPU. There's too many factors here (at least I think so) because hardware is a pretty big variable and CPU's with SSE instruction sets can quite easily handle a lot of these things. I'm not sure why you would get such bad framerate with only 25 base triangles considering GPU's are meant to handle many more than that in just ambient lighting effects alone. This is one of the reasons that games that come out have issues on certain hardware, it's just hard to tell what performs better where.

share|improve this answer
It's because geometry shaders have terrible tessellation performance. You should never use them to tessellate anything; at least, not on hardware that doesn't also have tessellation shaders. Hardware with tessellation shaders is designed to magnify geometry, so it has memory buffers and such that make this process smooth. Hardware before then does not have these features, so while a geometry shader theoretically can do a 1:400 vertex magnification, you never should. –  Nicol Bolas Jun 30 '11 at 2:25
add comment

The objective is not to load as much as possible onto what may be the most efficient processor, but to balance the workload so that each has something to be doing as continuously as possible during each frame. If you put to much onto one processor it will be choked while the other is sitting idle - as you've discovered.

Unfortunately that's something that it's impossible to give any absolute guidelines for. You've got to profile your program, determine it's behaviour, and figure out how to - if you even need to - distribute your workload based on the results of that.

Geometry shaders need a very fine balancing act to be effective. Having one enabled will introduce it's own overhead so you need to carefully tune the amount of work it does - too little and you'll run slower than if you did the work elsewhere - even if it's once per vertex instead of once per primitive - (particle systems can be an example of this), too much and you'll overwhelm it.

share|improve this answer
add comment

Your Answer


