Le 2022-05-04 à 14:40, Kenneth a écrit :
> I have noticed some kind of similar media-rendering behavior, especially with
> scattering media (but also with emission + absorption.)
> 
> I'm running V3.8.0 beta 1  (Windows), on a core I7 8-core/16-thread machine.
> 
> I currently use the default 'render block size' of 32X32 pixels and no 'mosaic
> preview'. The last few 'render blocks' that get processed in my images (which
> are in areas where there is media) seem to cause my machine to work *extremely*
> hard. I have noticed this in two different ways: My machine's cooling-fan speed
> greatly increases; and the Windows 'Task Manager' app shows that those last few
> blocks cause the processor to suddenly jump to nearly 100% use.
> 
> On my machine, there does not seem to be an actual slowdown in the render-- just
> some very hard processor work behind-the-scenes.
> 
> This is my *guess* as to what is going on (simply from a user's standpoint, and
> not a programmer's):
> Due to symmetric multi-processing, it would seem that each 'render block' in the
> image is being processed by a particular core/thread(?)-- or, the blocks for
> most of the render are being shared among those. But for the very last block--
> or last few blocks-- the SMP process is reducing the number of threads(?) to
> process those... in other words, maybe the last block is using only one core,
> and trying to make it do *all* of the processing... resulting in a slowdown (or
> overheating of the processor, in my case.)
> 
> Again, this is purely guesswork. I don't know the inner workings of processors
> or POV-ray's SMP stuff ;-)
> 
> 
> 
Each render block is rendered by a single core. So, your supposition is 
correct.
In cases similar to this one, reducing the render blocks MAY improve the 
performance by forcing those problematic blocks to get rendered by more 
than a single core.

So, try using +rb16 or +rb12 and see if there is any improvement.
Also, changing the rendering pattern so that the rendering start near 
the centre could help to at least hide some of the slowdown by having 
the problem blocks starting to get rendered sooner.

Post a reply to this message