[Mesa-dev] [PATCH] r600g: order atom emission v2

[Marek Olšák]

On Thu, Sep 6, 2012 at 8:34 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
> On Thu, Sep 6, 2012 at 2:29 PM, Marek Olšák <maraeo at gmail.com> wrote:
>> This looks good to me. It's funny to see the r300g architecture being
>> re-implemented in r600g. :)
>>
>> There's one optimization that r300g has that this patch doesn't. r300g
>> keeps the index of the first and the last dirty atom and the loops
>> over the list of atoms look like this:
>> for (i = first_dirty; i <= last_dirty; i++)
>>
>> And after emission:
>> first_dirty = some large number;
>> last_dirty= 0;
>>
>> The atoms should be ordered according to how frequently they are
>> updated (except when the ordering is required by the hw). But most
>> importantly, if there are no state changes, the loops are trivially
>> skipped.
>>
>> Marek
>
> Don't think this optimization is worth it, there won't be much more
> than 32 atom in the end and it definitely can't be ordered from most
> frequent to less frequent as some of the stuff need to be at the last
> being emitted and they are frequent one (primitive type for instance).

I didn't say all atoms *must* be sorted. I meant that some (most?)
atoms can be sorted, i.e. you can have some atoms at fixed positions
(like the primitype type or the seamless cubemap state), but you have
always at least *some* freedom where you put the rest. The ordering I
had in mind was actually from the least frequent to the most frequent,
in other words, from the framebuffer (least frequent) to shaders to
textures to constant buffers to vertex buffers (most frequent).

Of course, the code should document which atoms must have fixed
positions along with an explanation. The comment that all atom
positions must not be changed isn't enough, because it's not true.

Marek