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
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.
-
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
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
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
I'm looking to do the following in OSG, and I wonder if I'm on the right
track (before wasting time needlessly): have two render processes run in
parallel on two different GPUs, have one render a scene to texture and
let this texture be read by the other process and mapped to an object in
a
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
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
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
9 matches
Mail list logo
