 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/14/20 12:35 PM, William F Pokorny wrote:
> On 9/14/20 4:42 AM, Ton wrote:
>> Hello everybody,
>>
>> when I use am3 (stochastic anti-aliasing) in the latest version
>> (10064738), it
>> is about 5 times slower then in uberpov:
>>
>> Persistence of Vision(tm) Ray Tracer Version
>> 3.8.0-x.10064738.unofficial (g++ 7
>> @ x86_64-pc-linux-gnu)
>> Render Time:
>> Photon Time: No photons
>> Radiosity Time: No radiosity
>> Trace Time: 0 hours 20 minutes 4 seconds (1204.944 seconds)
>> using 4 thread(s) with 4542.093 CPU-seconds total
>>
>> UberPOV Raytracer Version 1.37.1.0-beta.10 (g++ 7 @ x86_64-pc-linux-gnu)
>> Render Time:
>> Photon Time: No photons
>> Radiosity Time: No radiosity
>> Trace Time: 0 hours 3 minutes 52 seconds (232.382 seconds)
>> using 4 thread(s) with 907.615 CPU-seconds total
>>
>> Command line is:
>> povray +d +p +q9 +am3 +a0.1 +ac0.9 +r6 AntiAliasingTest.pov
>> uberpov +d +p +q9 +am3 +a0.1 +ac0.9 +r6 AntiAliasingTest.pov
>>
>> Does anybody have a clue why povray is so much slower?
>>
>> Cheers
>> Ton
>>
>
> Are the results more or less similar?
>
> I know uber differs in code structure. I've myself run across an am3
> case in v3.8 where the run time - on a solid color change - increased
> 100x. Not yet dug into the latter. Beyond that, no idea.
>
> If the AntiAliasingTest.pov scene is relatively small and self
> contained, could you post a copy? I'll at least put it in my issues
> directory, though who knows when I might take a look at it.
>
> Bill P.
i've been using the am3 anti-aliasing in POV-Ray 3.8.0-alpha.10064268 in
conjunction with area lights... i'm able to use adaptive 0 then use am3
to cleanup edges etc... so i'd appreciate you finding /some/ time to see
if some speed gains can be found
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ton" <ton### [at] gmail com> wrote:
>
> Wow, a hundred times slower, and I was complaining about 5 times!
>
> Here is my little test file:
[snip}
on Windows 7...
I don't know if this is useful, but I ran your test scene in three different
version of POV-Ray, using your command-line switches. 800 X 600 render.
1) the experimental build you used (Windows version) which is the most recent--
v3.8.0x.10064738+av694
render time: 19 seconds
2) the latest development build-- v3.8.0-alpha.10064268+av691
render time: 23 seconds
3) v3.7.1-beta 9 (which isn't really useful as a comparison-- I had to delete
"ac0.9" from the command line, as this version didn't recognize it)
render time: 93 seconds
The two 3.8.0 versions produce relatively close render times in Windows... so it
seems that the LONG render time might be Linux-specific(?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/15/20 6:20 PM, Kenneth wrote:
> "Ton" <ton### [at] gmailcom> wrote:
>
>>
>> Wow, a hundred times slower, and I was complaining about 5 times!
>>
>> Here is my little test file:
> [snip}
>
> on Windows 7...
> I don't know if this is useful, but I ran your test scene in three different
> version of POV-Ray, using your command-line switches. 800 X 600 render.
>
> 1) the experimental build you used (Windows version) which is the most recent--
> v3.8.0x.10064738+av694
>
> render time: 19 seconds
>
> 2) the latest development build-- v3.8.0-alpha.10064268+av691
>
> render time: 23 seconds
>
> 3) v3.7.1-beta 9 (which isn't really useful as a comparison-- I had to delete
> "ac0.9" from the command line, as this version didn't recognize it)
>
> render time: 93 seconds
>
> The two 3.8.0 versions produce relatively close render times in Windows... so it
> seems that the LONG render time might be Linux-specific(?)
>
>
>
>
linux POV-Ray 3.8.0-alpha.10064268 at 800 x 600 ... 16.116 seconds
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/15/20 7:38 PM, Ash Holsenback wrote:
> On 9/15/20 6:20 PM, Kenneth wrote:
>> "Ton" <ton### [at] gmailcom> wrote:
>>
>>>
>>> Wow, a hundred times slower, and I was complaining about 5 times!
>>>
>>> Here is my little test file:
>> [snip}
>>
>> on Windows 7...
>> I don't know if this is useful, but I ran your test scene in three
>> different
>> version of POV-Ray, using your command-line switches. 800 X 600 render.
>>
>> 1) the experimental build you used (Windows version) which is the most
>> recent--
>> v3.8.0x.10064738+av694
>>
>> render time: 19 seconds
>>
>> 2) the latest development build-- v3.8.0-alpha.10064268+av691
>>
>> render time: 23 seconds
>>
>> 3) v3.7.1-beta 9 (which isn't really useful as a comparison-- I had to
>> delete
>> "ac0.9" from the command line, as this version didn't recognize it)
>>
>> render time: 93 seconds
>>
>> The two 3.8.0 versions produce relatively close render times in
>> Windows... so it
>> seems that the LONG render time might be Linux-specific(?)
>>
>>
>>
>>
> linux POV-Ray 3.8.0-alpha.10064268 at 800 x 600 ... 16.116 seconds
when i change version to 3.8 (from 3.7) in the supplied test file...
it's consistently 3 seconds faster
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/14/20 5:26 PM, Ton wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>>
>> Are the results more or less similar?
>>
>> I know uber differs in code structure. I've myself run across an am3
>> case in v3.8 where the run time - on a solid color change - increased
>> 100x. Not yet dug into the latter. Beyond that, no idea.
>>
>> If the AntiAliasingTest.pov scene is relatively small and self
>> contained, could you post a copy? I'll at least put it in my issues
>> directory, though who knows when I might take a look at it.
>>
>> Bill P.
>
> Wow, a hundred times slower, and I was complaining about 5 times!
>
> Here is my little test file:
...
>
Had to recompile my uberpov. The system libraries had changed since I
last compiled. Compiling uber now a bit of a pain as a good many code
and header updates are needed...
Whining ahead of my first morning coffee I guess. :-)
I'll post an image to binary.images, but answering my initial question -
the results are not similar. p380 is am3 working better with your flag
set than is uberpov. This I believe explains the run time difference(1).
Running compiles of the latest commit of both versions, I see the
following slow down uber to v3.8:
2.4 -> 13.02 ---> 442.50%
I also see a bug because in v3.8 we are getting the am3 stats:
...Samples: 0 Smpls/Pxl: 0.00
where we should see >0 samples and samples/pixel >1.0.
(Jim, I see a slight difference v3.7 to v3.8 scene version too 0.5% or
so - not sure what's up there. For performance I run single threaded.
I'd need to do runs forcing longer run times to be sure how real that
difference is I guess - another day perhaps)
Bill P.
(1) - I have a mental itch there was some difference in flag usage
between uberpov and the initial v3.8 implementation - but it's just not
coming to me. Anyone else recall something? Looking at the commit for
v3.8 where am3 came in, it did have additional changes to the base over
uberpov in planning for better interaction with other features like
media. What has or has not been done in that respect for am3 support I
do not know.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in Windows 7--
I finally downloaded UberPOV from Github after all these years(!), to give it a
try-- the 'plug-in' version that runs within v3.7.0. But I'm running into
problems with Ton's test scene, specifically his command-line settings of
+d +p +q9 +am3 +a0.1 +ac0.9 +r6
The "+ac.0.9" command is not being recognized. (And yes, I specified #version
3.8 in the test scene itself, in global_settings). That seems strange, as Ton
gets his scene to work in UberPOV...at least in Linux.
The version of UberPOV I'm using is the 'latest' v1.37 (as of late 2016 I
think). Within v3.7.0, it actually shows up as "v3.8.0-alpha.9811560+av591"
But there is also a stand-alone version of UberPOV with its own installer that
Clipka created at an earlier date. I haven't tried that one yet.
Is there an operational difference between the plug-in version I'm using and the
stand-alone version, concerning the "ac0.9" command?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2020-09-17 à 12:21, Kenneth a écrit :
> in Windows 7--
> I finally downloaded UberPOV from Github after all these years(!), to give it a
> try-- the 'plug-in' version that runs within v3.7.0. But I'm running into
> problems with Ton's test scene, specifically his command-line settings of
> +d +p +q9 +am3 +a0.1 +ac0.9 +r6
>
> The "+ac.0.9" command is not being recognized. (And yes, I specified #version
> 3.8 in the test scene itself, in global_settings). That seems strange, as Ton
> gets his scene to work in UberPOV...at least in Linux.
>
> The version of UberPOV I'm using is the 'latest' v1.37 (as of late 2016 I
> think). Within v3.7.0, it actually shows up as "v3.8.0-alpha.9811560+av591"
>
> But there is also a stand-alone version of UberPOV with its own installer that
> Clipka created at an earlier date. I haven't tried that one yet.
>
> Is there an operational difference between the plug-in version I'm using and the
> stand-alone version, concerning the "ac0.9" command?
>
>
>
The «plugin» version need to reside in a sub-folder of another
installation. It piggy back on another installed version.
The «stand alone» is similar but come with all the other files of a
standard version. As the stand alone version is older, it may contain
some bugs that where fixed in the later version, and lack some
optimizations and features.
You may want to install the standalone version, then, replace the
executable with the latest version.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain Martel <kua### [at] videotronca> wrote:
>
> The «plugin» version need to reside in a sub-folder of another
> installation. It piggy back on another installed version.
Yes, that is what I am currently doing-- the UberPOV v1.37 'plug-in' is
piggybacking on my v3.7.0 installation, as per Clikpa's old instructions.
UberPOV is actually a v3.8.0.alpha+xxx (in Windows, anyway); what is strange is
that the "+ac0.9" command is not recognizied there, whereas it *is* recognized
in the other 3.8.0xx versions I have.
Yet it DOES work for Ton in *his* UberPOV version.
>
> You may want to install the [UberPOV] standalone version, then, replace the
> executable with the latest version.
That's an interesting idea; I guess I could try that as a last resort.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> Alain Martel <kua### [at] videotronca> wrote:
>
> >
> > The «plugin» version need to reside in a sub-folder of another
> > installation. It piggy back on another installed version.
>
> Yes, that is what I am currently doing-- the UberPOV v1.37 'plug-in' is
> piggybacking on my v3.7.0 installation, as per Clikpa's old instructions.
> UberPOV is actually a v3.8.0.alpha+xxx (in Windows, anyway); what is strange is
> that the "+ac0.9" command is not recognizied there, whereas it *is* recognized
> in the other 3.8.0xx versions I have.
>
> Yet it DOES work for Ton in *his* UberPOV version.
>
> >
> > You may want to install the [UberPOV] standalone version, then, replace the
> > executable with the latest version.
>
> That's an interesting idea; I guess I could try that as a last resort.
My version of uberpov is from https://github.com/UberPOV/UberPOV, the last
version, dated 10 February 2015.
My version of povray 3.8 is from https://github.com/POV-Ray/povray/tags, the
last version, v3.8.0-x.10064738, dated 19 February 2019.
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, but I don't have any experience with
the piggy back.
BTW Uberpov out of the box doesn't compile right now, because the
boost-libraries have changed. I wouldn't mind checking my modified files in into
Uberpov, but I need permission to do that, and I don't want to create another
fork of povray. It's complicated and confusing with all those forks as it is.
Cheers
Ton.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/17/20 6:48 PM, Ton wrote:
...
> My version of uberpov is from https://github.com/UberPOV/UberPOV, the last
> version, dated 10 February 2015.
FWIW. That version will be missing the following commit in the uber branch:
commit 0d7ee74f74ec87c5fc93a4d17843491fc193a525
Author: Christoph Lipka <c-l### [at] usersnoreplygithubcom>
Date: Thu Sep 1 21:54:35 2016 +0200
Fixed bug in anti-aliasing mode 3.
This commit compensates for changes in official POV-Ray that caused
the image to be shifted by half a pixel in anti-aliasing mode 3.
---
This doesn't explain the performance difference as I compiled and ran:
commit 0333f9b5a8461aa7adb7fb8adea3b0eb1780caac (HEAD -> UberPOVdev,
UberPOV/develop)
Author: Christoph Lipka <c-l### [at] usersnoreplygithubcom>
Date: Mon Nov 21 03:42:43 2016 +0100
which includes the commit/fix above. I see the performance difference
you see with your flag settings. One I believe is due the v3.8
implementation doing more work (a better job) at any identical set of
flags.
Why? I don't know. Does it much matter? In the end we're after a result.
If I play a while running Uberpov aiming to match consumed cpu time(1),
when I get to 16.97s for v3.8 and 16.2 seconds for Uberpov, the images
are not identical - but the results are now quite similar.
To get these nearly matching image results and times I used:
povray +d +p +q9 +am3 +a0.1 +ac0.9 +r6 AntiAliasingTest.pov
uberpov +d +p +q9 +am3 +a0.035 +ac0.9 +r6 AntiAliasingTest.pov
I have a vague memory something with flag handling was different uberpov
to v3.8 as stated 'somewhere' by Christoph. I cannot clearly remember or
find it.
A wild guess would be something like one implementation getting the
internal anit-alias gamma handling right and other not, but - wild guess.
(1) - If the samples/pixel stats were working we could align these
counts of cpu time consumed.
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.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
