Xeons Box - E5 2640 v3 (x2) - this is old
i9 Box - i9 7980XE
Threadripper box - 3990x
I’ve just tested a quick scene.
Before today I was working on the i9 Box and sending DR renders with the Xeons joining in.
So here are my rendertimes.
i9 on it’s own - 19 mins 9 seconds
i9 with Xeons DR - 13 mins 40 seconds
i9 with Xeons and Threadripper DR - 9 mins and 36 seconds
i9 with Threadripper DR - 10 mins and 49 seconds
I then fired up the scene locally on the Threadripper and it rendered in 8 mins and 34 seconds.
The Threadripper on it’s own was the fastest option. I don’t understand. Has adding the Threadripper just made my other two machines completely redundant in terms of rendering? Is it that fast that the other 2 are hindering its capabilities? Or have I got a problem somewhere? Network maybe?
Im not sure if Im right, but when starting DR the scene gets saved and sent to the other machines. Then max has to fire up and load the scene on the nodes. So depending on your scene size/complexity/… this might take some time. Also bare in mind that the sending to the other nodes is a sequential process, so depending on your scene size and network speed, this might take some time too.
This could be the reason. Noise level is calculated differently for different parts of the image, and also it is re-calculated every 5 passes, and updating/collecting the images from slaves takes some time… So all in all it may not be a very reliable measuring method.
I think rendering to a pass limit could be a better solution. Especially to some higher number like 100 or more, in high resolution (1080 px or more).
5k, 2.5 nois limit, and just 8 minutes? That’s weird. The scene must have been super simple, or there was a lot of sky or other solid color visible. That probably didn’t render many passes, which makes the experiment even less trusty.
i mean, that’s my usual setup for final renders. So I don’t think it’s unreasonable to assume that rendering it as per I normally would, noting down the time, then doing the same but with the TR added and comparing the difference, is a decent way of comparing the speed increase?
It’s a reasonable way to find how things will change with your particular workflow, for sure. Overall though, DR may not be having a chance to contribute much, and the overhead of sending the scene, swapping data back and forth, etc. may be why DR doesn’t help with your particular workflow. Which is different from testing how DR can contribute in general, but of course, if this is how most of your scenes are set up, then it is important to know how DR changes your results in those particular set ups
Cool. Back to the original point though and to summarise. The TR is absolutely lighting quick, it just so happens this scene isn’t the best for testing as its too simplistic and I’ll really see the benefits on a more complex scene. I think everyone has kinda answered my question that I don’t have a problem as such, just needs a more ‘testing’ test.