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

[Jerome Glisse]

On Tue, Mar 26, 2013 at 12:40 PM, Marek Olšák <maraeo at gmail.com> wrote:
> 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.

I agree here, i don't think uncached bo for command stream on new hw
would bring huge perf increase, probably will just be noise.

>>
>> 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

I think Christian is thinking about new hw > cayman where we can skip
register checking because of vm and hardware register checking (the hw
CP checks that register in the user IB is not one of the privilege
register and block write and throw irq if so). On this kind of hw you
can have cmd stream in bo and don't do the map/unmap.

Cheers,
Jerome