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

[Christian König]

Am 27.03.2013 00:30, schrieb Dave Airlie:
> On 27 Mar 2013 08:45, "Dave Airlie" <airlied at gmail.com> wrote:
>>>>> correctly). But Marek is quite right that this only counts for state
>>>>> objects
>>>>> and makes no sense for set_* and draw_* calls (and I'm currently thinking
>>>>> how to avoid that and can't come up with a proper solution). Anyway it's
>>>>> definitely not an urgent problem for radeonsi.
>>>> It will be a problem once we actually start caring about performance
>>>> and, most importantly, the CPU overhead of the driver.
>>>>
>>>>> I still think that writing into the command buffers directly (e.g.
>>>>> without
>>>>> wrapper functions) is a bad idea, cause that lead to mixing driver logic
>>>>> and
>>>> I'm convinced the exact opposite is a bad idea, because it adds
>>>> another layer all commands must go through. A layer which brings no
>>>> advantage. Think about apps which issue 1k-10k draw calls per frame.
>>>> It's obvious that every byte moved around counts and the key to high
>>>> framerate is to do (almost) nothing in the driver. It looks like the
>>>> idea here is to make the driver as slow as possible.
>>>>
>>>>> packet building in r600g. For example just try to figure out how the
>>>>> relocation in NOPs work by reading the source (please keep in mind that
>>>>> one
>>>>> of the primary goals why AMD is supporting this driver is to give a good
>>>>> example code for customers who want to implement that stuff on their own
>>>>> systems).
>>>> I'm shocked. Sacrificing performance in the name of making the code
>>>> nicer for some customers? Seriously? I thought the plan was to make
>>>> the best graphics driver ever.
>>>
>>> Well, maybe I'm repeating myself: Performance is not a priority, it's only
>>> nice to have!
>>>
>>> Sorry to say so, but if we sacrifice a bit of performance for more code
>>> readability than that is perfectly ok with me (Don't understand me wrong I
>>> would really prefer to replace the closed source driver today than tomorrow,
>>> it's unfortunately just not what I'm paid for).
>>>
>>> On the other hand, we are talking about perfectly optimizeable inline
>>> functions and/or macros. All I'm saying is that we should structurize the
>>> code a bit more.
>> Its okay to take steps in the right direction, but if you start taking
>> steps that away
>> from performance in lieu of code readability then please be prepared
>> to deal with
>> objections.

Well agree, when it starts hurting performance so badly that we really 
need to think about it then we are doing something wrong here.

>> The thing is in a lot of cases, code readability is in the eye of the
>> beholder, I'm sure
>> Jerome though r600g was perfectly readable when he wrote it, but a lot
>> of us didn't
>> and spent a lot of time trying to remove the CPU overheads, not least
>> the amount of
>> time Marek spent. The thing is performance is measureable, code
>> readability isn't.
> I also realised there is a bit of irony in using llvm if code
> readability is a prime goal :-P, I'm sure .td is readable to some, but
> it takes a fair bit of learning.

Hui what? Well I've seen quite a number of compiler backends in the last 
15 years or so, and at least I find tablegen one of the best inventions 
in compilers since years (well I'm probably not the best person to ask, 
cause I also find flex easy to use :D). Just compare it to the alternatives.

But back to the topic. Maybe I should explain a bit of the background 
here: Alex and I spend a week last year at a customer explaining to them 
how our hardware and software stack works (plus a couple of mails after 
that meeting to clarify the details), and additional to that we are 
working with out internal resources which build the Windows CE driver 
out of our open source stack.

The really really sad news that I've got out of those activities is that 
when we want to explain how our hardware works (rings, config/context 
registers, PM4.........) it's easier to point them to the xf86-video-ati 
sources than to the r600g sources. For example I always need to answer 
the same question to them: "What are those NOP packets good for?"

Christian.

> Dave.
>