La scorsa settimana AMD ha dato il via a un lento processo di divulgazione di informazioni che ci porterà al debutto della sua prossima architettura grafica. In "GPU AMD del 2016: HDR, FreeSync tramite HDMI e nuovi standard" abbiamo illustrato i piani dell'azienda per implementare il supporto a DisplayPort 1.3 e HDMI 2.0a, espandere la disponibilità di FreeSync tramite l'HDMI e il modo in cui intende riprodurre contenuti HDR tramite la sua display pipeline. Quanto vi spiegheremo oggi è meno interessante per gli appassionati di PC, ma probabilmente è più importante per le prospettive a lungo termine di AMD, in quanto riguarda il modo in cui gli sviluppatori interagiscono con l'hardware.
Arriva GPUOpen
Sia AMD che Nvidia affermano di avere il polso dello sviluppo software e attirano regolarmente i membri della comunità disposti a sostenere le rispettive filosofie. Ne consegue quindi che le due aziende tendono a propagandare un modus operandi piuttosto che un altro. Nvidia ama puntare sui vantaggi di un middleware pronto da integrare, ottimizzato per il suo hardware ma di natura proprietaria, spesso causando problemi alla concorrenza. Al contrario AMD tiene alta la bandiera dell'open source, promuovendo l'accessibilità e i benefici della collaborazione. Secondo l'azienda è quello che vogliono maggiormente gli sviluppatori.
A detta di Nicolas Thibieroz, senior manager dell'ISV engineering team del Radeon Technology Group, il porting dei giochi tra console e PC è una delle sfide maggiori per gli sviluppatori. Così, per facilitare lo sviluppo cross-platform, AMD ha deciso di risolvere alcuni dei problemi emersi.
Nicolas ha identificato due problemi principali che frenano i progressi: accesso limitato alla GPU stessa ed effetti, strumenti, librerie e SDK chiusi. Nvidia si è occupata del primo aspetto con la sua NVAPI, che trascende lo scopo di DirectX e OpenGL per dare un controllo più diretto sul sottosistema grafico. Il secondo punto citato da AMD è invece incarnato dal programma Nvidia GameWorks.
La risposta di AMD si chiama GPUOpen ed è, in un certo senso, una continuazione del lavoro svolto con l'API Mantle. Lanciando una frecciata a Nvidia, Thibieroz ha affermato che GPUOpen include effettivi visivi, utility driver, strumenti per la risoluzione di problemi, librerie e SDK completamente open source. L'idea è che gli sviluppatori abbiano accesso a livello di codice agli effetti che usano, alla possibilità di fare modifiche e possano condividere il loro lavoro. AMD, implicitamente, beneficerà dei miglioramenti fatti nel corso del tempo.
GPUOpen sarà accessibile da un portale online con collegamenti a contenuti open source, post scritti dallo staff di AMD e da ospiti e aggiornamenti industriali. Tutto il codice sarà ospitato su GitHub, con tutti i benefici legati alla funzione collaborativa del sito.
Quando GPUOpen arriverò, questo gennaio, offrirà l'accesso a TressFX 3.0, GeometryFX, AOFX, ShadowFX, una manciata di strumenti, LiquidVR SDK, code sample in DirectX 11 e 12, strumenti legati al calcolo e diversi altri SDK. Tutto il software disponibile tramite GPUOpen sarà fornito senza restrizione sotto MIT License.
Espandere GPUOpen al mondo del calcolo
Lo scorso novembre AMD ha annunciato la Boltzmann Initiative, che include un driver Linux headless a 64 bit pensato per il mercato HPC, un compilatore per il calcolo eterogeneo destinato allo stesso settore e un insieme di strumenti per convertire il codice CUDA in portable C++.
AMD ha riconosciuto che in passato prendeva il suo driver grafico e lo "rimpacchettava" per l'uso nell'ambito server HPC, creando una soluzione di calcolo funzionante ma non interamente ottimizzata. Ora sta riprogettando il driver, togliendo enfasi dalla pipeline grafica e occupandosi maggiormente della latenza.
Allo stesso tempo il driver Boltzmann attiva un superset dello standard HSA ufficiale. Gran parte del colloquio che abbiamo avuto con AMD sul calcolo ha riguardato le sue APU. L'azienda, tuttavia, è più concentrata sull'abilitazione di HSA sulle schede video dedicate (specialmente le FirePro), un must se vuole guadagnare terreno sull'ecosistema di Nvidia.
È importante che AMD ottimizzi per le sue GPU dedicate per il calcolo, ma senza il supporto dagli sviluppatori l'azienda sa che non può fare breccia. OpenCL è notoriamente complicato, perciò AMD voleva uno strumento più accessibile per programmare i suoi processori grafici e centrali.
L'Heterogeneous Compute Compiler open source si affida a C++, quindi è di livello più alto rispetto allo scrivere per OpenCL. E con l'evoluzione di C++, l'HCC incorporerà gli ultimi standard. Contiene già una prima implementazione di una caratteristica chiamata Parallel STL per parallelizzare l'esecuzione tra le risorse disponibili.
Infine, AMD renderà possibile la conversione del codice CUDA in portable C++ tramite HIP, ossia Heterogeneous-compute Interface for Portability. Le potenziali implicazioni di HIP sono enorme, in quanto gli sviluppatori che hanno già familiarità con CUDA possono estendere il loro lavoro all'hardware AMD in modo piuttosto indolore. L'approccio aperto di AMD offre una via d'uscita dall'ecosistema proprietario di Nvidia, anche se l'azienda sta pensando di concedere in licenza il proprio software.
Abbiamo chiesto all'AMD senior fellow Ben Sander se vi siano implicazioni legali nel facilitare la traduzione del codice CUDA e ci ha assicurato che le capacità HIP sono basate su documentazione pubblicamente disponibile; l'API CUDA non è implementata in alcun modo. Non c'è nemmeno una perdita prestazionale anche se qualsiasi specifica ottimizzazione per registri o cache dell'architettura Nvidia andrà rivisitata.
Tutto questo è stato introdotto all'SC15 di Austin, Texas. Al recente technology summit di Sonoma AMD è entrata in maggiore dettaglio sullo stack software, incluso quello che chiama Lightning, il precedentemente descritto driver Boltzmann e il driver kernel AMDGPU (evidenziato in giallo nello schema sopra). Il compilatore Lightning è responsabile per la generazione del codice della GPU fino ad arrivare a ISA - una manna, secondo AMD, rispetto alle soluzioni che passano attraverso linguaggi intermedi.
Il compilatore e i driver hanno in comune l'accessibilità open source. Per illustrare la potenza collaborativa AMD ha mostrato un esempio di un errore in NVCC di Nvidia e nel suo HCC. Un refuso ha impedito al code snippet di essere compilato. NVCC ha identificato il problema lasciando allo sviluppatore il compito di capire cos'era andato storto. Poiché HCC usa il compilatore front-end open source Clang, che ha il suo controllo ortografico, è andanto un passo oltre suggerendo come risolvere il problema.
È chiaro che molti sviluppatori potrebbero beneficiare della natura open source di questi strumenti. Per estensione le applicazioni scritte potranno essere ottimizzate meglio, portando a migliori prestazioni. C'è anche un elemento, la trasparenza, che secondo AMD è importante per determinati clienti nel settore HPC. L'accesso al codice può essere utile per verificare la sicurezza e risolvere bug.
AMDGPU: ripensare l'approccio di AMD a Linux
AMD ha anche discusso i cambiamenti in corso nel suo approccio a Linux, dai mercati client ed embedded fino a quello HPC. La base della sua strategia è AMDGPU, un driver kernel base che supporta tutte le GPU/APU 2015 di AMD. Uno dei suoi scopi, secondo il senior fellow Christopher Smith, è offrire un supporto più ampio alle distribuzioni Linux. Una versione totalmente validata del driver è già integrata in Ubuntu e Fedora. AMD sta anche lavorando per accelerare l'accesso ai prodotti e alle caratteristiche affinché al debutto del nuovo hardware questo sia già supportato. È qualcosa che l'azienda dice sia particolarmente difficile quando si lavora con uno stack Linux proprietario.
Attualmente AMD offre un driver Radeon open source e un driver Catalyst closed source, entrambi basati su driver kernel-mode separati. Smith ha affermato che AMDGPU consolida i loro vantaggi, permettendo driver user-mode closed e open source che vi girino al di sopra. Il grafico sopra illustra come apparirà il tutto rispetto al modello precedente di AMD. All'estrema sinistra avete l'opzione "tutta aperta" con una base AMDGPU, driver user-mode open source costruito in Mesa, e il kernel e runtime HSA, disponibile upstream come un package integrato alle distribuzioni. La versione rivolta a professionisti e giocatori parte con la stessa base AMDGPU, incorpora UMD sia closed che open source e offrirà probabilmente anche driver open OpenGL e Vulkan.
C'è ancora molto da scoprire
Siamo abbastanza certi che la prossima infornata di notizie da AMD ci avvicinerà a una migliore comprensione di quello che sarà il nuovo hardware. Per ora, i riflettori sono puntati su GPUOpen, l'iniziativa dell'azienda per accelerare lo sviluppo cross-platform dei giochi, a cui si aggiunge un nuovo focus sulla propria strategia Linux. L'iniziativa dovrebbe aiutare AMD a sfruttare meglio il proprio hardware e puntellare altri angoli del suo portafoglio che necessitano di rinforzi. La cosa interessante, naturalmente, è che un investimento iniziale in open source paga il dividendo più tardi, quando la comunità è più coinvolta. Serviranno mesi prima di iniziare a vedere i prodotti degli annunci di oggi? Anni? Come tante iniziative in passato dovremo aspettare per valutare l'impatto di GPUOpen.
 |
Radeon R9 390 8 GB | |
 |
Radeon R9 380X 4 GB | |
 |
AMD FX-6300 |