Yes, this occurs in all of v1.2, v2.8.2, v2.9.6, and SVN head as of yesterday.
setActiveTextureUnit does indeed call glActiveTexture only when the requested unit is different to the previous call to setActiveTextureUnit. So in this respect, it's state caching is working. However, State::apply runs through a loop calling setActiveTextureUnit for each texture unit that it has ever heard about. This loop nicely cycles through, passing setActiveTextureUnit a fresh unit number on each iteration, changing the GL texture unit every single time, regardless of whether applyModeMap/applyAttributeMap actually do anything. On 12/22/2009 10:32:24 PM, Robert Osfield wrote: > Hi Lilith, > > It sounds like the lazy state updating in osg::State isn't functioning > in this case, either a bug or an oversight. > > Have you determined that this issue still occurs in svn/trunk? > > Robert. > > On Tue, Dec 22, 2009 at 12:54 AM, Lilith Bryant <dark...@gmail.com> wrote: > > Hi Robert, and the list, > > > > I have found a performance issue with multitexturing. > > > > Once a state has had texture attributes applied for units >=1 > > then excessive calls to glActiveTexture are made forever more. > > > > In particular, State::apply() and applyTextureMode() and > > applyTextureAttribute() unconditionally change the active texture unit > (with > > setActiveTextureUnit), even if they cause no actual state change. > > > > The GL trace ends up littered with glActiveTexture calls: > > > > glActiveTexture(GL_TEXTURE0) > > glBindTexture(GL_TEXTURE_2D,2) > > glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_S,GL_CLAMP_TO_BORDER) > > glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_T,GL_CLAMP_TO_BORDER) > > glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_LINEAR) > > glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_LINEAR) > > glTexParameterf(GL_TEXTURE_2D,GL_TEXTURE_MAX_ANISOTROPY_EXT,1.000000) > > glTexParameterfv(GL_TEXTURE_2D,GL_TEXTURE_BORDER_COLOR,0x4a8f8ac) > > glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_COMPARE_MODE,GL_ZERO) > > glActiveTexture(GL_TEXTURE1) > > glActiveTexture(GL_TEXTURE2) > > glActiveTexture(GL_TEXTURE3) > > glCallList(4) > > > > All those glActiveTexture calls happen on every single call to > State::apply() > > > > Note this is even after all the multitextured things are removed from the > > scene. > > > > It occur because the textureModeMapList and textureAttributeMapList are > > expanded, but never contracted. This itself isn't a problem, but the > > unconditional changing of the active texture unit in State::apply() etc, > JUST > > IN CASE, is the problem. > > > > Back in v1.2 I implemented a fix for this, that I never got around to > > submitting. Essentially it moves the call to setActiveTextureUnit from > > State::apply etc down into the State::applyMode/applyAttribute/ > > applyGlobalDefault functions. This allows those functions to decide at > the > > very last moment if the active texture unit really does need changing. > > > > This requires that applyMode/applyAttribute etc take an new optional > TexUnit > > parameter (with -1 meaning "DONT CARE WHICH", which is the value used for > > normal attributes/modes ) . The alternative to a parameter is a > member > > variable in State, "requiredStateChangeTexUnit" or similar. > > > > This is clearly going to be quite an invasive patch to otherwise very old > > code, so before I port my patch to the SVN head and submit it, I thought > I'd > > run it past you to see if: > > > > a) You'd be interested in receiving such a submission, and > > b) If you had a preference as to using a parameter vs member variable for > the > > required tex unit. > > > > I have attached my changed v1.2 files for your reference. > > > > Regards, > > Lilith > > > > > > > > _______________________________________________ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
