In questi giorni sono comparse diverse notizie (qui quella di LinusTechTips) relative alla possibilità di sfruttare con le DirecX 12 combinazioni ibride di GPU di AMD e nVidia o, detto più simpaticamente, di sfruttare le schede delle due case in modalità CrossSLI o SLIFire.

A livello teorico il multi-gpu eterogeneo è già ora possibile, ma è ostacolato a livello tecnico. Con le DirectX 12 un bel po' di barriere tecniche dovrebbero cadere, ma la visione che se ne vuole dare attraverso questi articoli sensazionalistici è puramente utopica.

Detto questo, attualmente con le DirectX 12 si può parlare di multi-gpu ASINCRONO: la GPU primaria - la più performante - viene usata per il rendering principale e macina più output possibili (a meno che non vi sia il vsync abilitato), mentre l'altra GPU, la secondaria (discreta o dedicata che sia), potrebbe essere usata per calcoli dove non è richiesto un output continuo (calcoli di background, non per forza correlati alla grafica) o che non richiedono una frequenza di output elevata. Nel migliore dei casi, un giorno potremo vedere una GPU secondaria usata per accelerare i calcoli di un motore fisico, dato che questo solitamente richiede tra i 15 e i 30 frame al secondo di aggiornamento (negli altri output di rendering il tutto viene interpolato via software). Si tratta, in generale, di un parallelismo di cui AMD ci ha dato una assaggio quando ha parlato della possibilità di utilizzare la iGPU di Kaveri per accelerare la fisica dei videogiochi.

In ultimo, il Ray Tracing ha una complessità che lo rende impraticabile per un utilizzo di GPU ibride, come parità di dettaglio e complessità di scena, a tutte le altre tecniche utilizzate. In conclusione, non vedremo mai una R9 390X leggere e scrivere sul pool di memoria di una GTX 980, o viceversa.

proseguendo, il multi-GPU eterogeneo per il rendering sincronizzato (es: AFR), infatti, è reso impraticabile dalle diverse ABI delle GPU, dai driver legati alle singole architetture e dalle architetture hardware interne stesse.
Nel caso si volesse far lavorare le configurazioni ibride come in questi giorni si sta affermando, per prima cosa si dovrebbero utilizzare solo le capacità e le funzionalità comuni alle varie schede (in poche parole, si utilizzerebbe solo un minimo comune denominatore, con conseguente perdita delle funzionalità avanzate). Certo, non è una cosa drammatica, ma sarebbe seccante per uno sviluppatore.
I problemi veri, comunque, risiedono nei driver e nelle ABI delle varie GPU: solo un pazzo potrebbe credere che i vari IHV si possano mettere al tavolo per discutere di come far convivere ABI e driver diversi; passare poi dalla teoria alla pratica diverrebbe ancor più comico nonché impraticabile a livello di risorse (sarebbe un lavoro immane e continuo), e comporterebbe sicuramente ad un overhead sostanzioso (overhead che oggi si sta cercando di ridurre il più possibile).

Quel che D3D12 permetterà realmente di fare nel multi-gpu parallelo con configurazioni Crossfire/SLI tradizionali è il superamento dell'AFR, offrendo l'opportunità di utilizzare tecniche già abbozzate anni addietro ma di difficile implementazione, in quanto l'API e la complessità dei driver (per come le conosciamo oggi) non permettevano un controllo diretto sulle risorse. Ma da qui ad andare a dire che una GTX 980 scriverà su, ed in base ai dati di una R9 290X, significa o scrivere per il piacere di disinformare o non capire nulla di programmazione.

Pubblicato in: NewsHardware
Tags: amd , crosssli , directx12 , multi gpu , nvidia , slifire

Autore: Alessio Tommasini
Esperto in: Programmazione, gaming, Windows

Ancora studente di informatica è appassionato di videogiochi, assemblaggio di PC e programmazione 3D tramite DirectX. Esperto di sistemi operativi Windows, videogames e periferiche.

51 news	6 articoli

Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.