pushed preparation patch for KMS

[Michel Dänzer]

On Thu, 2009-07-02 at 12:07 +1000, Dave Airlie wrote:
> 2009/7/1 Michel Dänzer <michel at daenzer.net>:
> > On Tue, 2009-06-30 at 16:38 +1000, Dave Airlie wrote:
> >>
> >> I pushed a patch that prepares the driver accel code for the upcoming
> >> KMS/DRI2 support.
> >>
> >> This mainly sorts out the accel interfaces and tries to hide the mess
> >> that supporting 25 different methods of
> >> accel does.
> >>
> >> Let me know if it breaks anything major, or if there is any insanity
> >> you'd rather see not live much longer.
> >>
> >> I've mainly tried to avoid having an #ifdef XF86DRM_MODE mass.
> >
> > Looking good basically. I haven't noticed any correctness regressions,
> > but x11perf -aa10text seems to have dropped from almost 600k/s to just
> > above 500k/s. Haven't had time to really look into why that is, but one
> > thing I noticed before on kms-support is that we seem to be
> > (re-)emitting some 2D state we never use with EXA, e.g. background
> > colours. It might be worth even trying not to re-emit state that hasn't
> > changed.
> 
> what hw was that on? my r500 has no difference before this commit and
> after it with aa10text.

RV350 in my PowerBook.

> I'll try and get to some older hw later. We could probably two 2D the same
> as 3D, setup the engine and then do emission, but I'm really trying to
> avoid adding a full state caching + change feature to the DDX. From what I can
> see for 2D we probably now emit 4 qwords more than previously.

Note that I'm not sure the performance regression is related to the 2D
state issue, x11perf -aa10text should be mostly Composite operations in
the hot path.

> But if I can reproduce it on my older hw I'll try and fix it.

Great, thanks. I'll also try and see if oprofile gives any hints, though
it probably won't if it's indeed related to the GPU command stream.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer