Blog

X.Org, perché con molti problemi?

Lo so che potrei risultare ripetitivo o cadere in luoghi comuni ma questo è un dato di fatto: X.Org, l'attuale architettura software per la gestione di tutto ciò che viene mostrato a video è fatiscente e per certi versi sta bloccando Linux sui desktop.

  • Tutte le volte che ci lamentiamo perché Flash è lento in molti casi è a causa di X.Org.
  • Tutte le volte che ci chiediamo perché sto cavolo di Compiz non funziona è per colpa di X.Org.
  • Tutte le volte che ci lamentiamo perché sul portatile la risoluzione più di 800x600 non va è per colpa di X.Org.
  • Tutte le volte che ci chiediamo perché un gioco o una finestra in 3D fa a cazzotti con il resto dello schermo è per colpa di X.Org.


Dopo questa carrellata di problemi che fanno passare la voglia di utilizzare Linux ad alcuni e fanno incuriosire altri, vediamo come siamo arrivati a questo punto, constatando però di avere fatto molti passi avanti rispetto ad anni fa.

Post image

Un po' di storia...

Bisogna dire che l'architettura di base di X.Org non è più cambiata da quando è stato fatto il fork con XFree86. Da allora le cose che funzionano sono rimaste tali e le cose che non funzionavano sono state in gran parte lasciate come erano. Io non so quante persone stanno dietro allo sviluppo di X.Org, ma a parte i driver Intel/ATI/nVidia gli altri driver sono rimasti obsoleti, nonostante le caratteristiche delle schede supportate potessero far girare composizione e accelerazione 3D.

Ma vediamo come l'evoluzione ha fatto il suo corso... In X.Org l'accelerazione 3D e quella 2D sono sempre state trattate separatamente, infatti mentre per il disegno 2D veniva usato XAA (XFree86 Acceleration Architecture) con accelerazione di base, per l'accelerazione 3D il tutto è demandato a DRI (Direct Rendering Infrastructure). L'accelerazione XAA fornisce tutte quelle funzioni di base per disegnare forme geometriche semplici, archi e linee che coincidono esattamente con i pixel usati per lo schermo, ciò vuol dire senza anti-aliasing. Per sopperire a questa limitazione venne sviluppata l'accelerazione EXA appunto per rendere usabile (usabile perché i calcoli vengono fatti dalla scheda grafica anziché dal processore) l'estensione XRender che forniva la gestione dell'opacità e il disegno di testo con anti-aliasing. Poi ci fu l'avvento della composizione del desktop con Compiz, quindi molte di queste caratteristiche vennero usate pesantemente e tutti i loro limiti furono così esposi a tutti. La composizione del desktop può avvenire solo se la scheda grafica e il driver riescono a scrivere in un'area di memoria che non sia quella che verrà visualizzata, in questo modo è possibile prendere questa immagine della finestra per inserirla nella texture di un oggetto 3D oppure farci alcune elaborazioni sopra e visualizzare il risultato finale.

Nel caso del 3D in modalità non fullscreen (in una finestra) le immagini prodotte vengono scritte direttamente nella memoria video con conseguenti problemi con trasparenze e successivamente con la composizione. Questo problema dovrebbe essere risolto con DRI2.

Post image

Gestione della memoria

Veniamo al nodo, la gestione della memoria. Quello che va fatto è la rimozione di codice duplicato per ogni driver per ottenere una parte della gestione della memoria comune e una parte specifica per ogni driver. La gestione condivisa andrebbe relegata al kernel e con essa sarebbe possibile mettere il modesetting (l'inizializzazione dello schermo in soldoni) nel kernel ed eseguirlo subito una volta per tutte. Una soluzione a questo frangente è la soluzione TTM di Tungsten Graphics e GEM di Intel. La parte condivisa è già pronta e alcuni driver come lo sperimentale noveau (driver open per schede nVidia) la stanno già usando. La Intel invece ha già integrato GEM nei propri driver ed è in sviluppo una versione del driver ATI che farà uso di un qualcosa di simile a GEM. Ognuno fa ancora il cazzo che gli pare!

Infatti i driver Intel sono i primi (e gli unici al momento) a supportare l'accelerazione UXA, un remake di EXA utilizzante GEM.

C'è da dire che comunque l'accelerazione 3D (come quella 2D) presuppone una buona gestione della memoria. Quindi sta tutto lì. E' perciò necessario trovare, o solamente implementare, un buon sistema di gestione della memoria comune e demandarlo al kernel. Così forse si avranno driver più leggeri e facili da sviluppare.

Questo piccolo sfogo e voglia di documentarmi è nato da quando ho provato Xubuntu su un vecchio PC che ho in casa che monta una scheda Intel 740. Il driver che la gestisce non supporta l'accelerazione EXA (nonostante ci siano tutte le funzioni della scheda) e il compositing, che dovrebbe fornire una GUI più reattiva alleggerendo il poco potente processore, va molto male!

Al momento sia le GTK che le QT stanno aumentando le loro performance scavalcando in alcuni casi il server grafico agendo direttamente sulla scheda grafica, tanto per capire come siamo messi bene.

Quello che si prospetta all'orizzonte è unificare e togliere. Nello specifico andrà usata l'accelerazione UXA, deprecata XAA, e tolto il supporto per DRI1, per tutti i driver, non solo Intel (>= 810), Radeon o nVidia ( >= GeForce).

Alcune fonti:
http://www.rojtberg.net/67/exa-uxa-dri-gem-ttm/
http://keithp.com/blogs/Sharpening_the_Intel_Driver_Focus/

Articoli correlati

DIASPORA* Facebook

Pubblicato il 18 giugno 2009 da e letto 1652 volte.

Link di trackback

Abbonati al feed RSS. Se non sai cos'è guarda qui.

Abbonati alla newsletter per ricevere via email ogni nuovo articolo pubblicato. L'indirizzo verrà gestito da FeedBurner.

Dai il tuo parere: Commenta questo articolo!
2 commenti su X.Org, perché con molti problemi?
  1. Lazza dice:

    No distinguiamo... Passi Compiz, passi la risoluzione, quello che vuoi.
    Ma flash fa pena perché è proprietario e il codice lo tocca solo la Adobe, quindi se ci sono dei bug... ce la mettiamo via e li sopportiamo.

    venerdì, 19 giugno 2009 alle 11:49
  2. DnaX dice:

    Allora come mai con l’accelerazione 2D XAA Flash funziona meglio che con l’accelerazione EXA (migliore)? Come mai a saturare la CPU non è Flash ma X.org? Inoltre mettendo i video a tutto schermo questo problema scompare (sia con XAA sia con EXA)... Non lo so di chi è clpa veramente, ma sicuramente è da tutte e due le parti. Sul portatile ad esempio dove uso l’accelerazione UXA funziona alla grande.

    domenica, 21 giugno 2009 alle 15:15
Lascia un commento

CC BY-NC-SA 3.0 2004-2012 Daniele Napolitano — Per informazioni sulla licenza leggere le Note legali
Torna su