GPU rendering in Blender v2.79b – Maxwell vs Pascal vs Volta
Tibor Nyers writes:
The field of computer graphics is enjoying a tremendous time as both new hardware features in dGPUs and deep learning techniques can speed up ray tracing. In anticipation of the next generation Turing NVIDIA cards BoostClock dissected the performance of the Maxwell, Pascal and Volta microarchitectures in Blender Cycles. The official Blender v2.79b release was used for the test with the Blender Institute-prepared benchmark scenes and the Barbershop Interior scene from Agent 327.
Someone explain Titan’s performance in the barbershop scene to me.
I have no clue, reported the issue to the devs: https://developer.blender.org/T56213
I don’t understand the conclusion for Windows 10 being slower:
“slower render times of Windows 10 is usually associated with an overhead in the Windows Display Driver Model (WDDM). What a quick look at the log files reveal is that the BVH construction takes a lot more time on Windows, mainly because of the ancient compiler (MSVC 2013).”
Does that mean that WDDM is adding overhead AND the old compiler causes longer BVH construction?
Or is the WDDM reason just a myth, and the true reason is just the old compiler?
Hey, sorry for the late reply!
If you have a look at the path tracing times, only the barbershop scene shows significant difference. So in general the statement that WDDM makes CUDA slower on Win10 is not true (anymore). I’m not sure why the barbershop shows this regression – it is the only one that can be considered somewhat complex (geometry size) and it uses the branched path tracing method.
Yes, with the older compiler scene setup and BVH construction takes longer. Unfortunately, most of the scenes tested are not complex enough, so the difference is only a few seconds, but for the more complex barbarshop scene. Ergo, Win10 is only marginally slower in most of the benchmarks scenes if you consider the full render time (scene setup + BVH + CUDA path tracing + compositing). Again, the numbers in the chart are pure path tracing times as this was meant to be a GPU benchmark.
I’m in the process of compiling blender with more recent compilers for Windows to see how much difference it means, plus I need complex geometry for BVH construction testing.
So that’s good news! At least we’re not dependent on Microsoft’s good will to do something about WDDM not being optimized with Cuda.
I’m considering AMD as well, on Win10, do you have any experience with them as well? I read they are good cards (eg Vega 64) but that for every render Blender has to compile a “kernel”, and the time it takes depends on scene complexity as well. This is annoying. Is it going to be fixed? Or can it be?
I have benchmarked AMD cards with Blender as well, and had no issues whatsoever. The kernel compilation takes place only once and it is not scene dependent, I saw no issues when running AMD cards with Blender Cycles. As far as I can tell, the RX 580 is on pair with the the GTX 1060, and the Vega64 has similar performance compared with the GTX 1080(Ti). I plan to update my benchmark Blender results with Vega64 and Ryzen CPUs as well. Here is a link to my older article: http://boostclock.com/show/000149/blender_2-79-AMD-OpenCL-dGPUs.html
Yes it would be interesting to see the latest cards from AMD benchmarked. And Ryzen too, since on paper they look very promising.
It would be interesting also to see not only pure rendering performance as you’re showing, but also any step before, like kernel compilation. And to have an idea of the time it takes for the preliminary tasks, and if they depend on the scene or not, if they take advantage of several cores or not. For example if a card is a bit faster when rendering, but slower before the actual render starts, it’s a negative for me because I do lots of relatively fast renders, and I like to have the first tile visible as soon as possible.
AMD kernel compilation is not scene dependent that’s good. But how long does it take? 3-5 seconds is the most I can wait for this additional step. Of course it depends on the CPU I guess.