Za Oculus Rift bit će vam potreban poprilično moća

http://www.bug.hr/master/vijesti/objavljeni-hardverski-zahtjevi-oculus-rifta/143089.aspx

Da neće mozda Oculus Rift malo i BitCoine rudarit kad mu treba takav hardware? 
Optimizacija: 0% - Potrositi (ne)efikasno i posljednji HW resurs

Prvo; to znaći da će rezolucija finalnog proizvoda ići vjerojatno na 4k rezoluciju (pola te rezolucije za svako oko; što je po meni optimalno. Sve manje od toga nije dobro).

Drugo; zaboravljaš da igra mora rendat dva pogleda u isto vrijeme, tj. istu scenu 2x i sve skupa držat na 60 FPS-a (60 FPS-a je optimalno za Oculus)

Treće: A što bi to po tebi jedan proizvođać hardware-a imao za optimizirat u igrama? To je ko da veliš da Samsung nije optimizirao monitor, pa ti GTA 5 šteka :D Istina; oculus je nešto specifičan slučaj, ali nije neka velika kemija što se tiće drivera, te je i dalje na developerima igre da riješe optimizaciju igre (bio Oculus u pitanju ili ne) i podršku za Oculus, kako bi igra radila kak spada , a ne na proizvođaću hardware-a.

Tak da su po meni ovi zahtjevi znak da ne misle napravit neki poluproizvod, nego uređaj koji bude radio kak spada, a za to treba hardware koji to sve može upogonit. 

 4 projekcije od jednom? Pretpostavljam da se radi o 4 uzastopne na manje djelove texture tako da se dobije približno jednaka brzina kao da proiciraš na jednu veliku.
Texture chasing ne dolazi u obzir jer su to u principu renderirane scene iz dva razlićita kuta, a efekt parallaxa je izuzetno bitan kao depth cue za mozak.
Nvidia je sa 900 serijom smanjila rendering pipeline u pola. Pretpostavljam da su omogućili ovo što si naveo "4 projekcije od jednom", odnosno potrebne dvije.
Treća stvar je što rezolucija texture na koju se renderira puno veća od one koja se prikazuje zbog potrebe deformiranja prikaza radi optike.
Oculus je izdao SDK v0.6.0.0 i dano je dosta mogućnosti da se optimizirat rendering pipeline.
Sa DK2 novije grafićke imaju problema prikazat scenu željenom brzinom, a ono što sam se uvjerio je, da detalji dolaze puno više do izražaja kad ih gledaš kroz brile za razliku od monitora.
Tako da mi se ćini da bu ovo osiguralo tržište za hardware za minimalno idućih 5g. i plus nakon toga za mobilni.

 Konkrentno, kod CSSM texture cashing nije mogao doci do izrazaja jer svaka projekcija renderira razliciti dio slike (blizu kamere, malo dalje, još dalje, i najdalje pa do beskonacnosti). U biti, kad renderiras jedan objekt instanciras ga 4 puta - po jedan za svaku projekcijsku matricu. (a ako xy istih objekata renderiras odjednom, onda instanciras 4*xy puta pa koristis % operator da dobijes info koju projekcijsku matricu koristiti sa kojom instancom). Osim 4 projekcijske matrice moras imat definirane i setove clipping ravnina. Jednostavno, za prvu instancu koristis prvu projekcijsku matricu i prvi set clipping ravnina(ja sam koristio 2 po projekciji jer rubovi screena takodjer djeluju kao clipping ravnine). I to je to. Objekti koji su bili predaleko za neku projekciju jednostavnu su odmah u vertex shaderu bili clippani. U teoriji, svaki objekt je bio finalno renedeiran samo jednom (veci objekti su u biti rascjepkani u manje djelove i svaki dio rendeiran sa svojom projekcijskom matricom).

Stvar je usprkost 4 puta više vertex shader posla radila jako jako brzo jer je pixel shader posao bio dominantan (velika rezolucija: 2048x2048). Skoro pa da nije bilo razlike u brzini renderiranja sa 4 projekcije i sa jednom projekcijom jer taj dodatni vertex shader posao je bio ništa prema ukupnom pixel shader poslu.

Tu si u pravu - texutre cashing ne dolazi do izražaja jer se razliciti djelovi scene renderiraju razlicitim projekcijskim matricama.

Kod renderiranja za dva oka odjednom, texture cashing jako dolazi do izražaja.

Naime, svaki objekt instanciraš dva puta. Dok se renderira neki trokutić za lijevo oko sa ljevom projekcijom, napuni se texture cashe baš za dio texture obuhvacen tim trokutićem. Odmah poslije njega ide trokutić desnog oka sa drugom projekcijskom matricom (eventualno je malo drugacije nakrivljen zbog druge perspektive), ali texture cashe je napunjen baš sa onim podacima koji mu trebaju. Time su texture operacije za ovaj drugi desni trokut extremno brze (kao da si renderirao obicni flat trokut bez textura) - texture fetch operacije su najskuplje, ali sad je sve vec u casheu. Još je dodatna prednost što će pola screen rezolucije zahtjevati manji mip level pa će dohvat textura opcenitno biti brzi, a dohvat texture za desni dio je prakticki nepotreban jer je vec u casheu. Na taj nacin zapravo mozes dobiti da je rendeiranje za dva oka brze od rendeiranja za jedno (preko cijelog ekrana) - to je extremna situacija koja se dogadja samo kod odredjene velicine trokuta, ali je ipak moguca.

Što se tiće time warpinga (samo zakretanje textra) i dinamicke reprojekcije (saznati 3d poziciju pixela preko dubine i XY pa proicirati novijom projekcijskom matricom) one se odnose na frame rate, a ne na ovo rendeiranje za dva oka. Potpuno drugi set problema je to.

Bilo bi idealno kada bi hardverski radili repojekciju u HMD. Tada bi mogao raditi rendering i na 20fps, ali bi raznim reproduckijama headset pro mogao interpolirati u 120 fps. Bilo bi puno scene thearinga i zamucenih povrsina jer iz jednog kuta ne mozes uvijek vidjeti sve djelove slike (i rubove scena bi billi koma), ali bi radilo... Naravno, tada bi se headsetu trebalo stati i zBuffer, ali ja to vidim kao jedini nacin za pobjediti bandwith limit na 4K @ 90fps - jednostavno ne prolauzi kroz HDMI 1.3 (trebam ovo provjeriti). Nisam siguran, ali misli da Sony upravo to i radi u headsetu (ne na tim rezama, i ne pravu reprojekciju vec obicno rotiranje, ali radi - uz malo juddera na bliskim objektima).