3 ms·
It's not that simple. The basic idea behind path tracing maps very well to GPU's, so you can get huge speedups there (10x-100x depending on the scene, geometry,
by w0utert 9y ago
It's not that simple. The basic idea behind path tracing maps very well to GPU's, so you can get huge speedups there (10x-100x depending on the scene, geometry, representation, etc). For example path tracing signed distance fields (volume textures, basically) can be done extremely efficiently on GPU's.
Things get a lot more difficult when the scene becomes more complex, if it needs to be animated, etc though. You need much more advanced forms of visibility detection/object culling, track scene changes, need to have an much bigger working set (models, textures, metadata) in memory, etc. The amount of code that needs to run compared to 'just the path tracer' starts to far outweigh what the GPU can efficiently process.
Hybrid solutions are of possible and widespread, but it is not easy to implement those in a way that will not annihilate the speedup you get from the parts running on the GPU because of synchronization, copying memory around between CPU <-> GPU etc. I can imagine that the kinds of rendering pipelines animation studios use likely depend on hundreds of individual tools from different suppliers, so it would be next to impossible to integrate and the full rendering pipeline efficiently if it runs partly on CPU and partly on GPU. But maybe some parts could be?
- gt_ 9y agoGood summary. I don’t think many 3D artists would disagree that ‘Redshift’ is slightly ahead of the small pack of GPU renders available, but switching has repercussions and limitations throughout the production. These CPU renderers will handle anything you throw at it.