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.

Post a reply to this message

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

Le 18-06-14 à 10: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.
> 
> 
> 

During the prerender, you only sample a single point per block. It sit 
between pixels for any even size. It can easily miss all the slow 
pixels, and could hit a single slow point, that would otherwise remain 
unrendered, in a fast block.

That mean that it's pretty easy to get fast block uselessly subdivided 
and slow ones not subdivided at all.
What you propose will be utterly unreliable.

But, since you often get those slow blocks near the centre of the image, 
using an alternate render pattern may help you : It can cause the slow 
blocks to start rendering early.

Alain

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> 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.

No, but it is actually possible to do this: Instead of rendering blocks from
left-top to bottom-right row by row, one can render a block in four
subdivisions. Should a block stall it would then be possible to subdivide and
split off the remaining subblocks. However, this requires more communication
than just an atomic counter to find blocks because it requires a queue of such
blocks (through that queue would need to be just threads*3 (or *15 for two
allowed subdivsisions) in depth.


Thorsten

Post a reply to this message

"Thorsten Froehlich" <nomail@nomail> wrote:
> Le_Forgeron <jgr### [at] freefr> wrote:
> > 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.
>
> No, but it is actually possible to do this: Instead of rendering blocks from
> left-top to bottom-right row by row, one can render a block in four
> subdivisions. Should a block stall it would then be possible to subdivide and
> split off the remaining subblocks. However, this requires more communication
> than just an atomic counter to find blocks because it requires a queue of such
> blocks (through that queue would need to be just threads*3 (or *15 for two
> allowed subdivsisions) in depth.
>
>
> Thorsten

Thanks for all your replies.
Indeed the algorithm and implementation would be a little more complex.

There is also another approach: the human approach and the reuse of the fixed
region render to allow ordered batch fixed region render + the remaining at the
end.

Nothing beats a pov-ray user for determining where the media/reflections are in
a static scene.

I am imagining that through the interface or through the command line, one would
supply render regions that would be treated in the selection order and the rest
of the scene through the selected block render pattern.

That could, however, be performed without any code modification through image
combination, And is probably already in the scope of things that are possible
through HttpPOV, but with some necessary overhead.

Rodrigo.

Post a reply to this message