Le 2023-05-06 à 07:40, Kenneth a écrit :
> "Chris R" <car### [at] comcastnet> wrote:
>> What I'm afraid of is that some interaction
>> between anti-aliasing, radiosity, and reflection is causing an infinite loop
>> measuring against thresholds.
> That's a really hard-core set of features to throw at POV-ray all at once, ha.
> Especially with isosurfaces added to the mix. I have similar scenes where I had
> to eliminate anti-aliasing altogether, if I didn't want to exclusively tie up my
> machine for days...and this on an 8 core/16 thread machine!
> My gut-feeling is that the slowdown for your last block is AA-related.
> One suggestion would be to reduce the size of your Render_Blocks. The default is
> 32X32 pixels, I think. I run complex-feature scenes at 8X8, which does improve
> the overall rendering speed on multi-core machines, and *helps* to keep that
> final render block from taking so much time. As Thorsten F. pointed out in an
> earlier post last year, each Render_Block uses an individual core (or thread-- I
> get the two confused.) By reducing the block size, the processor seems to work
> more efficiently, and doesn't have to spend all of its time on a single block
> (with a single core) while the other cores are sitting idle. Or something like
> I may have the technicalities wrong, but a smaller block size can sometimes
> speed-up the render. It definitely works for media and isosurfaces (but I'm not
> patient enough to throw in AA as well; most of my renders lately are just
> relatively quick tests of one thing or another.)
Yes, using smaller render blocks can absolutely help with some slower
renders. That is, renders that are not particularly fast and don't tend
to have long I/O pipes in use.
In multithread computing, the cores, virtual cores, used IS the thread
count. Cores = physical aspect. Thread = logical aspect. POV-Ray use one
thread per core/virtual core unless +WTn is used.
Post a reply to this message