Hi again,

 

Thanks for tips. The final implementation will work on 4 displays (2 video cards (NVIDIA) with 2 displays each).

So, I don’t really need two windows on each card. I can use 2 windows with 2 viewports… but I saw in osgProducer::OsgCameraGroup :

            if (renderSurfaceSet.size()!=_cfg->getNumberOfCameras())

        {

            // camera's must be sharing a RenderSurface, so we need to ensure that we're

            // running single threaded, to avoid OpenGL threading issues.

            _threadModel = Producer::CameraGroup::SingleThreaded;

        }

Is there a way to use 2 render surfaces with 2 cameras each, also multi-threaded (I mean 1 thread running 2 cameras for each window)?

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 16 octobre 2006 12:04
To: osg users
Subject: Re: [osg-users] Draw and SwapBuffers performance

 

Hi Mathieu,

For each graphics card you have basically one GPU than can only handle rendering from one graphics context at one time, and switching between these contexts will require flushes of all currently disptched commands and a state switch on the GPU to switch between the contexts, this is going to be expensive.  Ideally you should have one thread, rendering to one context on one graphics card. 

Do you really need two windows on each card? Could you get away with one window but two viewports?

If you really do need two seperate windows that the best solution would be two have the rendering for each camera to be seriealized.  Producer/osgProducer doesn't support this model of threading though so you'd have to manage it by hand.

Robert.

On 10/16/06, Labbe, Mathieu <[EMAIL PROTECTED]> wrote:

Hello,

            I'm testing the performance of OSG 1.2 with 2 displays (2 video cards (NVIDIA) with 1 display each and 2 CPUs dual core). I had strange results so I need help to understand. (I tested it on an application like OsgViewer). I used the stats option and some "printf()", I got these numbers:

 

With 4 cameras with same view, 4 contexts (4 windows 640 / 512, two windows on each display). At this point, I have 4 threads for the cameras:

FPS: 19.5                    

Update: 0.29 ms

Cull: 2.4 ms       Draw: 40 ms      GPU: 32 ms      Swap Buffers: 2.5 ms

Cull: 1.9 ms       Draw: 38 ms      GPU: 34 ms      Swap Buffers: 3.2 ms

Cull: 2.3 ms       Draw: 38 ms      GPU: 26 ms      Swap Buffers: 3.9 ms

Cull: 1.9 ms       Draw: 38 ms      GPU: 26 ms      Swap Buffers: 6.4 ms

 

Total:    Cull: 2.4 ms       Draw: 40 ms      Swap Buffers: 6.4 ms     = 20.49 Hz

 

With 4 cameras with same view, 1 context (1 window 2560 / 512, half of the window on each display). At this point, I have 1 thread for the cameras:

FPS: 39.7                    

Update: 0.18 ms

Cull: 1.2 ms       Draw: 5.4 ms     GPU: 0.6 ms    

Cull: 1.3 ms       Draw: 3.5 ms     GPU: 1.4 ms    

Cull: 1.2 ms       Draw: 3.5 ms     GPU: 0.5 ms    

Cull: 1.3 ms       Draw: 3.5 ms     GPU: 0.5 ms    

 

Total:    Cull: 5 ms         Draw: 15.9 ms   Swap Buffers: 4.3 ms     = 39.7 Hz

 

Why drawing stage is ten times larger (for each camera) when the threads are used?

 

I supposed that each camera calls glCallList() and for that, the threads don't have access to GPUs simultaneously. I tried to force the drawing stage to be sequential (I used a mutex around sh->draw( *this ) in Producer::Camera). I obtained these results:

 

With 4 cameras with same view, 4 contexts (4 windows 640 / 512, two windows on each display). At this point, I have 4 threads for the cameras:

FPS: 37                       

Update: 0.32 ms

Cull: 2.0 ms       Draw: 3.7 ms     GPU: 0.9 ms     Swap Buffers: 7.5 ms

Cull: 2.3 ms       Draw: 3.3 ms     GPU: 5.1 ms     Swap Buffers: 8.0 ms

Cull: 1.9 ms       Draw: 3.3 ms     GPU: 1.6 ms     Swap Buffers: 7.5 ms

Cull: 2.4 ms       Draw: 3.5 ms     GPU: 1.5 ms     Swap Buffers: 10.4 ms

 

Total:    Cull: 2.4 ms       Draw: 13.8 ms   Swap Buffers: 10.4 ms   = 37.6 Hz

 

Now I get better performance when the drawing stage is sequential (?!?why?!?) but the Swap Buffers take almost the double times of the initial configuration. I'm not very familiar with the SwapBuffers() function, so if someone who wants to tell me how it works (to explain why SwapBuffers() time are not always the same), it will be appreciated :)

 

Mathieu

 


_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

 

_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to