Hi Robert, It makes a lot of sense.
osglauncher is not playing by the rules for sure. Setting the data variance for its text objects to DYNAMIC (from UNSPECIFIED) solves the problem. Sorry if I missed that discussion, but shouldn't UNSPECIFIED behave like DYNAMIC with regards to threads blocking updates, since it means we don't really know if the content will change ? André -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: February-17-07 12:14 PM To: osg users Subject: Re: [osg-users] Multi-threading issues on Windows - a little bit more information Hi André, I'm still digest your email (threading is a complex issue), but I'll dive in provide some guidance on osgText - updating the texture field and rendering at the same time is not permitted and mutexing it while doable is really masking a higher level issue in the affected apps. What should be happening is that text fields that are updated during the frame should have their DataVariance set to DYNAMIC, this will tell the draw traversals to block the next frame till all the DYNAMIC text drawables+state are drawn. This DataVariance requirement applies to all Geometry and StateSet/StateAttributes setup/usage, so isn't a Text specific issue, a relates to the lightweight way that I've enabled parallel threading of update & cull with draw - only the static parts of the scene graphs leaves can be run in parallel, all dynamic parts must be dispatch in draw before the next frame commenses. If the Drawable and StateSet's don't declare that they are DYNAMIC then the frame block won't happen and update will run in parallel with draw and bug crashes will happen. Play by the rules at use DYNAMIC/STATIC correctly then things should run smoothly. The next question has to be which examples aren't yet playing by this rule. Robert. On 2/17/07, André Garneau <[EMAIL PROTECTED]> wrote: > Hi Robert, > > Here is an update on previous testing results I reported earlier this week. > Since then I concentrated mainly on characterizing crashes occurring in > multi-threading modes. > > * I have traced the stack for all crashes and they are all from the same > location (in some NVIDIA code). OpenGL errors are reported > (GL_INVALID_OPERATION). That error condition is triggered by the call to > glDrawBuffer() within RenderStage::drawInner. > > * If I remove the 6150 screen from the system, all tests but 2 will pass > (osgimpostor & osgprerendercubemap). The two tests that are still crashing > have the same stack trace as previously. Note that even though the other > tests pass, they still all generate the GL_INVALID_OPERATION error. > > * If I start osgdistortion from the command line, it will work. If I start > it from osglauncher, it will crash (as when the 6150 is present). > > At this point what I'm trying to determine is if we're hitting a bug in the > NVIDIA driver and if so, if there is something done that exacerbates the > condition. There seems to be a correlation between the OpenGL error and the > test (possibly) crashing after. Removing the 6150 from the system is only > hiding the condition in my opinion, since it can still happen (when launched > through osglauncher for instance). > > On another subject, while doing these tests I came across a multi-thread > issue with the Text class. In DrawThreadPerContext and > CullDrawPerCameraDrawThreadPerContext modes, allowing updates to text > instances while the draw threads are rendering causes race conditions since > there is one structure in Text that is used at draw time and can be cleared > at update time. The field in question is Text::_textureGlyphQuadMap. > > To replicate the issue, simply start osglauncher in a multi-screen setup and > move the mouse quickly across all pictures; in a matter of seconds you > should get an access violation. The two conflicting threads are one graphics > thread and the main thread doing its event traversal and handling the > intersection event with one picture (this will cause the setText method to > be invoked which will clear the _textureGlyphQuadMap while it is being > iterated upon by the draw threads). > > I have prepared a fix for this but it involves mutexing all set methods and > the draw method for the Text class (not something very pretty). I will > include it in a submission later today. > > Finally, I have also made the fix for the aspect ratio issue occurring when > one or more screens in the system have different aspect ratios. I will > include it in the same submission. > > One last note: It would be very interesting (and informative) to see if > other Windows users on this list also see the osgdistortion test crashing > when started from osglauncher (in dual-screen mode in multi-threaded modes) > or OpenGL errors being reported (through the following message: Warning: > detected OpenGL error 'invalid operation' after RenderBin::draw) for the > same test. > > André > > ============================================================================ > ============================================================================ > ============= > > I did some testing yesterday evening on Windows and here are my results: > > { Platform: Athlon X2 4200+, 2GB RAM, Windows XP latest patches, NVIDIA > GF7900GT & low-end NVIDIA 6150, 3 screens } > > Running runexamples.bat for each threading model > > Single-Threaded > =============== > > osgimpostor (extremely slow) > osgplanets (corrupted image on center & right screens - left screen OK) - > will double check my setup > > all other examples perform well > > CullDrawThreadPerContext > ======================== > > osgprecipitations (slow) > > crashes for: > > osgdistortion > osgdepthshadow > osgimpostor > osgprerender > osgprerendercubemap > osgshadowtexture > osgsimulation > > DrawThreadPerContext > ==================== > > osgprecipitations (slow) > > update processing seems to be out-of-sync > (very fast movements when mouse is used) > > No smoke/fire effects visible for: > (probably due to issue above) > > osgblendequation > osgmultitexture > > crashes for: > > osgdistortion > osgdepthshadow > osgimpostor > osgprerender > osgprerendercubemap > osgshadowtexture > osgsimulation > osgpick > osgspheresegment > > CullThreadPerCameraDrawThreadPerContext > ======================================= > > osgprecipitations (slow) > > update processing normal but performance generally sluggish on all examples > > crashes for: > > osgdistortion > osgdepthshadow > osgimpostor > osgprerender > osgprerendercubemap > osgshadowtexture > osgsimulation > osgpick > osgfxbrowser > > > I will try to look at some of these issues this evening. > > André > > > _______________________________________________ > osg-users mailing list > [email protected] > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ > _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
