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
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
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
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
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
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
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
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.
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
9 matches
Mail list logo