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 (http://en.wikipedia.org/wiki/PCI_Express), 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.

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.

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 (http://en.wikipedia.org/wiki/PCI_Express), 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.

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 (http://en.wikipedia.org/wiki/PCI_Express), 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 (random) 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.

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.

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 (http://en.wikipedia.org/wiki/PCI_Express), 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.

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.