 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
|
|
