X11 ARM-on

Nem volt könnyú kiválasztani az ARM lapot, amivel minimál, de fürge X desktopot szeretnék futtatni. Az EGL jól támogatott gyártói bináris driverekkel, de az Androiddal ellentétben az X GUI tipikusan csak kompozit ablakkezelésre használja az EGL-t, így elsősorban nem annak a sebessége számít.

A mai általános X GUI a következő pontokon támaszkodik a hardver gyorsítására a gyakorlatban:
1. EXA Composite (Xrender[1]): font raszterizálás GTK környezetben [2], firefox html5
2. EXA Copy: scroll, ablakok mozgatása (nem-kompozit WM esetén)
3. EXA Solid: widgetek kirajzolása
4. EGL: kompozit ablakkezelés, firefox webgl

Megnéztem 5 SoC-ot, hogy hogy is állnak ezen a téren;

I. sunxi (Allwinner A1X, A20): MK802 I-II, Cubieboard, Cubietruck, Mele A1000
Ezeket Mr. ssvb által önkéntesen fejlesztett fbturbo DDX driver hajtja. Az EXA Copy műveletet gyorsítja a G2D-vel, az EXA Solid gyorsítását megvizsgálták, de lassabb lenne az Allwinner SoC-okon mintha a CPU csinálná, így nem kapcsolták be. Az EXA Composite "érdeklődés hiányában" nincs gyorsítva. 2D blittert használ, nem a GPU-t.

II. exynos: ODROID-U{2,3}, Chromebook
Ez az fbdev és az arm-soc DDX driverekkel működik. Egyik sem biztosít hardveres gyorsítást, utóbbinál ez alól kivétel a kurzor kirajzolása. Innen ered a nyavajgás a Chromebookot X11-gyel használó juzerektől. A ChromeOS ugyanis már csak EGL-t használ X11 alatt, az EXA gyorsítás nem érdekük.

III. RK3188: MK802 III-IV
Ugyanaz mint az exynos, nincs saját DDX drivere, de még az arm-soc sem opció.

IV. imx6: Wandboard, CuBox-i
DDX drivere a gyártó által írt opensource imxfb-vivante. Teljes EXA gyorsítás a GPU-n.

V. adreno: DragonBoard
DDX (és 3D) drivere az opensource freedreno. A drivert egymaga Rob Clark készítette reverse engineeringgel. Mesa XA trackeren át lenne képes EXA-t gyorsítani, de a patchset nincs karbantartva. Amikor utoljára működött nála, nem érzett óriási javulást.

[1] Szemfülesebbek mondhatják, hogy: á, mit nekem unaccelerated Xrender, ott a Cairo gles surface backend! Igen ám, csak azt az alkalmazásnak is támogatnia kell és kb csak a Firefox támogatja*. Ráadásul kell hozzá az EGL_EXT_swap_buffers_with_damage bővítmény, ami nem tudom hogy áll az ARM-os gyártói bináris driverekben.
* Ezt hívják "hardware accelerated rendering"-nek ami nem kicsit FUD, hiszen az Xrender ugyanúgy a GPU-val van gyorsítva minden mai x86 rendszeren, csak a code path más.

[2] A font raszterizálás az XRender-en át nagyon lassú lehet ha az EXA composite ops nincs jól megtámogatva hardveresen, ami érezhető a termináltól a Firefox-on át mindenen. A Qt a 4.8-as verziótól nem is vállalja be a kétes előnyt, default a raster engine, ami a CPU-n végzi el a dolgokat az EXA helyett. A Qt5 pedig már nem is tartalmazza az XRender engine-t (egyelőre).
Ha a Qt alkalmazások gyorsabbnak tűnnek mint GTK-s párjaik, akkor valszeg ez a probléma. A Firefoxban egyébként ki lehet kapcsolni az XRender-t (about:config), de a html5 canvas-okhoz jól jön az (pl. fishblow teszt), ott a font raszterizálással ellentétben mindenképp hátrány ha nincs GPU.

Volt már egy korábbi írásom az Xorg és a hardver gyorsítás kapcsolatáról, ha valaki érdekel ez a téma abban még van pár morzsa az elinduláshoz.

TL;DR: Wandboard kell az X11 GUI-hoz.