AMD-spekulaatioketju (RDNA:n ja CDNA:n tulevat sukupolvet)
- Liittynyt
- 12.12.2016
- Viestejä
- 4 620
Sama kortti voi hyvin olla muuallakin ovh-hintainen, mutta kolmas piuha toki ok valinta sekin tässä tapauksessa
- Liittynyt
- 22.10.2019
- Viestejä
- 354
Joo, katsotaan minkä onnistuu saamaan, jos minkään. Luulin, että Pulse olis ollu noita ovh-malleja, mutta se meneekin yli 800 euron. Hellhoundin hintaa en vielä ole löytänyt.
Vaan toki ei haluais huonoa laatuakaan ostaa, että ehkä se ASUS jää hyllyyn ja nöyrtyy vielä muutaman kympin budjetin ylittämiseen.
Viimeksi muokattu:
- Liittynyt
- 22.10.2019
- Viestejä
- 354
Jaaha, ilman taidettiin jäädä. Jäin ostamaan Datatronikista Reaperia 720 eurolla ja pääsin jo kirjottamaan osoitetta, kunnes lensin jotenkin ulos jonosta ja se oli sitten siinä. Muuallakin enää pelkkää ei-oota.
Milloinkohan noita mahtaa tulla lisää ja nousevatkohan hinnat noista mitkä eivät olleet nyt ovh:lla?
Milloinkohan noita mahtaa tulla lisää ja nousevatkohan hinnat noista mitkä eivät olleet nyt ovh:lla?
- Liittynyt
- 12.12.2016
- Viestejä
- 4 620
Nousevat sinne alkaen 750€ non XT ja 800€ XT. Hinnat laskevat ehkä kesällä
Proshopissa asus prime non xt:tä vapaana
- Liittynyt
- 22.10.2019
- Viestejä
- 354
Joo, kiitos. Onneksi tässä nyt ei ole minkäänlainen kiire.
- Liittynyt
- 22.10.2016
- Viestejä
- 12 009
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 ja ollut pahempi pullonkaula
Mutta: Tämä törmäystarkastusten nopetus tehtiin tavalla, joka ei lisännyt sitä shader-kuormitusta, samalla shader-kuormituksella saadaan nyt tarkastettua (teoriassa) 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 kolmanneksi 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 kellojaksossa, vaikka joka tasolla on tuplamäärä alilaatikoita
Tällöin 64 0-tason laatikkoa sisältävästä 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ä on helposti parempi kuin tuo 1.5x.
Eli siis, AMD ei käytännössä tuplannut säteenjäljityksen nopeutta, vaan AMD n. 1.6-kertaisti säteenjäljityksen nopeuden, tavalla joka teki siitä shader-kuorman ja vaadittavan rinnakkaisuuden yms. kannalta helpompaa ja halvempaa (mutta vaati sen tuplamäärän törmäystarkastuksia ja leveämpiä piirin sisäisiä väyliä)
(*) 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, jollekin säteelle aloittaa nämä törmäystarkastukset.
Ja niin, mikä on nVidian puun tyyppi, sitä en tiedä. nvidian ekoissa RTX-piireissä se oli käsittääkseni radix-4, mutta voi uusissa sukupolvissa olla jopa 8 tai 16.
edit: Nyt onnistuin löytämään yhden nvidian sliden, joka vihjaisi, että nvidialla todennäköisesti jo 3000-sarjassa olisi radix-8-puu, mutta ei voi olla varma, koska tuo oli vaan kuvaesimerkki bvh-puun ideasta.
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 ja ollut pahempi pullonkaula
Mutta: Tämä törmäystarkastusten nopetus tehtiin tavalla, joka ei lisännyt sitä shader-kuormitusta, samalla shader-kuormituksella saadaan nyt tarkastettua (teoriassa) 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 kolmanneksi 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 kellojaksossa, vaikka joka tasolla on tuplamäärä alilaatikoita
Tällöin 64 0-tason laatikkoa sisältävästä 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ä on helposti parempi kuin tuo 1.5x.
Eli siis, AMD ei käytännössä tuplannut säteenjäljityksen nopeutta, vaan AMD n. 1.6-kertaisti säteenjäljityksen nopeuden, tavalla joka teki siitä shader-kuorman ja vaadittavan rinnakkaisuuden yms. kannalta helpompaa ja halvempaa (mutta vaati sen tuplamäärän törmäystarkastuksia ja leveämpiä piirin sisäisiä väyliä)
(*) 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, jollekin säteelle aloittaa nämä törmäystarkastukset.
Ja niin, mikä on nVidian puun tyyppi, sitä en tiedä. nvidian ekoissa RTX-piireissä se oli käsittääkseni radix-4, mutta voi uusissa sukupolvissa olla jopa 8 tai 16.
edit: Nyt onnistuin löytämään yhden nvidian sliden, joka vihjaisi, että nvidialla todennäköisesti jo 3000-sarjassa olisi radix-8-puu, mutta ei voi olla varma, koska tuo oli vaan kuvaesimerkki bvh-puun ideasta.
Viimeksi muokattu:
- Liittynyt
- 20.10.2016
- Viestejä
- 648
Eihän sitä koskaan tiedä, mutta trendi näyttää olevan että uudet isot julkaisut harvenee:
5000-sarja & RDNA: 7/2019
6000-sarja & RDNA2: 11/2020 (16kk)
7000-sarja & RDNA3: 12/2022 (25kk)
9000-sarja & RDNA4: 3/2025 (28kk)
Ekstrapoloitu ennuste on jotain 30kk eli syyskuu 2027, keskiarvo taas 23kk eli helmikuu 2027
NVIDIAlla vastaavasti
RTX 2000: 9/2018
RTX 3000: 9/2020 (24kk)
RTX 4000: 10/2022 (25kk)
RTX 5000: 1/2025 (28kk)
Veikkaan että RTX 6000 sarjasta virallista infoa aikaisintaan CES 2027.
Muoks; nykyinen 3080 on sitten 7 vuotta vanha kun on vihdoin järkihintaisia päivityksiä tarjolla, ja siitä varmaan saa vielä silloinkin pari sataa euroa käytettynä
Viimeksi muokattu:
Uutiset
-
Cooler Master julkaisi pitkään valmistellun Hybrid M -pelituolin hierontatoiminnoilla
6.3.2025 03:50
-
Apple julkaisi uuden sukupolven Mac Studion ja M4-aikaan päivittyneen MacBook Airin
6.3.2025 01:09
-
Apple julkaisi uuden M3 Ultra -järjestelmäpiirin Mac Studio -käyttöön
6.3.2025 01:00
-
HMD Global esitteli MWC 2025:ssä joukon uutuustuotteita – mukana älypuhelin teineille ja uusia näppäinpuhelimia
5.3.2025 22:03
-
Uusi artikkeli: Testissä AMD Radeon RX 9070 & 9070 XT
5.3.2025 21:38
