AMD Asynchronous Shaders: più efficienza alle GPU

Le GPU AMD basate su architettura Graphics Core Next implementano il supporto agli asynchronous shaders, grazie ai quali ottenere una superiore efficienza nella gestione dei vari comandi ai quali la GPU è chiamata per disegnare le scene 3D. Una importante componente per guadagnare efficienza, soprattutto nell'ottica dei visori per la realtà virtuale
di Paolo Corsini pubblicato il 31 Marzo 2015 nel canale Schede VideoAMDRadeon
Asynchronous Shaders
La disponibilità delle APU DirectX 12, inserite nel sistema operativo Microsoft Windows 10 e per questo motivo attese al debutto nel corso dell'estate, permetterà di ottenere interessanti incrementi prestazionali grazie ad una più efficiente gestione della GPU pipeline rispetto a quanto registrato con le API DirectX 11. Quello che le API DirectX 12 promettono è di fatto quanto AMD ha mostrato di poter ottenere con Mantle, e che in parallelo troveremo anche nella nuova versione di API OpenGL indicate con il nome di Vulkan.
Grazie ad una più efficiente gestione dei processi grafici che chiamano in causa la CPU per eseguire le elaborazioni richieste i tempi di rendering si riducono: aumentano quindi i frames al secondo che vengono generati mentre diminuisce la latenza di accesso. In questo modo è possibile ottenere, a parità di GPU utilizzata, una migliore scalabilità complessiva delle prestazioni soprattutto nel momento in cui il processore utilizzato dal sistema ha architettura multicore.
Un approccio non sincrono ma asincrono alla gestione delle operazioni richieste ad una GPU per elaborare le scene 3D prevede che i vari tasks presenti nelle differenti code di elaborazione possano venir schedulati in modo indipendente, ad esempio in questo modo:
- coda grafica per le operazioni di rendering;
- coda di calcolo per tutte le operazioni di supporto alle elaborazioni della GPU come la gestione della fisica, l'illuminazione della scena e il post processing
- coda di copia per i semplici trasferimenti di dati.
Le varie operazioni richieste al sistema per elaborare una scena grafica vengono quindi gestite in code di lavoro, che in un'ottica di sfruttamento ottimale devono venir eseguite quanto più possibile in parallelo. A questo risultato si può arrivare con un approccio multi-threaded, con il quale i task provenienti da differenti code vengono inviati all'elaborazione: questo però non solo porta ad una aumentata complessità ma può anche generare un collo di bottiglia quando si opera con GPU che possono processare solo un command stream alla volta. Manca inoltre un processo che dia una qualche forma di priorità a quei task che sono più importanti di altri ai fini dell'elaborazione complessiva.
Un approccio cosiddetto di pre-emption permette di dare priorità ad alcuni tasks rispetto ad altri: in questo modo i task ad alta priorità vengono eseguiti prima, lasciando in attesa quelli con un livello di priorità inferiore. Rispetto all'approccio multi-threaded non si ottiene un reale incremento dell'efficienza, in quanto la gestione dei tasks con differenti livelli di priorità può portare a dei colli di bottiglia prestazionali in presenza di continue richieste di switch tra i task.
L'approccio più efficiente, secondo AMD, è quello di sfruttare gli asynchronous shaders, grazie ai quali possono venir processati più command streams in parallelo arrivando ad un più efficiente sfruttamento delle risorse di sistema. In questo caso ogni coda può inviare comandi senza dover attendere che altri tasks vengano completati, comandi che vengono inviati agli shader engine della GPU e da questi eseguiti immediatamente e in modo simultaneo.
AMD ha implementato nelle proprie GPU appartenenti alla famiglia Graphics Core Next gli ACE, Asynchronous Compute Engines, che operano in parallelo con il graphics command processor. Possono gestire in modo indipendente lo scheduling e l'esecuzione di differenti tipologie di operazioni grafiche, operando in modo tale da massimizzare i task paralleli e così facendo ottenere la massima efficienza possibile. A seconda del tipo di GPU AMD che viene presa come riferimento possiamo trovare sino a 8 ACE, ciascuno dei quali è in grado di gestire sino ad un massimo di 8 code mantenendo accesso diretto alla cache L2 della GPU e alla Global Data Share.
L'utilizzo degli asynchronous shaders si rivela essere particolarmente utile in abbinamento ai visori per la realtà virtuale, in quanto permettono di eseguire il processamento dell'immagine VR in parallelo con il rendering riducendo la latenza e eliminando i fenomeni di stuttering e judder che penalizzano l'esperienza di visione. Questi shader sono inoltre molto utili per sfruttare alcune delle differenti tecniche VR come quelle di asynchronous image warping, time warp e global illumination.
AMD ha fornito alcuni test pratici ottenuti utilizzando le SDK LiquidVR: la risultante è un netto incremento della qualità di immagine finale di fatto con una penalizzazione prestazionale molto più contenuta rispetto a quella registrata disabilitando gli asynchronous shaders. Lo scenario che si apre è quindi quello di un mantenimento delle prestazioni velocistiche in presenza di un sensibile aumento della qualità d'immagine: la potenza di elaborazione degli asynchronous shaders viene quindi sfruttata in questa direzione.
Per AMD l'utilizzo di asynchronous shaders rappresenta una importante innovazione rispetto a quanto ottenibile al momento: grazie all'incrementata efficienza aumentano i frames al secondo medi e si riduce la latenza, con benefici diretti sia per la tradizionale grafica videoludica sia, e soprattutto aggiungiamo, per l'utilizzo di sistemi di realtà virtuale.
Resta ora da capire in che modo, quanto rapidamente e con quali ricadute sul mercato si svilupperanno i visori per la realtà virtuale. Al momento attuale siamo ancora a prodotti che sono nella fase di prototipi e che si apprestano a fare il primo, per certi versi pioneristico, debutto sul mercato. Se sarà questa la tecnologia in grado di rivoluzionare nuovamente il mercato dei PC legato ai videogiochi è quanto i produttori di tecnologia si attendono, e per molti versi sperano, ma solo il tempo saprà dare loro ragione o meno.
31 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infopiù probabile che mantle abbia cercato di anticipare dx12 scimmiottando le feature delle dx12
è cosi innovativo mantle che l'amd ha deciso di bloccarlo come progetto ....
PS : ma tutto il reparto R&D di amd è impiegato a fare slide sempre migliori
Che lavorino basandosi sugli stessi principi e obiettivi siamo d'accordo.. ma che DX12 sia venuto fuori da mantle proprio lo escluderei.
Una libreria del genere non salta mica fuori in una settimana, probabilmente ci stanno smanettando su da ANNI. Non è che hanno visto mantle e sono corsi a fare le DX12.
Chissà però quanto tempo ci metteranno...
ma il nuovo ceo che fa? prosegue sulla strada di rory read? si vede che se ne andrà anche lei tra 2 anni per prendersi qualche milioncino di liquidazione...
Una libreria del genere non salta mica fuori in una settimana, probabilmente ci stanno smanettando su da ANNI. Non è che hanno visto mantle e sono corsi a fare le DX12.
No, infatti. Le dx12 non sono altro che mantle con un nome diverso,figlio di un accordo di 4 mesi fa tra amd e Microsoft.
Magari capiremo qualcosa di più quando sarà possibile svolgere più test.
Ok, va benissimo.
Allora diciamo che le MANTLE e le DX12 sono "gemelli diversi" perchè semplicmente MS ed AMD hanno lavorato congiuntamente alla loro creazione.
Quindi il fatto che AMD abbi presentato prima il suo sistema "proprietario" e poi MS il suo equivalente "universale" è stato un puro gioco di tempistiche.
Ma non è che uno ha copiato l'altro o simili..
Non capisco perchè definisci mantle "proprietario" e DX12 "universale"
Sono entrambe proprietarie, anzi volendo ben vedere mantle è proprietario ma freeware e chiunque può usarlo, inoltre è stato annunciato anche per linux.
DX12 è solo windows e chiuso.
Hai ragione, mi sono espresso male.
Intendevo dire che mantle funziona esclusivamente con schede AMD.. in questo senso "proprietario".
Mentre invece DX12 è per tutte le schede.. come è giusto che sia.
Certo, se DX12 fosse open e freeware sarebbe bello davvero..
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".