POV-Ray : Newsgroups : povray.windows : Massively delayed Stop Render Server Time
7 Dec 2024 17:01:12 EST (-0500)
  Massively delayed Stop Render (Message 1 to 4 of 4)  
From: Bald Eagle
Subject: Massively delayed Stop Render
Date: 19 Mar 2016 18:50:00
Message: <web.56edd77df9a19c455e7df57c0@news.povray.org>
So, I've noticed that sometimes when I'm rendering a very large sized graphic
(10240 x 7680), that things slow way down, memory usages goes way up, and
clicking on _stop render_ is apparently unresponsive.
Then I wait while POV-Ray happily renders away - and then registers my stop
render - like minutes later.

I this a POV-Ray thing, a Windows 7 thing, a Dell Inspiron thing... ?
Has anyone else noticed this behaviour?

Win 7 Home Premium SP1
Dell N5110 i5-2410M 2.3 GHz
4GB, 64 bit

Running 3.7.0.msvc10.win64


Also, every so often F1 (Help) doesn't respond either.


Post a reply to this message

From: clipka
Subject: Re: Massively delayed Stop Render
Date: 19 Mar 2016 21:31:04
Message: <56edfd58$1@news.povray.org>
Am 19.03.2016 um 23:49 schrieb Bald Eagle:
> So, I've noticed that sometimes when I'm rendering a very large sized graphic
> (10240 x 7680), that things slow way down, memory usages goes way up, and
> clicking on _stop render_ is apparently unresponsive.
> Then I wait while POV-Ray happily renders away - and then registers my stop
> render - like minutes later.
> 
> I this a POV-Ray thing, a Windows 7 thing, a Dell Inspiron thing... ?
> Has anyone else noticed this behaviour?
> 
> Win 7 Home Premium SP1
> Dell N5110 i5-2410M 2.3 GHz
> 4GB, 64 bit
> 
> Running 3.7.0.msvc10.win64

This is a known effect for large images of simple scenes: For
sufficiently large images, the buffer in which POV-Ray assembles the
rendered image chunks into a complete image is not held in main memory,
but in a temporary file instead. As a consequence, the performance of
the thread that does this assembly is limited by the disk I/O bandwidth.
On the other hand, the render tasks that compute those chunks are
limited only by processing power and main memory bandwidth, and so in
simple scenes they may crank out results faster than the image assembly
thread can consume them. In such cases, the rendered chunks pile up in a
queue held in main memory, which grows larger and larger as render
progresses.

Of course it doesn't help that as the queue grows larger, chunks spend
more and more time in the queue, and are thus more and more prone to be
swapped out to disk by Windows' virtual memory management, creating even
more disk I/O workload.

As for the delay when stopping the render, it is important to note that
the queue of rendered chunks is actually a generic message queue, and so
the image assembly thread first has to process all the piled-up chunks
before it even receives the information that the render is to be
stopped. (Or at least that's what I think is happening; I'm currently
not deep enough into the details to say for certain. An alternative
explanation might be that the delay is caused by POV-Ray struggling to
release all the memory blocks holding the image chunks.)


> Also, every so often F1 (Help) doesn't respond either.

To my knowledge, this is entirely unrelated.


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Massively delayed Stop Render
Date: 20 Mar 2016 17:00:00
Message: <web.56ef0e944034445966dec5d70@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> As for the delay when stopping the render, it is important to note that
> the queue of rendered chunks is actually a generic message queue, and so
> the image assembly thread first has to process all the piled-up chunks
> before it even receives the information that the render is to be
> stopped. (Or at least that's what I think is happening; I'm currently
> not deep enough into the details to say for certain. An alternative
> explanation might be that the delay is caused by POV-Ray struggling to
> release all the memory blocks holding the image chunks.)

Each thread has its own queue, so it is not that the backend does not receive to
stop request, but that the frontend is simply still busy drawing the finished
blocks. Then it will find the render statistics etc. in the message queue of the
frontend. It should be visible even in the task manager that POV stops rendering
by the total processor usage, which drops to one thread doing the drawing.

The solution is to have enough memory to hold everything in RAM as the effects
will go away for the most part.

Thorsten


Post a reply to this message

From: Bald Eagle
Subject: Re: Massively delayed Stop Render
Date: 11 May 2016 21:00:01
Message: <web.5733d581403444595e7df57c0@news.povray.org>
"Thorsten Froehlich" <nomail@nomail> wrote:

> The solution is to have enough memory to hold everything in RAM as the effects
> will go away for the most part.

Indeed, adding another 4GB card gave the following:


Render Statistics
Image Resolution 10240 x 7680

Pixels:         78643200   Samples:               0   Smpls/Pxl: 0.00
Rays:           78643200   Saved:                 0   Max Level: 1/5

Ray->Shape Intersection          Tests       Succeeded  Percentage

Cone/Cylinder                  2906377         1227799     42.25
Sphere                          456980          212075     46.41
Bounding Box                1618119693       386343042     23.88

Shadow Ray Tests:            537601   Succeeded:                 18880
Shadow Cache Hits:            15221

Peak memory used:        1867010048 bytes

Render Time:
  Photon Time:      No photons
  Radiosity Time:   No radiosity
  Trace Time:       0 hours  0 minutes 18 seconds (18.858 seconds)
              using 4 thread(s) with 63.304 CPU-seconds total
POV-Ray finished
-
CPU time used: kernel 78.56 seconds, user 122.55 seconds, total 201.12 seconds.
Elapsed time 492.78 seconds.
Render averaged 159591.86 PPS (391033.08 PPS CPU time) over 78643200 pixels.


I could probably figure out a few tricks to trim down the render time for
something that is in essence a "line drawing".

I'm going to see if my system can accept 16GB, and see how things go from there.
  Eventually, I'm sure I'll see if I can find one of these juicy-sounding Xeos
chips and build a system around that with handfuls of memory cards...   :)
Alas, other more mundane things must be financed first.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.