Käymme artikkelissa läpi NVIDIAn uuden Ampere-grafiikka-arkkitehtuurin ominaisuudet pelaamisen näkökulmasta sekä tutustumme GA102-grafiikkapiiriin ja GDDR6X-muisteihin, joita käytetään sekä GeForce RTX 3080- että RTX 3090 -malleissa. Myöhemmin lokakuussa myyntiin saapuva GeForce RTX 3070 käyttää pienempää GA104-grafiikkapiiriä ja GDDR6-muisteja.
Testiartikkeli NVIDIAn omasta GeForce RTX 3080 Founders Edition -näytönohjaimesta julkaistaan 16. syyskuuta. Näytönohjainvalmistajien eli Asuksen, Gigabyten ja MSI:n GeForce RTX 3080 -mallien testi julkaistaan 17. syyskuuta. GeForce RTX 3090 -näytönohjaimien testitulokset saa julkaista 24. syyskuuta. GeForce RTX 3070 -näytönohjaimet saapuvat lokakuussa. NVIDIA ei vielä toistaiseksi julkistanut GeForce RTX 3060- ja 3050-malleja.
Lue artikkeli: Katsaus NVIDIAn Ampere-arkkitehtuuriin ja ominaisuuksiin
Artikkeli on julkaistu ennen kuin lykkäys oli tiedossa, päivitetty uusi julkaisuaikataulu.
Eikös se ollut niin, että ennakkomyyntiä näille ei ollut?
Olisiko nuo mahdollista suomentaa loppuun asti, eikä jättää puolitiehen?
Kyllä, saa tilata vasta julkaisupäivänä.
NRZ:ssä on kaksi tasoa, 0 ja 1. PAM4:ssä on 4 tasoa, 0, 1, 2 ja 3.
Tuon myötä PAM4 voi siirtää kaksinkertaisesti dataa per kellojakso, mutta sen toteuttaminen on kalliimpaa. Neljän signaalitason tunnistaminen on vaikeampaa ja signaali on herkempää häiriöille, minkä vuoksi etäisyydet on minimoitava.
Toisaalta kellotaajuus voi olla puolet pienempi samalla kokonaissiirtonopeudella, joka helpottaa jonkin verran kun tajuusriippuvaiset parasiittiset kapasitanssit ja induktanssit jäävät vastaavasti pienemmiksi.
Juu ja ne ovatkin selvästi pienemmät kuin GDDR6:lla, kun hyppy on vain 14-18 Gbps > 19 – 21 Gbps
Itsellä ei riitä tietotaito tuohon jälkimmäiseen osaan millään tasolla
Itse signalointihan ei ole mikään uusi tuttavuus, mutta tähän asti sitä on käytetty eniten kai verkkoyhteyksien toteuttamisessa. Tulevaisuudessa mm. PCIe 6.0 tulee käyttämään PAM4-signalointia, saa nähdä millaisia haasteita asettaa emoille.
Ei ole, mutta kuinka moni varmaan suurimmasta massasta oikeasti seuraa uutisia tai näitä välttämättä koko ajan? Sillä on iso ero jos arvostelut tulee vasta edellisenä päivänä tai pahimmillaan samana kun myynnit on. Ei sillä olisi välttämättä eroa, mutta jos ei ole, miksi ei avoimesti anneta vaan näyttää testejä hyvissä ajoin ennen ja antaa ihmisten pureskella informaatiota kylmällä päällä.
Joku voi ehkä parahtaa, että kyllähän Euroopan testaajien pitäisi julkistaa tulokset ja muiden myöhästelijöiden oma vika eikä ole syytä myötävaikuttaa. Ei se mielestäni mene niin vaan siten, että tasa-arvoisesti kaikki lähtevät samoilta viivoilta niinkuin näytönohjaimien myyjien kanssa. Ei se hauskaa ole, jos joku ottaa varaslähdön esim. myymisissä ja keräilee kaikki herkkurahat taskuihinsa kun toiset alkavat vasta myymään.
Vähän epäilen että sieltä mitään 3050:aa tulee, voisi luulla että tehdään mallisarja ilman RT-turhakkeita kuten 1660/1650 -sarjalaisten kohdalla.
Ja siellä 3090 Superi kaikki ytimet ehjänä.
Säteenjäljitys ei enää tällä vuosikymmenellä ole "turhake". Viime vuosikymmenen lopulla sen rautatuki oli oleellinen ominaisuus (vain) kehitysalustoissa, tällä vuosikymmenellä se on hyvin oleelinen ominaisuus kaikissa pelikorteissa. Sen sijaan suuri rasterointinopeus käy tällä vuosikymmenellä hyvin turhaksi.
Ja esim. elokuvissa säteenjäljitystä pon käytetty jo yli 10 vuotta, niissä se ei ollut turhake viime vuosikymmenelläkään.
3060 tullee melko pian koska piiri, mitä se tulee käyttämään on jo julkaistu 3070nä, 3060 tullee olemaan vain vähän cripplattu 3070.
Ja eiköhän nyt tule 3000-sarjaan vielä yksi tuota pienempi säteenjäljitystä tukeva piiri, josta sitten tulee esim. 3050.
tuo oli vaatimattomasti määritelty Pixar’s RenderMan | About
En kyllä edelleenkään usko säteenjäljitystekniikan olevan se oikea tekniikka tosiaikaiseen vuorovaikutteisen maailman mallintamiseen. Joku vokselipohjainen idea se lopulta varmaankin tulee olemaan kunhan sellainen saadaan aikaiseksi. Sen lisäksi että peleihin saadaan aikaiseksi erikoistehosteita niin linkki elokuvamaailmaan voi olla merkittävä.
Tehostebudjetit ovat nykyään järkyttäviä niin tilausta sille että raudalla vietettävälle jälkituotantoajalle saadaan halvemmat kustannukset lienee hyvinkin. En ole ihan varma meneekö NVIDIAn elokuvapuoli datakeskuspuolen myyntilukuihin vai ei, mutta jos menee niin siinä voisi olla yksi tekijä kyseisen osaston hyviin taloudellisiin lukuihin.
Sitä jäin pohtimaan että mahtaako näistä olla mitään hyötyä, kun lohkoketjuen laskeminen on käsittääkseni kokonaislukulaskentaa. Oma vaikutelma on että NVIDIA teki AMDt ja pudotti laskentapuolen ominaisuuksia neuroverkko ja liukulukulaskennan hyväksi vielä vahvalla pelipainotuksella. On mielenkiintoista nähdä kaksinkertaisen tarkkuuden liukulukusurituskyky ja raaka kokonaislukusuorituskyky suhteessa vaikkapa AMDn GCN6 kortteihin. Oma 50c on että lopputulos ei ole ihan yhtä mairitteleva kuin mitä peli ja renderöintitestit ennakoivat.
Ei säteenjäljitys varsinaisesti ole mikään keino MALLINTAA yhtään mitään, ja säteenjäljitys nimenomaan mahdollistaa rasterointia vapaamman tavan mallintaa asioita, koska säteenjäljityksessä pinnanmuodot voi määritellä millä tahansa matemaattisella kaavalla(toki nVidian ja AMDn raudat tukee suoraan vain kolmioita, mutta voidaan esim. tehdä BVH-puun läpikäynti raudalla ja sitten viimeisen tason tarkastus vapaasta kaavalla määritellystä geometriasta shadereilla softalla)
Ja säteenjäljitys toimii nimenomaan siten miten OIKEA TÄMÄN MAAILMAN FYSIIKKA toimii.
ei. Vokselit on vain keino MALLINTAA asioita, ei RENDERÖIDÄ ja kaikki järkevä heijastustenlaskenta tarvitsee pinnan suuntatiedon jota vokseleilla ei saa mitenkään järkevästi mallinnettua.
Tietokonegrafiikassa ensimmäisenä tulee algoritmitutkimus, sitten tulee elokuvat, ja näiden perässä pelit.
Tutkimuksessa on melko konsensus siinä että pääperiaatteena säteenjäljitys on paras tapa piirtää realistista grafiikkaa, mutta säteenjäljitys hyvin korkean tason käsite ja erilaisissa säteenjäljitysalgoritmeissa riittää vielä hyvin paljon kehitettävää.
Noiden minimi-maksimi -siirtymien poisto toki laskee kaistaa hieman, nopeasti pääteltynä tuo on "vain" 75% enemmän dataa per kellojakso kuin NRZ:lla kun 16 mahdollisesta siirtymästä kaksi on kielletty.
Turha nuita termejä on repiä takapuolesta kun jo kymmeniä vuosia takana oleva tutkimus osoittaa että tällä hetkellä säteenseuranta on se ns. holy grail jolla tuotetaan realistisimmat valaistusmallit. Siellä pohjalla saa olla datasettinä vokseleita, verteksejä, mitä vaan, mutta kuten yllä sanottua niin jostakin se informaatio pitää saada että voidaan alkaa valaisemaan sitä datasettiä ja se saadaan säteenseurannalla.
Voiko tuolla mallintaa valon aaltoluonnetta mitenkään? Jos ei diffraktiota pysty toteuttamaan, niin aika lailla jää vielä valaistus epätäydelliseksi.
Varmaankin nuo asiat mitä tapahtuu valolle raoissa jotka ovat pienempiä kuin valon aallonpituus ovat pyöristetty pois aproksimaatioissa. Mutta kyllähän tuolla ray-tracingillä saadaan paljon juttuja tehtyä jo ihan reaaliaikagrafiikassakin.
Varmaan hyvin pitkälle myös implementaatiosta kiinni ja laskentatehosta.
ok, diffraktio vaatii purkkaa säteenjäljitykselläkin:
Mallinnetaan se kapea rako pintana, johon säde osuu, ja sen pinnan shader-koodissa ammutaan siitä sitten lisää toisiosäteitä sen toiselle puolelle eri suuntiin (tai yksi säde satunnaiseen suuntaan)
Ja jotta tämä toimii hyvin, pitää sitten mallintaa myös valon vaihetta => esim. pelkän RGB-intensiteetin sijasta käsitellä jokaista sädettä kuin se olisi yksi fotoni, tallennetaankin siitä taajuus ja vaihe, ja fiksataan voimakkuus. Tämä toki tarkoittaa sitä että säteiden määrä kasvaa todella hurjasti ja käytännössä vasta joskus >10 vuoden päästä voidaan haaveilla raudasta jossa riittää suorituskykyä tällaiseen.
Njoo, huhuissa on että se olisi 3060ti. Se että onko normi 3060:nen enää tuolla piirillä on eri juttu. Tuo nvidian nimeämiskäytäntö meni niin uusiksi taas että vaikea pysyä perässä noissa. Mutta jos siruja kattellaan nykyset menisi jotenkin näin:
tu102->ga102: rtx titan -> rtx3090, rtx2080ti~~>rtx3080(tn. tulee rtx3080ti/S)
tu104->ga104: rtx2080/S->rtx3070, rtx2070S->rtx3060ti
tu106->ga106: rtx2070/060S -> rtx3060?, rtx2060 -> rtx3050ti?
On se hyvä että muillakin on joskus haasteita muotoilla vastauksia
Säteenjäljitys toimii hyvin staattisella maailmalla ja on sen takia hyvä valinta elokuvan ruudun piirtoon. Se on sen sijaan vaikea ympäristössä jossa pinnat liikkuvat jatkuvasti. Joskus oltiin jopa sitä mieltä ettei sääteenseurantaa tulla koskaan käyttämään tosiaikaisessa piirtämisestä.
Säteenseurannan iso ongelma on siinä että tekniikkaa pyrkii simuloimaan valon käyttäytymistä. Heitin vokselit vain konseptia jonka pohjalta voisi ehkä lähteä mallintamaan dynaamista maailmaa. En oikein tiedä miksi kutsua fysikaalisten ilmiöiden imitointa ilman simulointia, mutta joku approksimaatio tarvitaan jotta täysin dynaamisen maailman valaistusta pystyttäisiin mallintamaan.
BVH-puu pitää tosiaan rakentaa uudelleen mikäli scenen geometria muuttuu, mutta tämä ei ole mikään fundamentaalinen ongelma vaan vaatii vain laskentatyötä, ja tämän optimoimiseksi on paljon temppuja.
Scene on helppo jakaa esim. kahteen osaan, staattinen puoli ja dynaaminen puoli, ja jakaa puu kahteen haaraan ja laskea puu uusiksi vain dynaamiselle puolelle. Tämä jako toki tekee itse säteenjäljityksestä hiukan raskaamman kun puurakenne ei ole sen läpikäymisen suhteen optimaalinen, mutta tyypillisissä peleissä suurin osa scenestä on staattista joten tällä saadaan pudotettua puunrakennukseen tarvittava laskentatyö usein todella pieneen osaan "täydestä".
Ja kun puusta ei yritä tehdä muutenkaan "optimaalista" vaan tyydytään esim. sen verran epätasaiseen puuhun että tarvittavien testien määrä on esim. luokkaa 1.5-kertainen optimaaliseen puuhun nähden (eli otetaan ylimääräinen 0.66x hidastus itse säteenseurantaan), sitä puun rakentamista saa kyllä rinnakkaistettua todella hyvin vaikka kaikki geometria olisi dynaamista ja koko puu pitäisi uudelleenrakentaa joka frame. Tämä on vain laskentaa, joka halpenee jatkuvasti. Täysin optimaalisen puun rakentaminen sitten rinnakkaistuu huonosti.
Mites se tehdään rasteroimalla vähemmällä gpu/cpu-kulutuksella? Vastaus on tietysti, ettei tehdä ollenkaan. Tai tehdään ehkä lightmapeilla ja shadowmapeilla, jotenkin kikkaillen ja ei realistisesti.
Tämä oli se alkuperäinen idea. Nykymallisella piirtoliukuhihnalla saadaan uskottavan näköistä jälkeä aikaiseksi, mutta säteenjäljityksellä ei mikään riitä tosiaikaisen ja muuttuvan näkymän piirtoon. Tuskin tulee koskaan riittämäänkään. Tietääkseni kaikki nykyiset säteenjäljitystekniikat peleissä luovat tehosteita tosiaikaisesti tai sitten esilasketusti(DLSS) Koko näkymää ei yritä piirtää kukaan.
Nuo "nykyiset menetelmät" eivät toimi ollenkaan muuttuvan geometrian kanssa, joten ei voi kyllä puhua minkäänlaisesta realismista kun niinkin yksinkertainen asia kuin oven avaamisen vaikutus huoneen valaistukseen ei toimi.
http://www.insider.com/pixars-animation-evolved-toy-story-2019-6 tästä ehkä saa mittasuhteita siihen mitä vaatii kun lasketaan kokoruutuja säteenjäljityksellä. On turhaa hymistellä siitä ettei jotain saa tehtyä tosiajassa tavalla A kun ei sitä saa tavalla B myöskään.
Minecraft RTX on täysin path-tracetettu peli. Sekin pyörii aivan pelattavasti ja on ulkonäön puolesta täysin eri planeetalta verrattuna perinteiseen versioon.
Kun perinteisesti rendatun version valaistus on täysin onneton ja RTX näyttää hyvältä ja pyörii pelattavasti, niin missä se ongelma on? Siinä että pelin tekijät eivät ole jaksaneet miettiä miten asiat kannattaa tehdä niin, että homma pyörii olemassa olevalla raudalla?
Hybrid renderöinnillä mentäneen vielä pitkään. Toivottavasti pelintekijät saisivat kustannuksia alaspäin, kun kenttäsuunnittelu muuttuu vähemmän vaivalloiseksi. Ei tarvi enää leipoa valoja ja korjailla nurkkia joista valo vuotaa läpi tai korjailla paikkoja joissa valaistus näyttää huonolta. Toki käsin nypeltämälläkin ja heikolla raudalla saa hyvää jälkeä, kuten last of us II on osoittanut. Olisi hauska tietää montako tuhatta tuntia sen valaistusta on viilattu käsipelillä.
Minecraft on about vaikein mahdollinen peli valaista kunnolla. Siinä on 100%:sesti ja täysin käyttäjän mielen mukaan muuttuva geometria, jolloin valaistusta on mahdotonta toteuttaa perinteisesti pre-calculoiduilla lightmapeilla.
Meinaat että eri väristen isojen tasakokoisten ja pinnaltaan täysin tasaisten kuutioiden valaisu olisi jotenkin haastavaa? En vertaillut rasterointia ja säteenjäljitystä vaan kahta erilaista näkymää säteen jäljityksen näkökulmasta. Ehkä joku Tetris olisi vielä helpompi mutta jotain pelattavaa sisältävä esimerkki. Voi tietty olla että RT versiossa on tarkemmat mallit käytössä. Itse olen pelannut vain tavisversiota konsolilla junnujen kanssa.
DXR:ssa ei ole sellaista optimointia, että voisi tehdä tasakokoisina kuutioina. Geometrian joutuu tykittämään kolmioiksi ja bvh puuhun. Softa ray tracella taas voisi kikkailla kaikenlaista, mutta sillon jäisi dxr raudat käyttämättä.
Kuutiossa on kahdeksan verteksiä ja sen piirtämiseen tarvitaan 12 kolmiota. Tetraedri on se yksinkertaisin kolmiulotteinen malli, muttei kuutio siitä paljon jää. Koko Minecraftin maailmassa ei taida olla yhtä paljon piirrettäviä kolmioita kuin yhdessä AAA pelin ruudussa.
Jos minecraftissa olisi softaoptimoitu ratkaisu, joka olettaa kuutioita niin sen kiihdytysrakenteen ja säteenseurannan voisi rakentaa paremmin. Kolmiot ja bvh ei ole siihen optimaalinen. Minecraftin suorituskyky tuskin muuttuisi paljoa dxr:n alla, vaikka ne palikat eivät olisi tasakokoisia kuutioita.
Se missä ne kuutiot voivat auttaa on optimalisen bvh puun rakentaminen myös dxr ratkaisun alla. Mutta se bvh puu rakentaminen tuskin on ongelma, kun ei siellä minecraftin maailmassa per frame kovin moni kuutio muutu.
DXR toimi niin, että maailma jaetaan kuutioihin ja kolmiot kuutioiden sisään. Jos dxr:ssa olisi moodi, jossa voisi jättää kolmiot pois ja olisi pelkkiä kuutiota kuutioiden sisällä niin minecraft:sta saisi sairaan nopean. Olisi vain joka kuutiolle tila tyhjä, ei tyhjä. Jos osuu ei tyhjään niin sitten tarkastellaan tekstuuria/kuutioita kuutioiden sisällä osumakohdassa. Kolmiot ja kolmioiden takana oleva geneerinen kiihdytysrakenne on minecraftin tapauksessa vain hidaste. Eli minecraft ei ole mitenkään optimaalinen tai erityisen nopeaksi saatava rakenne dxr:n kannalta. Ei kannata kuvitella, että minecraft olisi jotenkin erityisen kevyt. Etenkin kun minecraft on kokonaan path trace ratkaisulla tehty, eikä siellä ole missään kohtaa rasterointia mukana.
edit. Siellä nvidian raudassa on erikseen kuutioille ja kolmioille prosessointi. Ikävä kyllä dxr ei ole se optimaalinen api minecraft tapauksessa.
katso liitettä 448070
Olet ymmärtänyt tuon väärin täysin väärin. BVH-puussa 3D-maailma on jaettu Bounding Box -kuutioihin. Bounding Box Intersection -yksikkö laskee osuuko säde niihin kuutioihin, jos ei osu niin jatketaan seuraavaan laatikkoon jne jne, kun osumia tulee laskee triangle intersection yksikkö mihin kolmioihin se osuu sen Bounding Boxin sisällä.
edit:
Tästä diasta näkyy hyvin miten homma toimii, vasemmalla on 3D-malli visualisoiduin Bounding Box -kuutioin ja sen alla BVH-puu niistä bokseista. Bbox Intersection -yksikkö laskee osuuko säde siihen BVH:n laatikkoon, sen jälkeen se ohjataan seuraavaan ja seuraavaan kunnes löydetään oikea laatikko ja lasketaan Triangle Intersection -yksiköllä mihin kolmioihin se säde osuu sen sisällä.
katso liitettä 448115
Yritin kirjoittaa juuri noin. Minecraft tapauksessa kun ne palaset on kaikki kuutioita niin softatoteutuksella voisi tehdä pelkän bounding box implementaation ja heivata kolmiot kokonaan pois. DXR:n tapauksessa ensin veivataan bounding box:it läpi ja sen jälkeen tutkitaan kolmioita niiden sisällä. DXR:lla ei voi optimoida niin, että minecraftin kuutio olisi sama kuin bounding box. Tarvitaan ne kolmiot sinne bounding box:in sisälle.
Softalla voisi vielä tehdä erikoiskludgea, kun kaikki kuutiot ovat samankokoisia. Ei tarvi mitään x,y,z koordinaatteja, koska kaikki geometriatieto voidaan johtaa kuution indeksistä. Riittäisi pelkkä 3d tekstuuri missä bitti 3d tekstuurissa kertoo onko kuutio tyhjä vai ei. Tuollaisen 3d tekstuurin kera bittien läpikäyminen softalla olisi naurettavan nopeata ja rakenne olisi pieni. Sen bitin kaveriksi vois lisätä muutaman tavun tavaraa, että saadaan samasta tietorakenteesta tekstuuri id:t sun muut. 128x128x128 tutkittava alue olisi 128x128x128/8 kokoinen muistissa=262kB. Annetaan siihen kylkeen vaikka 15bittiä lisää, että saadaan kuution metadata mukaan ja per frame läpikäytävä rakenne olisi edelleen vain 4MB.
Minecraft optimoitu säteenseuranta softaimplementaatio ei tarvi BVH puuta. Optimoidussa tapauksessa ei tarvisi koskaan rakentaa bvh:ta, koska maailman muuttaminen on vain 1bitin tai vaikkapa 2tavun nollaaminen/uudelleenkirjoittaminen 3d tekstuurissa. Jos kuutio tarvii enemmän dataa niin sen voi siirtää 3d tekstuurista ulos, että itse ray trace osa toimii nopeasti eikä lue liikaa muistista tavaraa.
dxr:lla on hyvin hankala ellei mahdoton tehdä minecraft:sta täysin optimaalinen versus softaimplementaatio. Eli se alkuperäinen kommentti johon vastasin, että kuutiot olisi yksinkertainen rakenne ei pidä dxr:n kanssa paikkaansa. Kuutio on dxr:ssa ihan yhtä vaikea tapaus kuin muu geometria. Se olisi mielenkiintoista tietää missä minecraft:in pullonkaula on, vaikuttaisiko suorituskykyyn kolmioiden määrän lisääminen vai ei?
Se hidastuu dramaattisesti jos view distance parametria kasvattaa.
Säteenseurannan saisi laskettua törkeän nopeasti ja hyvin pienellä muistikaistan käytöllä. Pullonkaula siirtyisi täysin shading puolelle. Samalla välttäisi kaiken bvh puun rakentamisen ja läpikäymisen, koska maailma on tasakokoisista kuutiosta koostuva. Mä tekisin niin softaratkaisussa, että olisi yksi 3d tekstuuri, missä on 2 bittiä per palikka. tyhjä, täysi läpinäkymätön, täysi läpinäkyvä tiedolla. Tuolla rullaa säteet ja päättelee x,y,z indeksistä kuution kulmat. Toinen 3d tekstuuri, jossa on sitten palikan tekstuuri yms. tiedot mitä käytetään shading prosessin aikana. Sitä toista 3d tekstuuria joutuisi käyttämään myös osittain läpinäkyvien kuutioiden tutkimiseen.
Tuolla tiedolla, jos se per frame läpikäytävä alue olisi 128,128,128 kokoinen niin se säteenseurannan tietorakenne olisi 128x128x128/8*2 tavua kokoinen(512kB). Tuo tietorakenne pysyisi helposti gpu:n sisällä. Melkein kaikki ram:in muistikaista jäisi shading työlle. Osittain läpinäkyvät kuutiot tosin söisivät muistikaistaa, kun läpinäkyvyys pitää tutkia palikan alpha tekstuurista/pintamateriaalista.
Ongelmaksi muodostuisi silti pelaaja ja npc hahmot, kun ne eivät ole kuutioita. Ne pitäisi jollain kludgella viritellä, mutta tuskin on tekemätön homma.
Olisi pitänyt kirjoittaa aluksi vain, että minecraft ei dxr:n alla hyödy tasakokoisesta kuutiomaailmasta. Minecraft toki hyötyy geometrian vähyydestä, kun niitä kolmiota on melko vähän. En minä odota isommissa määrin täysin ray tracing pohjaisia pelejä. Pitkään tulee hybridi olemaan mainstream ratkaisu. Ja tietenkin toisessa suunnassa unreal5 on täysin omanlaisensa softaratkaisu kera mikropolygonien(softarasteroija) ja ei kai käytä dxr:aa olleenkaan.
Se mikä mua kiinnostaa on, että miten eri raudat skaalautuvat. Onko pullonkaula raudassa kolmioiden läpikäyminen vai ehkä jokin muu osa prosessia. Kuinka paljon dxr+rauta tuo rasvaa siihen säteenseurantaan per säde? Jos sitä rasvaa on ympärillä niin se pullonkaula voi olla rasva eikä niinkään kolmioiden määrä. Jos olisi aikaa niin quake2 rtx:lla olisi kiva testailla. Quake2:en kenttiä vois tesseloida eri kolmiomäärille ja katsoa miten suorituskyky muuttuu.
edit. Jos/kun amd tarjoaa shadereihin kolmio ja kuutiotarkastuskäskyt ilman pakotusta dxr apista niin se voi avata mielenkiintoisia mahdollisuuksia minecraft tyyppiseen rajattuun käyttötapaukseen. Yleistetty ratkaisu ei ole paras suorituskyvyn kannalta, jos on mahdollista asettaa rajotteita, jotka helpottavat laskentaa.
Ei.
Jokaista sädettä kohden pitää joka tapauksessa tehdä joitain kymmeniä tarkastuksia niihiin BVH-laatikoihin. Se, että siellä on pari tasoa lisää laatikoita ja viimeisenä laatikon sisällä on kolmio johon myös tarkastetaan (ja sen kolmiotarkastuksen hitan on ehkä tuplat yhden laatikkotarkastuksen hinnasta) tekee vain luokkaa 20% lisää overheadia sen säteenjäljityksen tarkastusmäärään kokonaisuudessaan.
Ja samoin ne BVH-puun laatikot vaativat joka tapauksessa paljon muistia vaikka niiden sisällä ei enää olisi kolmioita vaan puun alin taso olisi suoraan ne itse primitiivit; Muistinkulutus pienenisi vain jonkin verran, ei mitenkään dramaattisesti.
Ei. Ensinnäkin, unohdat BVH-puun muistinkulutuksen kokonaan, ja toisekseen:
Jokaisesta pinnasta pitää olla talletettu pinnan tekstuurit (jokaisesta tekstuurista pointteri tekstuuriin sekä kordinaattidataa) ja tekstuuretita voi olla esim. 2 kpl (väridata sekä joku pinnan rosoisuutta kuvaava pintakartta). Vaikka tämä muu data olisi omassa tietorakenteessaan, tarvitaan kolmion yhtetyteen vähintään pointteri tai indeksi tähän tietorakenteeseen.
Lisäksi oletus jostain 128x128x128 läpikäytävästä alueesta minecraftissä on melkoisen alakanttiin.
Mutta, BVH-puun läpikäynti on melko välimuistiystävällinen asia. BVH-puun kymmenisen ylintä tasoa on käytännössä jatkuvasti välimuistissa ja huteja tulee vaan alemmista tasoista, ja viereiset säteet auttavat niissäkin toisiaan merkittävästi.
Geometriadatan määrä ei säteenjäljityksellä ole mikään ongelma, kun törmäystarkastusten määrä skaalautuu logaritmisesti , kiitos BVH-puun.[/quote]
Mieti minecraftia ennemminkin voxeli implementaationa missä ei tarvita kolmioita ja rakenteet on optimoitu sen päälle.
Mutta tämä keskustelu on jo ihan eri laukalla kuin mihin kommentoin alunperin.
Mitenköhän ne kuvittelet optimoivasi?
Ei BVH-puulla ideana ole mitään tekemistä kolmioiden kanssa vaan ihan samalla tavalla sitä tarvitaan järkeävään suorituskykyyn riippumatta siitä, millaisia ne matalimman tason primitiivit on; Ilman sitä brute-forcella tarvittavin törmäystarkastusten määrä on järkyttävän suuri ja suorituskyky todella hidas.