Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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

migration rejected from stackoverflow.com Jun 8 at 9:55

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as too broad by gnat, durron597, MichaelT, GlenH7, Snowman Jun 8 at 9:55

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. If this question can be reworded to fit the rules in the help center, please edit the question.

5  
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
3  
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

2 Answers 2

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

This is an old thread, but this recently published paper may answer this question. This paper, published in ACM Computing Surveys 2015 makes a case for moving away from "CPU vs GPU debate" to "CPU-GPU collaborative computing" paradigm. It also shows that both CPU and GPU have their unique strengths and hence, they may not replace each other.

A Survey of CPU-GPU Heterogeneous Computing Techniques

share

Not the answer you're looking for? Browse other questions tagged or ask your own question.