Kiitos tästä!
Olet useampaa kertaan sanonut, että pilveä ja paikallista ei voi sotkea...
Eli ei siis ole fiksu laske sitä puu osaa pilvessä ja ehkä seuraavaa ja rendata loput gpu:lla? Ilmeisesti tuossakin viiveet olisi se ongelma. Siirrettävää dataahan ei kaiketi olisi samoja määriä kuin rendatun kuvan siirrossa, jota itsekkään pidä järkevänä.
Mutta puhtaana amatöörinä kuvittelisin että datan määrä ei olisi hillitön kahden ensimmäisen vaiheen osalta.
Jos vielä aukaisut tuota niin oppisi wanha taas jotain uutta grafiikan piirron saralta!
Rasteroinnissa piirrettään kolmioita. Otetaan kolmio, piirretään se, otetaan toinen kolmio, piirretään se, jne.
Säteenjäljityksessä ei piirretä kolmioita lähtien kolmioista, vaan siinä tarkastetaan sitä, mihin säteet osuu.
Lauotaan yksi säde, tarkastetaan
kaikista kolmioista, että mihin se osuu, mahdollisesti lauotaan osumakohdasta uusi sekundäärisäde. Sitten lauotaan toinen säde jne.
Jotta voidaan tehdä tarkastus kaikista kolmoista, pitää säteenjäljitystä tekevällä laitteella olla omassa nopeassa muistissaan
kaikki kolmiot.
Ei voida jakaa eri laitteiden välillä, että "hoida sinä nämä kolmiot, minä hoidan nämä kolmiot"
Ja BVH-puu on tietorakenne, jolla voidaan optimoida sitä osumatarkastusta niihin kolmioihin. Kolmioita sortataan ja luokitellaan siten, että voidaan sen perusteella hylätä suuri osa kolmioista. Ennalta ei kuitenkaan voida tietää, mitkä kolmioit hylätään,
koko BVH-puu ja kolmiodata pitää olla melko nopeassa muistissa (DRAM)
BVH-puu koostuu laatioista, uloimman tason laatikko on niin iso, että sinne mahtuu sisään scenen kaikki kolmiot.
Yksinkertaisessa (*) radix-2-BVH-puussa tämän sisällä on sitten kaksi laatikkoa, molemmat sisältävät (noin) puolet kolmioista. Avaruudellisesti nämä laatikot kuitenkin overläppäävät tosiaan selvästi.
Ja seuraavalla tasolla taas molemmat näistä laatikoista sisältävät 2 laatikkoa, joissa molemmissa (noin) puolet näiden laatikoiden kolmoista.
Lopulta matalimmalla tasolla meillä on laatikoita, joissa on vain 1 tai 2 kolmiota. Sitten niistä tehdään se kolmioiden osumatarkastus.
Jos säde ei osu BVH-puun laatikkoon, se ei voi osua mihinkään laatikossa olevaan kolmioon.
Eli, kun laatikko käsitellään, tarkastetaan sen molemmat lapsilaatikot, että osuuko säe niihin. Ja jos säde osuu lapsilaatikkoon, laitetaan lapsilaatikko jonoon odottamaan käsittelyä. Jos säde ei osu lapsilaatikkoon, se ei voi osua mihinkään siellä olevaan kolmioon ja tarkastettavien kolmioiden määrä putoaa n. puoleen. Ja jos se seuraavalla tasollakaan ei osu toiseen laatikkoon, se putoaa neljäsosaan alkuperäisestä jne.
Toki välillä käy niin, että osutaan molempiin laatikon alilaatikoihin, sitten pitää tarkastaa molemmat.
Yhden (tai kahden) laatikon tai kolmion törmäystarkastus kestää raudalla luokkaa joitain kellojaksoja, (riippuen raudasta), softalla suuruusluokkaa sata kellojaksoa, eli joitain kymmeniä nanosekunteja, karkeasti ottaen samaa suuruusluokkaa kuin DRAM-muistin hakuaika. Ja puun läpikäynti on melko sarjallinen operaatio, lapsilaatikon osoite selviää vasta kun ylemmän tason laatikko on luettu, ja se, tarviiko sitä käsitellä, selviää vasta, kun ylemmän tason laatikko on kokonaan käsitelty. Yhden säteen sisällä rinnakkaisuutta on melko huonosti, lähinnä siellä on rinnakkaisuutta vain
1) kolmen levyisiä geometriavektoreita
2) laatikon molempien lapsilaatikoiden törmäystarkastus voidaan tehdä yhtä aikaa.
Yhden primäärisäteen renderöimiseksi voidaan joutua tekemään karkeasti n. 20 törmäystarkastusta, kokonaisuudessaan aika on siis softalla luokkaa parituhatta kellojaksoa(vajaa mikrosekunti), raudalla selvästi vähemmän.
Jokaista primäärisädettä kohden sitten tosin lauotaan tyypillisesti n. 3-4 sekundäärisädettä, eli puhutaan kokonaisuudessaan luokkaa parista mikrosekunnista, joka menee esim. yhdeltä ytimeltä yhden pikselin rendaamiseen.
Tämä on niin sarjallinen ja nopea operaatio, että tämän sisällä ei ole mitään järkeä yrittää rinnakkaistaa mitään erimerkiksi monilla säikeillä. Koko säde jäljitetään loppuun asti yhdessä säikeessä.
Sen sijaan eri säteitä voidaan laukoa loputtomasti rinnakkain eri säikeissä, myös eri säteiden laskeminen saman ytimen eri SIMD-linjoissa voi kehittyneellä SIMD-käskykannalla olla mahdollista, joskin ei triviaalia. Tällöin kolmiodata ja BVH-puu on kaikille säikeille/säteille yhteistä read-only-dataa.
ELi ruutu voidaan jakaa vaikka tuhansiin tiiliin, joista jokaista tiiltä rendaa eri prosessori, jotka voivat kyllä olla eri tietokoneissa. Kaikkein pitää kuitenkin päästä nopeasti käsiksi siihen BVH-puuhun ja kolmiodataan, eli jos niillä ei ole jaettua muistia, ne pitäisi duplikoida kaikille, ja kun scene muuttuu (eli kun mikä tahansa liikkuu, käytännössä siis joka frame), geometriadata ja päivitetty BVH-puu pitää uudelleen siirtää kaikille muille.
Käytännössä kolmiodata on luonnostaan paikassa, missä itse pelienginekin pyörii. Sen lähettäminen minnekään tahansa muualle kuluttaa aika paljon kaistaa. Jokaista kolmiota kohden 1-3 verteksiä(16-48 tavua) ja esim. joku viite tekstuuriin, sen kordinaatit, sekä pari lukua pinnan ominaisuuksista, niin ollaan helposti 32-64 tavussa per kolmio. Ja BVH-puussa laatikoita on suurinpiirtein sama määrä kuin kolmioita on, siitä luokkaa 32 tavua lisää. Ollaan helposti 64-96 tavussa per kolmio, ja meillä voi kolmioita olla esim. 250000 kpl.
Geometriadatan muistintarve helposti kymmeniä megatavuja. Tätä kun alkaa lähettämään 60 FPSää verkon yli, kaista menee yli gigatavu sekunnissa. Tai siten joka laite generoi uudestaan saman BVH-puun ja ollaan silti sadoissa megatavuissa sekunnisa. Vaikka 90% scenestä olisi staattista, ja lähetettäisiin vain muutokset(ja BVH-puun ylimpänä haarana olisi jako staattisiin ja dynaamisiin) , ollaan silti kymmenissä megatavuissa sekunnissa.
Onnistuu nopeassa lähiverkossa laskentaclusterissa, ei internetin yli.
Käytännössä, jos yritettäisiin hajauttaa ison verkon yli, pitäisi alkaa duplikoida aika paljon koko pelienginestä, että kaikki eri rendaajat osaisivat laskea kaikkien pelin kolmioiden paikat. Ja tässä tehdään entistä enemmän samaa homma monessa paikassa, ja tulee entistä pahempia synkronointiongelmia.
Järkevä/mahdollinen malli on, että samalla palvelinclusterilla pilvessä pyörii sekä pelin verkkopeliserver(jonka takia siellä on se pelienginen data) että säteenjäljitysrendausfarmi, mutta sitten ei enää kannata lähettää sinne pelaajan kotikoneelle/päätelaitteelle mitään rendattavaksi, vaan lähettää asiakkaalle vain valmis kuva.
(*) Tässä esimerkissä siis vielä jätetty tekemättä tuo optimointi, mistä edellisessä viestissäni mainitsin. Se on kuitenkin vain yksi taso lisää puuhun, eikä sinänsä muuta puun toimintaperiaatetta mitenkään. Puu vaan ei ole tasapainossa, tämän tason osalta ei jakaudu puolet ja puolet, jos lisätty tämä ylimäräinen taso staattisen ja dynaamisen geometrian erottelemiseksi.
