Raggiungere l’irrangiungibile

Le specifiche su come Lucid è in grado di far lavorare assieme GPU di differente potenza e stesso marchio e GPU di differenti marchi sono legate agli algoritmi di bilanciamento del carico dell’azienda.

C’è una ragione per cui ATI e Nvidia vogliono che abbiniate schede grafiche simili per lavorare in coppia.

ATI supporta tre differenti modalità di visualizzazione in modalità CrossFire: alternate frame rendering, dove una GPU si occupa dei frame pari e l’altra di quelli dispari, supertiling mode, che divide lo schermo in sezioni da 32×32 pixel per poi essere renderizzate alternativamente da ogni GPU, e scissor mode, dove lo schermo è diviso in due, una parte è renderizzata dalla GPU 1 e l’altra dalla GPU 2. ATI stessa ammette che la modalità scissor non è così efficiente come le altre tecniche, ma lavora meglio con i titoli OpenGL. Ovviamente, il supertiling e la scissor sono tecniche del CrossFire, poiché ATI stessa suggerisce di programmare con la modalità di alternate frame rendering in mente. Per questo, molte della applicazioni che funzionano in CrossFire sono ottimizzate per questa modalità .

Nvidia supporta due modalità : split-frame rendering e alternate frame rendering. La prima funziona come la modalità scissor di ATI, dividendo i frame e il carico di lavoro in due pezzi. Anche in questo caso, l’efficienza è inferiore. Alternate frame rendering funziona come nel caso di ATI, una scheda si occupa dei frame pari e l’altra di quelli dispari.

Il problema con le modalità split-frame e scissor è che, mentre aiutano ad alleviare il carico di pixel processing, ogni GPU deve immagazzinare l’intero frame in memoria, quindi i calcoli geometry e il bandwidth della memoria non vengono alleviati dal carico, quindi non si migliora l’efficienza. Inoltre, il tiling è afflitto negativamente dalle dipendenze inter-frame, come gli obiettivi del rendering nei frame seguenti.

Come risultato, AFR è la modalità più usata. È quindi chiaro che è meglio avere due GPU della stessa potenza che lavorano, alternativamente, sui i vari frame. Anche in questo caso, può però accadere che il rendering di un frame necessiti di qualche millisecondo in più rispetto a quello precedente, comportamento che porta all’insorgere di artefatti a cui ci si riferisce con il termine di micro-stuttering. Anche se meno percepibile ad alte velocità , è inevitabile capire se una configurazione CrossFire o SLI può cadere o meno in questo effetto. Su questa questione ci torneremo a breve.

Lucid pone alcuni requisiti base per il corretto funzionamento di Hydra: deve permettere l’uso di GPU non identiche, agevolare la scalabilità con più di una scheda installata, eliminare la necessità di un connettore esterno tra due schede. Grazie a questi chiari obiettivi autoimposti dall’azienda, per noi è abbastanza semplice valutare lo stato evolutivo di questa tecnologia.

Secondo Lucid, il suo motore Hydra è in grado di intercettare le chiamate DirectX/OpenGL e, anziché usare una modalità come l’AFR per dividere i carichi di lavoro, rompe ogni frame in task. Un task può essere, per esempio, un oggetto 3D; sarà poi il motore a determinare quale tecnica di rendering usare. Questi task sono distribuiti alle GPU installate (al momento il supporto è per due GPU) tramite il driver del produttore (che non è consapevole della presenza del software Lucid, poiché Hydra implementa la Device Driver Interface standard di Windows 7). I task completati sono poi inviati nuovamente a quello che Lucid chiama "layer interoperativo", dove il frame è composto e inviato alla GPU a cui è collegato lo schermo.

Per rendere questo processo dinamico – e con questo intendiamo la capacità di supportare GPU differenti – Hydra implementa un meccanismo di risposta che valuta le prestazioni dell’hardware grafico installato in tempo reale e regola i carichi di conseguenza. In teoria, la tecnologia Lucid evita così il problema del micro-stuttering dell’alternate frame rendering e risolve le dipendenze inter-frame che penalizzano lo split-frame rendering.