AMD LiquidVR e NVIDIA VRWorks: quali sono le differenze?

Uno degli aspetti chiave dell'esperienza con la realtà virtuale è quello di fornire una bassa latenza ed una frequenza d'aggiornamento del visore adeguata. Concettualmente la VR non è un'idea così nuova, visto che il suo sviluppo prosegue da decenni, ma tecnologie arretrate e prezzi elevati non gli hanno permesso di emergere. La qualità grafica e le tecnologie a disposizione degli sviluppatori sono cresciute tantissimo e ad oggi possono offrire un ottimo supporto alla virtual reality, seppur con qualche compromesso ancora presente.
Fra tutte le aziende coinvolte nel settore della VR non potevano di certo mancare AMD e NVIDIA, che con le loro GPU saranno determinanti per offrire le giuste prestazioni ai visori. Entrambe hanno proposto i loro SDK (Software Development Kit) al fine di aiutare gli sviluppatori a sfornare applicazioni di qualità superiore. Per AMD abbiamo LiquidVR, per NVIDIA c'è invece VRWorks. Ognuno dei due ha obiettivi specifici, supportati da determinate librerie e set di funzioni utilizzabili. Ma quali sono le differenze fra i due?

AMD LiquidVR

AMD LiquidVR fa parte dell'iniziativa GPUOpen della società di Sunnyvale: questo vuol dire che il suo codice è presente su GitHub ed è quindi liberamente utilizzabile ed editabile. L'SDK per le Radeon è composto da quattro componenti principali, di cui il più importante è senza dubbio l'Asynchronous Compute Engine (ACE). Esso fu introdotto con la prima versione di Graphics Core Next (GCN) a fine 2011, e fornisce gli async shader che addizionano al mix più flessibilità alla coda dei comandi. Molte schede grafiche trattano le istruzioni di calcolo e grafiche separatamente, ma ACE consente agli sviluppatori di far girare le due tipologie di codice nella stessa coda. Quando fu introdotto ACE non ebbe molto seguito, perché era solo un metodo per rendere efficienti le Compute Unit delle Radeon, e solo oggi ACE è diventato effettivamente utile. Il design GCN impiega uno scheduler in order, cioè con una serie di passi ben definiti, ma gli async shader possono rendere il tutto più dinamico se necessario. Ciò va anche direttamente a vantaggio delle nuove librerie grafiche, DirectX 12 e Vulkan, che possono diventare più elastiche. Senza ACE gli scheduler sarebbero costretti a cambiare contesto ogni volta che si rende necessario effettuare un passaggio da un'istruzione di calcolo ad una grafica (o viceversa), generando decisamente più overhead. Per effettuare tale switching, ad esempio, c'è il bisogno di salvare tutta una serie di informazioni, effettuare il cambio e poi ripristinare lo stato originale. Queste sono tutte operazioni che con ACE si risparmiano, il che si traduce direttamente in maggiori cicli a disposizione per il chip grafico.

Uno degli aspetti che maggiormente beneficia degli async shader è l'Asynchronous Time Warp (ATW). Questa è una tecnica per abbassare la latenza di rendering dei frame e ridurre l'effetto nausea e in generale il motion sickness. Se c'è troppa latenza un'istantanea potrebbe essere ripetuta, ed ATW fa in modo di "spostare" l'ultimo frame sulla scena in maniera tale che non venga percepito questo effetto. In sostanza, se un determinato frame non è pronto, allora vengono trasferiti spazialmente i frame già calcolati, così che l'utente possa sempre percepire un'esperienza fluida e latenza bassa. Gli sviluppatori affermano che il warping sia una caratteristica che tutti i visori e gli SDK dovrebbero implementare. ATW è un processo grafico che può essere, grazie ad ACE, schedulato insieme a tutti gli altri task, poco importa di che tipologia essi siano.
Latest Data Latch è invece una tecnica molto legata ad ATW, e serve per ridurre la cosiddetta latenza motion-to-photon. In altri termini, essa diminuisce il tempo che intercorre tra il movimento della testa dell'utente e la visualizzazione sul display. Il rendering su un HMD avviene con una collaborazione fra CPU e GPU, la quale deve aspettare alcuni dati dalla prima. Latest Data Latch lascia che la scheda grafica non abbia più bisogno del processore, almeno per gran parte del lavoro.

LiquidVR Direct-To-Display è invece una feature molto semplice: evita che il sistema operativo possa interrompere l'esperienza ponendo in foreground le notifiche, come ad esempio quelle relative agli aggiornamenti.
Infine abbiamo Affinity Multi-GPU, che ha l'obiettivo di migliorare le performance dei sistemi CrossFire. Uno dei maggiori problemi della VR su sistemi a più schede grafiche è che l'AFR (Alternate Frame Rendering) è una tecnica vecchia e che risulta del tutto inadeguata per questa applicazione, in quanto introduce tanta latenza. Affinity Multi-GPU abbatte questa problematica assegnando una scheda grafica ad ogni occhio, sfruttando l'SFR (Split Frame Rendering) anziché l'AFR. Le prestazioni ne beneficiano sicuramente, anche se non è chiaro quale sarà il fattore di scaling oppure quali saranno le prestazioni con tre o quattro schede video.

NVIDIA VRWorks

NVIDIA VRWorks offre tante tecniche simili al suo rivale LiquidVR. Il software development kit dell'azienda di Santa Clara mostra cinque tecnologie chiave, anziché le quattro della variante AMD, più altre che sono esplicitamente riferite al campo professionale e quindi alle schede Quadro.
La prima caratteristica è VR SLI, che è molto simile ad Affinity Multi-GPU: abbiamo due schede grafiche ed ognuna è assegnata ad un occhio, per raddoppiare teoricamente le performance. Anche qui viene impiegato l'SFR e non l'AFR per abbassare al minimo possibile la latenza. L'applicazione genera un solo flusso di comandi e sta poi ad una maschera dell'SDK indirizzare l'istruzione apposita ad una determinata scheda grafica. Per lavorare, VR SLI deve essere integrato nell'engine di gioco e sta agli sviluppatori decidere se implementare o meno il sistema. Direct Mode e Front Buffer Rendering sono invece affini ad AMD Direct-To-Display. La tecnica NVIDIA non consente al sistema operativo di sovrapporre finestre al gioco o di tornare al desktop, con il risultato di una migliore user experience.
Il quarto elemento di VRWorks è Context Priority, la funzionalità di warping di casa NVIDIA. Gli async shader di AMD permettono ad ATW di essere schedulato insieme alle istruzioni grafiche, mentre su hardware NVIDIA ciò non è attivato. Questo vuol dire che le GTX effettuano il context switching, anche se la casa madre ha affermato di aver introdotto un metodo particolare che non introduce troppi ritardi. Non abbiamo ancora i dettagli tecnici dell'implementazione, ma sappiamo che Context Priority abilita due code: una a priorità normale che gestisce le normali operazioni di rendering, e un'altra ad alta priorità che invece può essere utilizzata per ATW. La seconda coda ha la facoltà di sovrapporsi a tutto il resto quando c'è bisogno, e di farlo con una velocità elevata, con un tempo inferiore al millisecondo.

L'ultimo modulo di NVIDIA VRWorks è Multi-Resolution Shading, una caratteristica che non trova alcun riscontro nell'SDK di AMD. E' una feature implementata con l'architettura Maxwell, ed è stata mostrata per la prima volta lo scorso anno alla GDC 2015. Essa è una tecnica molto intelligente, che sfrutta una delle peculiarità della realtà virtuale. Tramite Multi-Resolution Shading si taglia ai bordi l'area da renderizzare, calcolando meno pixel. E' un po' come se stessimo passando dal carico del QHD a quello del Full HD. Non si perde alcun dettaglio visivo, poiché semplicemente l'area agli estremi non può essere "vista" attraverso le lenti di un HMD. Questo va a tutto beneficio delle prestazioni, che salgono dal 30 al 50% a seconda delle circostanze.

Quindi, quale dei due è meglio?

Mettendo tutti i pezzi insieme, non c'è un vero vincitore fra i due. Non esistono attualmente tecniche che dovrebbero far propendere gli sviluppatori per l'uno o per l'altro software development kit. Sia Oculus che HTC/Valve stanno comunque lavorando a stretto contatto con NVIDIA ed AMD. Rift, per esempio, può attualmente sfruttare Direct Mode e Context Priority da un lato, Direct-To-Display ed Async Shaders dall'altro. Oculus ha addirittura implementato una propria tecnica per il timewarping, ma non ha mai parlato del supporto al Multi-GPU con VR SLI o Affinity Multi-GPU. HTC e Valve stanno lavorando in modo simile ad Oculus, seppur oggigiorno non c'è ancora nessuna notizia in merito al timewarping. Vive, però, sfrutta delle tecniche che scalano l'immagine dinamicamente al fine di mantenere i 90 frame per secondo, quindi l'assenza del timewarp potrebbe poi non essere un problema così grosso. Infine, anche sul visore di HTC non c'è traccia della compatibilità con le GPU parallele sfruttando SFR, anche se nel test VR rilasciato da Steam - ovvero SteamVR Performance Test - le cose sono diverse: su quest'ultimo lavora bene un 2-way SLI o un CrossFire a due schede, ed è un ottimo indizio che potrebbe indicare un supporto a breve.