[PATCH] Remove XAA

[Connor Behan]

On 22/09/13 09:53 AM, Alex Deucher wrote:
> On Sun, Sep 22, 2013 at 12:27 PM, Matthieu Herrb
> <matthieu.herrb at laas.fr> wrote:
>> On Sun, Sep 22, 2013 at 08:59:42AM -0700, Alan Coopersmith wrote:
>>> On 09/21/13 07:49 AM, devzero at web.de wrote:
>>>>> Deliberately breaking drivers without giving people a chance to fix them
>>>>> isn't fair.  Because of the current development model of Xorg people may
>>>>> not notice that stuff is broken for more than six months.
>>>> Yes, this sucks big.
>>> You're replying to a year and a half old e-mail.   People have had plenty of
>>> chance to fix the drivers they still use now, and most of the ones people use
>>> have been fixed.
>> Sorry, but this is only partially true.
>>
>> In OpenBSD we're still having a number of issues with drivers that are
>> used and have not been fully fixed. My limited time and knowledge of
>> EXA have not allowed to make enough progress to tell that old drivers
>> are performing as good now with EXA than they were performing with
>> XAA.
>>
>> Affected drivers are at least
>>
>> - xf86-video-cirrus (no EXA code at all in xf86-video-cirrus)
>> - xf86-video-mach64 (render acceleration broken in EXA)
>> - xf86-video-mga (render acceleration broken in EXA, need to be
>>   disabled to have a working server)
>> - xf86-video-nv shadowfb broken, no EXA acceleration for older
>>    chipsets. have to run it completely un-acceleratied.
>> - xf86-video-sis (mostly broken for quite a bit of time)
>> - xf86-video-sunffb only shadowfb "acceleration" after dropping XAA
> In most cases, shadowfb is probably as fast or faster than XAA.  XAA
> is effectively shadowfb since offscreen pixmaps were broken and
> disabled years ago.
>
> Alex
Render acceleration is beyond anything XAA did, so an EXA driver where
this fails is not any worse. If performance drops significantly with XAA
gone, it might be because DRI was disabled as a side effect. With some
old drivers, if XAA can't be found, they will just abandon the task of
setting up a memory map for acceleration.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20130922/5c5b8736/attachment.pgp>