VTune Results; cRenderWorker::RayRecursion; VolumetricShader vs. RayMarching

[mancoast]

Greetings,

I am curious about the Volumetric Shader.
It appears that cLights::GetLight is causing some sort of bottleneck in execution.
Please consider the data below.


This first screenshot shows a tree view summary of CPU instruction usages by functions.
99.5% of total execution cycles are spent within the scope of cRenderWorker::doWork.
For this particular hotspots view in Vtune, percentages are shown in the GUI.

 
We also know that 99.4% of time is spent executing cRenderWorker::RayRecursion.
One level deeper inside RayRecursion, we see 24.4% of time allocated to cRenderWorker::RayMarching.
Also inside RayRecursion, we see 68.2% of time allocated to cRenderWorker::VolumetricShader.

 
With source code view, see 24.4% of time allocated to cRenderWorker::RayMarching.

 
With source code view, see 68.2% of time allocated to cRenderWorker::VolumetricShader.

 
This leads me to believe that we are spending much time in the VolumetricShader.
Within cRenderWorker::VolumetricShader there are two loops retiring billions of instructions to self.

 
The loop at line 349 of VolumetricShader contains function call to cLights::GetLight.

 
Also, the loop at line 375 of VolumetricShader contains function call to cLights::GetLight.

 
It appears that over 50% of all CPU instructions are retired by function calls to cLights::GetLight.

 
The loop at line 349 of VolumetricShader contains function call to cLights::GetLight.
This specific call to cLights::GetLight retires approximately 25% of all CPU instructions.

 
Also, the loop at line 375 of VolumetricShader contains function call to cLights::GetLight.
This other call to cLights::GetLight also retires approximately 25% of all CPU instructions.

 

Why these calls to cLights::GetLight are consuming so many CPU cycles?
Any suggestions for optimization?

Thanks,
coast

[Buddhi]

Could you attach settings which you used for testing?

[mancoast]

6mb too big to attach, heres the link

https://github.com/mancoast/mandelbulber2/raw/k1om/_menger-coastn_anim.fract

[taurus]

6mb too big to attach, heres the link

https://github.com/mancoast/mandelbulber2/raw/k1om/_menger-coastn_anim.fract

Little noob question inbetween. Did you ever render this animation? Depending on fps it should be around 20 minutes. I wonder wether all the stuff below [frames] was necessary to point out, what you mean.

[Buddhi]

6mb too big to attach, heres the link

https://github.com/mancoast/mandelbulber2/raw/k1om/_menger-coastn_anim.fract

It's a HUGE test case! Have you rendered whole animation to do benchmarking or only one frame. I'm asking because I would like to do similar profiling using valgrind and then start to look why cLights::GetLight() was highlighted here.

[mancoast]

Hello,

This render is not yet completed.
For VTune I render a randomly selected frame.
This keeps the results fresh with different samples.

After Vtune/changes, I run overnight on the servers to get frame to frame time differences.

As of now, its about 50%.

I am excited to test your latest commit with the isAnyLight modification.

Thanks,
coast

[Buddhi]

Thanks to your enormous animation I have found and fixed another bug. The program allocated too much memory when flight animation was loaded and previews were used. No it uses about 20% of former memory usage. I have also improved speed of refreshing animation table.