[Mesa-dev] [PATCH] radeonsi: add cs tracing v2

[Marek Olšák]

On Tue, Mar 26, 2013 at 3:59 PM, Christian König
<deathsimple at vodafone.de> wrote:
> Am 26.03.2013 15:34, schrieb Marek Olšák:
>
>> Speaking of si_pm4_state, I think it's a horrible mechanism for
>> anything other than constant state objects (create/bind/delete
>> functions). For everything else (set/draw functions), you want to emit
>> directly into the command stream. It's not so different from the bad
>> state management which r600g used to have (which is now gone). If you
>> have to call malloc or calloc in a set_* or draw_* function, you're
>> doing it wrong. Are there plans to change it to something more
>> efficient (e.g. how r300g and r600g emit non-CSO states right now), or
>> will it be like this forever?
>
>
> Actually I hoped that r600g sooner or later moves into the same direction
> some more. The fact that we currently need to malloc every buffer indeed
> sucks badly, but that is still better than mixing packet generation with
> driver logic.

I don't understand the last sentence. What mixing? The set_* and
draw_* commands are supposed to be executed immediately, therefore
it's reasonable and preferable to write to the CS directly. Having any
intermediate storage for commands is a waste of time and space.

>
> Also I don't think that emitting directly into the command stream is such a
> good idea, we sooner or later want that buffer to be a buffer allocated in
> GART memory. And under this condition it is better to build up the commands
> in a (heavily cached) system memory and then memcpy then to the destination
> buffer.

AFAIK, GART memory is cached on non-AGP systems, but even uncached
access shouldn't be a big issue, because the access pattern is
sequential and write-only. BTW, I have talked about emitting commands
into a buffer object with Dave and he thinks it's a bad idea due to
the map and unmap overhead. Also, we have to disallow writing to
certain unsafe registers anyway.

Marek