Re: [osg-users] Question about views, contexts and threading

2008-11-24 Thread Ferdi Smit
Robert, I tried your suggestion, but it didn't have any effect. It's probably a driver issue then (nvidia 180.06 beta). I should receive a dual GTX260 system any day now; I'll try and see if that works better. Robert Osfield wrote: HI Ferdi, Could try the same tests but with the following e

Re: [osg-users] Question about views, contexts and threading

2008-11-20 Thread Don Leich
I tried the changes of osgviewer and not much difference on 4 systems except the texture on the cow appears in the copies (Optimizer previously bleached the cow). My traces for system curly look the same. Others systems I just look at behavior. -Don Hi All, On Thu, Nov 20, 2008 at 4:01 P

Re: [osg-users] Question about views, contexts and threading

2008-11-20 Thread Robert Osfield
HI Ferdi, Could try the same tests but with the following env var set: set OSG_SERIALIZE_DRAW_DISPATCH=OFF This will disable the mutex that serializes the draw dispatch. Have a search through the archives on this topic as I've written lots about this topic and the fact serialize draw curious

Re: [osg-users] Question about views, contexts and threading

2008-11-20 Thread Ferdi Smit
Thank you, that at least explains some of the drawing times I've been seeing. I ran more tests on our dual-gpu system, summarized below. Not striclty OSG related, but they may be interesting nonetheless... - Scene of 25x 1 million polygon model, all visible. Culling etc neglibile. - Stand-alo

Re: [osg-users] Question about views, contexts and threading

2008-11-18 Thread Robert Osfield
Hi Ferdi, The understand what is happening with draw in the two instances you need to understand how OpenGL operates. For each graphics context OpenGL maintains a FIFO that is filled by the applications graphics thread for that context, and is drained by the driver that batches the commands/data

Re: [osg-users] Question about views, contexts and threading

2008-11-18 Thread Ferdi Smit
Hi Robert, I ran some more tests with a realistic scene of ~25M polygons (25 times the same 1M model). Stand-alone this is rendered at ~15 FPS on one GPU (8800GTX or Quadro FX5600 + Intel Quad Core). Multi-_processing_ with two contexts at two gpus, both rendering this scene, the 8800 stays at

Re: [osg-users] Question about views, contexts and threading

2008-11-17 Thread Robert Osfield
Hi Ferdi, W.r.t performance and stability of multi-threading the graphics, as long as you have two GPU's the most efficient way to drive them should be multi-threaded - there is a caveat though, hardware and drivers aren't always up to scratch, and even then they should be able to manage the multi

Re: [osg-users] Question about views, contexts and threading

2008-11-17 Thread Ferdi Smit
Thanks Robert. I did a quick test with two viewers from two threads and it appears to be working. Btw, from my experience, PBO doesn't seem to be any faster (and on some hardware much slower) for downloading textures to host than glReadPixels, while for uploads it is almost consistently faster.

Re: [osg-users] Question about views, contexts and threading

2008-11-17 Thread Robert Osfield
Hi Ferdi, osgViewer::CompositeViewer runs all of the views synchronously - one frame() call dispatches update, event, cull and draw traversals for all the views. So for you case where you want them to run async, this isn't supported. Supporting within CompositeViewer would really complicate the