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

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

Dave.