Is XAA still supported in recent and future xserver?

[Alex Deucher]

On Mon, Sep 13, 2010 at 7:40 PM, Michael <macallan at netbsd.org> wrote:
> -----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.
>

It's not deliberately broken. It just doesn't fit modern hardware very
well and thus no one actively developing acceleration code uses it.
If someone wants to step up and maintain it, that would be great.

Alex

> 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-----
>