Il coltello in mano al programmatore

Qualcosa in comune tra Metal e la PlayStation 3

di

thumbnail

15

giu

2015

L’anno scorso Apple ha presentato la tecnologia per iOS. Ora la spinge su OS X. Quale potente magia la muove?

Metal è una nuova libreria grafica molto vicina all’hardware, da utilizzare per spremere ancor più frame al secondo a parità di CPU, GPU e RAM. Durante il WWDC 2015, Metal è stato annunciato anche per i Mac.

Nel mondo della produzione di librerie grafiche multimediali (per esempio i game engine) uno dei componenti più complessi, ottimizzati e spinti al limite delle capacità dell’hardware è proprio quello che si occupa del rendering a video della scena. Questo componente fa lavorare CPU e RAM occupandosi di preparare per la GPU – in uno specifico ordine e formato – tutti i dati necessari per il disegno del prossimo frame. E poi – tlack – si tira una leva digitale (draw call) e questi dati entrano in quella macina mastodontica che è la nostra scheda video. Tra i diversi risultati il più importante è l’immagine che viene generata sul framebuffer pronta ad essere spedita via cavo al nostro display.

Veniamo al punto: dove si pone Metal? Allo stesso livello di OpenGL. Lo sostituisce, o meglio, lascia allo sviluppatore la possibilità se usare Metal o OpenGL ora che tutti i dispositivi iOS ed OS X li supportano entrambi.

Ma come, direte: oltre vent’anni di evoluzioni di OpenGL (versione 1.0 nel 1992), motori superlavorati, trick e capriole digitali che ci hanno stupito con immagini che mai sarebbero state possibili altrimenti su quell’hardware, e poi arriva Metal che promette pari feature e prestazioni superiori?

Succede che le macchine per la produzione di grafica real time sono cambiate dal 1992 ad oggi. Il gap tra CPU e GPU si è ampliato e diversificato, la RAM in diversi casi ora risulta condivisa tra i due, i vertex e fragment shader hanno conquistato un ruolo di rilievo all’interno della pipeline ed i processi GPGPU prendono sempre più piede.

Dove potrebbe beneficiare un diverso modello di programmazione video? La risposta a questo andrebbe ricercata nell’enciclopedia dei workaround generatasi nel tempo intorno all’interfaccia OpenGL.

Caratteristiche di Metal

Al solito: i tempi sono cambiati. Ecco perché Metal nonostante vent’anni di OpenGL.

OpenGL espone la GPU come una macchina a stati: prepari i dati, lanci il calcolo, prendi il risultato, ripeti. Possiede una singola funzione per l’avvio della graphic pipeline ed ha una sezione di memoria virtualmente o fisicamente dedicata. Col tempo i processi legati al rendering hanno accumulato tanta complessità da rendere più conveniente gestire l’intero processo a granularità fine (invece che preferire un paio di trick ad alto livello) magari lanciando qualche draw call a vuoto solo per riempire qualche cache. Sono così andate generandosi diverse versioni ed estensioni OpenGL che abilitano diversi meccanismi specifici: a volte per abbracciare una nuova tecnologia, altre per ufficializzare ed ottimizzare quanto era workaround nella generazione precedente, ma sempre proponendo una interfaccia a stati ad alto livello.

Arriva il nuovo

Parola d’ordine: esporre la complessità invece che risolverla. Sembra che Sony si sia spinta in questa direzione con PlayStation 3 (esiste un NDA tra questa informazione e la verità) ma è certo che AMD abbia preferito questo paradigma per Mantle e Microsoft per DirectX 12. Apple segue con Metal.

Il fulcro del nuovo e possibile è costituito dall’esposizione dei command buffer, ovvero la to-do list della GPU. Tramite questo componente l’applicazione diventa responsabile nel definire (anche in maniera asincrona!) i comandi da eseguire nel frame successivo, controllando anche il delay tra CPU e GPU. To make a long story short, il programmatore ha ora il coltello dalla parte del manico e niente più mani legate per eseguire quel bilancino tra CPU e GPU necessario a sfruttare al massimo l’hardware.

È altresì chiaro che, in quanto buffer, i comandi non vengono eseguiti direttamente, bensì si accumulano in una coda che sarà premura della GPU svuotare nel più breve tempo possibile. Qui possiamo evidenziare tre conseguenti vantaggi:

  • l’applicazione potrà sfruttare i diversi core della CPU per dare più filo da torcere alla GPU;
  • l’applicazione potrà utilizzare l’ammontare dinamico delle risorse libere per gestire la lunghezza del command buffer;
  • il controllo sugli errori per ogni stato presente sul command buffer potrà essere eseguito in anticipo e comunque in modo asincrono rispetto all’esecuzione dello stesso.

OpenGL che fa? Sta a guardare il concorrente che prende il via? Ahimé si, al momento. Ma questo vuole anche sottolineare che OpenGL non ha, tecnologicamente parlando, nulla da invidiare. Infatti in casi particolari e con le giuste combinazioni di estensioni e configurazioni della macchina anche qui si può parlare di un driver con zero overhead. Il punto dolente rimangono, appunto, tutti i requisiti di compatibilità che OpenGL porta con sé: versioni, profili e funzioni deprecate si attorcigliano tra vecchie e nuove soluzioni, tutte utili ad ottenere lo stesso risultato.

Cosa ne sarà di OpenGL? Personalmente lo figuro indisturbato sulla sua strada, sicuro del fatto suo e ben ancorato a tutti i sistemi con una GPU, anche se uno dei creatori di DirectX non la pensa proprio uguale.

Metal è nuovo nella misura in cui rimettere ordine e fare cernita dell’utile nel gabbiotto degli attrezzi può garantire riparazioni più efficienti in futuro. Metal piace ed è già sotto il cofano di qualche motore 3D. Metal ha anche un nome che non mi dispiace affatto, ma questa è un’altra storia.




Giacomo Cappellini (@Arkanoid) è da cinque anni analista programmatore e tool-maker di applicazioni per smartphone e tablet, da dieci anni deviato nel multidisciplinare mondo dello sviluppo di videogiochi cross-platform. Nonostante una grave e particolare forma di ossessione verso lo how-it’s-done, trova ancora tempo e modo per parlarne.

Letto 4.387 volte | Tag: , , , , , , , , , , , , , ,

Lascia il tuo commento