From: Gerrit V. <vo...@vo...> - 2010-01-16 10:51:47
|
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 |