 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/07/2012 11:05 AM, clipka wrote:
> Obviously, as we're talking about discrete events, you can't measure
> this ratio for a particular /moment/, so you need to measure it over
> /some/ timespan.
Sure. But a shorter timespan would be much more useful.
>> 1. It means that if the speed increases or decreases for any reason, the
>> display takes a /long/ time to respond. I'd prefer to see an
>> instantaneous speed readout.
>
> OTOH it probably gives you a better overview of the render performance
> for the scene as a whole.
It might be useful if POV-Ray could actually try to estimate the time
remaining. It's not especially useful looking at the average PPS for the
entire scene.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> > 1. It means that if the speed increases or decreases for any reason, the
> > display takes a /long/ time to respond. I'd prefer to see an
> > instantaneous speed readout.
> OTOH it probably gives you a better overview of the render performance
> for the scene as a whole.
Maybe it should display two numbers: "Overall PPS" and "Current PPS".
The latter one would be the average of the last n pixels (where n would
be something small, such as 10).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> On 06/07/2012 11:17 AM, clipka wrote:
> > You're doing something fundamentally wrong here: You should have a
> > single instance of POV-Ray running, with 100% CPU utilization :-P
> >
> > (Hint: Get POV-Ray 3.7!)
> Maybe when the beta finishes, eh?
It is finished. It's a release candidate.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.07.2012 12:22, schrieb Invisible:
> It might be useful if POV-Ray could actually try to estimate the time
> remaining. It's not especially useful looking at the average PPS for the
> entire scene.
Estimating the time remaining is pretty difficult, as you'll often have
very inhomogenous complexity across the entire image. The sky, for
instance, is usually comparatively simple; the main motif - typically in
the center of the image - is usually quite complex; and the ground may
(or may not) be quite easy again. So any naive prediction is doomed to
be wrong, and may be off by orders of magnitude.
One attempt that might make sense would be to use a more-or-less random
ordering of SMP render tiles, and estimate the remaining time as (blocks
remaining)*(total time spent for the actual render)/(blocks rendered).
That still doesn't help with render time estimation during photon
gathering, radiosity pretrace, or even mosaic preview (anti-aliasing
requirements may be inhomohenous across the image without any necessary
corellation with per-ray render time).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.07.2012 12:20, schrieb Invisible:
> On 06/07/2012 11:17 AM, clipka wrote:
>
>> You're doing something fundamentally wrong here: You should have a
>> single instance of POV-Ray running, with 100% CPU utilization :-P
>>
>> (Hint: Get POV-Ray 3.7!)
>
> Maybe when the beta finishes, eh?
Hint: Beta phase has officially finished quite a while ago, we're in
release candidate phase by now ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/07/2012 11:48 AM, Warp wrote:
> Maybe it should display two numbers: "Overall PPS" and "Current PPS".
> The latter one would be the average of the last n pixels (where n would
> be something small, such as 10).
Well, I'd like that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.07.2012 12:48, schrieb Warp:
> Maybe it should display two numbers: "Overall PPS" and "Current PPS".
> The latter one would be the average of the last n pixels (where n would
> be something small, such as 10).
As of 3.7 that would perfectly useless, as render results (and thus
progress) are reported to the frontend in blocks of (IIRC) typically
32x32 = 1024 pixels. Even the time between incoming render blocks would
be a bad basis, as they may come in a pretty irregular pattern depending
on how well the threads remain in sync. I think the average over the
last N render blocks, where N is the number of render threads, would be
the minimum reasonable value.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 05/07/2012 08:25 PM, Warp wrote:
>
>> What the number is telling is how many virtual cores are being used at
>> the moment by that process (assuming that it's using all of the virtual
>> cores fully).
>
> Ah, I see. The number measures the amount of processor time /allocated/
> by the OS, not the amount of actual computation process made. Got it.
>
> So if a task spends most of its time idle due to cache misses or sharing
> executing units with a second hyperthreaded task, or whatever, the OS
> can't easily measure that.
>
Exactly. On my underpowered Stinkpad, TaskMangler will routinely report
that the 2 cores are about 12-15% each, but the whole PC has become
almost unresponsive since it's swapping and the swapfile sits on a
software encrypted disk*, so the PGP task needs to be swapped in to
encrypt/decrypt every swap file activity.
*Don't ask. Company policy.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Ah, I see. The number measures the amount of processor time /allocated/
>> by the OS, not the amount of actual computation process made. Got it.
>
> Exactly. On my underpowered Stinkpad, TaskMangler will routinely report
> that the 2 cores are about 12-15% each, but the whole PC has become
> almost unresponsive since it's swapping and the swapfile sits on a
> software encrypted disk*, so the PGP task needs to be swapped in to
> encrypt/decrypt every swap file activity.
>
> *Don't ask. Company policy.
Now if a task isn't running because of swapping, /that/ should be quite
easy for the OS to determine. (The OS deschedules it until the disk I/O
request completes, after all...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.07.2012 16:08, schrieb Francois Labreque:
> Exactly. On my underpowered Stinkpad, TaskMangler will routinely report
> that the 2 cores are about 12-15% each, but the whole PC has become
> almost unresponsive since it's swapping and the swapfile sits on a
> software encrypted disk*, so the PGP task needs to be swapped in to
> encrypt/decrypt every swap file activity.
Oh holy hens & scrambled eggs!
How can the PGP task even be swapped in if it's swapped out and needs to
be swapped back in in order to decrypt itself from the swap file? >_<
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
