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/
