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

[Jerome Glisse]

On Tue, Nov 16, 2010 at 9:43 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
> 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
>

Before i forget, the fact that cso shows up that high on cpu is likely
the outcome of cso not living long enough, like being deleted right
after being use and those we endup with nothing the cso cache and we
keep rebuilding over and over. Then come the problem of how to
determine what is the best live time of a cso, for DX it's easy but
for GL best we can do is do wild guess, some app might use some GL
state once every minute and those GL state might consumme memory for
no good reason btw those 2 usage ... Anyway just wanted to point out
the obvious of my results.

Cheers,
Jerome