[Mesa-dev] Path to optimize (moving from create/bind/delete paradgim to set only ?)
Zack Rusin
zackr at vmware.com
Tue Nov 16 18:15:22 PST 2010
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
More information about the mesa-dev
mailing list