Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've noticed that many 3d programs normally do vector/matrix calculations as well as geometric transformations on the CPU. Has anyone found an advantage in moving these calculations into vertex shaders on the GPU?

share|improve this question

Generally speaking: Mesh transformations are done on the GPU. You send in the transformation matrix to the GPU and the shader applies it to all verticies of the mesh.

Using the GPU to calculate the Matrix itself is a different matter & is actually slower on the GPU because there are so many stored values that change from frame to frame that are necessary to help determine the final transformation matrix. Sending this data to & from CPU - GPU is slow. Also, on the CPU, the calculations are done once, whereas on the GPU, they would be done for each vertex.

share|improve this answer
W.r.t. the "actually slower on GPU" part; this is a very broad statement. If you're talking about constructing the matrix for each vertex on GPU then your performance will depend on your bottlenecks. You'll only get slower performance if you are ALU/ register bound on the GPU, which is not necessarily the case. Doing exactly the same thing on a CPU would also be slower under these bottleneck scenarios. An example where this is commonly done on GPU: vertex shaders construct vertex tangent space matrices on the fly to save vertex fetch bandwidth. Again, dependent on your bottlenecks, so YMMV. – jpaver Aug 27 '10 at 18:32
I can't downvote, but this answer should be downvoted. It's very wrong to say "actually slower on the GPU". – Adam Feb 9 '14 at 17:02

Many geometric transformations can be done on non-GPU processors, however one must consider the target platform. Your mileage will vary based on what platform you're targeting, and the bottlenecks of that platform.

One consideration is bus bandwidth between the device that is generating the geometry, and the device that is rendering the geometry.

In a typical modern PC system, the CPU is on one side of the PCIe bus (, and the GPU is on the other. The only way you can transfer per-frame generated data from CPU to GPU (and vice-versa) is via this bus. This means, you can be limited by the transfer speed of this bus. If your target platform has PCIe 2.x with 16 lanes, you have 8GB/s bandwidth. In practice, transfers across the PCIe are not 100% efficient, as some of the bandwidth is consumed for the protocol during your transfers. Depending on the size of your transfers, you could lose 5-10% of your bandwidth just on the per-packet overhead.

eg. Given a PC platform that is running PCIe 2.x with 16 lanes, how much data can you generate per frame for feeding to the GPU? Assuming you want the run at 60fps, this translates to 8GB/60 = 136MB per frame for PCIe 2.x. Multiplying by some (guestimated) 90% factor to account for driver communication overhead and PCIe transfer protocol overhead, you can generate around 120Mb data per frame without being limited by PCIe 2.x bandwidth.

Another question you have to answer: will the generation of this 120Mb of data be easily achievable in 1/60th of a second on your target CPU? Remembering that you have to perform a number of other game tasks on your CPU, you can run into a lack of time to generate the transformed data. In terms of just pure ALU throughput, this can limit you on CPU. In terms of CPU to sysmem buses, you can also be limited by the bandwidth (which varies, but is around ~8.5GB/s on recent CPUs).

Alright, so what factors makes it more viable to do on a GPU then? One factor is GPU memory bandwidth, which is the bandwidth between the GPU and it's local video memory. On contemporary mid-range GPUs this video memory bandwidth can be as high as 200GB/s (yes, that's 25x the PCIe 2.x bandwidth). Another factor is that the GPU is massively parallel, has hundreds of ALUs and is able to hide memory access latency by running thousands of threads at a time.

All of these factors can contribute to the obvious win of pushing more work onto the GPU, but again YMMV depending on your target platform.

share|improve this answer

What do you mean by "mesh transformations"? Transforming geometry by some set of matrices? Most games these days will let the GPU handle simple transformations, skinning, etc. And most of them will be using vertex shaders to do it. On some platforms you either don't have shaders, or there are other advantages to doing these things on the CPU. For example, on the PS3 you can take some load off the RSX by letting the SPUs handle skinning and transformation. If you're doing multi-pass lighting then skinning on the CPU can be advantageous, since you only have to do it once and submit the results to be drawn for each rendering pass. So there are exceptions, but in general most games are doing these things on the GPU and in shaders.

Or did you mean something fancier, like using the GPU for general vector math? These days we have general purpose GPUs that can run fairly generic C code via systems such as CUDA. It is possible to take advantage of this for heavy vector math, and I know there are programs out there that do this. I don't have any experience with it personally though.

share|improve this answer
changed "mesh transformation" to "geometric transformation" to help clarify the question. i'm also waiting for opencl es, which could be available early as next year. – zmdat Aug 27 '10 at 14:10

There are situations where having everything on rendered on the GPU might make sense, but you can't set constants inside a shader and there is really no where else to set them up except on the CPU side before a draw call.

Even if you could compute your constants, like the bone transformation matrices, on the GPU with a custom initialization program, you probably wouldn't want to. the GPU is really good at parallel execution, but has a much slower clock speed.

Transforming a hierarchy is not trivially parallelizable, because the child nodes depend on the parents, but transforming all the vertices in a mesh is, because the vertices are computational independent from each other.

The general rule is:

  • Serial processing : CPU
  • Parallel processing : GPU
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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