I motori grafici futuri saranno di nuovo software?

[Filippo1974]

Ciao a tutti,

stamattina mi è cascato l'occhio su questa intervista rilasciata da Tim Sweeney, creatore del motore grafico di Unreal.

http://www.tomshardware.com/2008/03/11/tim_sweeney_part_2_directx_10_is_the_last_relevant _graphics_api_/index.html

Interpellato sul futuro dei giochi 3D per PC, Tim ha sollevato la possibilità, peraltro molto concreta, che il software vada via via abbandonando la strada delle API standard fin qui percorsa (e che ha nelle DirectX e in OpenGL i due principali rappresentanti) per tornare ad una implementazione totalmente proprietaria ed interamente basata sul software. Il vantaggio principale, secondo Sweeney, è che così facendo ci si libererà definitivamente del "sovrappeso" dovuto all'utilizzo dell'API (OpenGL o DirectX che sia), sovrappeso che tra parentesi l'introduzione delle DirectX 10 avrebbe dovuto diminuire.

Sweeney ha confidato che gli sviluppi futuri dei giochi Epic (di cui egli è CEO) andranno proprio in questa direzione, ovvero fare a meno delle API standard e introdurre un motore grafico che gestisca direttamente la GPU in proprio e con accesso diretto, utilizzandola come una vera e propria estensione alla CPU del PC.

Le API grafiche sono quindi destinate a sparire? Secondo Sweeney no: esse rappresentano comunque una comodità per gli sviluppatori che non intendono sobbarcarsi il notevole fardello di gestire una GPU con un accesso diretto; chi però vorrà trarre il massimo dall'hardware disponibile farà meglio a seguire la strada di Epic.

Se questa visione avesse veramente un seguito, sarebbe un sostanzioso passo avanti nella rincorsa del PC all'efficienza delle console. Sicuramente le specifiche stesse alla base delle DirectX 10 hanno dato una buona mano: i requisiti molto più stringenti sull'hardware rispetto alle versioni precedenti delle DX hanno permesso alle GPU di nuova generazione di "assomigliarsi" molto di più rispetto a prima, e questo paradossalmente potrebbe rendere più facile la possibilità di fare completamente a meno di un'API per accedere all'hardware video.

Ricordiamo che un'API (Application Programming Interface) è una libreria di funzioni software, che ha principalmente il compito di nascondere al programmatore la reale struttura dell'hardware sottostante: tramite l'API, il programmatore "vede" un modello astratto di un determinato componente hardware, ed è compito poi dell'API stessa, di concerto con il driver di quel componente hardware, tradurre il modello astratto nelle funzioni specifiche dell'hardware in questione.

Resta da vedere come un ipotetico accesso diretto alla scheda video sarebbe possibile, visto che da quanto mi è dato sapere, attualmente la famiglia Windows non consente un utilizzo diretto ed esclusivo di una periferica hardware da parte di un'applicazione.

Ciao
Filippo

[weyes]

...
Resta da vedere come un ipotetico accesso diretto alla scheda video sarebbe possibile, visto che da quanto mi è dato sapere, attualmente la famiglia Windows non consente un utilizzo diretto ed esclusivo di una periferica hardware da parte di un'applicazione.
...



Molto interessante questa riflessione. Mi sembra che gia' molti giochi in effetti sviluppino un motore grafico proprio.
L'utilita' delle API in questo caso e' quella di mascherare la complessita' dell'hardware sottostante agli sviluppatori fornendo un interfaccia comune per ogni tipo di GPU.
Questo lo si paga chiaramente con un overhead di operazioni che se si potesse evitare porterebbe sicuramente anche ad un vantaggio in termini di prestazioni.


Il fatto pero' di utilizzare una GPU come estensione della CPU e' discutibile perche' in questo caso gli sviluppatori dovrebbero non soltanto sobbarcarsi i dettagli di interfacciamento a basso livello ma anche fornire diverse versioni del software per ogni diverso tipo di GPU.

Il futuro secondo me e' invece piu' legato alla parallelizzazione. Rendere le GPU praticamente autonome, svincolando la CPU che rimarrebbe libera per effettuare altre operazioni. Al momento infatti le operazioni grafiche richiedono non solo buone GPU ma anche buone CPU perche' entrambe concorrono al risultato finale.
La parallelizzazione e' infatti la strada che il mercato segue con le CPU a n-core ma anche con le nuove schede grafiche (ad esempio le SLI).

Riguardo l'utilizzo di una periferica in esclusiva direi che il problema era presente nelle prime versioni di Windows. Ad esempio con NT non tutti i giochi si potevano eseguire proprio per questo motivo.
La misrosoft invento' una cosa che chiamo' HAL (Hardware Abstraction Layer) proprio per superare questa difficolta'. L'introduzione avvenne con Windows 2000.
Grazie ad hal un'applicazione non puo' impossessarsi in esclusiva di una periferica ma puo' comunicare con essa a basso livello. Cosa che mi sembra rientri nel quadro della discussione in oggetto.

[Filippo1974]

Il fatto pero' di utilizzare una GPU come estensione della CPU e' discutibile perche' in questo caso gli sviluppatori dovrebbero non soltanto sobbarcarsi i dettagli di interfacciamento a basso livello ma anche fornire diverse versioni del software per ogni diverso tipo di GPU.

E' vero, ma come dicevo nel mio post, il fatto che le GPU si assomiglino molto più di una volta, dopo l'introduzione delle DirectX 10 (che hanno di fatto dato una forte spinta nell'uniformare l'hardware di produttori diversi) faciliterebbe il compito di uno sviluppatore che volesse controllare direttamente una GPU.

Non dimentichiamo poi che esiste già un'interfaccia, creata sia da Nvidia che da ATI, per l'uso delle proprie schede video come CPU aggiuntive, naturalmente non "pari grado" della CPU vera e propria (le GPU, per quanto evolutesi nel tempo, non hanno ancora la flessibilità di una CPU completa) ma specializzate nell'esecuzione delle porzioni di un software più parallelizzabili e più intensive dal punto di vista computazionale. Nvidia permette tutto ciò attraverso il CUDA (http://www.nvidia.com/object/cuda_home.html); ATI non so se abbia un nome per una tecnologia equivalente, ma so per certo che c'è.

In pratica, quindi, secondo Sweeney in futuro gli sviluppatori preferiranno svincolarsi dal percorso rigido e predefinito offerto dalle API attuali (OpenGL/DirectX) e useranno le schede video come ausilio alla CPU del PC per eseguire un renderer totalmente software, tramite meccanismi analoghi a quello che ho citato sopra.


Il futuro secondo me e' invece piu' legato alla parallelizzazione. Rendere le GPU praticamente autonome, svincolando la CPU che rimarrebbe libera per effettuare altre operazioni. Al momento infatti le operazioni grafiche richiedono non solo buone GPU ma anche buone CPU perche' entrambe concorrono al risultato finale.

Questo in realtà era quello che si era cercato di fare nei primi anni 2000, con una forte diversificazione dell'hardware allo scopo di parallelizzare tutto: l'audio con l'APU (Audio Processing Unit, vedi le varie Audigy e X-Fi di Creative), il video con le GPU, poi si è provato anche con la fisica con questa "meteora" delle PPU (Physics Processing Unit, in pratica i prodotti di Ageia).

Adesso invece, la parola d'ordine è "unificazione": non più unità hardware distinte per compiti specifici, ma semmai più componenti fisici che possono venire uniti a formare un'unità logica da riutilizzare per tutto. Ha iniziato Windows Vista, bandendo il supporto hardware per l'accelerazione audio e introducendo al suo posto uno stack audio totalmente software; sono venute poi le tecnologie già citate di Nvidia e ATI, CUDA e non-so-come-si-chiama-l'altra per l'uso delle schede video come acceleratori per computazioni General Purpose; ora Intel ha pronto in tasca il progetto Larrabee per una CPU/GPU multi-core basata sul set di istruzioni x86, e AMD l'anno prossimo arriverà con le CPU "Swift" (notizia fresca) che altro non sarebbero se non le prime incarnazioni concrete del progetto Fusion per avere una CPU e una GPU nello stesso zoccolo (in pratica, un processore con integrata anche la sezione grafica).

Intel sta battendo questa strada in modo ancora più radicale, promuovendo un paradigma di programmazione dove non c'è più una distinzione tra CPU e altri acceleratori presenti nel computer: lo sviluppatore si concentra su cosa vuole ottenere, e gli strumenti di sviluppo genereranno del codice distribuito, che possa utilizzare tutte le CPU (o simili) in modo concorrente per eseguire il software creato dallo sviluppatore.

Non più quindi diverse unità hardware distinte per compiti distinti, ma tanti "mattoncini", magari alcuni più efficienti di altri in taluni tipi di computazione, ma tutti legati tra loro a formare un'unica "unità di computazione" a disposizione del programmatore.

In questa visione si inserirebbe questa proposta di creare motori di rendering totalmente software, che non dipendano quindi da una particolare API.


Riguardo l'utilizzo di una periferica in esclusiva direi che il problema era presente nelle prime versioni di Windows. Ad esempio con NT non tutti i giochi si potevano eseguire proprio per questo motivo.
La misrosoft invento' una cosa che chiamo' HAL (Hardware Abstraction Layer) proprio per superare questa difficolta'. L'introduzione avvenne con Windows 2000.
Grazie ad hal un'applicazione non puo' impossessarsi in esclusiva di una periferica ma puo' comunicare con essa a basso livello. Cosa che mi sembra rientri nel quadro della discussione in oggetto.

In realtà è il contrario: fino a Windows 2000, il sistema permetteva senza tanti problemi l'accesso diretto alle periferiche hardware (escluso solamente Windows NT, che essendo destinato ad usi professionali/aziendali, per ragioni di robustezza/sicurezza non poteva certo permettere che qualche software si arrogasse il diritto di prendere il controllo esclusivo di parte del sistema). Con l'avvento di Windows 2000, che ha segnato il primo esemplare della famiglia Windows che unificava il segmento consumer (Windows 9x) con quello professionale (Windows NT 4), il kernel era quello della famiglia NT, con tutte le restrizioni del caso (quindi niente accesso esclusivo alle periferiche).

L'HAL non è stato fatto per permettere un accesso a basso livello, ancorché non esclusivo. Anzi: ha proprio lo scopo di mascherare totalmente la struttura dell'hardware fisicamente presente, mostrando al software un'interfaccia generica che di fatto impedisce di accedere alle peculiarità specifiche di quell'hardware. Quindi l'HAL, per come funziona, impedisce totalmente qualunque "velleità" di accesso a basso livello, e a maggior ragione l'accesso esclusivo da parte di qualsivoglia software...

Ciao
Filippo

[weyes]

Filippo prendo per buono tutto quello che dice.
Soprattutto l'ultima parte, gia' mentre la scrivevo non ero sicuro al 100% di questo HAL :rolleyes:

Apprezzo molto queste elucubrazioni :)