 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On 9/18/20 6:36 AM, William F Pokorny wrote:
...
>
> I don't think we have a fat rabbit to chase here.
>
> Of course run time improvements with am3 would be welcome. I have on my
> list to do some profiling with parametrics. Might take a side look at
> am3 too while I've got those compiles about. I've got the color shift
> issue to replicate and run down someday too. Hmm, wonder if I can
> trigger it with your simpler test cast Ton.
>
We can indeed! All one needs do is change:
background { color srgb <0, 0, 0> }
to:
#declare Acajou = srgb <0.29804,0.18431,0.15294>;
background { color Acajou }
and the cpu time jumps.
16.918 -> 3443.029 ---> 20251.28%
Plus the results are to my eye not as good.
Does uberpov has the same behavior:
16.172 -> 3512.926 ---> 21622.27%
A fat rabbit.
Bill P.
Bill P.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
William F Pokorny <ano### [at] anonymous org> wrote:
> >
> > Hmm, wonder if I can
> > trigger it with your simpler test cast Ton.
> >
>
> We can indeed! All one needs do is change:
>
> background { color srgb <0, 0, 0> }
>
> to:
>
> #declare Acajou = srgb <0.29804,0.18431,0.15294>;
> background { color Acajou }
>
> and the cpu time jumps.
>
> 16.918 -> 3443.029 ---> 20251.28%
>
> Plus the results are to my eye not as good.
>
> Does uberpov has the same behavior:
>
> 16.172 -> 3512.926 ---> 21622.27%
>
WOW! That's incredible. Excellent detective work, Bill.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"Ton" <ton### [at] gmail com> wrote:
> My version of uberpov is from https://github.com/UberPOV/UberPOV, the last
> version, dated 10 February 2015.
OK. I downloaded the Windows 64-bit version of this-- I *think* it's the correct
'stand-alone' version-- dated one day earlier on the Github page: UberPOV
v1.37.1.0.beta10
> Povray 3.7 doesn't have the stochastic rendering mode am3, that's probably why
> your plugin on version 3.7.0 doesn't work...
Apparently you're correct; this earlier(!) version of UberPOV DOES recognize the
"+ac0.9" command. That seems strange to me; I would have thought that the
(later) piggyback version for 3.7.0 would also have that ability already
built-in to its binary, thus 'overriding' 3.7.0's limitation. Anyway, it does
work. Thanks.
[William wrote...}
> Hmm, wonder if I can trigger it with your simpler test cast Ton.
>
> We can indeed! All one needs do is change:
> background { color srgb <0, 0, 0> }
> to:
> #declare Acajou = srgb <0.29804,0.18431,0.15294>;
>background { color Acajou }
> and the cpu time jumps...
[snip]
In the Windows version of UberPOV beta 10 (the version I downloaded, as above),
the render times for Ton's scene are identical, with or without this
background/color change-- a quick 4 seconds at 800X600. But the visual results
indicate that AA is not working at all, or very minimally. And, as you mentioned
earlier, the render statistics say:
Antialiasing...on (Method 3, Threshold 0.100, Depth 6, Jitter 1.00, Gamma 2.50)
samples: 0 Smpls/Pxl: 0.00
-----------
[off-topic]
This UberPOV beta 10 'stand-alone'(?) installation was an interesting
experience. Unpacking it in 7-zip, it unzips as a 'application'. I thought this
would be an 'installer'-- but no, clicking on it launches UberPOV itself...with
scenes present that I had already opened in some other version of POV-ray. It
makes me wonder what assets this version is automatically using; maybe from
within my 3.7.0 folder(s)?
Another odd thing:
Running Ton's test scene the first time in this version, there was a fatal
error... in his camera declaration, of all places!
camera
{
location <25, 8, 0>
right <image_width / image_height, 0, 0>
look_at <12, 0, 0>
}
The fatal error was at the 2nd line-- ""Expected numneric expression, / found
instead". Huh?!
So I changed that line to the more standard syntax,
right x*image_width/image_height
..... but that triggered a *different* fatal error...
"No matching } in 'camera', * found instead". Huh?!
I finally got it to work by using
right <1.3333,0,0>
Very strange...especially since my own more complex scenes run perfectly OK with
the 'problem' syntax. (Although, in my scenes, I never put the camera
declaration as the last item. Maybe that's the culprit?)
It's a good thing that I have a sense of humor; otherwise, these crazy errors
would drive me insane ;-)
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On 9/18/20 7:22 AM, William F Pokorny wrote:
> On 9/18/20 6:36 AM, William F Pokorny wrote:
> ...
>>
>> I don't think we have a fat rabbit to chase here.
>>
>> Of course run time improvements with am3 would be welcome. I have on
>> my list to do some profiling with parametrics. Might take a side look
>> at am3 too while I've got those compiles about. I've got the color
>> shift issue to replicate and run down someday too. Hmm, wonder if I
>> can trigger it with your simpler test cast Ton.
>>
>
> We can indeed! All one needs do is change:
>
> background { color srgb <0, 0, 0> }
>
> to:
>
> #declare Acajou = srgb <0.29804,0.18431,0.15294>;
> background { color Acajou }
>
> and the cpu time jumps.
>
> 16.918 -> 3443.029 ---> 20251.28%
>
> Plus the results are to my eye not as good.
>
> Does uberpov has the same behavior:
>
> 16.172 -> 3512.926 ---> 21622.27%
>
> A fat rabbit.
>
> Bill P.
tried changing my am3 test file like above ... cannot duplicate issue
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On 9/18/20 10:47 AM, Kenneth wrote:
> "Ton" <ton### [at] gmail com> wrote:
>
>> My version of uberpov is from https://github.com/UberPOV/UberPOV, the last
>> version, dated 10 February 2015.
>
> OK. I downloaded the Windows 64-bit version of this-- I *think* it's the correct
> 'stand-alone' version-- dated one day earlier on the Github page: UberPOV
> v1.37.1.0.beta10
>
>> Povray 3.7 doesn't have the stochastic rendering mode am3, that's probably why
>> your plugin on version 3.7.0 doesn't work...
>
> Apparently you're correct; this earlier(!) version of UberPOV DOES recognize the
> "+ac0.9" command. That seems strange to me; I would have thought that the
> (later) piggyback version for 3.7.0 would also have that ability already
> built-in to its binary, thus 'overriding' 3.7.0's limitation. Anyway, it does
> work. Thanks.
>
> [William wrote...}
>> Hmm, wonder if I can trigger it with your simpler test cast Ton.
>>
>> We can indeed! All one needs do is change:
>> background { color srgb <0, 0, 0> }
>> to:
>> #declare Acajou = srgb <0.29804,0.18431,0.15294>;
>> background { color Acajou }
>> and the cpu time jumps...
> [snip]
>
> In the Windows version of UberPOV beta 10 (the version I downloaded, as above),
> the render times for Ton's scene are identical, with or without this
> background/color change-- a quick 4 seconds at 800X600. But the visual results
> indicate that AA is not working at all, or very minimally. And, as you mentioned
> earlier, the render statistics say:
>
> Antialiasing...on (Method 3, Threshold 0.100, Depth 6, Jitter 1.00, Gamma 2.50)
>
> samples: 0 Smpls/Pxl: 0.00
>
> -----------
> [off-topic]
> This UberPOV beta 10 'stand-alone'(?) installation was an interesting
> experience. Unpacking it in 7-zip, it unzips as a 'application'. I thought this
> would be an 'installer'-- but no, clicking on it launches UberPOV itself...with
> scenes present that I had already opened in some other version of POV-ray. It
> makes me wonder what assets this version is automatically using; maybe from
> within my 3.7.0 folder(s)?
>
> Another odd thing:
> Running Ton's test scene the first time in this version, there was a fatal
> error... in his camera declaration, of all places!
>
> camera
> {
> location <25, 8, 0>
> right <image_width / image_height, 0, 0>
> look_at <12, 0, 0>
> }
>
> The fatal error was at the 2nd line-- ""Expected numneric expression, / found
> instead". Huh?!
>
> So I changed that line to the more standard syntax,
> right x*image_width/image_height
>
> ..... but that triggered a *different* fatal error...
> "No matching } in 'camera', * found instead". Huh?!
>
> I finally got it to work by using
> right <1.3333,0,0>
>
> Very strange...especially since my own more complex scenes run perfectly OK with
> the 'problem' syntax. (Although, in my scenes, I never put the camera
> declaration as the last item. Maybe that's the culprit?)
>
> It's a good thing that I have a sense of humor; otherwise, these crazy errors
> would drive me insane ;-)
i've not followed uber for a bit now ... but in version povray
3.8.0-alpha.10064268 you don't even have to set the right vector
anymore: http://wiki.povray.org/content/Reference:Camera#Aspect_Ratio
... so i'm not sure where the uber you're using is at ... just a thought.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Ash Holsenback <no### [at] spam com> wrote:
>
> i've not followed uber for a bit now ... but in version povray
> 3.8.0-alpha.10064268 you don't even have to set the right vector
> anymore: http://wiki.povray.org/content/Reference:Camera#Aspect_Ratio
Thanks; I didn't know about that change.
> ... so i'm not sure where the uber you're using is at ...
All of the versions that I could find are here:
https://github.com/UberPOV/UberPOV/releases
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
hi,
Ash Holsenback <no### [at] spam com> wrote:
> On 9/18/20 7:22 AM, William F Pokorny wrote:
> > On 9/18/20 6:36 AM, William F Pokorny wrote:
> > ...
> >>
> >> I don't think we have a fat rabbit to chase here.
> >>
> >> Of course run time improvements with am3 would be welcome. I have on
> >> my list to do some profiling with parametrics. Might take a side look
> >> at am3 too while I've got those compiles about. I've got the color
> >> shift issue to replicate and run down someday too. Hmm, wonder if I
> >> can trigger it with your simpler test cast Ton.
> >>
> >
> > We can indeed! All one needs do is change:
> >
> > background { color srgb <0, 0, 0> }
> >
> > to:
> >
> > #declare Acajou = srgb <0.29804,0.18431,0.15294>;
> > background { color Acajou }
> >
> > and the cpu time jumps.
> >
> > 16.918 -> 3443.029 ---> 20251.28%
> >
> > Plus the results are to my eye not as good.
> >
> > Does uberpov has the same behavior:
> >
> > 16.172 -> 3512.926 ---> 21622.27%
> >
> > A fat rabbit.
> >
> > Bill P.
>
> tried changing my am3 test file like above ... cannot duplicate issue
fwiw, same here, also alpha.10064268. in fact the coloured bg version is
faster,
edited transcript:
Script started on Fri 18 Sep 2020 20:58:43 BST
jr@crow:1:tmp$ c### [at] ngton pov
#version 3.8;
global_settings {
assumed_gamma 1
noise_generator 2
}
#ifndef (global.N)
#declare N = 0;
#end
#if (N)
background {color srgb <.29804,.18431,.15294>}
#else
background {color srgb 0}
#end
union {
#for (I, -25, 25, 1)
cylinder {
<-20, 0, 0>, <20, 0, I>, 0.01
}
#end
pigment {
color srgb<1, 1, 1>
}
}
light_source {
<25, 8, 0>, rgb<1, 1, 1>
}
camera {
location <25, 8, 0>
right <image_width / image_height, 0, 0>
look_at <12, 0, 0>
}
jr@crow:2:tmp$ pov38 ngton.pov +d +p +q9 +am3 +a0.1 +ac0.9 +r6
Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10064268.unofficial
(g++ 4.8.2 @ x86_64-slackware-linux-gnu)
...
Support libraries used by POV-Ray:
ZLib 1.2.8, Copyright 1995-2012 Jean-loup Gailly and Mark Adler
LibPNG 1.4.20, Copyright 1998-2012 Glenn Randers-Pehrson
LibJPEG 8, Copyright 1991-2016 Thomas G. Lane, Guido Vollbeding
LibTIFF 3.9.7, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI
Boost 1.54, http://www.boost.org/
OpenEXR 1.7.1 and IlmBase 1.0.3, Copyright (c) 2002-2011 Industrial Light &
Magic.
Dynamic optimizations:
CPU detected: Intel,SSE2,AVX
Noise generator: avx-intel (hand-optimized by Intel)
Parser Options
Input file: ngton.pov
Remove bounds........On
Split unions.........Off
Library paths:
/home/jr/.local/povray/include
/usr/local/share/povray-3.8/extra
/usr/local/share/povray-3.8/include
/usr/share/fonts/local
Clock value: 0.000 (Animation off)
Image Output Options
Image resolution.....960 by 720 (rows 1 to 720, columns 1 to 960).
Output file..........ngton.png, 24 bpp PNG
Dithering............Off
Graphic display......On (gamma: sRGB transfer function)
Mosaic preview.......Off
Continued trace......Off
Information Output Options
All Streams to console..........On
Debug Stream to console.........On
Fatal Stream to console.........On
Render Stream to console........On
Statistics Stream to console....On
Warning Stream to console.......On
==== [Parsing...] ==========================================================
----------------------------------------------------------------------------
Parser Statistics
----------------------------------------------------------------------------
Finite Objects: 51
Infinite Objects: 0
Light Sources: 1
Total: 52
----------------------------------------------------------------------------
Parser Time
Parse Time: 0 hours 0 minutes 0 seconds (0.001 seconds)
using 1 thread(s) with 0.000 CPU-seconds total
Bounding Time: 0 hours 0 minutes 0 seconds (0.000 seconds)
using 1 thread(s) with 0.000 CPU-seconds total
----------------------------------------------------------------------------
Render Options
Quality: 9
Bounding boxes.......On Bounding threshold: 3
Antialiasing.........On (Method 3, Threshold 0.100, Depth 6, Jitter 1.00,
Gamma 2.50)
==== [Rendering... Press p to pause, q to quit] ============================
----------------------------------------------------------------------------
Render Statistics
Image Resolution 960 x 720
----------------------------------------------------------------------------
Pixels: 691200 Samples: 0 Smpls/Pxl: 0.00
Rays: 5249224 Saved: 0 Max Level: 1/5
----------------------------------------------------------------------------
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------------------
Cone/Cylinder 123247827 1250084 1.01
Bounding Box 187640060 147701275 78.72
----------------------------------------------------------------------------
Shadow Ray Tests: 1226634 Succeeded: 0
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Render Time:
Photon Time: No photons
Radiosity Time: No radiosity
Trace Time: 0 hours 0 minutes 11 seconds (11.444 seconds)
using 2 thread(s) with 22.876 CPU-seconds total
==== [Paused... Press p to resume] =========================================
Press p, q, enter or click the display to continue...
POV-Ray finished
jr@crow:3:tmp$ pov38 ngton.pov +d +p +q9 +am3 +a0.1 +ac0.9 +r6 declare=N=1
Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10064268.unofficial
(g++ 4.8.2 @ x86_64-slackware-linux-gnu)
...
----------------------------------------------------------------------------
Render Statistics
Image Resolution 960 x 720
----------------------------------------------------------------------------
Pixels: 691200 Samples: 0 Smpls/Pxl: 0.00
Rays: 2283041 Saved: 0 Max Level: 1/5
----------------------------------------------------------------------------
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------------------
Cone/Cylinder 51037867 472363 0.93
Bounding Box 77941671 61111153 78.41
----------------------------------------------------------------------------
Shadow Ray Tests: 463586 Succeeded: 0
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Render Time:
Photon Time: No photons
Radiosity Time: No radiosity
Trace Time: 0 hours 0 minutes 5 seconds (5.006 seconds)
using 2 thread(s) with 9.995 CPU-seconds total
==== [Paused... Press p to resume] =========================================
Press p, q, enter or click the display to continue...
POV-Ray finished
'pov38' is a BASH alias for 'nice -n 19 povray'.
regards, jr.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
"jr" <cre### [at] gmail com> wrote:
> Ash Holsenback <no### [at] spam com> wrote:
> > On 9/18/20 7:22 AM, William F Pokorny wrote:
> > > On 9/18/20 6:36 AM, William F Pokorny wrote:
> > > ...
> > > and the cpu time jumps.
> > > ...
> fwiw, ...
no sleep. :-( so, if you (WFP)/anyone is interested, I can add to the ..
mystery.
I have the same alpha.10064268 installed on two machines, and I mean the same.
both built from the same tarball using nearly identical package build scripts.
on one machine, as posted, I see a decrease in time by (just) better than 50%
for the coloured background. on the other, the alpha behaves as you describe,
time up from seconds to over a quarter of an hour. wow. I also tried two older
3.8.0-alphas (9893777 and 9945627) on a third box, they too run faster by around
50% when colour is used. one thing I noticed is that where time decreases, on
the older boxes, the "CPU detected" reads "Intel,SSE2,AVX", whereas for the ..
misbehaving alpha (newer box) it's "Intel,SSE,AVX,AVX2,FMA3". no idea whether
that is relevant, still, it'd be interesting to know what CPU flags others see.
anyway, as Kenneth intimated, computing, eh? -- all good fun.
regards, jr.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On 9/18/20 8:21 PM, jr wrote:
> "jr" <cre### [at] gmail com> wrote:
...
>
> no sleep. :-( so, if you (WFP)/anyone is interested, I can add to the ..
> mystery.
>
> I have the same alpha.10064268 installed on two machines, and I mean the same.
> both built from the same tarball using nearly identical package build scripts.
> on one machine, as posted, I see a decrease in time by (just) better than 50%
> for the coloured background. on the other, the alpha behaves as you describe,
> time up from seconds to over a quarter of an hour. wow. I also tried two older
> 3.8.0-alphas (9893777 and 9945627) on a third box, they too run faster by around
> 50% when colour is used. one thing I noticed is that where time decreases, on
> the older boxes, the "CPU detected" reads "Intel,SSE2,AVX", whereas for the ..
> misbehaving alpha (newer box) it's "Intel,SSE,AVX,AVX2,FMA3". no idea whether
> that is relevant, still, it'd be interesting to know what CPU flags others see.
> anyway, as Kenneth intimated, computing, eh? -- all good fun.
>
>
Jim, and all thanks for the data. And jr, especially, for picking up the
"Intel,SSE,AVX,AVX2,FMA3" bit. It is what I see here for run time
optimization. I've hit a few other cases where - for whatever reasons -
that run time CPU optimization isn't faster for me, though usually it
is. Nothing previously was anywhere as dramatic a slow down.
I've never looked over Christoph's am3 code. Guess I'll go take a peek.
Bill P.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
On 9/19/20 8:22 AM, William F Pokorny wrote:
...
>
> I've never looked over Christoph's am3 code. Guess I'll go take a peek.
>
Hey jr, Given you have machine which shows the slow down and one which
does not, would you be willing to add the following test in compiles for
both machines? Then try white/black and white/color renders on both?
In tracetask.cpp, at about line 764, insert code so things look like:
double cf = confidenceFactor[neighborSamples-1];
PreciseRGBTColour sqrtvar = Sqrt(variance);
if (variance.red()<0)
throw POV_EXCEPTION_STRING("kaboom");
PreciseRGBTColour confidenceDelta = sqrtvar * cf;
I think in povr I've fixed the stats - so your line counts might be a
little different.
I hacked the up front confidence array (as vector) to something simpler
so my b/w runs in about 2 seconds and my color one in 34s. Stats now
show for the two renders:
Pixels: 360000 Samples: 609399 Smpls/Pxl: 1.69
and
Pixels: 360000 Samples: 9511337 Smpls/Pxl: 26.42
Bill P.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|
 |