On Saturday 28 June 2008, Tim Moore wrote:
> I received a private comment about this point too. Mapping cameras to
> different windows, which can be opened on arbitrary screens, will
> absolutely still be supported. I know that multi-GPU setups are
> important for professional users and our demos. The setup you just
> described would be an important test case for my proposed system: 4
> monitors attached to two GPUS. As I understand it you will get the best
> performance with each GPU treated as a large virtual screen, so here
> you want two graphics windows -- one opened on each display (GPU) --
> with two cameras mapped to each window.

The reason is more or less clear:
Imagine one gpu. You can feed that single gpu with exactly one command stream. 
If two applications work on the same gpu, they must be serialized by locks in 
the driver/kernel anyway. If two applications/threads race for that gpu, you 
will observe that the kernel decides at some ramdom points when to 
reschedule. When the other application starts running, the gpu's state must 
be set up for the application in question. That is in effect a graphics 
context switch, which is something of the expensiver things for a gpu.

In contrast to that, if you have one single window for one gpu, osg will 
coordinate when to switch graphics contexts. you will change that context n 
times for n windows without racing for the same gpu from within the same 

Ok, if you have more than one gpu, you have independent command streams into 
the gpu, that can be used without context changes in real parallel. For them 
it is best you feed them in parallel.
So one thread per gpu will be best ...

So far theory, Robert told me that this would be observed with real setups.
Matthias Börner, has told me that they measured nvidia OpenGL performamce for 
a customer and that they found best performance in a slightly different test 
scenario with that multi screen setup.

So, in the end what is best will be somehow driver and may be version 
dependent. That is, the configuration mechanism schould be flexible enough to 
support both variants ...

> Interesting to know. OK, perhaps no matrix syntax.
> ...
Well, there is the osg::Matrix::getFrustum() method. This one returns the 
clipping planes for the cull visitor. Make sure this method does not give an 
error. Or extend the implementation (if this is sensible extensible) of that 
method and feed that to Robert.

> It sounds like the arrangement I described could be easily hooked up to
> your animation.
Hmm, I am not sure if we need some application code in the animation code. I 
believe that we need to distinguish between different render to texture 
cameras. That ones that will end in mfd displays or hud or whatever that is 
pinned into models. And one that are real application windows like what you 
describe - additional fly by view, and so on. And I believe that we should 
keep that separate and not intermix the code required for application level 
stuff with building of 3d models that do not need anything application level 
code to animate the models ...
I think of some kind of separation that will also be good if we would do HLA 
between a viewer and an application computing physical models or controlling 
an additional view hooking into a federate ...

Looking forward to that stuff!



Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
Flightgear-devel mailing list

Reply via email to