It looks like for each MatrixTransform you add to the scene, you get TWO calls to glMatrixUnform4fv, one for the osg_ModelViewMatrix and one for the osg_ModelViewProjectionMatrix Compared to the fixed pipeline I have 1500 gl calls during one frame, and in fixed only 450. That should make for some of the decrease in performance.
Other than that a profiling does not give anything specific CPU related when running the application. It is just that the draw call can be 2-4 times slower (perhaps due to the number of gl calls). But the GPU time is also higher, about 100% with the same complexity (and a really simple shader). /A On Thursday, April 8, 2021 at 10:05:28 AM UTC+2 robert....@gmail.com wrote: > Hi Anders, > > On Thu, 8 Apr 2021 at 08:42, Anders Backman <backm...@gmail.com> wrote: > >> Have you all noticed that the time for Draw is dramatically more >> expensive for a shader based scene compared to fixed functionality? > > > It can be faster or slower, it depends upon the nature of your scene graph > and how you manage state. If you have lots of uniforms and lots of > different shaders then this could introduce a high CPU overhead. > > In general for a shader based subgraph the CPU overhead tends to be > higher. However, shaders gives you lots of opportunities to batch data, > use things like instancing etc, so you can overall end up with a lower CPU > overhead. > > > >> I have the most basic shader possibility comparing to a fixed >> functionality rendering pipeline. The difference in Draw call is: >> >> 1.3 ms (fixed) compared to *3.74ms* (shader) in a scene with 300 boxes. >> 7776 vertices, 3886 triangles. >> >> RTX2080. Windows 10. OSG 3.6.4. >> >> It feels kind of bad to start with a huge overhead already from the start. >> For larger scenes the difference shrinks. Still very much noticeable. >> With a stupid scene with 10000 drawables (same boxes) difference between >> "empty" shader is < 10%. >> > > The OSG/OpenGL combination doesn't handle fine grained scene graphs at all > well - hence my batching comment above. Could you try instancing to reduce > the CPU overhead. > > Or... try the VulkanSceneGraph/Vulkan. It sounds like a simple enough > scene graph to replicate quite easily in the VSG, it may well be an order > of magnitude faster for the type of usage case even without using > techniques like instancing to batch the data. > > Cheers, > Robert. > -- 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/9fee7eaf-5b13-49b4-b9e2-23fe99870d7dn%40googlegroups.com.
