Tim, 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.
Yep, 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 application. 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! Greetings Mathias ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Flightgear-devel mailing list Flightgearfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/flightgear-devel