William F Pokorny <ano### [at] anonymousorg> wrote:
> On 6/29/23 09:31, Chris R wrote:
> > I may end up shifting the camera location slightly and see if that eliminates
> > the problem spots, but I'd be interest in trying to figure out whether I'm just
> > hitting some threshold edge condition where an algorithm is just never
> > terminating.  Could I be hitting a loop where the threshold condition cannot be
> > met due to floating point precision problems?
>
> (64 cores... What a dream! :-) )
>
> Yes, always possible there is some unknown problem causing the run
> extreme render times.
>
> Given you have the problem isolated to two blocks, why not try what Bald
> Eagle suggested. There are the (start row / end row) and (start column /
> end column) controls. These I used often while running down various
> solver issues (image artefacts) in 2017 / 2018 (a).
>
> So. You could start by making a pretty good guess at the image rows
> covering those to hung blocks. Then try row by row renders using:
>
> povray ... +sr600 +er600 ...
>
> povray ... +sr601 +er601 ...
>
> When you find a row which hangs you can then start to use the column
> options:
>
> povray ... +sr602 +er602 +sc500 +ec1500 ...
>
> povray ... +sr602 +er602 +sc700 +ec900 ...
>
> You might need to 'kill' the hung processes (or cntl-c cancel if that
> works) while you isolate to pixels. You can use the 'kill' command for
> this or 'kill' via linux process monitoring commands like top/htop.
>
> Should be you can leave all other options the same and slowly isolate
> the problem pixels. If like my old hanging transparent blobs, it might
> end up being just a pixel position or two (b).
>
> If you can get to a scene of reasonable size and complexity also cut
> down to a small number of problem pixels, I'll take a look at it on my
> little two core i3 while doing some extra performance/debugging stuff.
>
> Note though. Real life has me tied up until late July or more likely
> early August so I won't be able to look at anything immediately.
>
>
> Aside: I think all linux distribution offerings come with 'top' or
> 'htop' commands. It might be interesting to kick off one of these
> commands in a terminal while povray is struggling to look at whether cpu
> bound (povray processes at near 100%) or perhaps consuming large amounts
> of memory - and so perhaps the 'hung' threads are paging even on your
> huge machine (b). Large memory use would hint at runaway recursion
> internal to the code (runaway transparency being one way this might
> happen).
>
> Bill P.
>
>
> (a) Somewhere, I have a script framework which isolates to particular
> pixels automatically based on various triggers - but that framework had
> nothing which isolated on 'long render times...'
>
> (b) Or there is a very remote chance the block is hung on exit. We have
> seen 'render block' hangs with the Simple Direct media Layer (SDL1.2)
> preview code - which the official v3.8 code still uses - though there
> has long been a newer and less buggy 2.0 package. Using something like
> top or htop, you might see the povray process(es) using very little cpu
> or memory resource in this sort of case.

Thanks for all of the debugging hints.

Top is reporting that 2 cores are running at 100%, so one per 64-pixel block.
Memory has held constant, and this machine has 80GB so I don't think it's paging
very often.  Not much else is running on the machine at this point.

I'm going to leave it running over the 4-day holiday weekend and if nothing has
changed I'll kill it and try to isolate it.  Or if I'm feeling ambitious I'll
see if I can attach gdb to the running process and at least look at the stack
trace.

-- Chris R.

Post a reply to this message