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