Le 14/06/2018 à 16:26, rodv92 a écrit :
> Hello, I had an idea about a feature that could make renders faster for
> multithread multicore operations.
> 
> Some areas of a render are always slower (media, lights, reflections, etc..)
> 
> I think it could be possible to make a low-res pre-render to identify block size
> rendering speed for the different blocks.
> 
> Each block of the pre-render would be then given a weight according to render
> speed.
> 
> When performing full resolution render, these blocks would be subdivided into
> smaller blocks according to weight.
> 
> This would allow the allocation of more cores to smaller regions that render
> slower.
> 
> It would prevent the "lone core end-of-render effect" when a single core renders
> a big and slow region when others sit idle.
> 
> The algorithm seems easy to implement.
> The more parallel is the computer (dual CPU, 8 to 12 cores per cpu), ex: 48
> hyper-threading cores, the more gain there would be.
> 
> Of course, rendering gain time must offset the prerender time.
> 
> Maybe this idea has been already thought of, i dunno.
> 
> 
> 

The final stage of that evolution would be a more complex code than
simply requesting a block size of 1.

The problem with sampling is just that: samples. It won't protect you of
pathological scenes were the expensive spots are just near the sampling
position.

On Windows, the flow of blocks has no back pressure (the rendering
threads can overflow the thread collecting the blocks), so it is
important to have block big enough to have some free time for the
collecting thread. On other systems, there is no such problem, the
communication of block holds the senders when the receiver is at risk.
So a smaller block is not a problem.

Post a reply to this message