We are using multiple threads, but only a single aspect. We get away with this because we only construct new data in the secondary threads. There are never two threads accessing the same field containers concurrently. I looked at the code that is already in place to reset the GL object ID, and I really can't explain why that wouldn't be working in this case.
-Aron On Tue, Jun 8, 2010 at 12:58 AM, Gerrit Voß <vo...@vossg.org> wrote: > > Hi, > > On Thu, 2010-06-03 at 09:44 -0500, Carsten Neumann wrote: >> Hello Gerrit, >> >> Gerrit Voß wrote: >> > On Wed, 2010-06-02 at 12:17 -0500, Carsten Neumann wrote: >> >> Aron Bierbaum wrote: >> >>> We have been running into what appears to be a corner case in the >> >>> ShaderProgram. As most of you probably know each OpenSG object that >> >>> needs to track a GL object ID registers it's OpenGL creation and >> >>> destruction functors through Window::registerGLObject(). This >> >>> registration returns a unique OpenSG ID for each registered object. >> >>> This unique OSG is then used in each objects handleGL() and >> >>> handleDestroy() methods to get the context specific OpenGL object ID >> >>> from each window. (ex: win->getGLObjectId(getGLId())) The normal >> >>> operation is that when an object is created for a window you call the >> >>> OpenGL function and set the OpenGL object ID in the ID map. Then in >> >>> handleDestroyGL() you clear this ID mapping by setting it back to >> >>> zero. >> > >> > not quite, the reset should have happened from where the destroyed >> > functor is called but it seems in the wrong place. I would prefer >> > to have it there instead of pushing the responsibility to every >> > class that uses the gl id infrastructure. >> >> hm, ok, that would prevent this kind of problem in the future. >> >> >>> Although I think that we should fix these locations so that the IDs >> >>> are rest correctly, can the ShaderProgram code be changed to not have >> >>> such a fragile requirement for checking the OpenGL ID against zero. I >> >>> have attached a patch for an older revision of OpenSG 2.0 that relaxes >> >>> this requirement and we have been using for a few weeks without any >> >>> issues. >> >> I've also committed a patch similar to the one you sent, but made >> >> surrounded the test with #ifdef OSG_DEBUG. >> >> If indeed ShaderProgram can test the mode instead of the gl id, this can >> >> be removed again. >> >> Thanks again for the bug analysis and patch! >> > >> > to understand it better, how many windows are in your environment ? >> > >> > In general something looks not quite right in the whole gl object >> > handling inside the window so I will have a further look. >> >> quite possible, it is a bit complicated ;) However, I think the only >> problem is that the _id array entry are not set to zero when the >> corresponding _glObject array entry is set to NULL in doFrameExit(). >> Window::registerGLOject() only looks into _glObject to determine what >> ids are available. > > hmm, there is/was a this->setGLObjectId(i+j, 0); in there but IMHO to > late as the _ids array is a window local array, so with multiple windows > only the last window should have the ids set to 0. But the example uses > only 1 window so there seem to be another way around it. I'm still > hunting for this, one suspect is the early out in destroyGLObject in > case of parallel drawers. > > I'm still building a test setup ;) > > >> hm, thinking about this, I'm not even sure we really need to set unused >> ids to zero (except to ease debugging perhaps). ShaderProgram should >> probably just not use id 0 to mean the same as mode == initialize? > > from looking at it, it was probably just laziness on my side as the > initial if already contained initialize I did not bother to check again. > I don't see a reason why we can change to check the mode. I'll change it > and observe it for a while. > > kind regards > gerrit > > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Opensg-users mailing list > Opensg-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/opensg-users > ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
