On 27 Mar 2013 08:45, "Dave Airlie" <airl...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
