Wayland cosa è?

Prima di tutto un poco di storia:

Esistevano negli anni 80′ dei computer chiamati Workstation, costavano come l’equivalente di un auto fin un camion e questi venivano usati principalmente per fare grafica come CAD/CAE/CAM, foto-ritocco, disegno tecnico, ecc.. Per questo si pensa che la grafica sia una cosa recente, prima bisognava essere ricconi per fare grafica!

Avevano schede grafiche che oggi giorno fanno ridere ma per quello che dovevano fare lo facevano bene, ma come pilotarle via software? I driver? I Tools? Ecc.. Ovvero tutta roba software? Roba anche costosissima!

XX-Window-System

Per questo i principali produttori di schede grafiche si alleano per ridurre le spese e standardizzare le schede stesse e nasce X11 (anno 1987 da un progetto del MIT del 1984) e poi XFree86 (specie per integrare su piattaforma Intel nel 1992), però era una raccolta dei vari programmi delle varie aziende e quindi avevano una licenza propria che spesso ostacolava l’integrazione. Questo permette lo stesso lo sviluppo di altre componenti libere come OpenGL (usate anche in Windows 10 e il suo wrapper DirectX12).

X_client_server_example.svg

Nel 22 gennaio 2004 per questo nasce Xorg per fare un unico programma ed eliminare la baraonda di licenze. Il gruppo è attualmente gestito da un consiglio di amministrazione che comprende: Stuart Anderson (Free Standards Group), Egbert Eich (SUSE), Jim Gettys (HP), Georg Greve (Free Software Foundation Europe), Stuart Kreitman (SUN Microsystems ora Oracle), Kevin Martin (Red Hat), Jim McQuillan (Progetto Linux Terminal Server), Leon Shiman (Shiman Associates) e Jeremy White (Code Weavers).

Nel 2011 muore XFree86, ultimo rilascio nel 2008.

Xorg è servizio (in inglese server) come può essere Apache per il web. Un servizio si può modularizzare e (in questo caso) stabilire collegamenti con diversi kernel di diversi OS, Librerie grafiche (esempio OpenGL), motori grafici e soprattutto diversissimi driver con diversissimi standard.

 

Wayland non è un servizio!!!

 

Però dal 2004 e poi portandosi dietro tutta la compatibilità di XFree86 il nostro Xorg è divenuto un elefante: Milioni di schede grafiche supportate, milioni di configurazioni possibili, milioni di compatibilità driver, vattelappesca OS e relativi Kernel, di collegamenti su possibili librerie grafiche e motori grafici. Non solo Xorg include anche un suo Motore Grafico anche se basilare (dunque è un composer) e quindi serve solo per definire le finestre dei WM e i DE.

Dato che Xorg possiede un motore grafico che oramai serve solo per la definizione dei WM e DE, qualcuno pensa che Xorg serve solo per il “Desktop”… Sbagliato: Ogni oggetto grafico compreso CAD, foto/immagini, disegni, videogiochi, ecc, persino i font ovvero le scritture sullo schermo sono grafica. Ovvero tutta la grafica del PC è Xorg!!!

Insomma, per esempio, per fare un quadrato sullo schermo, devo mandare una chiamata ad Xorg, quando lo prende Xorg lo passa al suo motore grafico (peggio se si usa un motore grafico esterno), che invia il permesso al kernel se lo può fare, che legge la Libreria Grafica di come si fa questo quadrato, che invia al driver che comunica alla scheda grafica come fare l’abbozzo e rinvia che l’esegue al Xorg che ciclando prende la risposta e la rinvia al Motore Grafico che dice che OK l’azione, ecc. ecc. Ed ecco il quadrato sullo schermo, se poi pensate che una immagine sullo schermo è moltooo più complesso notate quanto tempo impiega! Notate che se non fate nulla il Xorg continua nel suo monitoraggio delle richieste!

x-architecture

Quanto di “questo” esiste adesso? Oramai le schede grafiche sono tutte standard e solo eccezioni possono essere definite via driver anch’essi standard, le configurazioni oramai sono dei motori grafici che è meglio che siano propri dell’applicazione per fare il meglio possibile e gli OS sono rimasti in 5 ed oramai con grandi capacità e i rimanenti OS seguono i loro standard. In effetti sono nati derivazioni di Xorg come Xorg-lite e Xorg-Vesa e altri, ma togliere codice imbrigliato/mischiato si è rivelato un compito immane e spesso forte di errori perchè mancava poi quella parte del codice in quella particolare eccezione.

Perchè avere un server/servizio? Meglio fare un Framework, ovvero una serie di librerie collegate con programmi d’utilità che collegano il Kernel, driver (che collegano le schede video), Motore Grafico e librerie grafiche.

Framework= Insieme di librerie e programmi d’utilità e altro tutto armonizzato e collegato direttamente.

Wayland Usa un PROTOCOLLO di comunicazione standard suo, quindi si può anche definire che Wayland sia solo un protocollo, anche se poi comprende molte altre cose annesse quindi sarebbe più giusto, se visto da fuori, di parlare di framework.

Moltoooooooooo più semplice, moltooooo più rapido, senza occupare memoria e CPU nei tempi morti, senza aspettare che un servizio giri il task della richiesta e poi il task della risposta,   senza tenere in memoria o occupare tempi CPU parti di programmi per compatibilità con vecchie schede/driver/Librerie-grafiche/kernel/ecc oramai sparite. Senza il gigantismo che nasconde chissà quanti Bug nascosti!

Riprendendo l’esempio del quadrato accade questo: Il Motore Grafico del programma (CAD, immagine, DE/WM, ecc..) deve fare un quadrato, allora linka ->Driver->Kernel->libreria-grafica … Fatto il quadrato! Per fare una immagine molto complessa:  Linka ->Driver->Kernel->libreria-grafica, fatto! Nei tempi morti nessun occupazione di CPU e memoria! Inoltre nessun rimpallo delle operazioni da fare!

wayland-architecture

Allora perchè non hanno fatto da subito un Framework-video (come Wayland e MIR e altri sui smartphone) invece di un Server-video (come Xorg)?

Perchè un  Framework-video se lo vuoi usare su un OS, Motore Grafico, Libreria, Driver che non rispetta lo standard o l’uso comune devi modificarlo pesantemente e faticosamente, mentre un servizio come Xorg basta modificare le chiamate che riceve e l massimo mettere un eccezione nell’esecuzione o una routine interna.

Ecco perchè adesso si usa un Framework-video come Wayland: Solo Linux e al massimo BSD, Driver standard di schede ultima generazione (dal 2010?) e librerie grafiche corrispondenti allo standard OpenGL come Vulkan o già inserite in OpenGL/OpenCE. STOP!

Wayland utilizza funzioni del kernel Linux come DRM (Direct Rendering Manager), KMS (Kernel Mode Settings) e GEM (Graphics Execution Manager) per gestire direttamente un compositore integrato; Questa particolare architettura permette di ottenere prestazioni migliori rispetto a X Window System in quanto vengono eliminate alcune commutazioni di contesto mentre molte delle estensioni del protocollo X11 vengono implementate nelle API di Wayland.

Ovvio che cerco di spiegarlo il più semplicemente possibile (c’è un mondo intero da spiegare) e maggiori dettagli li troverete sui siti delle varie organizzazioni!

Vulkan

Vulkan sono nuove librerie grafiche che entreranno in OpenGL appena escono dalla beta ovvero quando saranno complete. Infatti sono definite glNext ovvero estensioni della libreria OpenGL e cambieranno anche il loro modus-operandi.

Sono concepite per i videogiochi, tanto che è AMD (derivata appunto dal suo Mantle) che preme per le sue schede grafiche specializzate sui videogiochi e anche Valve, Sony, Epic-games, Steam, ecc. tutte ditte specializzate o cui introiti derivano dai videogiochi.

Però quello che si può usare per i videogiochi si può usare per CAD, Grafica semplice, video-grafica, ecc.. ecco perchè tantissime aziende (esempio Unity per MIR) le sponsorizzano specialmente dopo l’aborto delle directX12 e le “nuove” specifiche per DirectX13.

  • OpenGL-base usa il linguaggio ad alto livello GLSL per la scrittura di shader che costringe i driver OpenGL l’esecuzione del proprio compilatore per GLSL che esegue in fase di esecuzione dell’applicazione la traduzione dello shader del programma in codice eseguibile per la piattaforma di destinazione. Vulkan fornisce un intermediario binario chiamato SPIR-V (standard Portable Intermediate Representation), analogo (ma migliore) all’HLSL (che deve rispettare GLSL) delle DirectX. Questo riduce l’onere sui fornitori di driver, permette la precompilazione dei shader, permette agli sviluppatori di applicazioni di scrivere shader in linguaggi diversi da GLSL.
  • Oltre al SPIR-V (e per compatibilità GLSL) verrà aggiunto il supporto ad un vero e proprio C++.
  • OpenCL (calcolo) e Vulkan (grafica) finiscono sotto lo stesso tetto grazie a SPIR-V.
  • Multipiattaforma API supportate sia sui dispositivi mobili che su schede grafiche di fascia alta.
  • OS agnostic per migliorare la portabilità delle applicazioni create utilizzando l’API.
  • Migliorato, anzi specializzato il supporto per i sistemi moderni che utilizzano multithreading.
  • Ridotto il carico sulla CPU in situazioni in cui la CPU costituisce il collo di bottiglia, permettendo un throughput più elevato per i calcoli GPU e rendering.
  • Il supporto è orientato verso Wayland e MIR (ovvero base Linux) quindi bisogna riscrivere tutto DirectX 12 il che comporta anche un onere non da poco!
  • Ci sono anche funzionalità di clonazione del kernel (solo Linux) grazie al comando clCloneKernel.
  • Sono già disponibili sulla Console Steam OS (Steam Machines, che poi può essere istallato anche su PC) che si basa sul Linux Debian/Ubunto. (ma supportato anche Suse e Fedora)

Qui il Tutorial (in inglese) per gli sviluppatori.

Come mai MIR?

 

Canonical (la ditta che produce Ubunto) era entusiasta di Wayland, dato che permette di eliminare Xorg e quindi tutto il carico su CPU e memoria e quindi adatto allo smartphone!

Infatti Canonical vuole produrre un OS per smartphone basato su Ubunto di grandi prestazioni.

Però i ritardi di Wayland, lo sviluppo non incentrato sui smartphone, rogne tra sviluppatori, ecc. decisero la Canonical di buttarsi e fare un progetto tutto suo. Il risultato è che hanno sottovalutato il problema (malgrado che per velocizzare hanno usato concetti di sviluppi per ora chiusi) e quindi non solo hanno rallentato Wayland ma anche che sono in ritardo con MIR.

Menomale che MIR è incentrato su gli stessi standard di Wayland e quindi sono diventati progetti simili e quasi interscambiabili. Solo il tempo può decidere se MIR verrà abbandonato o integrato o un successo.

Per ora solo Canonical lo supporta, al contrario delle migliaia d’integrazioni e supporti che detiene Wayland!

 

Weston

Quando dico che più di un protocollo (dunque si può implementare in qualsiasi libreria come le QT e GTK) è un framework è perchè ci sono anche programmi e utilità al suo interno; Uno di questi è Weston che sostituisce anche il client-X11.

Quello che manca (ma può tranquillamente mancare) al Wayland è un compositore ovvero un Motore Grafico di basso livello in modo di sostituire quello incorporato in Xorg in special modo per compatibilità. Infatti Weston è programma per sé stesso anche se per funzionare occorre di tutto il resto di Wayland.

Usa le librerie di composizione grafica come Cairo, Lib-input , Lib-Jpeg mtdev e Mesa, che guarda caso sono le librerie che usano i browser per trasformare il HTML in immagini e altra grafica, solo che qui converte le chiamate in grafica. GTK+ usa Weston come composer di base dalla ver. 3.1 .

 

Wayland quando esce?

 

Wayland è già stabile (stabilissimo dalla release 1.6 e siamo al 1.9 del 24/11/2015), anche se continuamente si perfeziona! Mancano per ora la convergenza degli altri verso di lui, ovvero dei DE/WM, CAD, programmi come OpenOffice (anche questo usa grafica!), browser, video (player, editor, ecc.), ecc.

Lo vedremo su KDE 6, Gnome 4, TDE, LXQT, ecc. ma anche programmi come Libreoffice (video presentazione), Gimp, Inkscape, Blender, ecc.. successivi. Ma anche prima di queste versioni!

Ma anche molte altre applicazioni come Nemo-ux  che batte Surface 1000 a 0: Ebbene è quello che vedete nei film di fantascienza e para-tecnologici.

Wayland lo vedremo in azione (in doppia possibilità all’accesso se usare Xorg o Wayland) nella prossima versione di Suse Leap 43 e Fedora 23 (se non prima?). Mentre dopo lo troveremo per tutte le distro per PC potenti ovvero non quelle per PC datati.

 

Ciaooooooooooooooooooooooooo

 

 

 

 

 

Precedente Installare OpenSuse con SD Successivo SLE o 13.2 o Leap o cosa?