We just ran into this problem when implementing a ray tracer using the GPU that will be presented soon at the upcoming Graphics Hardware Workshop.
Our ray intersection algorithm implemented on the GPU (an "old" Radeon 8500) was able to intersect 114M rays per second. This was loads faster than the best CPU implementation, which could handle between 20 and 40 intersections.
But when we tried to implement a ray tracer based on this, and an efficient one that didn't intersect every ray with every triangle, the readback rate killed us. Our execution times slowed down to the low end of the fastest CPU implementations.
And the readback delay seems to be completely due to the drivers, which apparently still use the old PCI-bus code. If the drivers could use the full potential of the AGP bus, our ray tracer could approach twice the speed of the best CPU ray tracers.
Graphics accelerators have been doubling in powers every six months or so. So a dual GPU would be really cool for about that long.
It has been interesting to see all the tricks needed to keep up with the GPU performance growth curve. The growth curve is so much steeper than the CPU growth curve (double every 18 months) because graphics processors can take advantage of more parallelism.
But the parallelism has mostly just happened on chip for consumer GPU's. It will be interesting to see how well it works between chips. This sounds awfully similar to UNC's PixelFlow, which used object-parallelism (GPU-parallelism) and image composition to construct the final image. And between chips parallelism is more feasible than the between-computers solution of WireGL.
Slashdot Mirror
Our ray intersection algorithm implemented on the GPU (an "old" Radeon 8500) was able to intersect 114M rays per second. This was loads faster than the best CPU implementation, which could handle between 20 and 40 intersections.
But when we tried to implement a ray tracer based on this, and an efficient one that didn't intersect every ray with every triangle, the readback rate killed us. Our execution times slowed down to the low end of the fastest CPU implementations.
And the readback delay seems to be completely due to the drivers, which apparently still use the old PCI-bus code. If the drivers could use the full potential of the AGP bus, our ray tracer could approach twice the speed of the best CPU ray tracers.
It has been interesting to see all the tricks needed to keep up with the GPU performance growth curve. The growth curve is so much steeper than the CPU growth curve (double every 18 months) because graphics processors can take advantage of more parallelism.
But the parallelism has mostly just happened on chip for consumer GPU's. It will be interesting to see how well it works between chips. This sounds awfully similar to UNC's PixelFlow, which used object-parallelism (GPU-parallelism) and image composition to construct the final image. And between chips parallelism is more feasible than the between-computers solution of WireGL.