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 [email protected] wrote:

> Hi Anders,
>
> On Thu, 8 Apr 2021 at 08:42, Anders Backman <[email protected]> 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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/9fee7eaf-5b13-49b4-b9e2-23fe99870d7dn%40googlegroups.com.

Reply via email to