Katsaus NVIDIAn Ampere-arkkitehtuuriin ja ominaisuuksiin

[Kaotik]

Kaotik kirjoitti uutisen/artikkelin:
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

Linkki alkuperäiseen juttuun

 

[Kapteeni_kuolio]

Hyvä artikkeli, mutta taisi tuo FE-revikoiden julkaisuaikataulu lykkääntyä? NVIDIA viivästyttää GeForce RTX 3080 Founders Edition -testejä

 

[Sampsa]

Hyvä artikkeli, mutta taisi tuo FE-revikoiden julkaisuaikataulu lykkääntyä? NVIDIA viivästyttää GeForce RTX 3080 Founders Edition -testejä

Artikkeli on julkaistu ennen kuin lykkäys oli tiedossa, päivitetty uusi julkaisuaikataulu.

 

[Norwood]

Haisee vähän tuo viivästynyt aikataulu... Ikinä en ymmärrä mitään muuta syytä kuin että hypen voimalla myydän mahdollisimman paljon, jos ja kuin suinkin mahdollista. Ja tämäkin syynä viivästyksille testien julkaisussa siinä toivossa että porukka menee mahdollisimman sokkona ennakkotietojen mukana.

 

[Heseman]

Haisee vähän tuo viivästynyt aikataulu... Ikinä en ymmärrä mitään muuta syytä kuin että hypen voimalla myydän mahdollisimman paljon, jos ja kuin suinkin mahdollista. Ja tämäkin syynä viivästyksille testien julkaisussa siinä toivossa että porukka menee mahdollisimman sokkona ennakkotietojen mukana.

Eikös se ollut niin, että ennakkomyyntiä näille ei ollut?

 

[aop]

GDDR6X-muistit ovat NVIDIAn ja Micronin yhteistyön hedelmä ja niiden merkittävin muutos on NRZ-signaloinnin (binäärinen Non-Return to Zero) vaihto PAM4-signalointiin (4-tasoinen Pulse Amplitude Modulation).

Olisiko nuo mahdollista suomentaa loppuun asti, eikä jättää puolitiehen?

 

[Melbac]

Mitäs eroa on nzr ja pam4 välillä eli pam4 korkeampi datansiirto nopeus ja pienempi latenssi?.Ei täällä mitään hiton mikropiirien suunnittelijoita olla.Tavallinen pulliainen taitaisi tajuta nämä jutut niin että 102 piirissä on muistit samalla piirillä kuin gpu(joka siis hoitaa näytön 3d yms jutut) ja 104 piirissä se gpu on erillisellä piirillä kuin ne muistit.

 

[autobiography]

Eikös se ollut niin, että ennakkomyyntiä näille ei ollut?

Kyllä, saa tilata vasta julkaisupäivänä.

 

[Kaotik]

Mitäs eroa on nzr ja pam4 välillä eli pam4 korkeampi datansiirto nopeus ja pienempi latenssi?.Ei täällä mitään hiton mikropiirien suunnittelijoita olla.Tavallinen pulliainen taitaisi tajuta nämä jutut niin että 102 piirissä on muistit samalla piirillä kuin gpu(joka siis hoitaa näytön 3d yms jutut) ja 104 piirissä se gpu on erillisellä piirillä kuin ne muistit.

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.

 

[zepi]

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.

 

[Kaotik]

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.

 

[Norwood]

Eikös se ollut niin, että ennakkomyyntiä näille ei ollut?

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ä.

 

[djtob]

Voihan... No, ei sille mitään voi. Joudutaan sitten odottamaan pari päivää lisää. Hyvää siinä on, että te siellä voitte rauhassa jyystellä erilaisia testejä sillä uutuudella. Kiinnostaisi lukea artikkelia jo sen takia, että mitä te pojat olette uutta keksineet testeihinne?

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.

 

[UX]

Melko rajattu ihmisjoukko on se, joka omaan harrastuskäyttöön ostaa yli 500€ näytönohjaimen. Veikkaan, että köyhemmät rendaajat, crypto-mainaajat ja jokuset tieteellisen laskennan työläiset näitä hommaa. Voihan olla, että pelaajat seuraa näitä uutisia kaikkein suurimmalla innolla ja tää ennakkotilauskielto vaan mahdollistaa sen, että pelaajille riittää näitä paremmin.

 

[SShadow]

Tuonne näyttää hyvin mahtuvan vielä 3080 Ti 11GB muistilla, kunhan sopivia kiviä tulee tehtaalta ulos myytäväksi asti, eli ensi vuonna?
Ja siellä 3090 Superi kaikki ytimet ehjänä.

 

[hkultala]

"NVIDIA ei vielä toistaiseksi julkistanut GeForce RTX 3060- ja 3050-malleja. "

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.

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.

 

[jive]

Ja esim. elokuvissa säteenjäljitystä pon käytetty jo yli 10 vuotta, niissä se ei ollut turhake viime vuosikymmenelläkään.

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.

 

[jive]

Melko rajattu ihmisjoukko on se, joka omaan harrastuskäyttöön ostaa yli 500€ näytönohjaimen. Veikkaan, että köyhemmät rendaajat, crypto-mainaajat ja jokuset tieteellisen laskennan työläiset näitä hommaa. Voihan olla, että pelaajat seuraa näitä uutisia kaikkein suurimmalla innolla ja tää ennakkotilauskielto vaan mahdollistaa sen, että pelaajille riittää näitä paremmin.

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.

 

[hkultala]

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.

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.

Joku vokselipohjainen idea se lopulta varmaankin tulee olemaan kunhan sellainen saadaan aikaiseksi.

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ää.

 

[Low Life]

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.

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.

 

[PÌÎUW®[ªøËrhl¾ÇÌ°1¿¼]

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.

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.

 

[aop]

Ja säteenjäljitys toimii nimenomaan siten miten OIKEA TÄMÄN MAAILMAN FYSIIKKA toimii.

Voiko tuolla mallintaa valon aaltoluonnetta mitenkään? Jos ei diffraktiota pysty toteuttamaan, niin aika lailla jää vielä valaistus epätäydelliseksi.

 

[PÌÎUW®[ªøËrhl¾ÇÌ°1¿¼]

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.

 

[hkultala]

Voiko tuolla mallintaa valon aaltoluonnetta mitenkään? Jos ei diffraktiota pysty toteuttamaan, niin aika lailla jää vielä valaistus epätäydelliseksi.

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.

 

[jabbadap]

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.

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?

 

[jive]

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.

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.

 

[DiamondTear]

Onkohan tuo 3090:n epätäydellisyys siitä johtuvaa, että yield ei olisi ollut tarpeeksi hyvä jos olisi koko piiri käytössä?

 

[hkultala]

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ä.

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.

 

[jive]

Totta. Haastan miettimään miten pelaajan kädessä pitämän kynttilän valaisema näkymä mallinnetaan kun valonlähde, kamera ja näkymän liikkuvat objektit kaikki liikkuvat suht vapaasti toisiinsa nähden, puhumattakaan ns. elävän valon loimun kuvaamisesta. Puuttuu enää väreilevä vedenpinta ja vedessä uivat kalat niin ollaan lähellä pahinta mahdollista kohtausta.

 

[zepi]

Totta. Haastan miettimään miten pelaajan kädessä pitämän kynttilän valaisema näkymä mallinnetaan kun valonlähde, kamera ja näkymän liikkuvat objektit kaikki liikkuvat suht vapaasti toisiinsa nähden, puhumattakaan ns. elävän valon loimun kuvaamisesta. Puuttuu enää väreilevä vedenpinta ja vedessä uivat kalat niin ollaan lähellä pahinta mahdollista kohtausta.

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.

 

[jive]

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.

 

[zepi]

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.

 

[jive]

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.

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.

 

[zepi]

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?

 

[jive]

Minecraft? No toisaalta jos oma ehdotukseni oli se haasteellisin niin paljon helpompaa kuin Minecraft on vaikea keksiä.

 

[finWeazel]

Kai cyberpunk2077 ja vampire bloodlines2 on ne lähitulevaisuuden pelit, jotka myy ray tracing kortteja. Witcher3:en tuleva raytrace päivitys kiinnostaa myös. Mulla witcherin lisäosat jääneet pelaamatta niin ne vois pelailla ray trace päällä. Konsoleissa ja amd:n tulevissa grafiikkapiireissä onmyös ray tracing olemassa niin ei tässä enää kannata pyristellä vastaan.

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ä.

 

[zepi]

Minecraft? No toisaalta jos oma ehdotukseni oli se haasteellisin niin paljon helpompaa kuin Minecraft on vaikea keksiä.

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.

 

[jive]

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.

 

[finWeazel]

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ä.

 

[jive]

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.

 

[finWeazel]

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.

 

[Kaotik]

edit. Siellä nvidian raudassa on erikseen kuutioille ja kolmioille prosessointi. Ikävä kyllä dxr ei ole se optimaalinen api minecraft tapauksessa.

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ä.

 

[finWeazel]

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ä.

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?

 

[Griffin]

Mitä hyötyä kuutioista olisi? Pinnan kulma pitää silti tietää. Ja heijastus laskea..

 

[pomk]

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.

 

[finWeazel]

Mitä hyötyä kuutioista olisi? Pinnan kulma pitää silti tietää. Ja heijastus laskea..

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.

 

[jive]

Siinä sellainen vokselipohjainen piirtomalli sitten olisi

 

[hkultala]

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.

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.

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.

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.

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.

Geometriadatan määrä ei säteenjäljityksellä ole mikään ongelma, kun törmäystarkastusten määrä skaalautuu logaritmisesti , kiitos BVH-puun.[/quote]

 

[finWeazel]

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.

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.

 

[hkultala]

Mieti minecraftia ennemminkin voxeli implementaationa missä ei tarvita kolmioita ja rakenteet on optimoitu sen päälle.

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.