3 ms·
There are many aspects to this. The biggest is indeed memory. Scene complexity if VFX has always eaten hardware advances. Average frame time used to be 2h thro
by virtualritz 2y ago
There are many aspects to this. The biggest is indeed memory. Scene complexity if VFX has always eaten hardware advances.
Average frame time used to be 2h throughout my career and it never got smaller, however fast hardware became available (and this includes GPUs).
And because scene complexity was always larger than what fit on GPUs for most stuff this was always the limiting factor in how effective they could be.
Another issue people in these debates ignore is R&D.
The amount of R&D you have to spend to make cutting edge offline rendering work perfectly on the moving target that is GPUs is insane, compared to CPUs.
To give you an idea, look at the list of limitations RenderMan XPU (CPU+GPU) has compared to its CPU counterpart (nowadays called Ris) [1]. If you're A CG supervisor that page is a giant red flag for relying on XPU in your production in any way because any limitation you hit has to be worked around. And the biggest expense in production is human labor.
Pixar has sunk probably dozens of man years of R&D into XPU (I think it was announced at Siggraph 2017). I.e. that's seven years times number of developers.
In a shootout, a year ago (with a scene simple enough to fit on a GPU, mind you), the noise levels of the RenderMan XPU render were marginally better that those of 3Delight, for the same render time.[2] And that's after seven years of R&D and with the aforementioned limitations (none of which apply to 3Delight or to RenderMan Ris but the latter had unacceptable noise levels if you look at the images).
3Delight only supports CPU and their team of just half a dozen people has spend 100% of their time, sinc3 1999, on that. Instead of chasing GPUs.
If you have complex scenes or volumes, 3Delight will beat any GPU renderer (and any CPU renderer anyway). I'm happy to bet on this.
On a side note, my guess is that GPU-related R&D was a factor in what killed Clarisse. They even successfully ported OSL to GPU -- laudable! But briefly after the company went under ...
Maybe their time would have been better spent to make the renderer more robust and faster on CPU instead. Just a guess ofc.
This is the high-end stuff. There are lots of GPU path tracers out there and they're all great as long as your scene complexity doesn't cross a certain threshold. And as long as you do not need OSL support, I think only Evee has this.
[1] https://rmanwiki-26.pixar.com/space/REN26/19661981/XPU+Features+and+Limitations https://rmanwiki-26.pixar.com/space/REN26/19661981/XPU+Featu...
[2] https://github.com/tristan-north/renderBench https://github.com/tristan-north/renderBench
- MyOutfitIsVague 2y agoI see. Thank you for the detailed response. It sounds to me that GPUs could be a better option if there was significantly more stability and standardization across the board, but we're really just not in that place.
- virtualritz 2y agoYes, absolutely. If GPUs where as accessible and stuff as stable and standardized as in CPU land many of the above caveats would not apply. The memory barrier may still be there but my guy feeling is we would have so much more code running on GPU then that there would have been solutions developed for this, too, long ago. Raph Linus is currently writing a blog post from the perspective of someone who has been working on GPU-accelerated 2D vector rendering. It echos some of the issues I touched on above. Well worth reading when it is released (probably will hit HN front page anyway): https://github.com/raphlinus/raphlinus.github.io/pull/104 https://github.com/raphlinus/raphlinus.github.io/pull/104