Hi Robert, Wojciech my initial guess was that the lengthy draw dispatch of the master view and failing cull & draw parallelism was the result of the same problem.
However, they actually seem to be different problems and I'll focus first on the draw dispatch. The master camera draws only a screen aligned quad and nothing else (scene with shadows is rendered by the slave camera). Also no dynamic geometry. But, I indeed have a read buffer operation: a glGetTexImage call in the postdraw callback of the master camera. This call takes ~12 ms. I read back a small texture that is rendered by a camera in the current frame. The camera uses FRAME_BUFFER_OBJECT as render target implementation. It looks like using glReadPixels to read directly from the FBO is the advised method for getting data back to the system memory. How do I get the FBO that the camera is rendering to? Or, is there a better method to get the texture data back to the sysmem? cheers, tugkan > Hi Tugkan, > > Robert mentioned lengthy read operation. It may be related to read > buffer operation thats used to compute shadow volume in > LightSpacePerpspectiveShadowMapDB. If your slave view uses > osgShadow::LightSpacePerpspectiveShadowMapDB then you may check if > osgShadow::LightSpacePerpspectiveShadowMapCB (cull bounds flavour) has > the same problem. > > I am aware of LightSpacePerpspectiveShadowMapDB glReadBuffer limitation > but I could not find quick and easy to implement workaround that would > do this without scanning the image by CPU. I allocate small 64x64 > texture and render the scene there, then read it into CPU memory and use > CPU to scan pixels to optimzie shadow volume from depths and pixel > locations strored in this prerender image. > > Wojtek > > ----- Original Message ----- From: "Robert Osfield" > <[email protected]> > To: "OpenSceneGraph Users" <[email protected]> > Sent: Wednesday, January 13, 2010 1:04 PM > Subject: Re: [osg-users] RTT slave views and multi-threading > > > Hi Tugkan, > > The osgdistortion example works a bit like what you are describing, > could you try this to see what performance it's getting. > > As for general notes about threading, if you are working on the same > graphics context as you are then all the draw dispatch and the draw > GPU can only be done by a single graphics thread so there is little > opportunity to make it more parallel without using another graphics > card/graphics context and interleaving of frames. > > As for why the second camera is very expensive on draw dispatch, this > suggest to me that it's blocking either due to the OpenGL fifo being > full or that it contains a GL read back operation of some kind. > > Robert. > > On Wed, Jan 13, 2010 at 11:34 AM, Tugkan Calapoglu <[email protected]> > wrote: >> Hi All, >> >> I am using a slave view for rendering the scene to a texture. Initially >> I tried with a camera node, however, this did not work well due to a >> problem in LiSPSM shadows and I was suggested to use RTT slave views. >> >> My setup is as follows: There is a single main view and I attach a slave >> view to it. This slave view is attached with addSlave( slave , false ); >> so that it does *not* automatically use the master scene. >> >> I attach a texture to the slave view and make my scene child of this >> view. I attach a screen aligned quad to the main view. This quad >> visualizes the RTT texture from the slave view. >> >> Now I have a threading problem which can be seen on the snapshot I >> attached. There are two issues: >> 1- The main view (cam1) has a very large draw time even though it only >> renders the screen aligned quad. I double checked to see whether it also >> renders the actual scene but this is not the case. >> >> 2- Slave view does not run cull and draw in parallel. Cull and draw do >> run in parallel if they are not rendered with the slave view. Moreover, >> if I change the render order of the slave camera from PRE_RENDER to >> POST_RENDER it is ok. >> >> I could simply use POST_RENDER but I am afraid it introduces an extra >> one frame latency. If I render the screen aligned quad first and the >> scene later than what I see on the quad is the texture from previous >> frame (right?). >> >> Any ideas? >> >> cheers, >> tugkan >> >> >> >> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Tugkan Calapoglu ------------------------------------- VIRES Simulationstechnologie GmbH Oberaustrasse 34 83026 Rosenheim Germany phone +49.8031.463641 fax +49.8031.463645 email [email protected] internet www.vires.com ------------------------------------- Sitz der Gesellschaft: Rosenheim Handelsregister Traunstein HRB 10410 Geschaeftsfuehrer: Marius Dupuis Wunibald Karl ------------------------------------- _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
