Is XAA still supported in recent and future xserver?

Michael macallan at netbsd.org
Mon Sep 13 16:40:17 PDT 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Sep 13, 2010, at 7:28 PM, Alex Deucher wrote:

> On Mon, Sep 13, 2010 at 6:55 PM, Michael <macallan at netbsd.org> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello,
>>
>> On Sep 13, 2010, at 6:41 PM, Matt Dew wrote:
>>
>>> <snip>
>>>>
>>>> I understand the urge to slim the server down, but deprecating XAA
>>>> isn't the way to do this.
>>>>
>>>> In order to deprecate something, there needs to be a replacement.  
>>>> As
>>>> others in this thread have stated, there is hardware for which  
>>>> EXA is
>>>> slower than XAA or does not work all together. So EXA is not a 1:1
>>>> replacement for XAA.
>>>>
>>>> I can't see why being able to remove XAA (which would be the  
>>>> intended
>>>> goal of deprecating it) would help anything anyway. The xserver can
>>>> already be easily built without XAA.
>>>>
>>>
>>> Agreed that a replacement is needed before removing anything.  I  
>>> think
>>> we're all in agreement there.
>>>
>>> I'm not necessarily arguing for dumping XAA (I don't know enough for
>>> that, hence my questions.).  I'm just from the school of thought  
>>> that
>>> if two things are redundant, get rid of one of them. Less  
>>> maintenance,
>>> confusion, duplicated effort, ...   If EXA could be made to be
>>> performant on that hardware, I think getting rid of XAA would be a
>>> good idea, for the pre-mentioned reasons.  If it can't, then end of
>>> discussion for me.
>>
>> This would be a hell of a lot easier if EXA had an optional XAA- 
>> like VRAM
>> allocator which doesn't insist on variable strides. With that alone
>> converting most drivers would be almost trivial.
>>
>
> Well, part of the reason for EXA was to target a certain base level of
> hardware to better match the requirements of modern desktops.  Why add
> support for old more limited hardware to EXA when we have XAA already?

That would be a valid argument if XAA wasn't deliberately broken and  
left to bitrot.

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBTI62YcpnzkX8Yg2nAQJ4mggAryikfbwZHL0BXj/r7ETzQFTShwZHciRb
18itPesXTlwYZoCc0piKq4s6Z8250E2hBda/8uKwRz2QMU0SRS1I9cJYABdjm3S4
Rtlc8W//xjf3YkM3JMmkInK7f9DFR/c+XKXrk9MrxPIFUDAfqMH6EViWTCApIjgk
O6DMuJ7yQuagje6ZS3syTVirSshr825AIH4lgvxJtg67iGI+SxsTfBbOFWzAPR72
wl/y4V+98krY6Uyz5kEiN6p3z6AaVOYi4XuUsin3T/AKQR48V3gklNteTpIMvM/2
DTXxDfPFcbUMGqjhw8ODmWY0ISG9fyVS+i39qm8LNDsmGzBIev5wcg==
=orQ6
-----END PGP SIGNATURE-----


More information about the xorg-devel mailing list