pushed preparation patch for KMS
Dave Airlie
airlied at gmail.com
Thu Jul 2 03:30:46 PDT 2009
2009/7/2 Michel Dänzer <michel at daenzer.net>:
> 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.
>
yeah thats what I was wondering, like maybe the extra if statements in the accel
codepaths make a big difference or a bigger diff on powerpc. like
really the amount of
3D state emitted shouldn't be that much bigger, unless I'm flushing
more often somewhere
or reemitting the 3D base state too often.
Dave.
>> 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
>
More information about the xorg-driver-ati
mailing list