GPU Computing

[ErmaC]

Fonte: tech360 tecnology your way

Titolo originale: Nvidia CUDA vs ATI Stream: le schede grafiche di ultima generazione accelerano la compressione dei video

Adattamento: nessun adattamento versione originale interamente riportata

 

GPU Computing

 

 

Nvidia CUDA. ATI Stream. Due modi differenti per declinare lo stesso concetto. Quello che in passato si chiamava GPGPU (General Purpose computation on Graphic Processing Unit) e che oggi invece si preferisce definire GPU Computing, ovvero l’esecuzione via GPU di calcoli differenti dall’elaborazione grafica.

 

Le schede grafiche di ultima generazione sono in grado non solo di renderizzare scene 3D estremamente dettagliate a frequenze di fotogramma elevatissime, ma possono perfino calcolare le interazioni fisiche all’interno del videogioco oppure, uscendo dall’ambito “entertainment” sono in grado di eseguire calcoli algebrici complessi, simulazioni climatiche, fisiche e mediche, elaborazione di segnali o immagini, compressione, conversione e decodifica di video, cifratura e decrittazione di password e tanto altro ancora.

 

Un qualcosa che è reso possibile dalle moderne GPU dotate di architetture “flessibili”, ossia a “shader unificati”, in cui il chip è composto da tante unità di elaborazione programmabili, chiamate shader processors o stream processors, che trasformano un processore grafico nell’equivalente di un supercomputer parallelo. Talmente efficiente nell’esecuzione di alcuni compiti da polverizzare anche la più veloce CPU quadcore oggi in commercio!

 

Sia AMD che Nvidia hanno messo in commercio schede dedicate all’elaborazione via GPU. Prodotti che svolgono esclusivamente quel compito. Non più schede grafiche ma veri e propri “acceleratori di calcolo”. Nel caso di AMD parliamo di FireStream. Nel caso Nvidia invece di Tesla.

 

Ma queste sono soluzioni professionali. Quello che vogliamo invece valutare noi è come un utente oggi possa avvantaggiarsi (e in quale misura) della propria scheda grafica “consumer” per compiti differenti dall’esecuzione dell’ultimo videogioco in 3D. Ad esempio per la compressione/conversione di video.

 

Di seguito approfondiremo dunque l’approccio GPGPU che sta dietro alle soluzioni sviluppate da AMD e da Nvidia e metteremo queste ultime a confronto usando una delle prime applicazioni in grado di supportare entrambe le tecnologie di GPU Computing.

 

 

 

L’evoluzione dei chip grafici

 

 

Parlare di GPGPU solo pochi anni fa sarebbe stato impensabile. I chip grafici (il termine GPU ancora non trovava giustificazione) erano infatti delle soluzioni “specializzate”, sviluppate esclusivamente per l’elaborazione di pixel e vertici. La loro struttura era definita a monte, con un certo quantitativo di risorse di calcolo destinate al rendering e un’altra parte destinata invece al calcolo della geometria. Gli ingegneri assegnati al progetto cercavano quindi di bilanciare la soluzione grafica in modo tale che questi due elementi avessero un loro equilibrio. Tuttavia questo determinava sempre e comunque uno spreco di risorse. Perché alcuni giochi o applicazioni richiedevano maggiori prestazioni dal lato rendering e altri invece caricavano maggiormente il lato geometria. In entrambi i casi parte del chip restava sottoutilizzata. Questo tra l’altro poneva dei vincoli molto rigidi a chi sviluppava software pensato per sfruttare l’accelerazione 3D. A seconda delle caratteristiche dell’architettura grafica “dominante” era necessario rimanere entro certi margini, sia in termini di complessità delle geometrie che dei rendering. Diversamente il gioco non sarebbe stato in grado di girare fluidamente. Le architetture grafiche programmabili hanno progressivamente risolto questo problema.

 

Verso un concetto di GPU

 

 

La programmabilità dei chip grafici si è evoluta di pari passo con le specifiche DirectX. A dare il via è stato DirectX 8, che nel 2000 ha introdotto un linguaggio per la gestione degli shader, chiamato High Level Shading Language (HLSL). Uno shader nel campo della computer grafica è un set di istruzioni software che sono utilizzate per calcolare degli effetti di rendering. Esistono tre tipi di shader: vertex shader, geometry shader e pixel shader. Il primo tipo di shader converte le coordinate 3D dello spazio virtuale in coordinate 2D per la visualizzazione su schermo. Il secondo tipo genera invece la geometria. Infine il terzo tipo calcola il colore dei pixel e viene usato per effetti di illuminazione e ombreggiatura o per le operazioni di mapping. Inizialmente ognuno di questi shader veniva programmato attraverso istruzioni specifiche e il chip grafico era sviluppato con sezioni programmabili destinate alla gestione dei pixel, vertex o geometry shader. Da questa programmabilità è nato il concetto di GPU (Graphic Processing Unit), che si fa risalire ad inizio 2001 con il lancio delle soluzioni GeForce 3 e Radeon 8500. Un passo in avanti notevole rispetto ai chip di vecchia generazione con pipeline non programmabili.

 

La GPU veniva però vista solo come un chip grafico più efficiente, capace di gestire meglio le proprie risorse. Ci sarebbe voluto ancora del tempo per far evolvere questa tecnologia verso una maggiore programmabilità e soprattutto per comprendere che quest’ultima poteva essere sfruttata anche su set di dati che non fossero necessariamente vertici e pixel, ma che potevano essere gestiti alla stregua di questi ultimi.

 

In DirectX 8/DirectX 8.1 era implementato il linguaggio Shader Model 1.x. Con DirectX 9 nel 2002 si è passati a Shader Model 2.x (le prime schede a utilizzarlo erano ATI Radeon 9700 Pro e Nvidia GeForce FX), mentre con DirectX 9.0c nel 2004 si è approdati a Shader Model 3.0 (utilizzato da Nvidia GeForce 6 e ATI Radeon X1000). Ogni iterazione successiva del linguaggio di shading aggiungeva caratteristiche in grado di estendere la programmabilità dei chip grafici. E di volta in volta l’hardware si adeguava a queste specifiche. Ma la vera svolta è arrivata con Windows Vista e DirectX 10, che ha introdotto a fine 2006 lo Shader Model 4.0. Quest’ultimo ha infatti unificato il set di istruzioni per la programmazione di vertici e di geometria. E unificando il set di istruzioni era più sensato che i chip grafici fossero costruiti in modo completamente “flessibile”, non più con parti separate dedicate all’elaborazione di pixel e vertici, bensì con elementi polifunzionali capaci di eseguire all’occorrenza qualsiasi tipo di shader. E’ così che sono nate le prime schede grafiche con architettura a shader unificati, la cui struttura può essere paragonata ad un supercomputer su singolo chip.

 

Shader unificati e GPU Computing

 

 

Ogni GPU basata su architettura a shader unificati è composta da un certo numero di elementi di calcolo programmabili e capaci di operare in parallelo. Queste unità di calcolo possono eseguire shader di qualsiasi tipo. Quindi l’intero potenziale della GPU viene costantemente sfruttato al 100%, indipendentemente da come è stata strutturata l’applicazione che dovrà essere accelerata.

 

La prima GPU di questo tipo è stata il chip Xenos, sviluppato da ATI per la console da gioco Xbox 360. Mentre la prima soluzione commerciale per PC è stata la serie GeForce 8 di Nvidia, lanciata nel novembre del 2006, seguita poi dalla serie Radeon HD 2000 di ATI nel maggio del 2007. Queste due famiglie di prodotti sono state anche le prime soluzioni grafiche compatibili DirectX 10.

 

Sia ATI che Nvidia avevano intuito fin da subito il potenziale di computing delle GPU con architettura a shader unificati, ma è stata Nvidia a compiere il primo e più importante passo rilasciando, contestualmente al lancio della serie GeForce 8, un kit di sviluppo software per applicazioni GPGPU.

 

La maggior parte dei calcoli eseguiti dalle GPU a shader unificati sono del tipo SIMD (Single Instruction Multiple Data), ovvero una singola operazione può essere eseguita su più dati contemporaneamente. E’ lo stesso principio alla base delle istruzioni speciali che equipaggiano le CPU, come MMX (MultiMedia eXtensions) e SSE (Streaming SIMD Extension). Ma una GPU è molto più veloce di una CPU nell’esecuzione di questi compiti, il che ha fin da subito creato una “frattura” tra chi come Intel sostiene che la CPU debba fare sempre di più e meglio e chi invece, Nvidia in primis, sostiene la centralità del ruolo della GPU.

 

Per poter funzionare efficacemente su una GPU i calcoli da eseguire devono poter essere scomposti in una serie di operazioni “parallelizzabili”, ossia da eseguire in parallelo. In questo caso si parla di Stream Computing. Questo significa che non tutti i tipi di operazioni si prestano al GPU Computing. E comunque l’efficacia di esecuzione dipenderà dal livello di esecuzione parallela ottenibile.

 

Ad essere privilegiate per l’esecuzione via GPU sono le applicazioni in campo ingegneristico, oppure in quello della chimica e della biologia, ma anche nelle simulazioni climatiche o sismiche, nell’analisi finanziaria, nella ricerca genetica.

 

Per rendere applicabile GPGPUs i è reso inoltre necessario estendere la programmabilità delle GPU e aumentare la precisione di calcolo nelle pipeline di rendering. Le schede grafiche consumer di Nvidia e AMD sono particolarmente efficaci nell’eseguire calcoli floating point a singola precisione (32 bit). Il floating point a doppia precisione (64 bit) viene eseguito molto più lentamente. AMD con l’ultima generazione degli acceleratori professionali FireStream supporta in hardware il floating point a doppia precisione.

 

ATI Stream e Nvidia CUDA

 

 

Per sfruttare una GPU con applicazioni di GPU Computing servivano in passato applicazioni sviluppate ad hoc con una programmazione diretta del chip. Cosa che presupponeva un alto livello di esperienza e una conoscenza approfondita dell’hardware. Tra i primi esempi troviamo la messa a punto di un client Folding@Home basato su codice GPGPU per schede Radeon, che fin dal 2006 ha dato notevole impulso alla ricerca nel campo del “protein unfolding”.

 

Oggi sia AMD che Nvidia hanno messo a punto dei linguaggi che semplificano notevolmente lo sviluppo di codice GPGPU anche a chi possieda normali conoscenze di programmazione con un linguaggio ad alto livello quale il C. Le GPU in questo modo hanno cominciato ad affermarsi come soluzioni estremamente convenienti di High Performance Computing (HPC) in ambito sia scientifico che accademico.

 

La soluzione Nvidia si chiama CUDA (Compute Unified Device Architecture). CUDA è un engine di computing che fornisce accesso al set di istruzioni nativo e alla memoria della GPU. E’ in grado di interpretare vari linguaggi ad alto livello, dal C a Python, Fortran e Java (attraverso wrapper prodotti da terze parti) e lavora in combinazione con driver compatibili (come le ultime release dei Forceware) e con una scheda grafica GeForce con architettura a shader unificati (quindi a partire dalla serie 8) oppure con un acceleratore dedicato Tesla. Permette quindi di sfruttare appieno e in modo semplice la potenza di elaborazione parallela delle GPU.

 

Il kit di sviluppo CUDA include un compilatore, delle librerie per GPU, un debugger e un profiler e vari esempi di codice sorgente per imparare a programmare in questo linguaggio. Tra il software ottimizzato CUDA troviamo un plugin per il programma di calcolo scientifico Matlab e un plugin per Premiere CS4 dedicato alla compressione/conversione video nei formati HD H.264 chiamato RapiHD e sviluppato da Elemental Technologies.

 

La risposta di AMD a Nvidia CUDA si chiama ATI Stream. Stream è un insieme di tecnologie hardware e software che permettono alle GPU AMD di accelerare – lavorando in congiunzione con la CPU - applicazioni diverse dalla grafica. Il supporto a Stream è stato abilitato lo scorso dicembre con la release 8.12 dei driver ATI Catalyst per le schede ATI Radeon basate su GPU R600 o superiore (quindi a partire dalla serie HD 2000). AMD ha anche reso disponibile un’applicazione ottimizzata Stream, con l’encoder video ATI Avivo, che viene installato con i driver Catalyst ma che al momento funziona solo con Vista a 32 bit e con le schede ATI Radeon serie HD 4000 (quindi i modelli 4600 e 4800).

 

ATI Stream è disponibile per gli sviluppatori sotto forma di un SDK (siamo alla versione 1.3 Beta) scaricabile liberamente dal sito AMD e che comprende il compilatore Brook+ e CAL (Compute Abstraction Layer), ossia la componente che traduce il codice Brook+ in istruzioni eseguibili dalla GPU. Brook+ è una variante per GPU del linguaggio open source Brook, che è analogo al C.

 

Dal lato utente ATI Stream e Nvidia CUDA offrono due approcci molto simili allo stesso problema, ossia semplificare la programmabilità delle GPU in un ottica di GPU Computing, facendo leva su un linguaggio di alto livello molto diffuso come il C. Le due tecnologie però non sono interoperabili. Questo significa che un’applicazione ottimizzata ATI Stream potrà girare solo su hardware AMD, mentre una ottimizzata CUDA potrà girare solo su hardware Nvidia. Si tratta dunque di ottimizzazioni specifiche, con cui l’uno e l’altro produttore tentano di attirare utenti (e supporto degli sviluppatori) verso la propria causa. Nell’attesa che DirectX 11, con la componente DirectX Computing e dall’altra parte OpenCL stabiliscano uno standard per lo sviluppo di applicazioni accelerate via GPU.

 

Al momento questo è limite più grosso alla diffusione del GPU Computing. Ma Nvidia è un passo avanti perché CUDA è disponibile da più tempo e perché le GPU GeForce con architettura a shader unificati integrano anche un’altra tecnologia di GPU Computing, ossia PhysX, che permette l’elaborazione della fisica via GPU, sfruttando le librerie sviluppate da Ageia, società che Nvidia ha acquisito.

 

Il supporto PhysX, così come quello CUDA è integrato direttamente all’interno dei driver Forceware. Al momento l’unica implementazione di rilievo della tecnologia PhysX riguarda il videogioco Mirror’s Edge di Electronic Arts, che eseguito su hardware Nvidia permette la visualizzazione di effetti più realistici e un frame rate sensibilmente superiore.

 

Due approcci differenti

 

 

Se dal punto di vista software, a livello concettuale ATI Stream e Nvidia CUDA sono simili, sul fronte hardware Nvidia e AMD hanno intrapreso la strada della programmabilità delle proprie GPU con approcci architetturalmente differenti. Guardare semplicemente alle specifiche ci dice poco o nulla riguardo al potenziale delle soluzioni sviluppate dall’uno e dall’altro produttore. Ad esempio le schede AMD della famiglia ATI Radeon HD 4000 (basate su GPU R700) hanno ben 800 stream processors. Mentre quelle Nvidia della famiglia Geforce 200 (basate su GPU GT200/GT200b) arrivano ad averne “solo” 240. Detto così sembra che AMD abbia un vantaggio incolmabile sul prodotto Nvidia. In realtà sia la natura che la complessità di queste unità di elaborazione parallele cambia drasticamente. Cambia il modo che i singoli elementi hanno di comunicare tra loro all’interno del chip. E cambia la loro capacità di eseguire certi compiti. Insomma anche se la soluzioni ATI sulla carta sembrerebbe offrire una “granularità” superiore, un potenziale maggiore di elaborazione parallela, in realtà questa cosa non è valida a priori. Perché le due soluzioni non sono immediatamente confrontabili, non come lo sarebbero due processori X86, uno dualcore e l’altro quadcore.

 

L’unica strada che possiamo percorrere nel confrontarle in ambito GPU Computing è di utilizzare il solo software che al momento si avvantaggi dell’elaborazione via GPU su entrambi i prodotti. Si tratta dell’ultima versione di PowerDirector, un software di editing ed elaborazione video di tipo consumer, sviluppato da Cyberlink, che con l’ultima patch - la 2516 - attiva il supporto GPGPU sia per Nvidia CUDA che per ATI Stream.

 

Prodotti testati e procedure

 

 

Per testare l’efficacia di questo software abbiamo scelto due modelli di scheda per ciascuno dei due brand. Un modello mainstream e una versione di fascia alta. Nel caso dei prodotti mainstream la scelta è caduta su ATI Radeon HD 4850 e su Nvidia GeForce 9800GT. Entrambe con un prezzo stimato al pubblico nell’intorno dei 150 euro iva compresa. Per le versioni di fascia alta invece ci siamo orientati su una ATI Radeon HD 4870X2 e una Nvidia GeForce GTX285, il cui prezzo è compreso tra i 350 e i 400 euro al pubblico iva compresa.

 

Come piattaforma per i test abbiamo utilizzato un PC con CPU Intel Core i7 965 Extreme Edition a 3.2GHz e scheda madre Intel DX58SO “SmackOver” in abbinamento a 3GB di RAM Qimonda DDR3-1066 (con latenza 7-7-7-20) configurata in modalità triple channel e a un’unità SSD Intel X25-M da 80GB. Come sistema operativo abbiamo installato Windows Vista Ultimate versione 32 bit SP1 insieme ai vari aggiornamenti presenti su Windows Update e, a seconda della scheda grafica installata agli ultimi driver video di AMD (ATI Catalyst 9.2) e Nvidia (Forceware 182.06 WHQL). Da BIOS abbiamo attivato sia HyperThreading che Turbo Mode.

 

Il sistema così configurato rappresenta il top oggi disponibile in commercio. In questo modo ci siamo assicurati che non ci fossero dei colli di bottiglia nell’esecuzione dei test dovuti alle prestazioni dello storage oppure alla capacità di elaborazione della CPU.

 

I test con PowerDirector sono stati eseguiti sia con accelerazione GPU abilitata, utilizzando le quattro schede in esame, che con accelerazione GPU disabilita, per misurare le prestazioni di conversione utilizzando la CPU Intel Core i7.

 

Oltre a Cyberlink PowerDirector abbiamo poi eseguito dei test con due encoder dedicati, ovvero ATI Avivo Video Encoder e Badaboom Encoder 1.1 di Elemental Technologies. Il primo gira solo su hardware AMD compatibile ATI Stream e solo sotto OS a 32 bit. Il secondo invece gira solo con hardware compatibile Nvidia CUDA. In questo caso per mantenere una certa omogeneità nei confronti abbiamo optato per formati di compressione perlomeno simili tra loro.

 

Partendo da un file VOB (estratto da un DVD) da 1GB di dimensione abbiamo quindi avviato una conversione in formato H.264 MPEG4 con qualità massima su Cyberlink PowerDirector. Discorso analogo con Avivo, dove lo stesso file video di origine è stato convertito in un MPEG4 con qualità massima (da 1GB a 373MB di dimensione). Con Badaboom Encoder il file VOB è stato convertito in formato MPEG4 per iPhone con qualità massima (da 1GB a 215MB di dimensione).

 

I file compressi naturalmente variano tra loro come dimensione e qualità, perché non era possibile rendere perfettamente identici i parametri di output. Per questo motivo i tempi di conversione da un software all’altro vanno considerati come indicativi e non come riferimenti assoluti delle prestazioni di un dato hardware.

 

Nel caso della soluzione ATI Radeon HD 4870X2 va precisato che nessuno dei software testati è stato in grado di avvantaggiarsi della presenza di due GPU. I risultati ottenuti sono quindi paragonabili a quelli di una scheda ATI Radeon HD 4870 a singola GPU.

 

Accelerate via GPU certe applicazioni “volano”

 

 

Nel guardare a questi test sono due le cose da considerare. Innanzitutto il supporto al GPU Computing in PowerDirector è da affinare. Del resto si tratta della prima applicazione che si spinge fino a sfruttare sia CUDA che Stream. Quindi passibile di miglioramenti. Seconda cosa, i risultati da noi proposti (in termini di incrementi prestazionali ottenibili) non vanno intesi in senso assoluto ma solo limitatamente a questo specifico caso, ovvero la compressione/conversione di video. Come dicevamo prima le GPU sono dei supercomputer “specializzati”. Per loro stessa natura possono essere velocissime a svolgere certi compiti ma lente su altri. Non sono sostituibili in tutto e per tutto alle CPU. Ci sono quindi alcune operazioni che si prestano ad essere accelerate da una GPU e altre che resteranno sempre dominio delle CPU. Così come tra le operazioni “GPU oriented”, ci saranno alcuni ambiti che privilegeranno l’architettura di Nvidia e altri invece che saranno più favorevoli all’approccio ATI. I risultati di questo nostro primo test sono quindi puramente indicativi. Un “assaggio” di ciò che è possibile ottenere oggi utilizzando una scheda grafica per compiti diversi dall’elaborazione grafica e nello specifico per rendering di effetti o compressioni di video. Con applicazioni differenti i risultati relativi tra ATI ed Nvidia potrebbero variare anche di molto. Ci riserveremo quindi in futuro di effettuare altri test su questo interessantissimo ambito di applicazione delle tecnologie grafiche, mano a mano che si renderanno disponibili nuovi software ottimizzati sia per CUDA che per Stream. Ad esempio Kaspersky sta sviluppando una soluzione antivirus chiamata SafeStream, che utilizza l’accelerazione via GPU per la scansione rapida senza gravare sulla CPU. Mentre Elcomsoft ha realizzato dei software per la decodifica di password e l’auditing di reti Wifi che utilizzano la GPU per algoritmi di decrittazione. Ma non è che l’inizio.

 

A partire dall’autunno infatti il confronto tra architetture di GPU si sposterà su un terreno comune con l’arrivo di DirectX Computing, la componente GPGPU di DirectX 11 che verrà introdotta insieme a Windows 7 (ma che diversamente da DirectX 10 sarà compatibile anche l’OS immediatamente precedente, in questo caso l’attuale Windows Vista). Mentre un approccio alternativo di GPU Computing tramite API standard verrà offerto da OpenCL. Entrambe queste API saranno supportate dai framework CUDA e Stream. A quel punto il GPU Computing troverà forse i presupposti che gli mancano oggi per affermarsi come tecnologia a larga diffusione.

 

Ultima revisione: .: ErmaC :. 30 Luglio 2010