RDNA4-arkkitehtuurista ja säteenjäljityksestä:
RDNA2ssa ja RDNA3ssa säteenjäljityksen BVH-puun läpikäynti tehtiin softalla shader-ytimillä, kun se nvidian piireillä tehdään raudalla.
Ennen RDNA4n julkaisua mietittiin, että josko AMD nyt siirtyisi rautaratkaisuun puun läpikäynnissä, että saadaan shader-kuormaa alas, mutta tätä ei vieläkään tapahtunut.
Säteenjäljitysten törmäystarkastusnopeus RDNA4ssa kuitenkin tuplattiin, ja jos tämä tuplaus olisi tehty vain suoraan säteenjäljitysyksiköiden määrää korkealla tasolla kasvattamalla, ja jäljittämällä useampaa sädettä rinnakkain, shader-kuormitus olisi vaan kasvanut.
Mutta: Tämä törmäystarkastusten nopetus tehtiin tavalla, joka ei lisännyt sitä shader-kuormitusta, samalla shader-kuormituksella saadaan nyt tarkastettua tuplamäärä laatikoita.
RDNA2- ja RDNA3-sukupolvissa BVH-puu oli radix4-tyyppinen (quadtree), eli jokaisella laatikolla oli maksimissaan 4 alilaatikkoa.
Eli jos vaikka meillä oli 64 matalimmin tason (0-tason) laatikkoa, niin korkeimman tason laatikko sisältää 4 toiseksi korkeimman tason laatikko, toiseksi korkeimman tason laatikot sisältävät kukin 4 kolmanenksi korkeimman tason latikkoa (4*4=16), nämä 16 kolmanneksi korkeimman tason laatikkoa sisältävät kukin 4 matalimman tason laatikkoa (4*16 = 64)
Ja sitten törmäystarkastusyksiköt oli organisoitu siten että ne pystyy tarkastamaan laatikon kaikki 4 alilaatikkoa kerralla, joka kellojakso yksi taso puuta, 4 laatikkotarkastusta(*)
RDNA4ssa BVH-puu muutettiin radix4-muodosta radix-8-muotoon (octree)
Eli 64 0-tason laatikkoa talletettaisiinkin puuhun tavalla, että korkeimman tason laatikko sisältää 8 toiseksi korkeimman tason laatikkoa, nämä 8 kukin sisältävät 8 matalimman tason laatikkoa (8*8=64)
Samalla törmäystarkastusykiköitä muutettiin siten, että ne pystyvät kerralla tekemään 8 laatikkotarkastusta keralla yhdessä kellojaksossa, eli edelleen yhden tason verran puuta
Tällöin puusta tarvii käydä läpi vain kaksi tasoa kolmen sijaan että saavutaan sen 0-tasolle.
Tästä kun vähän laskee, niin tajuaa, että vaikka törmäystarkastusten teoreettinen maksimimäärä kellojaksossa kasvoi kaksinkertaiseksi, puun läpikäynti nopeutuikin vain 1.5-kertaisesti perustapauksessa, jossa puuta pitää jäljittää vain yhteen lehteen.
Mutta: ei pidä ajatella, että nyt "laskentatehoa menee hukkaan" koska 2x laskentateholla saadaan usein vain 1.5x nopeutus, koska se raaka laskentateho ei yleensä ole se pullonkaula.
Se mikä on kallista on kaikki monimutkaisuus, erilliset muistiaccessit, kaiken kontrollioverhead jne. Ja nyt puut läpikäydessä myös erillisten muistiaccessien ja kontrollioperaatioiden määrä putoaa 33%, joskin ne muistiaccessit on nyt tuplasti leveämpiä.
AMDlle oli käytännössä helpompaa ja halvempaa tuplata niiden törmäystarkastusyksiköiden järeys laittamalla ne tekemään kerralla 8 tarkastusta ja syöttämällä niille tuplamäärän dataa(samasta lähteestä, helpolla leveällä latauksella) kuin mitä olisi ollut saada millään keinolla käytyä puuta läpi 1.5-kertaisella nopeudella millään muulla tavalla.
ja lisäksi, usein se säde osuu moneen laatikkoon että pitää tarkastaa useita lapsilaatikoita. Silloin tuo nopeutus radix-4-puun ja radix-8-puun välillä helposti parempi kuin tuo 1.5x.
(*) Käytännössä yksittäiseltä säikeeltä siihen tarkastukseen ja puun alilaatikoiden hakemiseen muistista menee kyllä useampi kuin yksi kellojakso (viive >1 kellojakso), mutta tämä homma on liukuhihnoitettu ja monisäikeistetty, että lasketaan montaa säiettä limittäin ja joka kellojakso voidaan jollekin säikeelle aloittaa nämä törmäystarkatukset.