TH: siete sicuramente in contatto costante con i produttori di hardware. Cosa chiedi alla prossma generazione di GPU per renderti il lavoro più facile?
Johan: è una bella domanda. Abbiamo una lista abbastanza lunga di cose su cui stiamo lavorando e comunichiamo ai produttori, ma una delle cose che mi piacerebbe vedere e che Intel ha già implementato è PixelSync, il loro metodo per sincronizzare la pipeline grafica su una base per pixel. Possiamo applicare molte tecniche interessanti con questa tecnologia, come la order-independent transparency per il rendering dei capelli o della vegetazione. E si può eseguire blending programmabile quando si vuole pieno controllo del blending anziché usare le unità a funzione fissa nella GPU.
Ci sono molte cose interessanti che si possono abilitare grazie a questa programmabilità e vorrei che anche AMD e Nvidia facessero qualcosa di simile. È molto efficiente anche dal punto di vista dei consumi e dall'efficienza generale sull'hardware di Intel, quindi ritengo che la sfida per Nvidia e AMD sarebbe realizzare qualcosa di simile con efficienza perché hanno architetture differenti. Cos'altro vorremmo? Di solito abbiamo incontri con i produttori che durano 14, 15 ore o un giorno intero e parliamo di tutto.
TH: sarebbe bello poter ascoltare cosa viene detto in quelle discussioni.
Johan: Sì, è davvero divertente. Ne ho parlato recentemente, vorremo permettere alla GPU di lavorare in modo più eterogeneo usando diversi compute shader in parallelo con carico grafico e far lavorare CPU e GPU maggiormente insieme. Una cosa come questa è possibile sulle console perché sono sistemi integrati, con GPU e GPU nello stesso die. In ambito PC ci sono le APU e anche gli Ultrabook di Intel hanno la grafica integrata.
Desidero che ci sia maggiore collaborazione tra CPU e GPU in modo da poter usare tecniche di rendering più avanzate. Ad esempio, una volta che abbiamo renderizzato lo Z-buffer per una scena sappiamo la profondità di ogni singolo pixel e in base a tale informazione possiamo applicare shadow maps solo alle aree necessarie. Solitamente non abbiamo quell'informazione, e la CPU prepara il dato che la GPU renderizzerà pochi fotogrammi dopo.
Oggi questi due componenti si passano molto lavoro e non si ha una vera reattività. Penso che andando avanti con un'interazione più stretta di CPU e GPU potremo applicare più tecniche intelligenti e meno del tipo brute force. È un argomento molto frequente quando parliamo con chi progetta l'hardware.
TH: ci piacerebbe sapere, secondo te, quale caratteristica potrebbe fare la differenza più grande in quanto a realismo. E che cosa potrebbe migliorare davvero l'esperienza dell'utente finale?
Johan: penso che ci siano alcune cose che riguardano il realismo e l'esperienza. Una cosa che non ho ancora detto è che Nvidia sta facendo un bel lavoro con il nested data parallelism - penso lo chiamino dynamic parallelism - sulle loro GPU Kepler. Questa consente di usare un sacco di altri meccanismi di programmabilità e offrire buone prestazioni.
Per il realismo nello specifico ci sono diverse cose ad affrontare, dato che oggi usiamo tante tecniche di rendering realizzate attraverso la rasterizzazione e il post-processing. Diventeranno sempre di più all'aumentare della complessità delle scene in cui vogliamo avere più superfici trasparenti. Proviamo a usare la rasterizzazione standard e poi applicare la profondità di campo e il motion blur correttamente, perché farlo in post-processing è davvero limitante; diciamo che c'è una trasparenza e due o tre layer di finestre insieme ad alcuni effetti particellari, e successivamente si vuole applicare alla scena la profondità di campo, ma avete solo il vostro depth buffer. Questo non ha idea delle superfici trasparenti, o se ce l'ha non sa cos'hanno dietro.
Penso che la sfida sia capire cos'è buono, efficiente per la futura pipeline grafica, anche per il mobile che potrebbe avere vincoli differenti. E per la profondità, dato che la pipeline di rasterizzazione è davvero molto efficiente, ma ha dei limiti. Ci sono alternative come microtriangoli o micropoligoni rasterizzatori o la stochastic rasterization - dove si può iniziare dalla profondità di campo e dal motion blur per renderli parte più integrate del rendering. Questa soluzione ha anche potenziali svantaggi, ma si deve arrivare al punto in cui molte di queste tecniche possano interagire liberamente. Penso che ciò possa portare un sacco di realismo in più. Ovviamente parlo solo di quello che i produttori di GPU e noi possiamo realizzare insieme.
Ci sono un sacco di cose che possiamo fare con il nostro motore e che faremo in futuro. Cose come un rendering basato maggiormente sulla fisica (physically based rendering) e uno shading in cui proviamo a usare misure reali di fonti di luce e materiali per provare a rappresentarle accuratamente all'interno del gioco. Solitamente nei motori e giochi precedenti prendevamo un'aspetto di riferimento e poi provavamo a ricrearlo, ma in realtà non facevamo rilevazioni, non conoscevamo i vari range.