Re: [Opensg-core] ShaderExecutableVarChunk and ShaderCache

[Gerrit V. <vo...@vo...>]

Hi,

On Sat, 2010-01-16 at 10:10 -0600, Carsten Neumann wrote: 
> 	Hello Gerrit,
> 
> Gerrit Voß wrote:
> > On Tue, 2010-01-12 at 19:52 -0600, Carsten Neumann wrote:
> > 
> >> - 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.
> 
> ok, thanks a lot for tracking this down. I'll merge the change into my 
> branch and try it.
> 
> > Somehow the geometry is not correct, not sure if it should be ?
> 
> try hitting 'l' (lower case 'L') to have an animation play, without that 
> the skeleton is in a more or less undefined pose. With that the only 
> geometry problem should be at the helmet - there are some 
> flipped/missing triangles.

ah ok, with 'l' it looks better ;)

> >> 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.
> 
> I guess it would only provide a performance advantage when used with 
> named uniform blocks in 3.2, but it is sometimes quite convenient to use 
> the same set of uniforms with a bunch of shaders.

yes, the whole new handling of passing uniforms/data to shaders is
something on my list to look at.

> > 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.
> 
> yeah, I had not looked into those since they seemed to be related to 
> SEVarChunks in the cache not being cleaned up correctly, at least that 
> was were I stopped looking further ;)

it was related but not the same. There was a bug in the tree
destruction. The last one left is a counting issue which just
needs a little time/work to resolve.

kind regards
  gerrit