Hi, On Tue, 2010-01-12 at 19:52 -0600, Carsten Neumann wrote: > Hi Gerrit, > > I'm trying to find a problem with the hardware vertex skinning stuff I'm > working on. I have a HardwareSkinningAlgorithm container that holds a > program and a variables chunk, that are created when rendering for the > first time. > Switching to hardware mode for the second time (which creates a new algo > object) the gl ids returned by glCreateProgram() are the same ones than > the first time around, which I think leads the shader cache to return > cached ShaderExeVarChunk objects instead of creating new ones. > I could use some hints on how the ShaderProgramVariablesChunk (and its > backend rep ShaderExeVarChunk) and the ShaderCache interact: > > - the attached patch fixes a small oversight where we activate a program > without updating the draw env. This can result in the SEVarChunk to look > up uniforms in the wrong program.
hmm, in general it shouldn't be a problem, only if one calls validateGLObject manually. But in this case there is always a way to get it wrong. Anyway I applied your patch to the trunk. > - looking at the bugle trace of the program when it switches to hardware > mode for the second time I see the following sequence: > > glCreateProgram() = 6 > glAttachShader(6, 2); > glAttachShader(6, 5); > glAttachShader(6, 4); > glLinkProgram(6); > // error checks > glUseProgram(6); > glUniformMatrix(...); > > note the missing getUniformLocation() calls, even though the program was > relinked and locations became invalid. > > - part of the problem seems to be that the cache does not add a > destroyed functor to SPVarChunk, so when it dies the entries in the > cache are not evicted. yes, there was a typo, it should have been ifndef instead of ifdef. I fixed that one. Now I get the same gun everytime I switch through, and I checked as the var chunks is properly destroyed glGetUniform is now called correctly because a new VarChunk is found every time. Somehow the geometry is not correct, not sure if it should be ? > Defining OSG_SHC_REF_CLEANUP helps a bit, but > produces many warnings from Window::validateGLObject: > WARNING: Window::validateGLObject: obj with id XXX is NULL! or > WARNING: Window::validateGLObject: id is 0! > > Do you have any info on the status of the code, e.g. what would be the > preferred values for the three defines at the top of OSGShaderCache.h > (OSG_SHC_USE_REF, OSG_SHC_REF_CLEANUP, OSG_ASSERT_TREE)? These are really only debug, test and validation defines. They should all be off. > I'm not sure I understand how one SEVarChunk can reliably be used with > more than one SEChunk, since the uniform locations seem to be stored in > the former, but can be different for different SEChunks? > It never could, that followed 1.x which stored the chunk to which the variables reference explicitly. I have a look how it could be extended. I have to check what happens if the shader it recompiled anyway. Something else I looked into, the exit crashes of your test program. One I could fix, one is still left and needs a little more time. But this one could be avoided by destroying the mgr object last instead of second. kind regards gerrit -- Gerrit Voß 盖瑞客 --------------------------------------------------- Centre for Advanced Media Technology (CAMTech) 南洋理工大学, Nanyang Technological University, (NTU) 新加坡, Singapore -------------------------------------------------- CAMTech is a joint centre of Fraunhofer-IGD & NTU -------------------------------------------------- If we communicate everything we ever think, speech just becomes static. And all of us become bores. J. Clarkson ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
