Hi Robert,

>   1) might be the OS or other application/process running at the same time 
> and periodically running,, make sure you
> have as few other apps and processes running during testing
>   2) the OpenGL fifo might be very close to filling on each frame and 
> sometimes fills complete blocking your
> application/OSG from putting more data into the fifom causing the stall.

there's no other major application running at the same time. The system
monitor doesn't show up anything at the stall rate.

Beside the application I have only some consoles open, so no other
graphical application that might be using OpenGL.


> What happens with the stalls if you reduce the amount of data?  Is there a 
> trigger point where the amount of data trips
> the system and it begins to exhibit the stalls?

With the 55MB coordinate/normal data the draw times are very stable
between 14-17ms. With the 110MB coordinate/normal data most draw times
are between 40-50ms with the stall up to 200ms about every 10 frames,
but it's not deterministic every 10 frames.

I just talked to a colleague that tested it on a newer system with the
110MB coordinate/normal data. He has no stalls at all and the draw times
are quite stable at 20ms. I read that the NVIDIA GTX 970 doesn't really
take advantage of PCI-E 3.0 and runs with almost the same performance on
PCI-E 2.0. So I suspect that it might really be about the memory performance.


> Have you tried just using standard vertex arrays, so no VBO and no display 
> lists?  This would force it to copy on each
> new frame, but sometimes can help.

It's a lot slower with standard vertex arrays.


> How is the update, cull and draw, draw GPU stats typically look when working 
> OK and when stalls happen?

The update and cull times are quite low (<0.5ms) in all cases, with or
without the stall and regardless of the size of the coordinate/normal data.


> There may be completely different ways of achieve the end result you want, 
> from using VulkanSceneGraph (Vulkan is just
> far better designed handling data management) through to refactoring to use 
> shaders to do more of the heavy lifting, 

The problem is that it's a big graphical application based on the OpenGL
fixed pipeline so even using shaders for this isn't an option at the
moment, because a lot of other graphical features are based on the fixed
pipeline.

Thanks a lot for your time!


Greetings,
Daniel

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/20210624093934.GA6797%40octa.

Reply via email to