[Mesa-dev] Path to optimize (moving from create/bind/delete paradgim to set only ?)

[Zack Rusin]

On Tuesday 16 November 2010 20:26:03 Jerome Glisse wrote: 
> Anyway my point is that here the gl state tracker is not to blame,
> it's only the fact that real application lead to a lot of cso
> activities and i am not convinced that what we might possibly win with
> cso is more important than what we loose when considering API such as
> GL.

And I disagree so we're at a stalemate and we'll never reach a conclusion. 
What I'm saying is that this isn't how we can ever reach a technical decision. 
There needs to be a compelling evidence for doing something that is obviously 
unintuitive. 

And this is unintuitive because there's a limited number of blend, depth, 
alpha, stencil or rasterizer states any application needs and quite frankly 
it's very small so caching it makes a hell lot of sense. I think it's more 
likely that we stuffed some value into one of  the cso's that should have a 
separate set method or that there's a bug somewhere. 

Anyway what I think is of no consequence, what matters is what you can prove. 
It'd be trivial to see:
1) what exactly changes that caching fails,
2) would a better hashing function and a better hash fix it,
3) whether it's a special case and requires special handling or whether it's 
globally the concept of csos,
4) whether the state tracker can be improved to handle it,
5) how much better things are when we don't cache (trivial to try by just 
changing the cso_set functions to just set stuff instead of using the 
create/bind semantics)

If you can prove your hypothesis, awesome! great find, lets change it. 
Otherwise I think the bikeshed should be blue because I'm a boy and I like 
blue.

z