X.Org, perché con molti problemi?
Questo articolo è molto vecchio e potrebbe essere obsoleto
- 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.
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.
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/
Lazza scrive —
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.
DnaX scrive —
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.