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

[Jerome Glisse]

On Tue, Nov 16, 2010 at 9:15 PM, Zack Rusin <zackr at vmware.com> wrote:
> 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
>

Agree, i am just trying to get someone to look into it before i do ;)
I am more focusing on fixing the short coming of the r600 pipe driver
first. But i will get back to this cso things, and anyone is more than
welcome to take a look at it (openarena or nexuiz are showing lot of
cso activities with r600g or noop driver). I never meant to say jump
on this new wagon because it looks more promising, i am just trying to
stress out that no one should take the promise of cso caching for
granted because as far as i can tell it's not holding any of it as of
today.

Also noop driver is only marginaly faster than fglrx and you will see
that cso account for around 5%-10% of cpu time of 25% for the whole
mesa activities, also noop is special as the copy/swap buffer of the
current ddx is call, so it also slow done thing (thought i use small
resolution to minimize this).

Note that the shader constant upload part of my mail is disjoint from
cso and for that part i am convinced and i did give number showing
that it's unappropriate to use the pipe buffer allocation path but
that we should rather directly provide the program constant buffer ptr
to pipe driver and let the pipe driver pickup the best solution for
its hw.

Cheers,
Jerome