Dynamic Bucket size when DR rendering based on speed statistics

[muoto]

Would it be possible to have dynamic bucket size when rendering on DR based on speed statistics from the DR renderers ?

For instance, i have 3 workstations that are quite new, 3 render nodes that are 3-4 years old, and that render half the speed as the new workstations.

It wouldn'y maybe matter so much in the beginning of the rendering, but maybe the last 20%, vray could adapt the size and the assigment of the buckets ?

Or adapt in the beginning the bucket size according to statistics (with default size of 48, i have on a 3000x3000 render : 2min32, with 24 i have : 2min13) ?

[Joelaff]

Chaos says they are working on a new method that will multi thread remaining blocks, ideally eliminating a Last Block Syndrome.

Hopefully it will take into account DR as well, and put all cores on all machines on the remaining blocks to keep all machines at 100% even at the end of the render.

They need to do this before they remove the controls to adjust block size, which should never be removed anyway. We like small blocks and follow mouse when doing test renders. Having so absurd auto-set block size all the time would be a terrible thing.

[^Lele^]

Having so absurd auto-set block size all the time would be a terrible thing.

It would be indeed.
Thankfully, there were never any plans to do so.

[Joelaff]

It would be indeed.
Thankfully, there were never any plans to do so.

Good. Then maybe we can get the block size adjustments added to GPU

I get GPU is a different animal. I get it's not ideal or the most efficient for a single machine, but I still contend the user knows the best block size to use in any circumstance. Just make the defaults reasonable, but let us tweak it. Using a large block is not efficient if the whole render gets tied up waiting for the last block. This applies to CPU or GPU.

I don't want to hijack this thread with another discussion on the immutable GPU block sizes, though.

The OP had a cool idea about calculating the speed of each box and using that intelligently.

[^Lele^]

Without first having an idea of what the contents of the frame being rendered are, there is no way to optimise a thing.
Past statistics -beyond the tracing speed of a client- do not guarantee future performance.

This is why the approach being worked on is based on a prepass to the actual tracing.
Scoring clients could help, sure, but not in the way it's been proposed: it will need the back up of an analysis of scene contents.

[Joelaff]

Yes, it is indeed very difficult to predict. A Prepass approach sounds really nice!

[^Lele^]

To be clear: by "prepass" i mean the Light Cache.

[Joelaff]

To be clear: by "prepass" i mean the Light Cache.

I figured. Seems like you guys have been making good use of that (Adaptive Dome, etc.) This is great to see.