Katsaus AMD:n RDNA2-grafiikka-arkkitehtuuriin

[Kaotik]

Kaotik kirjoitti uutisen/artikkelin:
AMD esitteli uudet RDNA2-arkkitehtuuriin perustuvat Radeon RX 6000 -sarjan näytönohjaimet lokakuun lopulla. Yhtiö esitteli aluksi kolme näytönohjainta, joista Radeon RX 6800 ja RX 6800 XT saapuivat myyntiin 18. marraskuuta ja suorituskykyisin malli RX 6900 XT on tulossa 8. joulukuuta. Käymme tässä artikkelissa läpi uudistetun RDNA2-grafiikka-arkkitehtuurin ominaisuudet sekä tutustumme ”Big Navi”- eli Navi 21 -grafiikkapiiriin.

• Lue testiartikkeli: AMD Radeon RX 6800 & 6800 XT
  

RDNA2-grafiikka-arkkitehtuuri



Uusi RDNA2-arkkitehtuuri tuo AMD:n näytönohjainten ominaisuudet samalle tasolle uusimpien standardien kanssa eli mukana on tuki DirectX 12 Ultimate -rajapinnalle kaikkine ominaisuuksineen sekä tulevalle DirectStorage-rajapinnalle. Täysin uutena ominaisuutena mukana on uusi L3-tason Infinity Cache -välimuisti, joka kasvattaa näytönohjainten käytössä olevaa muistikaistaa merkittävästi.



AMD:n mukaan uusi arkkitehtuuri parantaa energiatehokkuutta 54 % edeltävään RDNA-arkkitehtuuriin nähden. Luku on saavutettu nostamalla grafiikkapiirin kellotaajuuksia prosessoripuolelta saatujen oppien ja arkkitehtuurioptimointien avulla, parantuneilla virransäästöominaisuuksilla sekä suorituskykyä per kellojakso parantavin muutoksin. Yhtiön mukaan esimerkiksi Compute Unit -yksiköt toimivat nyt 1,3-kertaisella kellotaajuudella samalla tehonkulutuksella RDNA-arkkitehtuuriin verrattuna.



Navi 21-grafiikkapiiri (Big Navi)

[gallery link="file" ids="55325,55323,55327"]

Navi 21 rakentuu yhteensä 26,8 miljardista transistorista ja se valmistetaan TSMC:n 7 nanometrin valmistusprosessilla. Piisirun pinta-ala on 519,8 neliömillimetriä ja sen sisälle on saatu mahdutettua käskyjä suoritettavaksi jakava Command Processor, neljä Shader Engineä, neljän megatavun L2-välimuisti ja 128 megatavua Infinity Cache- eli L3-välimuistia sekä 256-bittinen GDDR6-muistiohjain. Infinity Cache -välimuisti on jaettu neljään 32 megatavun lohkoon, joista kukin on yhdistetty neljään 16-bittiseen muistiohjaimeen.

Command Processor muodostuu tässä sukupolvessa yhdestä grafiikkatehtäviä jakavasta Graphics Enginestä, Geometry Processor -yksiköstä ja neljästä laskentatehtäviin erikoistuneesta Async Compute Enginestä. Kukin Shader Engine rakentuu yhteensä kymmenestä Dual Compute Unit- eli 20 Compute Unit -yksiköstä, neljästä RB+:ksi ristitystä ROP-yksiköstä, rasteroijasta, primititiivi-yksiköstä ja niiden L1-välimuisteista. Lisäksi sirulta löytyvät PCI Express 4.0 x16 -väylä, multimediayksiköt sekä näyttöohjain. Piirin sisäisenä väylänä toimii Infinity Fabric -verkko.



Radeon RX 6900 XT:ssä on käytössä täysi Navi 21 -grafiikkapiiri 80 CU-yksiköllä ja 5120 stream-prosessorilla. 6800 XT:ssä CU-yksiköitä on karsittu pois käytöstä 8 ja 6800:ssa 20 kappaletta, joka vaikuttaa myös säteenseurannasta vastaavien Ray Acceleration- ja teksturointiyksiköiden lukumäärään. 6800-mallissa on lisäksi alhaisemmat kellotaajuudet ja vähemmän ROP-yksiköitä. Kaikki mallit on varustettu 256-bittisellä muistiväylällä, 16 gigatavun GDDR6-näyttömuistilla ja 128 megatavun Infinity Cache -välimuistilla. Mielenkiintoisena huomiona 6900 XT- ja 6800 XT -malleilla on sama 300 watin TDP-arvo.



Compute Unit -yksikkö

[gallery link="file" columns="2" size="medium" ids="55321,55322"]

RDNA2-arkkitehtuurin uusissa Compute Unit -yksiköissä rakenne on pysynyt pääosin ennallaan. Yhdessä CU-yksikössä on 64 stream-prosessoria, skeduleri (vuorontaja), skalaariyksiköitä, joukko välimuisteja sekä neljä teksturointiprosessoria. Uutena ominaisuutena teksturointiprosessoreihin on lisätty uusi Ray Acceleration -yksikkö, joka kiihdyttää säteenseurantaa. Sirun yhteensä kahdeksan RB+-ROP-yksikköä toimivat kaksinkertaisella nopeudella aiempaan nähden, jonka myötä koko sirun RB+-yksiköt vastaavat 128 vanhaa ROP-yksikköä.

Compute Unit -yksiköt kykenevät suorittamaan FP32-tarkkuuden laskuja natiivinopeudella 128 käskyä kellojaksossa per CU ja FP16-tarkkuudella 2:1-nopeudella 256 käskyä kellojaksossa. AMD on ottanut mukaan myös aiemmin vain osasta piirejä löytyneen kyvyn laskea INT8-tehtäviä 4:1 ja INT4-tehtäviä 8:1-nopeudella. FP64-tarkkuus on tuettu vain 1:16-nopeudella.



Ray Acceleration -yksikkö ja DirectX 12 Ultimate -ominaisuudet

[gallery link="file" columns="2" size="medium" ids="55312,55310"]

AMD:n säteenseuranta-arkkitehtuuri perustuu uuteen Ray Acceleration -yksikköön, joka laskee säteiden törmäystarkistukset BVH-puun kanssa sekä törmäysaikojen järjestelyn. BVH-puussa eteneminen sekä tietenkin varsinainen säteiden piirto hoidetaan stream-prosessoreilla. Vertailun vuoksi NVIDIAn ratkaisussa myös BVH-puussa eteneminen tapahtuu RT-ytimen sisällä.

AMD:n säteenseurantakiihdytys kykenee laskemaan neljä säteen laatikkotörmäystä tai yhden säteen kolmiotörmäyksen kellojaksossa per Compute Unit -yksikkö. Infinity Cache -välimuisti puolestaan säästää myös säteenseurannassa muistikaistaa, sillä yhtiön mukaan suuri osa BVH-puun käyttödatasta voidaan säilyttää nopeassa välimuistissa.

[gallery link="file" ids="55309,55311,55313"]

Mesh-varjostimet ovat DirectX 12 Ultimaten uusi vaihtoehto geometrian prosessointiin. Mesh-varjostimet noudattavat grafiikkatehtävien sijasta laskentatehtävien ohjelmointimallia ja ne mahdollistavat kompaktien mallien luomisen rasterointiyksikön tarpeisiin suoraan grafiikkapiirillä. Niiden avulla voidaan muun muassa optimoida varjostusta poistamalla näkymättömiä pintoja työlistalta aiempaa tehokkaammin.

Vaihteleva varjostustarkkuus eli Variable Rate Shading tai VRS on suunniteltu parantamaan suorituskykyä varjostamalla osia ruudusta normaalia matalammalla tarkkuudella. AMD:n VRS-toteutus tukee normaalin 1x1-tarkkuuden lisäksi matalampia 2x1, 1x2 ja 2x2-tarkkuuksia.

Sampler Feedback Streaming on puolestaan suunniteltu parantamaan tekstuureiden streamausta. Se pienentää muistikaistan tarvetta selvittämällä jo ennakkoon, mitä osia esimerkiksi kustakin tekstuurista tarvitaan, jolloin se voidaan ladata muistiin ennakkoon ja jättää tarpeettomat osat lataamatta. Ominaisuuden avulla voidaan optimoida tulevien ruutujen rendeöröintiurakoita entistä tehokkaammiksi.



Infinity Cache



Grafiikkayksiköiden aiempaa parempi suorituskyky vaatii tuekseen sen mukana kasvavan muistikaistan. Muistikaistan kasvattaminen on kuitenkin haastavaa; leveämmät muistiväylät vaativat suurempikokoisen grafiikkapiirin fyysisten liitäntäpintojen mahduttamiseksi mukaan ja nopeampien muistien saatavuus on heikoissa kantimissa. GDDR6X-muistit eivät olleet saatavilla ajoissa RDNA2:n kannalta ja HBM-muistit nostavat puolestaan kustannuksia muun muassa niiden vaatiman interposer-alustan takia.

Myös välimuistien kasvattaminen kasvattaa piirien kokoa ja siten hintaa, mutta AMD näki myös tässä mahdollisuuden hyödyntää prosessoripuolen osaamista. AMD:n mukaan Zen 2 -arkkitehtuurissa käytettävää välimuistia mahtuu samaan pinta-alaan nelinkertainen määrä yhtiön grafiikkapiireissä käytettyyn L2-välimuistiin nähden, joten sen hyödyntäminen mahdollisti merkittävästi suuremman välimuistin samaan hintaan.

[gallery link="file" ids="55317,55318,55319"]

AMD päätyi Navi 21:ssä 128 megatavun kokoiseen Infinity Cacheksi ristittyyn L3-välimuistiin. Yhtiön testien mukaan 128 Mt:n L3-tason välimuistin osumaprosentti olisi Full HD -resoluutiolla noin 80 %, 1440p-resoluutiolla vajaat 75 % ja 4K-resoluuutiolla keskimäärin 58 %. Suurempi välimuisti nostaisi osumaprosenttia entisestään 4K-resoluutiolla, mutta parannukset 1440p- ja etenkin Full HD -resoluutioilla lisämuistista jäisivät marginaalisiksi.

Välimuistin hyödyt eivät jää vaan kasvaneeseen muistikaistaan, vaan AMD:n testien mukaan se tehostaa myös suorituskyvyn kasvua, kun grafiikkapiirin kellotaajuutta nostetaan. Yhtiö ei julkaissut valitettavasti tarkkoja prosentteja, mutta yhtiön julkaiseman dian mukaan ero Infinity Cachella varustetun RDNA2-grafiikkapiirin ja L3-välimuistittoman RDNA2-grafiikkapiirin välillä kasvaa sitä enemmän, mitä korkeampi kellotaajuus on. Lisäksi Infinity Cache kutistaa muistihakujen viiveitä parhaimmillaan 48 % ja keskimäärin 34 % verrattuna viime sukupolven 14 Gbps:n GDDR6-muistiehin ja 256-bittiseen muistiväylään verrattuna. Nopeampien muistien myötä muistihakujen viiveet GDDR6-muistista ovat myös aiempaa matalammat, mutta ero jää selvästi alle 20 %:iin.

[gallery link="file" columns="2" size="medium" ids="55320,55315"]

Suorituskyvyn ohella Infinity Cache -välimuisti parantaa myös piirin energiatehokkuutta, sillä muistihaut sieltä vaativat tehoa vain 1,3 pikoJoulea, kun GDDR6-muistihaut vievä 7-8 pJ. AMD:n laskelmien mukaan välimuisti yhdistettynä 256-bittiseen GDDR6-muistiin tarjoaa parhaimmillaan 2,4-kertaisesti muistikaistaa per watti, kun verrokkina on 384-bittinen GDDR6-muisti ilman Infinity Cache -välimuistia.

Navi 21 -grafiikkapiirin 128 megatavun Infinity Cache toimii oletuksena 1,4 GHz:n peruskellotaajuudella ja se on yhdistetty L2-välimuisteihin ja siten muuhun grafiikkapiiriin 8192-bittisellä (16 x 64 tavua) Infinity Fabric -väylällä. Peruskellotaajuudella toimiessaan välimuisti tarjoaa siis muistikaistaa noin 1,43 Tt/s ja 1,94 GHz:n Boost-kellotaajudella1,99 Tt/s. Jo RDNA2-arkkitehtuurin julkaisussakin nähdystä diasta laskettu 1,15 Tt/s:n arvioitu kaista perustuu ilmeisesti realisoituvaan muistikaistaan teoreettisen maksimin sijasta.



Loppusanat

Viimeistään RDNA2-arkkitehtuuri osoittaa AMD:n saaneen uuden vaihteen silmään näytönohjainmarkkinoilla. Uusi arkkitehtuuri parantaa samalla valmistusprosessilla grafiikkapiirin energiatehokkuutta yli 50 %, mitä voidaan pitää näytönohjainmarkkinoilla merkittävänä saavutuksena yhdessä sukupolvessa. Saavutuksessa merkittävä rooli oli uudella Infinity Cache -välimuistilla, joka paitsi kasvattaa merkittävästi grafiikkapiirin käytössä olevaa muistikaistaa, myös laskee tehonkulutusta ja muistihakujen viiveitä.

AMD:n seuraava etappi näytönohjainpuolella on luonnollisesti pienempien Navi 22- ja Navi 23-grafiikkapiirien julkaisu todennäköisesti ensi vuoden alkupuolella. Sen jälkeen ensi vuoden lopulla tai vuonna 2022 luvassa on uusi RDNA3-arkkitehtuuri. Yhtiö on tähän mennessä varmistanut, että RDNA3-grafiikkapiirit tullaan valmistamaan tarkemmin määrittelemättömällä ”kehittyneellä valmistusprosessilla”. Arkkitehtuuritason mahdollisista muutoksista ei tässä vaiheessa vielä tiedetä mitään.

Linkki alkuperäiseen juttuun

 

[hkultala]

Nyt pisti silmään yksi asia:

AMDn slidessä mainitaan "high speed performance libraries" keinona parantaa tuota suorituskykyä (ja myös energiatehokkuutta).

High performance-kirjastojen käytön suora vaikutus energiankulutukseen tosin on tyypillisesti sitä nostava, mutta energiatehokkuuden suhteen tässä lienee kyse siitä, että kun sallitaan HP-kirjastojen komponenttien käyttö tietyissä kriittisissä paikoissa, niin kun tällä helpotetaan ajoituksia, niin että
1) synteesityökalun tarvii tehdä vähemmän optimointeja joissa tuotetaan monimutkaisempi mutta nopeampi logiikka niille kriittisille poluille
2) voidaan piiriä esim. ajaa samalla kellotaajuudella pienemällä jännitteellä.

Toisaalta, vuotovirrat on kyllä HP-kirjastoilla selvästi pahemmat, eli vaikka energiatehokkuus rasituksessa paranee, idlekulutukseen tämän vaikutus on todennäköisesti haitallinen.



Excavatorin yhteydessä AMD tosiaan mainosti käytännössä vastakohtaista myös virrankulutusoptimointina:

Toisaalta, mitä useammat kirjastot synteesityökalulla on käytössään, sitä enemmän sillä on valinnanvaraa optimoida aina tilanteen mukaan, valita tiettyihin paikkoihin komponentit jostakin kirjostosta, toisiin paikkoihin (jossa vaatimukset esim. nopeuden suhteen erilaiset) komponentit toisista kirjastoista.

 

[ratkakapu]

Nythän mä vasta hokasin, että tuo infinity cache on mahdollisesti konseptina keksitty alunperin APU-puolella ja leivottu mukaan näihin isoihin sitä kautta.

Nyt on siis huhuja 20CU APU-piiristä. Ilman cachea tuossa ei ole mitään järkeä, kun jopa 8CU näyttis on kaistarajoitteinen DDR4 muisteilla. Cachen kanssa kyseessä voi olla melko jytky

Kuinkahan paljon pinta-alaa 128Mt cache vie?

 

[demu]

Kuinkahan hyvin tuo Infinity Cache toimisi HBM/HBM2/HBM2e/HBMnext -muistiratkaisun kanssa?
Eiköhän sellainenkin tulla näkemään.

 

[zepi]

Kuinkahan hyvin tuo Infinity Cache toimisi HBM/HBM2/HBM2e/HBMnext -muistiratkaisun kanssa?
Eiköhän sellainenkin tulla näkemään.

Hyödyt HBM:n kanssa ovat paljon vähäisemmät, koska HBM:n energiatehokkuus on jo reippaasti parempi kuin GDDR:llä pJ/b mittarilla ja kaistaakin on tarjolla enemmän kuin GDDR:llä.

Tosin sillä varauksella, että piirin sisäinen cache + yhden stäckin HBM tietty riittää isommalle laskentakapasiteetille kuin yksi stäkki ilman cachea.

5nm:llä 64-128MB SRAM alkaa muodostua etenkin isoissa piireissä aika nobrainer ratkaisuksi. (Tosin välimuistia voi olla koko piirin sijaan myös CU tasolla jaettuna.)

 

[Kaotik]

Kuinkahan hyvin tuo Infinity Cache toimisi HBM/HBM2/HBM2e/HBMnext -muistiratkaisun kanssa?
Eiköhän sellainenkin tulla näkemään.

Infinity Cachen toiminta ei muutu mitenkään oli siellä muistiohjaimen perässä sitten vaikka SDR- tai HBM3-muistia, se istuu siis muistiohjainten ja muun grafiikkaohjaimen välissä ja muistiväylille mennään silloin kun cachesta ei löydy mitä haettiin.

 

[ratkakapu]

Kuinkahan hyvin tuo Infinity Cache toimisi HBM/HBM2/HBM2e/HBMnext -muistiratkaisun kanssa?
Eiköhän sellainenkin tulla näkemään.

Ei auttaisi juuri paljoakaan, koska silloin muistikaistaa on muutenkin saatavilla tarpeeksi.

Tosin hyötykäytössä tietysti tuollainenkin rakenne olisi varmaan mahdollista hyödyntää tehokkaasti, mutta pelikäytössä tuskin ilman kovaa optimointia

 

[demu]

Hyödyt HBM:n kanssa ovat paljon vähäisemmät, koska HBM:n energiatehokkuus on jo reippaasti parempi kuin GDDR:llä pJ/b mittarilla ja kaistaakin on tarjolla enemmän kuin GDDR:llä.

Tosin sillä varauksella, että piirin sisäinen cache + yhden stäckin HBM tietty riittää isommalle laskentakapasiteetille kuin yksi stäkki ilman cachea.

5nm:llä 64-128MB SRAM alkaa muodostua etenkin isoissa piireissä aika nobrainer ratkaisuksi. (Tosin välimuistia voi olla koko piirin sijaan myös CU tasolla jaettuna.)

Ajatuksena oli se, että kun HBM-muistin muistikellot ovat suhteellisen matalat, saataisiinko muistilatensseja parannettua suhteessa enemmän kuin nopeampia kelloja käyttävillä GDDR6-muisteilla?

 

[KVahlman]

Hassua että tossa infinity cache diassa on maininta että yli 64MB tarjoaa kyllä parempaa osumaprosenttia mutta "at a huge area cost". Ja sitten kuitenkin itse tuotteessa on tuplat. Vissiin sitten kuitenkin kannatti.

 

[Kaotik]

Hassua että tossa infinity cache diassa on maininta että yli 64MB tarjoaa kyllä parempaa osumaprosenttia mutta "at a huge area cost". Ja sitten kuitenkin itse tuotteessa on tuplat. Vissiin sitten kuitenkin kannatti.

Selitys on siinä tekstissä kuvaa ennen (ja olisi mainittu toisessa diassa mitä en uutiseen valinnut), tuossa diassa puhutaan GPU:ssa tyypillisesti käytettävästä välimuistista. AMD:n ratkaisu oli käyttää Zen 2:sta tuttua neljä kertaa tiiviimpää välimuistia, eli sitä saatiin 128 Mt samaan tilaan kuin 32 Mt jos se olisi samaa kuin GPU:n L2-välimuisti

 

[KVahlman]

Selitys on siinä tekstissä kuvaa ennen (ja olisi mainittu toisessa diassa mitä en uutiseen valinnut), tuossa diassa puhutaan GPU:ssa tyypillisesti käytettävästä välimuistista. AMD:n ratkaisu oli käyttää Zen 2:sta tuttua neljä kertaa tiiviimpää välimuistia, eli sitä saatiin 128 Mt samaan tilaan kuin 32 Mt jos se olisi samaa kuin GPU:n L2-välimuisti

Veisi se 64Mt silti puolet vähemmän tilaa kuin 128Mt, mutta ehkä se pinta-ala siinä kohtaa ei enää ole "huge" sitten joo. Olin näemmä hypännyt tuon kappaleen yli, kiitokset tarkennuksesta.

 

[Kaotik]

Veisi se 64Mt silti puolet vähemmän tilaa kuin 128Mt, mutta ehkä se pinta-ala siinä kohtaa ei enää ole "huge" sitten joo. Olin näemmä hypännyt tuon kappaleen yli, kiitokset tarkennuksesta.

Veisi toki, mutta 64 Mt ja yli on hyötyä vielä huomattavasti 4K:lla. Jos tuolla ei olisi tarkoitus pelata 4K:lla sitä olisi aika taatusti max se 64 Mt

 

[hkultala]

Nythän mä vasta hokasin, että tuo infinity cache on mahdollisesti konseptina keksitty alunperin APU-puolella ja leivottu mukaan näihin isoihin sitä kautta.

Intelillähän tuontyylinen oli erillisellä Crystell Well-piirillä jo monta vuotta sitten (mutta ei enää uusissa malleissa, koska intelin niissä käyttämä eDRAM ei skaalaudu uusille valmistustekniikoille, Crystall Well-piirit tehtiin "22nm" tekniikalla, tosin niitä paketoitiin vielä samaan pakettiin joidenkin "14nm" prosessorien kanssa)

Nyt on siis huhuja 20CU APU-piiristä. Ilman cachea tuossa ei ole mitään järkeä, kun jopa 8CU näyttis on kaistarajoitteinen DDR4 muisteilla. Cachen kanssa kyseessä voi olla melko jytky

Kuinkahan paljon pinta-alaa 128Mt cache vie?

Nykyisellä TSMCn "7nm" tekniikalla aika lailla neliömillimetrin/mega, eli n. 128M tekisi n. 128mm^2.

Mutta ei siinä 20 CUn APUssa 128 megaa tarvisi kun tavoiteresoluutiot on paljon pienempiä, framepuskurien koot on paljon pienempiä ja tekstuureistakin käytetään keskimäärin pienemmän resoluution MIP-MAPejä.

64 megaa olisi ehkä myös overkill ja pinta-alaltaan (n .64 mm^2) keskikokoiselle APUlle sekin liikaa, jo 32 megaa olisi huomattava apu jos resoluutio ei nouse 1920x1080 korkeammaksi. Mutta jos se meinaisi olla liian vähän, myös 48 megaa voisi olla myös vaihtoehto.


Mutta jos nuo huhut viittaa myöhemin tuleviin piireihin, niin TSMCn "5nm" tekniikalla HD-SRAM vie tilaa n. 0.78x siitä mitä "7nm:llä" eli 64 megaa olisi n. 50 mm^2, 48 megaa olisi n. 38mm^2 ja 32 megaa olisi n. 25mm^2.

 

[Griffin]

Kyllä nykyään toimistokoneisiinkin on syytä saada liitettyä kunnolla toimiva 4K näyttö tai 2-3 kpl 1440p näyttöä. Tietysti Työpöytä Exceli pyörähtää ilman noita kikkojakin, mutta on myös ohjelmia, joissa on sitten 3D:tä..
Onko noiden nopeiden (hbm) muistien integrointi prossun viereen todellakin niin kallista, että ei kannata käydä myymään prossuja, joissa olisi 8 - 32 gigaa HBM:ää?
Eihän noita monia läppäreitä muutenkaan nykyisin laajennella, kun pahimmillaan kaikki muisti on tinattu emolle..

 

[Kaotik]

RDNA2:n ISA julki

https://developer.amd.com/wp-content/resources/RDNA2_Shader_ISA_November2020.pdf

 

[hkultala]

RDNA2:n ISA julki

https://developer.amd.com/wp-content/resources/RDNA2_Shader_ISA_November2020.pdf

Piti heti katsoa millainen tuo säteenjäljityksen käskykanta on, sivu 80, ja siellä on käskyt

IMAGE_BVH64_INTERSECT_RAY,IMAGE_BVH_INTERSECT_RAY

(ainoa ero näissä on että BVH-puun osoitteet on 32 vs 64 bittiä)

Tuo käsky lukee sisään 4 skalaarirekisteriä ja 8-12 vektorirekisteriä , ja palauttaa 4 vektorirekisteriä.

Skalaarirekisterissä on asetukset/tarkempaa mode-tietoa että mitä tarkkaanottaen tehdään, vektorirekistereissä on sitten säteiden geometriat ja osoite BVH-puun nodeen

Sama käsky tarkastaa osumat sekä laatikkonodeen että kolmionodeen eikä kutsujan tarvi tietää, kummasta on kyse. Laatikkonode sisältää neljän laatikon geometriat(radix4-puu), kolmionode sisältää yhden kolmion.
Jos kyseessä on laatikkonode, niin:
1) tarkastetaan osumat kaikkiin neljään laatikoon, ja kaikkien laatikoiden osumaflagit sekä lapsilaatikoiden osoitteet palautetaan. Jos osutaan moneen laatikkoon, osumat sortataan.
2) Kolmionodesta palautetaan tarkka osumapaikka ja kolmio-id, tai ei osumaa-flagi.


Mutta, koska nuo geometriat tulee sisään vektoreinta, tarkoittaa se sitä, että yksi kutsu tähän käskyyn ei tee vain neljää laatikkotarkastusta vaan kokonaisuudessaan 4*32=128 tai 4*64=256 laatikkotarkastusta, ja sitä suoritetaan 32 tai 64 kellojakson ajan kussakin säteenjäljitysyksikössä (riippuen ollaanko 32- vai 64-leveässä moodissa)

8-12 input-rekisterin lukeminen kuitenkin kestää yhdeltä säikeeltä vain n. 4-12 kellojaksoa, joten kun yksi säie laukoo säteenjäljitysoperaation, se voi mennä nukkumaan pitkäksi aikaa ja toinen säie voidaan siirtää ajoon sen tilalle.

Jossain aiemmassa viestissäni virheellisesti oletin, että uusi käsky tarvii antaa joka kellojakso ja sen perusteella sanoin, että säteenjäljityskäskyjen käynnistäminen täydellä teholla syö puolet shader-prosessorin laskentakapasiteetista. Todellinen onkin n. 5-8 kertaa vähemmän , eli näiden käskyjen pelkkä käynnistäminen "tuhlaa" shader-tehoa vain n. 6-8%.

Eli se, että säteenjäljityskäskyjen käynnistäminen söisi laskentaresursseja shadereilta ei siis ole mikään käytännön ongelma.

Kutsujan pitää kuitenkin tarkastaa paluuarvot sekä mahdollisesti huolehtia siitä, 1) että talletetaan kaukaisempien törmänneiden laatikoiden node-osoitteet koska niitä voidaan vielä tarvita jos lähempien laatikoiden sisempien laatikoiden tai kolmioiden kaikki tarkastukset failaa 2) kun tulee täysi huti, kaivaa esille näitä kauempana olevia laatikoita.

Se, että tämä kaikki tehdään 32 tai 64 levyiselle SIMDille kerralla toisaalta tekee tästä siihen vekslaukseen kuluvan ajan suhteen melko tehokasta, eikä tähänkään pitäisi kulua juurikaan shader-tehoa,
mutta toisaalta se myös laittaa omat optimointihaasteensa AMDn ajureille, että miten se saadaan tehtyä optimaalisesti, ja huonontaa koko homman hyötysuhdetta:

Triviaali-implementaatiolla voisi käydä (ja välillä käykin) siten, että yhden 32-kokoisen wavefrontin 31 linjaa on löytänyt lähimmän laatikon ja saa puun käytyä läpi esim. 12 askeleessa, mutta yhden linjan säde failaa puun lehtihaaroissa ja joutuu palaamaan BVH-puussa pariin kertaan paljon ylemmälle tasolle ja käyttääkin vaikka 30 askelta. Ja kun kaikki 32 sädettä on samassa wavefrontissa ja SIMD-vektorissa, ne 31 muuta linjaa sitten idlaa/laskee tyhjää kun yhden takia mennään sakkokierroksille.



ja se, että säteenjäljitysyksiköt on integroitu TMUIhin on kuitenkin todellinen suorituskykyyn hidastavasti vaikuttava tekijä, jos shadereilla halutaan esim. accessoida tekstuuria jonka väriarvon perusteella lasketaan lopullinen väriarvo, tai jonka sisältävän pintadatan perusteella lasketaan toisiosäteen suunta, tämä kilpailee lataus-yksiköistä säteenjäljitysyksiköiden kanssa.

Tämä voi olla kuitenkin järkevä tradeoff; Täysin erilliset säteenjäljitysyksiköt olisivat todennäköisesti tulleet paljon kalliimmiksi eikä niitä olisi ehkä samaan pinta-alan voitu laittaa läheskään näin suurta määrää.

 

[hkultala]

Kyllä nykyään toimistokoneisiinkin on syytä saada liitettyä kunnolla toimiva 4K näyttö tai 2-3 kpl 1440p näyttöä. Tietysti Työpöytä Exceli pyörähtää ilman noita kikkojakin, mutta on myös ohjelmia, joissa on sitten 3D:tä..

Ei se välimuistin määrä rajoita millään tavalla sitä, mitkä resoluutiot toimii. Se vaikuttaa ainoastaan suorituskykyyn, suorituskyky putoaa enemmän suurilla resoluutioilla.

Ja toimistosoftat ei tarvi paljoa näyttissuorituskykyä.

Ja esim. windows on ties kuinka monen vuoden ajan piirtänyt KAIKEN käyttäen sitä näyttiksen 3d-rautaa.

Onko noiden nopeiden (hbm) muistien integrointi prossun viereen todellakin niin kallista, että ei kannata käydä myymään prossuja, joissa olisi 8 - 32 gigaa HBM:ää?
Eihän noita monia läppäreitä muutenkaan nykyisin laajennella, kun pahimmillaan kaikki muisti on tinattu emolle..

Ensinnäkin, HBMn tapauksessa toistaiseksi vielä on:

AMDllä ei ole (vielä) käytössään paketointitekniikka jolla se voisi käyttää HBM(2)-muistia ilman interposeria, ja se interposer maksaa paljon.

Tämä on kuitenkin muuttumassa, mutta en tiedä, millä aikataululla.

Ja sinne CPUn kanssa samaan pakettiin voisi myös tunkea esim. 192 tai 256 bitin leveydeltä jotain LPDDR4sta, ja saada sillä selvästi kaistaa lisää nykyisiin CPuihin verrattuna.

Toisekseen:

Oleellinen kysymys on, että olisiko se nopea muisti pelkälle näyttikselle, vai myös CPUlle.

1) Sen antaminen pelkän näyttiksen käyttöön tarkoittaisi sitä, että moni asia toimisi paljon epäoptimaalisemmin kun CPU ja GPU ei voi vaan accessoida samaa muistia saumattomasti. On paljon sellaista rinnakkaislaskentaa, joka kannattaisi laskea näyttisydinten tapaisilla ytimillä, mutta joita ei kannata alkaa kopioimaan näyttiksen muistiin, kun kopioiminen tuhlaa enemnän virtaa ja aikaa kuin itse laskenta.

Kun CPU ja GPU käyttävät samaa muistia, tällaiset asiat voidaan laskea tehokkaasti GPUlla.

2) Sen käyttäminen koko järjestelmän keskusmuistina tarkoittaisi sitä, että sitä keskusmuistia ei voisi laajentaa. Tämä ei oikeasti olisi suuri ongelma, kunhan vaan sitä muistia alunperin laitettaisin tarpeeksi, mutta AMD eikä Intel ei kumpikaan tunnu uskaltavan tehdä ratkaisuija, joiden muistimäärää ei voi laajentaa.

Mutta toivottavasti Applen esimerkki nyt antaa AMDlle ja Intelillekin rohkeutta tässä asiassa.



Oma visioni on, että pitäisi siirtyä muistiratkaisuihin, joissa kaikki DRAM on prosessorin kanssa samassa paketissa ja olisi siis melko suurella kaistalla. Määrä olisi alkuun esim. 16 gigaa, ja se olisi sekä CPUn että integroidun GPUn käytettävissä. Tämän lisäksi olisi sitten muistikammoilla joku (aluksi n.) 128 gigaa jotain NVRAMia. 64-bittinen rajapinta tänne riittäisi.

NVRAM siis toimisi sekä nopeana säilömuistina, jonne on asennettu käyttis sekä eniten käytetyt softat että myös RAMina. Koska se olisi NVRAMia, softia voi suoraan ajaa sieltä kopioimatta niitä DRAMiin. Tämä vähentäisi DRAMin kulutusta paljon, joten se 16 gigaa riittäisi pitkälle. Ja jos se 16 gigaa RAMia alkaisi loppua kesken, harvemmin käytettyä dataa vaan siirrettäisiin sinne NVRAMiin (josta sitä voisi kuitenkin edelleen suoraan käyttää ilman sen swappaamista takaisin DRAMiin).

 

[Griffin]

Eikös HBM3 (Jonka olisi alumperin pitänyt tulla tänä vuonna) pitäisi mahdollistaa kapeammat, mutta nopeammat väylät s.e. piisirut saadaan samalle alustalle, kuten ZEN prossuissa, eli ei tarvita kallista piipalaa siihen väliin..

Mitä lie käynyt ko projektille, kun ei ole tainut kuulua mitään...?

Eikös se uusin variaatio HBM 2:sesta sallinut jo jotain 24 Gigaa yhteen pinoon? Senhän pitäisi olla enemmän, kuin tarpeeksi, kaikkeen peruskäyttöön ja pelailuun ym. Sain sen käsityksen, jotta HBM2:n kanssa se vlipalikka olisi jotan 20$:n luokkaa hinnaltaan. Ei se nyt niin kauhean kalliilta kuulosta, jos lopputuloksena olisi oikeasti hyvä tuote.

Sen käsityksen olen saanut, että HBM:llä pitäisi saada kaistaa pienemmällä virrankulutuksella, joten se olisi hyvä nimenomaan johonkin läppäriin.. Jos tuollaisia prossuja tulisi, niin erillis näyttikset läppäreissä muuttuisivat melko harvinaisiksi, kun prossuun saisi helposti näyttiksen, joka oikeasti pyörittelisi 1440P:llä kaikkia nykyisiä pelejä kohtuullisen ok.