 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2020-04-30 7:23 AM (-4), William F Pokorny wrote:
>
> Thanks for the update.
You're welcome.
> I've never gotten to where evaluate is part of my isosurface flow... How
> much does the evaluate feature typically buy you?
>
> In my experiments 10-15% at most - and it's sometimes slower, but I've
> also not stuck with using it. Am I'm missing bigger possible gains?
In my experience it helps with POV-Ray 3.6, but slows things down with
POV-Ray 3.7--for the same isosurface function! I once had a mind to ask
the group about this anomaly, but I never got a round tuit (POVers
charge a premium for those!), and I cannot find my records of the timing
statistics. I don't normally use it, but I believe Thomas de Groot uses
it a great deal.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cousin Ricky <ric### [at] yahoo com> wrote:
> In my experience it helps with POV-Ray 3.6, but slows things down with
> POV-Ray 3.7--for the same isosurface function! I once had a mind to ask
> the group about this anomaly, but I never got a round tuit (POVers
> charge a premium for those!), and I cannot find my records of the timing
> statistics. I don't normally use it, but I believe Thomas de Groot uses
> it a great deal.
Hmmm. I didn't know about the 3.6 to 3.7 issue.
I use it ... maybe 50% of the time?
Because I'm fantastically lazy with experimental / developmental code, and just
copy existing code from whatever file or open tab is closest at hand.
I have been meaning to get 'round to writing a nice concise isosurface code
block for my Insert Menu stuff, but I haven't gotten there yet. Maybe by
2021...
If I can remember to do it, I can record times for with/without evaluate in the
future.
Maybe I'll just collect a bunch of functions into an array and see if I can
figure out how to record the render times automagically when I run them all as
an animation.
Is there a way to access and record the max_gradient that was found and write
that to a file?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2020-04-30 1:29 PM (-4), Bald Eagle wrote:
>
> Is there a way to access and record the max_gradient that was found and write
> that to a file?
The Warning_Console option (+GW) should do it. But beware that 3.7
neglects to report the max_gradient under certain conditions. See:
https://news.povray.org/povray.beta-test/thread/%3Cweb.51c722c522807ec9540235480%40news.povray.org%3E/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 30/04/2020 om 18:21 schreef Cousin Ricky:
> On 2020-04-30 7:23 AM (-4), William F Pokorny wrote:
>>
>> I've never gotten to where evaluate is part of my isosurface flow...
>> How much does the evaluate feature typically buy you?
>>
>> In my experiments 10-15% at most - and it's sometimes slower, but I've
>> also not stuck with using it. Am I'm missing bigger possible gains?
>
> In my experience it helps with POV-Ray 3.6, but slows things down with
> POV-Ray 3.7--for the same isosurface function! I once had a mind to ask
> the group about this anomaly, but I never got a round tuit (POVers
> charge a premium for those!), and I cannot find my records of the timing
> statistics. I don't normally use it, but I believe Thomas de Groot uses
> it a great deal.
I have not really used 'evaluate' in my isosurfaces. I have played with
it of course but as far as I can remember, I did not find any
significant use for it in my scenes. I browsed a couple of them and
'evalate' is never used.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2020-05-01 2:51 AM (-4), Thomas de Groot wrote:
> Op 30/04/2020 om 18:21 schreef Cousin Ricky:
>>
>> In my experience it helps with POV-Ray 3.6, but slows things down with
>> POV-Ray 3.7--for the same isosurface function! I once had a mind to
>> ask the group about this anomaly, but I never got a round tuit (POVers
>> charge a premium for those!), and I cannot find my records of the
>> timing statistics. I don't normally use it, but I believe Thomas de
>> Groot uses it a great deal.
>
> I have not really used 'evaluate' in my isosurfaces. I have played with
> it of course but as far as I can remember, I did not find any
> significant use for it in my scenes. I browsed a couple of them and
> 'evalate' is never used.
Hmmmm. Perhaps I'm mixing you up with one of the many POVers doing
Landscapes Of The Week many years ago. The search continues for a
satisfied evaluate user...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 01/05/2020 om 18:44 schreef Cousin Ricky:
> On 2020-05-01 2:51 AM (-4), Thomas de Groot wrote:
>> Op 30/04/2020 om 18:21 schreef Cousin Ricky:
>>>
>>> In my experience it helps with POV-Ray 3.6, but slows things down
>>> with POV-Ray 3.7--for the same isosurface function! I once had a
>>> mind to ask the group about this anomaly, but I never got a round
>>> tuit (POVers charge a premium for those!), and I cannot find my
>>> records of the timing statistics. I don't normally use it, but I
>>> believe Thomas de Groot uses it a great deal.
>>
>> I have not really used 'evaluate' in my isosurfaces. I have played
>> with it of course but as far as I can remember, I did not find any
>> significant use for it in my scenes. I browsed a couple of them and
>> 'evalate' is never used.
>
> Hmmmm. Perhaps I'm mixing you up with one of the many POVers doing
> Landscapes Of The Week many years ago. The search continues for a
> satisfied evaluate user...
Christoph Hormann perhaps?
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/30/20 12:21 PM, Cousin Ricky wrote:
...
>
>> I've never gotten to where evaluate is part of my isosurface flow...
>> How much does the evaluate feature typically buy you?
>>
>> In my experiments 10-15% at most - and it's sometimes slower, but I've
>> also not stuck with using it. Am I'm missing bigger possible gains?
>
> In my experience it helps with POV-Ray 3.6, but slows things down with
> POV-Ray 3.7--for the same isosurface function! I once had a mind to ask
> the group about this anomaly, but I never got a round tuit (POVers
> charge a premium for those!), and I cannot find my records of the timing
> statistics. I don't normally use it, but I believe Thomas de Groot uses
> it a great deal.
Hmm, That stinks of a thread safety issue. Let me take a quick look at
the code.
On a quick read I agree with comments left long ago from the core
developers - evaluate is not thread safe... ;-)
Also sort of looks like the on the fly evaluate adjustments are sticky
for the isosurface. Meaning they are not done on a ray by ray basis
which itself is questionable except with really well behaved functions
(no sharp edges / local high gradients).
All doesn't mean things won't kinda sorta work if you set the right
limiting parameters. Isosurfaces are like that...
Will take a deeper look before 'boom,' but think this feature just made
my povr nuke it list. There is considerable overhead for it even when
not using it.
If someone wants to test how much performance we get in v37, v38 by
using it, running with one thread best for accuracy. Unsure what to
trust results wise. A box with sharpish edges - it might adjust the
internal gradient downward to where the image at the sharp edges changes
(sharper bits get missed). Who knows, maybe this would make for a
smoother image on average, certainly would render faster.
If folks do turn up performance numbers, I am still interested.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Given all of the isosurface stuff I [try to] do, and the functions that are
needed to do them, I really do have to say that it seems like something is
amiss.
I mean, I watch people code shaders, and then I follow along the best I can with
analogous POV-Ray code, and things quickly get SLOW - for a single render -
while they are still happily running at 30+ fps.
(and damn - RT vortices... :O
https://www.shadertoy.com/view/MlS3Rh
https://www.win.tue.nl/~vanwijk/ibfv/ibfv.pdf
)
Is it a function evaluation issue?
Do vector functions make thing THAT much faster?
(they even use swizzling)
Is it a core isosurface code issue?
Can the pigment pattern - to - isosurface trick help to speed that up?
Is it that the shaders use GPU rather than cpu (ShaderToy runs in a browser...)
Does the shader stuff somehow get compiled beforehand?
I also have to bring up the parametric object speed again - I haven't yet dug
into the source for that, but it doesn't really make any sense why that should
be any slower than any of the rest of the object primitives, or at least THAT
much slower.
Maybe the reason for its drag can point to clues for speeding up ALL of the
function evaluations?
I would of course like to help - you could always point to filenames in 3.7/3.8
and approximate line numbers so I can familiarize myself with the moving parts
and begin to more fully wrap my head around what's going on and let my
subconscious crunch on it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/2/20 9:51 AM, Bald Eagle wrote:
>
> Given all of the isosurface stuff I [try to] do, and the functions that are
> needed to do them, I really do have to say that it seems like something is
> amiss.
>
> I mean, I watch people code shaders, and then I follow along the best I can with
> analogous POV-Ray code, and things quickly get SLOW - for a single render -
> while they are still happily running at 30+ fps.
>
> (and damn - RT vortices... :O
> https://www.shadertoy.com/view/MlS3Rh
> https://www.win.tue.nl/~vanwijk/ibfv/ibfv.pdf
> )
>
> Is it a function evaluation issue?
> Do vector functions make thing THAT much faster?
> (they even use swizzling)
> Is it a core isosurface code issue?
> Can the pigment pattern - to - isosurface trick help to speed that up?
> Is it that the shaders use GPU rather than cpu (ShaderToy runs in a browser...)
> Does the shader stuff somehow get compiled beforehand?
>
> I also have to bring up the parametric object speed again - I haven't yet dug
> into the source for that, but it doesn't really make any sense why that should
> be any slower than any of the rest of the object primitives, or at least THAT
> much slower.
> Maybe the reason for its drag can point to clues for speeding up ALL of the
> function evaluations?
>
> I would of course like to help - you could always point to filenames in 3.7/3.8
> and approximate line numbers so I can familiarize myself with the moving parts
> and begin to more fully wrap my head around what's going on and let my
> subconscious crunch on it.
>
It's complicated and you've guessed a lot of it.
I think the biggest speed differences come from gpu/simd optimization.
If you can break down a problem in a way which lets you feed those very
wide compute units with huge chunks of the problem at a go, you speed
things up by many multiples - even with simd which isn't that wide(1).
Exploiting gpus / simd units in a general way - which doesn't perch you
at the top of a massive software stack - doesn't look easy to me(2).
Bill P.
(1) - I think even the massively parallel gpu cards are not too far off
from running out of gas. You can only make parallel so much of the job.
With the cpu core counts going ever higher - should we bother with a lot
of gpu optimization?
(2) - I have looked at using GPUs with isosurfaces. A 5000 way min, no
problem... Each time I take a peak at gpu code, it's just too much, ever
changing, software infrastructure. I cannot find a way in that's easy
enough and of general enough use.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/2/20 9:51 AM, Bald Eagle wrote:
>
...
> I also have to bring up the parametric object speed again - I haven't yet dug
> into the source for that, but it doesn't really make any sense why that should
> be any slower than any of the rest of the object primitives, or at least THAT
> much slower.
> Maybe the reason for its drag can point to clues for speeding up ALL of the
> function evaluations?
>
...
>
I don't use it, but forgot about your mention of parametric...
I'm not sure why so slow either though suppose we should expect it to be
3x slower as a sort of baseline. Never looked at it with any of the
performance tools. Next time I have a compile set up for profiling I'll
try to remember to run a parametric or two. Maybe something will pop out.
I've dug a little into parametric shadow issues. I think Jerome has a
github issue open on the parametric for something similar. Didn't dig
deep, but looked to me like the code only returns one root which can be
an problem for shadows.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
