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