XAA In X.Org Has Finally Met Its Executioner

[daniels]

In other words, any last shreds of acceleration are being removed for any cards in that list. Way to make even more hardware unusable.

In practical terms, you're not getting acceleration anyway. XaaNoOffscreenPixmaps has been the default since 2008, which means that XAA will only accelerate operations where the only drawable referenced is the screen pixmap. For GTK and Qt, this means nothing ever, since they do all their rendering to an offscreen pixmap first, and then copy that to the screen pixmap. If you're running in a composited environment -- it's all offscreen. So, about the only effect this really has is making xtank and Motif apps in a non-composited environment slower.

[gilboa]

Gaah.
Hopefully someone will notice that besides QXL (that's still being activally developed) cirrus is the default virtualized graphics card in qemu / qemu-kvm.
I'd hate to move all my non-QXL VM's to vesa because of this...

- Gilboa

[airlied]

Gaah.
Hopefully someone will notice that besides QXL (that's still being activally developed) cirrus is the default virtualized graphics card in qemu / qemu-kvm.
I'd hate to move all my non-QXL VM's to vesa because of this...

- Gilboa

I hope someone will learn how to read.

Dave.

[gilboa]

I assume that I misread something.
Feel free to explain what I missed (as opposed to mocking my failing intelligence).

- Gilboa

[Ex-Cyber]

I assume that I misread something.
Feel free to explain what I missed (as opposed to mocking my failing intelligence).

What you missed is that the cirrus driver is not actually being dropped, it will just be temporarily broken in git by the removal of XAA, which wouldn't have accelerated much anyway on any system released in the past ~4 years.

[curaga]

In practical terms, you're not getting acceleration anyway. XaaNoOffscreenPixmaps has been the default since 2008, which means that XAA will only accelerate operations where the only drawable referenced is the screen pixmap. For GTK and Qt, this means nothing ever, since they do all their rendering to an offscreen pixmap first, and then copy that to the screen pixmap. If you're running in a composited environment -- it's all offscreen. So, about the only effect this really has is making xtank and Motif apps in a non-composited environment slower.

No such system will run a compositing environment. We are talking mostly laptops with integrated neomagic, trident, whatever.

Operations as basic as moving a window will become slow, no? Oh, and the loved behavior of MS Windows too will appear, where moving a window will peak one core.

[Ex-Cyber]

No such system will run a compositing environment. We are talking mostly laptops with integrated neomagic, trident, whatever.

Operations as basic as moving a window will become slow, no? Oh, and the loved behavior of MS Windows too will appear, where moving a window will peak one core.

I'd be surprised if moving a window isn't already slow on this hardware. When most of it came out, it was still standard practice to only show an outline when moving a window.

[curaga]

MGA should be included in the list. The only driver version supporting EXA is the experimental 1.9, and it works worse than the stable, XAA-using one.

[gilboa]

What you missed is that the cirrus driver is not actually being dropped, it will just be temporarily broken in git by the removal of XAA, which wouldn't have accelerated much anyway on any system released in the past ~4 years.

1. Don't be rude. Period.
2. There's no doubt that cirrus and old, and should be have taken behind the shed and shot; but as long as qxl has yet to reach the same stability (as cirrus), I can only hope the X-devs will take the time to maintain with some-type-of-working-acceleration.

Are we done?

[mattst88]

Yeah, it's sad... I have an Alpha that I was going to set up with a 3DFX Voodoo3 in the near future. Looks like I'll have to restrict myself to older versions of X.org if I want a working non-VESA driver. That, or I finally have to learn X driver development and figure out how to port the voodoo driver to EXA, and possibly KMS/DRI2...

Wasn't someone actually working on a KMS driver for 3dfx cards a few years back as part of a documentation GSoC project?

I did a GSoC project writing a KMS driver for 3DLabs video cards, and James Simmons was working on KMS for 3dfx video cards, so you're combining the two.