X.Org Server 1.17 Likely To Have Built-In KMS Modesetting Driver

[J?rnS]

Sorry, I forgot to quote, I was referring to uid313's posting.

[Mat2]

It would be great if somebody wrote a decent (high-performance) KMS kernel driver for VESA.
The interface is very common, and works very good if the firmware knows your monitor resolution.
I have been using it on my old box (Geforce 4 MX 420, Athlon 1700+, 1GB RAM) and the experience was better then with the binary nvidia driver (of course I was using only 2D).

There was some proposition by David Herrmann, but it did not get into the kernel.

http://lists.freedesktop.org/archives/dri-devel/2013-January/034058.html

This driver is nice, but unfortunately very slow - see dvbe_vesa_read() in the link above.

It would be possible to get some code from the uvesafb driver and possibly share it in a common module.
The uvesafb driver could be even turned completely into KMS and use the framebuffer compatibility layer.

I have been toying with the idea of writing this driver and investigating it, but did not have time and this seemed quite difficult, especially the memory management code.

There should also be a new kernel command line parameter, say "basicvideo". When set, it should disable all device-specific drivers (radeon, intel, etc.) and use only the platform ones (VESA/UEFI).
That way, if the native driver does not work, you have a backup.

[curaga]

Vesa and high-performance in the same sentence is an oxymoron. The cpu will do the work in every case, you can only try to save a mem copy or two, which won't bring it to par with any accelerated card.

[Mat2]

Vesa and high-performance in the same sentence is an oxymoron. The cpu will do the work in every case, you can only try to save a mem copy or two, which won't bring it to par with any accelerated card.

I meant relatively high-performance, faster then the David's patch.

[Gusar]

X has no XAA any longer (for quite a while now). But it should be added back, imho. Many old graphic cards that used to work "fine" are now working only unaccelerated (NoAccel in xorg.conf), which is really a PITA.

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-sis/+bug/1066464

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-mach64/+bug/1077975

And the devs of X don't care about that. Thanks!

Even XAA was unaccelerated ever since offscreen pixmaps got deactivated, which happened a few years before XAA was yanked completely. So from the acceleration perspective, there's no difference between XAA and NoAccel.

About those bug reports, The SiS driver has a patch, and if it doesn't work for all GPUs, Arch uses an alternative patch that simply disables the DownloadFromScreen/UploadToScreen hooks, this way EXA works for sure with all SiS GPUs. Not a problem with X devs if Ubuntu doesn't ship fixed packages. I only skimmed the other bug report, but it seems there's patches there as well.

Bottom line, the solution isn't adding back XAA, but writing fixes and getting those fixes into distro packages.

[robclark]

What about xa? Is it supposed to be faster than glamor, using gallium directly without OpenGL?

(xa) : (glamor) = (gallium-nine + wine) : (vanilla wine)

doubtful.. XA just implements EXA, so it is still sw fallbacks for everything that EXA does not support. Glamor should be able to accelerate more of the x11 drawing primitives, avoiding fallbacks (and therefore stalls)..