CJ's AMD Radeon Info & Nieuwsdiscussietopic - Deel 144

[DaniëlWW2]

Astennu schreef op donderdag 17 september 2020 @ 14:19:
Nieuwe drivers zijn uit:
https://www.amd.com/en/su...e-notes/rn-rad-win-20-9-1

Ligt het aan mij is de multi monitor black screen bug gefixt? Ik zie die er niet meer bij staan.

Dat komt omdat die nu bovenaan de fixed lijst staat.
Maar ik had er de afgelopen tijd al veel minder last van. Fijn dat die eindelijk gefikst is want dat was het enige dat ik nog wel eens had. Verder draait het hier al ruim een halfjaar perfect.

[Astennu]

DaniëlWW2 schreef op donderdag 17 september 2020 @ 15:17:
[...]


Dat komt omdat die nu bovenaan de fixed lijst staat.
Maar ik had er de afgelopen tijd al veel minder last van. Fijn dat die eindelijk gefikst is want dat was het enige dat ik nog wel eens had. Verder draait het hier al ruim een halfjaar perfect.

Mmh vraag me af of dit dezelfde was:
A black screen, system crash or TDR may occur while gaming when performing task switches, enabling performance metrics overlay, or having video content/web browsers open on secondary displays on Radeon RX 5000 series graphics products system configurations

Was voorheen volgens mij niet Navi only mijn broer had er met Vega ook last van. Heb hem gezegd dat hij deze drivers maar eens moet proberen.

[Sissors]

Astennu schreef op donderdag 17 september 2020 @ 16:37:
[...]


Mmh vraag me af of dit dezelfde was:
A black screen, system crash or TDR may occur while gaming when performing task switches, enabling performance metrics overlay, or having video content/web browsers open on secondary displays on Radeon RX 5000 series graphics products system configurations

Was voorheen volgens mij niet Navi only mijn broer had er met Vega ook last van. Heb hem gezegd dat hij deze drivers maar eens moet proberen.

Ik heb daar soms last van met mijn 5700XT, of nou ja, het scherm gaat op zwart bij bepaalde task switches / als het scherm in standby is gegaan en weer wakker moet worden. Toch weer eens drivers bijwerken dan.

[Astennu]

Ik zag net deze. Wat bij opviel (vraag me af of dat klopt) is dat Ampere geen dubble FP16 kan doen binnen een FP32 shader waar turing dat wel kan. Dat vind ik wel opmerkelijk. AMD doet dit al sinds Vega en de PS4 Pro. Zo wel een stap terug zijn als Ampere dat niet zou kunnen. Wat ook nog kan is dat de gecombineerde Int32/FP32 units dat niet ondersteunen en alleen de fixed FP32 units dat kunnen.
Al zou je dan nog rond de 44Tflop verwachten want volgens mij kan een FP32 unit wel gewoon FP16 doen in dezelfde tijd alleen gebruik je een deel van de mogelijkheden niet?

Wat wel kan is dat nVidia het niet meer nuttig vind en dat door de tensor cores laat doen? Ik weet niet of die FP16 bewerkingen identiek zijn aan de mogelijkheden van de normale shaders? al was dit iets wat turing ook al kon doen.

[ Voor 14% gewijzigd door Astennu op 17-09-2020 16:48 ]

[sunsmountain]

DaniëlWW2 schreef op donderdag 17 september 2020 @ 14:20:
[...]
L2 cache zit in het midden van de chip bij RDNA.
Maar ik zie echt niet in hoe dat ooit gaat passen, gewoon echt niet. Van die 505mm² is waarschijnlijk echt de halve chip dan cache. Gewoon nee.

Dat valt op zich wel mee. 8GB is ongeveer 70 miljard transistors, 128MB dus 1/64 daar van, dat is ong. 1,1 miljard. Big Navi heeft minimaal 21 miljard transistors. Veel meer als ze met hun design density dichter bij de node density (theoretische max density) gaan zitten.

https://www.techspot.com/article/2024-anatomy-ram/
Ja, GDDR4 niet GDDR6. Maar veel zal dat niet schelen per MB denk ik. Prestatie verbeteringen komen al een tijdje niet meer uit het verdubbelen van transistors, maar uit hogere frequenties, dual, quad data paden, etc.

Het kan. Ik zie niet waar en hoe. Maar misschien een slimme Zen2 ingenieur in het RDNA2 team, wèl.

[sunsmountain]

Astennu schreef op donderdag 17 september 2020 @ 16:47:
[Afbeelding]

Ik zag net deze. Wat bij opviel (vraag me af of dat klopt) is dat Ampere geen dubble FP16 kan doen binnen een FP32 shader waar turing dat wel kan. Dat vind ik wel opmerkelijk. AMD doet dit al sinds Vega en de PS4 Pro. Zo wel een stap terug zijn als Ampere dat niet zou kunnen. Wat ook nog kan is dat de gecombineerde Int32/FP32 units dat niet ondersteunen en alleen de fixed FP32 units dat kunnen.
Al zou je dan nog rond de 44Tflop verwachten want volgens mij kan een FP32 unit wel gewoon FP16 doen in dezelfde tijd alleen gebruik je een deel van de mogelijkheden niet?

Wat wel kan is dat nVidia het niet meer nuttig vind en dat door de tensor cores laat doen? Ik weet niet of die FP16 bewerkingen identiek zijn aan de mogelijkheden van de normale shaders? al was dit iets wat turing ook al kon doen.

Ruwe power. Oude games met FP16 maken weinig kans om een bottleneck te zijn in Ampere. 29.8 TFLOPS is veel. Wat de driver ook nog kan doen is geloof ik 2 FP16s in 1 FP32 stoppen. Opgelost, dubbele FP16 TFLOPS terug. Maar als je pure FP16s aan de hardware geeft (de meeste games werken nu met FP32), dan pakt een Ampere FP32 core er maar 1tje per klokcycle op.

Tensor cores doen geen FP, dat is meer voor matrix-vermenigvuldiging. Zoals ray tracing, anti-aliasing, upscaling. Geen schaduw/kleur berekenen van pixeltjes (hoewel daar de matrix / ray / AA masker wel op kan werken als groep van pixeltjes = niet hetzelfde als die pixeltjes uitrekenen, eerder transformeren wat er al uitgerekend is).

[Astennu]

sunsmountain schreef op donderdag 17 september 2020 @ 17:19:
[...]

Ruwe power. Oude games met FP16 maken weinig kans om een bottleneck te zijn in Ampere. 29.8 TFLOPS is veel. Wat de driver ook nog kan doen is geloof ik 2 FP16s in 1 FP32 stoppen. Opgelost, dubbele FP16 TFLOPS terug. Maar als je pure FP16s aan de hardware geeft (de meeste games werken nu met FP32), dan pakken een FP32 core er maar 1tje per klokcycle op.

Tensor cores doen geen FP, dat is meer voor matrix-vermenigvuldiging. Zoals ray tracing, anti-aliasing, upscaling. Geen schaduw/kleur berekenen van pixeltjes (hoewel daar de matrix / ray / AA masker wel op kan werken als groep van pixeltjes = niet hetzelfde als die pixeltjes uitrekenen, eerder transformeren wat er al uitgerekend is).

Die dubbele FP16 of Rapid Pack Math zoals AMD het noemt is juist iets nieuws wat games kunnen gebruiken als FP32 niet nodig is. Volgens mij maakt ID daar gebruik van in Wolfenstein. En misschien ook wel weer in Doom Ethernal. Je kan dan veel efficiënter simpelere berekeningen doen. FP32 is lang niet altijd nodig.

[Sp3ci3s8472]

Dennism schreef op donderdag 17 september 2020 @ 12:50:
Toch jammer dat AMD het op die manier lijkt te doen, als ze duidelijkheid hadden verschaft voordat de RTX kaarten in de verkoop gaan hadden ze daar mogelijk nog disruptive kunnen zijn. Nu denk ik dat hele volksstammen al aan de RTX zit voordat AMD de kaarten presenteert.

Ik vraag me soms toch af waarom AMD de marketing zo aanpakt.

Valt wel mee, er zit ook een hele grote volkstam in de wachtrij . Grote vraag en waarschijnlijk toch een paperlaunch.

[sunsmountain]

MneoreJ schreef op donderdag 17 september 2020 @ 14:42:
[...]


Het zit zo, AMD blaakt van het vertrouwen als nooit eerder. Ze weten dat Big Navi zo goed is dat iedereen die nu NV gekocht heeft die kaart gewoon weer gaat verkopen, doet er niet toe hoe als ze hem maar slijten, in ruil voor AMD's absolute meesterwerk, en dat ze er geld op kwijtgeraakt zijn nemen ze voor lief. Dát is hoe goed die kaart wordt. Dan is marketing natuurlijk verder overbodig, de reclame verspreidt zichzelf als alle mensen die nu op de NV hype train gesprongen zijn massaal switchen en het doorvertellen. Die hele marketingafdeling van AMD zit zich nu al te verkneukelen!

Ziedaar mijn theorie, ik maak er later wel een YT-filmpje van waarin ik e.e.a. onomstotelijk bewijs.

Ik zie de memes al verschijnen, Risitas maar dan een AMD ingenieur over de 2080Ti owners:
YouTube: Nvidia Engineer talks about the RTX 3070 and RTX 2080 Ti
Alsof er 2x een bus over je heen rijdt

[Edmin]

Astennu schreef op donderdag 17 september 2020 @ 16:47:


Ik zag net deze. Wat bij opviel (vraag me af of dat klopt) is dat Ampere geen dubble FP16 kan doen binnen een FP32 shader waar turing dat wel kan.

Waarom vraag je datg niet in het NV topic? Hier hoort het iig niet

[DaniëlWW2]

sunsmountain schreef op donderdag 17 september 2020 @ 17:09:
[...]

Dat valt op zich wel mee. 8GB is ongeveer 70 miljard transistors, 128MB dus 1/64 daar van, dat is ong. 1,1 miljard. Big Navi heeft minimaal 21 miljard transistors. Veel meer als ze met hun design density dichter bij de node density (theoretische max density) gaan zitten.

https://www.techspot.com/article/2024-anatomy-ram/
Ja ik weet, GDDR4 niet GDDR6. Maar veel zal dat niet schelen per MB. Prestatie verbeteringen komen al een tijdje niet meer uit het verdubbelen van transistors, maar uit hogere frequenties, dual, quad data paden, etc.

Het kan. Ik zie niet waar en hoe. Maar misschien een slimme Zen2 ingenieur in het RDNA2 team, wèl.

Zo werkt het niet. Er zijn heel veel soorten geheugen met verschillende specificaties en toegangssnelheden. In de regel is hoe sneller, hoe meer ruimte. Cache is een compleet andere klasse dan GDDR en neemt veel meer ruimte in. Het is geen toeval dat de meeste videokaarten maar enkele MB aan L2 cache hebben. Dat neemt al heel wat ruimte in. Meer past echt niet. 128MB is letterlijk een paar honderd mm² als ik naar Navi 10 kijk als lijdraad.

[Sp3ci3s8472]

Astennu schreef op donderdag 17 september 2020 @ 14:19:
Nieuwe drivers zijn uit:
https://www.amd.com/en/su...e-notes/rn-rad-win-20-9-1

Ligt het aan mij is de multi monitor black screen bug gefixt? Ik zie die er niet meer bij staan.

Mooi, fixed mooi de bug met mijn Freesync scherm die soms optreedt.

[Sissors]

sunsmountain schreef op donderdag 17 september 2020 @ 17:09:
[...]

Dat valt op zich wel mee. 8GB is ongeveer 70 miljard transistors, 128MB dus 1/64 daar van, dat is ong. 1,1 miljard. Big Navi heeft minimaal 21 miljard transistors. Veel meer als ze met hun design density dichter bij de node density (theoretische max density) gaan zitten.

https://www.techspot.com/article/2024-anatomy-ram/
Ja, GDDR4 niet GDDR6. Maar veel zal dat niet schelen per MB denk ik. Prestatie verbeteringen komen al een tijdje niet meer uit het verdubbelen van transistors, maar uit hogere frequenties, dual, quad data paden, etc.

Het kan. Ik zie niet waar en hoe. Maar misschien een slimme Zen2 ingenieur in het RDNA2 team, wèl.

DRAM heeft 1 transistor + 1 capaciteit per unit cell. Dit is een speciale capaciteit die je niet in een standaard CMOS proces kan maken, en ze dus niet bij een RDNA2 GPU mee kunnen integreren. (Nou ja, theoretisch kan het vast, praktisch is anders). Een standaard SRAM cell is 6 transistoren. Daarbovenop kom nog aansturings en uitlees elektronica enzo, maar de SRAM cellen zelf zullen het meeste ruimte innemen. Met 128MB heb je dus meer dan 6 miljard transistoren aan SRAM nodig. Mij lijkt het onwaarschijnlijk veel.

[mrprancer]

dan toch maar de 5700XT nitro kopen.... kan ik tenminste bouwen....

[sunsmountain]

Sp3ci3s8472 schreef op donderdag 17 september 2020 @ 17:34:
[...]


Valt wel mee, er zit ook een hele grote volkstam in de wachtrij . Grote vraag en waarschijnlijk toch een paperlaunch.

De yields van RTX3080, 3090, 3070 zijn beter dan wat we van Samsung 8nm hadden verwacht. Toegegeven, je kan de 3080 en 3090 niet echt overclocken. Hoeft ook niet, ze zijn al overclocked uit de doos. De 3070 heeft mogelijk heel veel overclock ruimte, en kan voor $499 een puike koop zijn. Maar 2 weken later valt de AMD hamer.

Of niet. 3080 is zeker geen slechte koop nu, àls AMD er overheen gaat wat zeker mogelijk is, zal het denk ik niet met veel % zijn (max 10% meer fps voor dezelfde prijs, maar zonder DLSS 2.0).

[sunsmountain]

Sissors schreef op donderdag 17 september 2020 @ 17:55:
[...]

DRAM heeft 1 transistor + 1 capaciteit per unit cell. Dit is een speciale capaciteit die je niet in een standaard CMOS proces kan maken, en ze dus niet bij een RDNA2 GPU mee kunnen integreren. (Nou ja, theoretisch kan het vast, praktisch is anders). Een standaard SRAM cell is 6 transistoren. Daarbovenop kom nog aansturings en uitlees elektronica enzo, maar de SRAM cellen zelf zullen het meeste ruimte innemen. Met 128MB heb je dus meer dan 6 miljard transistoren aan SRAM nodig. Mij lijkt het onwaarschijnlijk veel.

Thanks @Sissors en @DaniëlWW2 ik heb weer wat geleerd. Dit sluit feitelijk die hele infinity cache uit. Dan moet het haast wel HBM2E zijn... of ze hebben de L1 / L2 bandwidth op een andere manier sterk verhoogd (met 80 CU's noodzaak).

ed.: big navi 21 miljard is uitgegaan van de design density van RX5700. https://www.reddit.com/r/..._navi_21_die_speculation/ Design efficiency (design density / max density) = 0,62. Maar als ze toch stiekem daar 0,72 van hebben gemaakt, dat is op TSMC 7nm+ die 6 miljard transistors. Het zou me wel weer een stunt zijn.

[ Voor 16% gewijzigd door sunsmountain op 17-09-2020 18:15 ]

[Mars Warrior]

Als ik zoek op HBM2E en Big Navi kom ik telkens deze plaat tegen van een gerucht uit Feb 2020.
Geen idee of dat al ontkracht is, dan mag deze post weer de prullenbak in...

[Munchie]

Mars Warrior schreef op donderdag 17 september 2020 @ 18:14:
Als ik zoek op HBM2E en Big Navi kom ik telkens deze plaat tegen van een gerucht uit Feb 2020.
Geen idee of dat al ontkracht is, dan mag deze post weer de prullenbak in...

[Afbeelding]

Ontkracht door hynix zelf.
https://news.skhynix.com/...t-gen_gpu_are_misleading/

[ocf81]

Als het helpt om de 3080 op zijn plek te zetten is HBM2E de extra kosten wel waard denk ik.

[Dennism]

sunsmountain schreef op donderdag 17 september 2020 @ 17:09:
[...]

Dat valt op zich wel mee. 8GB is ongeveer 70 miljard transistors, 128MB dus 1/64 daar van, dat is ong. 1,1 miljard. Big Navi heeft minimaal 21 miljard transistors. Veel meer als ze met hun design density dichter bij de node density (theoretische max density) gaan zitten.

Ik vraag me af of je hier niet naar het verkeerde kijkt. De 32MB L3 cache in Zen 2 zou +-34mm2 innemen terwijl een chiplet ongeveer 80mm2 is, flink wat "real estate" dus. Doe je dat x4 zit je op 136mm2 voor 128MB cache op het 7nm proces. kan natuurlijk zijn dat het met 7nm+ iets minder is, maar heel veel zal dat denk ik niet zijn.

[sunsmountain]

Dennism schreef op donderdag 17 september 2020 @ 18:34:
[...]


Ik vraag me af of je hier niet naar het verkeerde kijkt. De 32MB L3 cache in Zen 2 zou +-34mm2 innemen terwijl een chiplet ongeveer 80mm2 is, flink wat "real estate" dus. Doe je dat x4 zit je op 136mm2 voor 128MB cache op het 7nm proces. kan natuurlijk zijn dat het met 7nm+ iets minder is, maar heel veel zal dat denk ik niet zijn.

CPU cache is wel andere koek dan GPU cache, ik weet toevallig dat CPU's nog steeds veel complexere berekeningen kunnen maken dan GPU's, dus ook meer eisen stellen aan cache.

Maar goed, 6 miljard transistors zou nog steeds kunnen passen op big navi (ongeveer 100 mm^2 van de 505 mm^2), als de design density omhoog gaat ten opzichte van RX5700 (dat wordt bij 0,72 dan 6 van de 27 miljard voor de infinite cache, zie mijn eerdere aangepaste post).

ed: https://www.reddit.com/r/..._navi_21_die_speculation/
Overigens, Ampere GA102 zit op een Design Efficiency van 0.74.

En misschien is cache RAM laag qua density en geeft het minder hitte af, waardoor de RDNA ingenieurs niet bang hoeven te zijn voor de TDP. Dit lijkt me nou typisch een Zen 2 ingenieur truck, ook als CPU's niet van zulke gigantische caches gebruik maken, als je het bekijkt per CU, is het maar 1,6MB extra cache

[ Voor 19% gewijzigd door sunsmountain op 17-09-2020 19:20 ]

[Xadeon]

🧐

I've now got confirmation for both :

> Navi21 16GB VRAM
> Navi22 12GB VRAM

I have no idea if these are full die or cut down SKUs

— _rogame 🇵🇸 (@_rogame) 17 september 2020

[Werelds]

Astennu schreef op donderdag 17 september 2020 @ 16:47:
Ik zag net deze. Wat bij opviel (vraag me af of dat klopt) is dat Ampere geen dubble FP16 kan doen binnen een FP32 shader waar turing dat wel kan. Dat vind ik wel opmerkelijk. AMD doet dit al sinds Vega en de PS4 Pro. Zo wel een stap terug zijn als Ampere dat niet zou kunnen. Wat ook nog kan is dat de gecombineerde Int32/FP32 units dat niet ondersteunen en alleen de fixed FP32 units dat kunnen.

Verkeerde topic zoals @Edmin zegt maar ik beantwoord hem toch: de hybrid INT32/FP32 ALU's kunnen geen FP16. Het hybrid pad kan alléén FP32 of INT32 doen. Het andere pad kan FP32 of 2xFP16 (specifiek fused multiply-add, HFMA - overige FP16 ops gaan via de Tensor cores) doen.

[Edmin]

Modbreak:

Ok, ok... nu is het openstaande afgerond en kunnen we groene GPU's weer in het juiste topic bespreken....

[-The_Mask-]

Xadeon schreef op donderdag 17 september 2020 @ 20:21:
[Twitter]

Ik zou dan zeggen 2048 bit HBM2(E) voor Navi 21 en 384 bit GDDR6 voor Navi 22.

[DaniëlWW2]

Xadeon schreef op donderdag 17 september 2020 @ 20:21:
[Twitter]

Eindelijk.
Dat is dus waarschijnlijk HBM2E voor Navi 21 en Navi 22 met een 384bit bus. Kan dat stomme L2 cache verhaal hopelijk ook weg. Geeft meteen ook aan dat Navi 22 ook een aardig krachtige chip zal zijn als die een 384bit bus nodig heeft. Als we zien dat een XSX al 320bit/560GB/s heeft voor 52CU's op een relatief tamme 1825MHz en het een console is met een zeer snelle SSD, tja dan zat dit eraan te komen. 56CU's, laat staan 60 of misschien 64CU's op dik 2GHz gaat waarschijnlijk gewoon 384x16:8=768GB/s nodig hebben.

[sunsmountain]

DaniëlWW2 schreef op donderdag 17 september 2020 @ 20:50:
[...]


Eindelijk.
Dat is dus waarschijnlijk HBM2E voor Navi 21 en Navi 22 met een 384bit bus. Kan dat stomme L2 cache verhaal hopelijk ook weg. Geeft meteen ook aan dat Navi 22 ook een aardig krachtige chip zal zijn als die een 384bit bus nodig heeft. Als we zien dat een XSX al 320bit/560GB/s heeft voor 52CU's op een relatief tamme 1825MHz en het een console is met een zeer snelle SSD, tja dan zat dit eraan te komen. 56CU's, laat staan 60 of misschien 64CU's op dik 2GHz gaat waarschijnlijk gewoon 384x16:8=768GB/s nodig hebben.

Enige voorzichtigheid wel: de PS5 heeft dik 2GHz maar slechts 36CU. De XSX is met 52 CU's vast gezet op 1825 MHz. En hoezeer ik HBM2E + 384-bit geweldig zou vinden, en dat L2/2,5 cache verhaal in de prullemand wil, dat + 256-bit + 192-bit is nog steeds theoretisch mogelijk.

De voornaamste reden om nu tòch enthousiast te worden is dat RX5700XT een base clock heeft van 1680 MHz, en PC videokaarten veel minder worden tegengehouden door warmte ontwikkeling dan consoles, dus AMD hogere clocks kan halen. Veel hoger dan de 1400 MHz base clock van RTX3090. 80 CU op 2,2 GHz zou gehakt maken van de RTX3090...

Dit zou wel eens een AMD Pascal momentje kunnen worden (als de goede fundering in RDNA1 zijn gelegd à la Maxwell), +40/50% clockspeed toen voor nVidia. Ik denk dit keer een combinatie van hogere clocks, hogere IPC en architectuur/slimme geheugen oplossing.

[Astennu]

Ik zie niet hoen dat Twitter bericht bewijst dat het 384 bit wordt?
Je zou dan eerder 12 of 24 gb verwachten.

Dit lijkt toch meer op 256 met 16gb en 192 met 12gb.

En wat is er mis met een grote hoeveelheid cache ipv geheugen bandbreedte? Als prestaties maar goed zijn hoor je mij niet klagen. Voor de efficiëntie is het beter om je data dicht bij je compute units te hebben.

[DaniëlWW2]

Astennu schreef op donderdag 17 september 2020 @ 23:16:
Ik zie niet hoen dat Twitter bericht bewijst dat het 384 bit wordt?
Je zou dan eerder 12 of 24 gb verwachten.

Dit lijkt toch meer op 256 met 16gb en 192 met 12gb.

En wat is er mis met een grote hoeveelheid cache ipv geheugen bandbreedte? Als prestaties maar goed zijn hoor je mij niet klagen. Voor de efficiëntie is het beter om je data dicht bij je compute units te hebben.

Omdat Navi 21 zeer waarschijnlijk 80CU's is en Navi 22 waarschijnlijk ergens rond de 56 a 60CU's zit. Met 16gbps kijk je dan naar 512GB/s en 384GB/s. 64GB/s erbij voor een verdubbeling aan CU's over Navi 10 klinkt behoorlijk onrealistisch. Idem voor 64GB/s minder voor circa 50% extra CU's.

Qua cache zou het gaan om 120MB extra over Navi 10 om op 128MB uit te komen. Dat is letterlijk een paar honderd mm^2]. Het zou neerkomen op Navi 10 nemen, de chip min of meer verdubbelen in formaat met alleen cache en opeens is het veel sneller. Navi 21 zou volgens de meest betrouwbare leakers namelijk 505mm^2] zijn. Daarin moeten dan 80CU's passen, in vier Shader Engines met elk twee Shader Array's. Krijg je dus ook 128 ROPS. Komt er ook nog eens RT bij waar het best zou kunnen dat ze meer cache per CU gaan toevoegen. Ook zal L2 waarschijnlijk al naar 16MB gaan vanwege de verdubbeling in Shader Array's. Is er ook nog transistordichtheid om hogere clock speeds te behalen. Ik heb werkelijk geen flauw idee waar ze zoveel cache kwijt moeten kunnen.

Ook betekent heel veel cache dat als een cel kapot is, je de chip kan downraten of weggooien. Daarnaast maakt het de chip onnodig groot tenzij ze iets hebben bedacht dat een gigantische sprong voorwaarts betekend. Ik zie het alleen niet met een GPU waar het draait om ALU's utiliseren. Het klopt gewoon niet. Niet financieel, niet technisch en niet uit de hoek van de meer betrouwbare leakers.

[sunsmountain]

DaniëlWW2 schreef op donderdag 17 september 2020 @ 23:47:
[...]


Omdat Navi 21 zeer waarschijnlijk 80CU's is en Navi 22 waarschijnlijk ergens rond de 56 a 60CU's zit. Met 16gbps kijk je dan naar 512GB/s en 384GB/s. 64GB/s erbij voor een verdubbeling aan CU's over Navi 10 klinkt behoorlijk onrealistisch. Idem voor 64GB/s minder voor circa 50% extra CU's.

Qua cache zou het gaan om 120MB extra over Navi 10 om op 128MB uit te komen. Dat is letterlijk een paar honderd mm[sup]2][/. Het zou neerkomen op Navi 10 nemen, de chip min of meer verdubbelen in formaat met alleen cache en opeens is het veel sneller. Navi 21 zou volgens de meest betrouwbare leakers namelijk 505mm[sup]2][/ zijn. Daarin moeten dan 80CU's passen, in vier Shader Engines met elk twee Shader Array's. Krijg je dus ook 128 ROPS. Komt er ook nog eens RT bij waar het best zou kunnen dat ze meer cache per CU gaan toevoegen. Ook zal L2 waarschijnlijk al naar 16MB gaan vanwege de verdubbeling in Shader Array's. Is er ook nog transistordichtheid om hogere clock speeds te behalen. Ik heb werkelijk geen flauw idee waar ze zoveel cache kwijt moeten kunnen.

Ook betekent heel veel cache dat als een cel kapot is, je de chip kan downraten of weggooien. Daarnaast maakt het de chip onnodig groot tenzij ze iets hebben bedacht dat een gigantische sprong voorwaarts betekend. Ik zie het alleen niet met een GPU waar het draait om ALU's utiliseren. Het klopt gewoon niet. Niet financieel, niet technisch en niet uit de hoek van de meer betrouwbare leakers.

Ja, op Navi10 grootte zou 128 MB L2 cache ongeveer 218 mm² zijn.
5529x4435 = 24521115
825x810x2 = 1336500
= 5,45% van 251 mm² = 13,68 mm² voor 8MB = 218 mm² voor 128 MB
https://www.reddit.com/r/...rom_fritzchen_fritz_link/

Maar op Zen 2 is het al een stuk minder, misschien zijn CPU en GPU caches toch vergelijkbaar, sorry @Dennism.

For Zen 2, a single chiplet is 74mm2, of which 31.3 mm2 is a core complex with 16 MB of L3. AMD did not breakdown this 31.3 number into cores and L3, but one might imagine that the L3 might be approaching 50% of that number

https://www.anandtech.com...yzen-3000-and-epyc-rome/5
~50% van 31,3 mm² voor 16MB = 125,2 mm² voor 128MB. En dat vervangt 13,68 mm², dus 111,52 van de 505 mm² zou cache zijn.

Maar misschien hebben ze lopen proppen:
https://www.techcenturion.com/7nm-10nm-14nm-fabrication

Navi10: 7nm (HPC) 66,7 M/mm²
10,3B, 251 mm², 41,0 M/mm²
Design factor 0,62.

Wat als ze de design factor verhoogd hebben zoals bij Vega64?
https://www.reddit.com/r/..._navi_21_die_speculation/

Navi21: 7nm (HPC) 66,7 M/mm²
26,3B, 505 mm², 52,0 M/mm²
Design factor 0,78.
=> 5,6 miljard extra transistors als je daar 2*Navi10 van aftrekt (voor 112MB, dat deelt lekker als 50 miljoen per MB)
=> 24,3% van de transistors is cache.
=> 0,795 keer kleiner.
=> 88,66 van de 505 mm² voor de infinite cache van Zen 2 in Navi21.
=> 17,6% van de ruimte is cache.

Wat @Astennu zegt, kan denk ik dus nog steeds. Liever zie ik gewoon HBM2E, maar misschien is de infinity fabric van Zen2 wel helemaal het einde.

[computerjunky]

sunsmountain schreef op donderdag 17 september 2020 @ 22:22:

De voornaamste reden om nu tòch enthousiast te worden is dat RX5700XT een base clock heeft van 1680 MHz, en PC videokaarten veel minder worden tegengehouden door warmte ontwikkeling dan consoles, dus AMD hogere clocks kan halen. Veel hoger dan de 1400 MHz base clock van RTX3090. 80 CU op 2,2 GHz zou gehakt maken van de RTX3090...

Dit zou wel eens een AMD Pascal momentje kunnen worden (als de goede fundering in RDNA1 zijn gelegd à la Maxwell), +40/50% clockspeed toen voor nVidia. Ik denk dit keer een combinatie van hogere clocks, hogere IPC en architectuur/slimme geheugen oplossing.

Hoe hoger de clock des te spechter de prestatie per watt.

En waarom je rdna2 op 2.2 ghz probeerd te vergelijken met rtx 3090 op 1400 mhz snap ik totaal niet. Die kaart zal ook gewoon romd de 1.8-1,9 ghz lopen. Base clocks zijn irrelevant net als turbo clocks. Het gaat om de boost clocks waar de kaart uiteindelijk op draait.

En de ene leak die ik kan vinder over de ps5 power draw geeft ongeveer 350 watt aan dat is dus ruim 200 voor alleen de gpu chip als ik zie hoe de cpu cores geclockt zijn. Die hoge clock kan dus wel eens gewoon erg veel sap uit de muur trekken en dus heet worden en dat maakt het opschaken op die clocks onwaarschijnlijk.

[M-spec]

computerjunky schreef op vrijdag 18 september 2020 @ 02:55:
[...]


Hoe hoger de clock des te spechter de prestatie per watt.

Op zichzelf zorgt verhogen van de kloksnelheid bijna voor lineaire prestatieverhoging en verbruik, dus niet voor slechtere prestaties per Watt. Het is de spanning die er voor nodig is wat het verbruik kwadratisch laat stijgen boven 1,0V. Juist onder de 1,0V load zoals tegenwoordig gebruikelijk wordt met het enorme aantal transistoren gaat het verbuik juist evenredig omlaag.

Mijn Vega56 werkt standaard bijvoorbeeld op 1200mV (1,15V) load en is begrenst op 220W. Echter op 1,0V is deze al in staat om 270W te trekken. Vandaar een undervolt de boostsnelheid al vaak laat stijgen omdat het vermogen en dus ook de temperatuur lager wordt. Maar dan komt chip kwaliteit om de hoek kijken.

Ik zag van een 3080 slide dat deze ergens 317W deed op maar 0.95V. Dat is dus relatief gezien al aan de zuinige kant voor het verbruik. Als de slide tenminste klopt.

[Xadeon]

computerjunky schreef op vrijdag 18 september 2020 @ 02:55:
[...]


Hoe hoger de clock des te spechter de prestatie per watt.

En waarom je rdna2 op 2.2 ghz probeerd te vergelijken met rtx 3090 op 1400 mhz snap ik totaal niet. Die kaart zal ook gewoon romd de 1.8-1,9 ghz lopen. Base clocks zijn irrelevant net als turbo clocks. Het gaat om de boost clocks waar de kaart uiteindelijk op draait.

En de ene leak die ik kan vinder over de ps5 power draw geeft ongeveer 350 watt aan dat is dus ruim 200 voor alleen de gpu chip als ik zie hoe de cpu cores geclockt zijn. Die hoge clock kan dus wel eens gewoon erg veel sap uit de muur trekken en dus heet worden en dat maakt het opschaken op die clocks onwaarschijnlijk.

Dat is het vermogen van de voeding, niet het constante verbruik.

[sunsmountain]

computerjunky schreef op vrijdag 18 september 2020 @ 02:55:
[...]


Hoe hoger de clock des te spechter de prestatie per watt.

En waarom je rdna2 op 2.2 ghz probeerd te vergelijken met rtx 3090 op 1400 mhz snap ik totaal niet. Die kaart zal ook gewoon romd de 1.8-1,9 ghz lopen. Base clocks zijn irrelevant net als turbo clocks. Het gaat om de boost clocks waar de kaart uiteindelijk op draait.

En de ene leak die ik kan vinder over de ps5 power draw geeft ongeveer 350 watt aan dat is dus ruim 200 voor alleen de gpu chip als ik zie hoe de cpu cores geclockt zijn. Die hoge clock kan dus wel eens gewoon erg veel sap uit de muur trekken en dus heet worden en dat maakt het opschaken op die clocks onwaarschijnlijk.

Hoe hoger het Voltage ja, slechter de prestatie per Watt.

Ik vergelijk graag base clock, in het geval worst case. Draait AMD ook standaard op boost clock? Dan kunnen we inderdaad beter op boost clock vergelijken:
1700-1730 MHz voor 3070 3080 3090
1905-1980 MHz voor 5700XT(X)

+10% performance @iso-power door puur het gebruik van N7P ipv N7, geeft dan speculatief, mogelijk:
2095-2180 MHz voor Navi21 = +395-450MHz!

200W in een PS5? Daar zit dus nog wel wat ruimte, in een PC letterlijk.

Natuurlijk, grotere chips halen moeilijker dezelfde clock als kleinere chips, maar niet per se. De voornaamste oorzaak van lagere clocks is langere datapaden, je hebt dan meer spanning V nodig om hetzelfde signaal met frequentie ω stabiel te houden. Als infinity cache er in zit, kan dit mogelijk de paden kort houden. En de clocks hoog.

Als je Navi21 gaat overclocken kom je misschien wel op 2,4GHz uit. Nog steeds een flinke +500MHz boven de RTX3090. (De 2233MHz max van PS5 is niet het maximum van RDNA2, maar er schijnt wel een punt te zijn dat de intra-CU logica het begeeft)

[ Voor 3% gewijzigd door sunsmountain op 18-09-2020 13:15 ]

[computerjunky]

sunsmountain schreef op vrijdag 18 september 2020 @ 13:14:
[...]

Hoe hoger het Voltage ja, slechter de prestatie per Watt.

Ik vergelijk graag base clock, in het geval worst case. Draait AMD ook standaard op boost clock? Dan kunnen we inderdaad beter op boost clock vergelijken:
1700-1730 MHz voor 3070 3080 3090
1905-1980 MHz voor 5700XT(X)

+10% performance @iso-power door puur het gebruik van N7P ipv N7, geeft dan speculatief, mogelijk:
2095-2180 MHz voor Navi21 = +395-450MHz!

200W in een PS5? Daar zit dus nog wel wat ruimte, in een PC letterlijk.

Natuurlijk, grotere chips halen moeilijker dezelfde clock als kleinere chips, maar niet per se. De voornaamste oorzaak van lagere clocks is langere datapaden, je hebt dan meer spanning V nodig om hetzelfde signaal met frequentie ω stabiel te houden. Als infinity cache er in zit, kan dit mogelijk de paden kort houden. En de clocks hoog.

Als je Navi21 gaat overclocken kom je misschien wel op 2,4GHz uit. Nog steeds een flinke +500MHz boven de RTX3090.

IEDERE gpu draait altijd op een boost clock tenzij er iets grondig mis is met ke build. Base clock is voor cpu en gpu irrelevant. Je kan dus op base willen vergelijken maar het slaat gewoon nergens op aangezien geen enkele gpu daar op zal draaien. En ja ook amd draait op een boost clock alleen heet het daar dacht ik game clock either way het is niet de base clock.

En met je 1700 mhz range zitje weer fout. Dat is de turbo clock die vanuit de board partner mee gegeven word niet de uiteindelijke boost clock waar de gpu op draait. Als je 3080 benchmarks had gekeken dan had je gezien dat ze gewoon boven de 1900 mhz lopen.

Deze kaarten overclocken zichzelf als er power en temperatuur headroom is en die is er eigenlijk altijd. Ik heb een blower cooler en zelfs mijn kaart draait standaard 130 mhz hoger dan de stock boost clocks en dus 400 mhz hoger als de base clocks. En je moet er echt moeite voor doen om dat tegen te gaan dus alle kaarten draaiejn hoger dan de opgegeven clock speeds tenzij je net als Jensen je gpu in de oven bewaard.

Die +500 mhz overclock op navi is dan ook een dikke vette illusie omdat de kaart zichzelf al overclockt is er nooit meer zoveel headroom. Ik kan mijn kaart nog 120 mhz hoger pushen maar dat levert al geen evenredige prestaties meer op in verhouding tot de mhz en is dus totaal de moeite niet waard.

De laatste jaren is dit een trend en is handmatig overclocken zonder extreme koeling en hardware mods echt een illusie aan het worden. De hardware pushed zichzelf al naar extremen.
Zo kon mijn 3770k intel cpu van stock all core 3.5 en turbo all core 3.9 makkelijk overclocked worden opp een lucht koeler naar 5.1 ghz (4.6 ghz zonder ook maar voltage aan te raken).
Mijn 9900k is in de fabriek al dermate overclocked dat er nooit meer zoveel headroom in zit. En dat is niet anders met ryzen of met GPU's of het nou nvidia of amd is.

Lang verhaal kort altijd vergelijken op de max clock waar de kaart werkelijk op zal draaien.

[Xadeon]

@computerjunky Lees even nog eens wat @sunsmountain bedoelt, want je maakt er weer een onsamenhangend verhaal van.

[sunsmountain]

computerjunky schreef op vrijdag 18 september 2020 @ 13:30:
[...]
...
En ja ook amd draait op een boost clock alleen heet het daar dacht ik game clock either way het is niet de base clock.
...
Lang verhaal kort altijd vergelijken op de max clock waar de kaart werkelijk op zal draaien.

Wacht even hoor, zeg je nou dat we Game Clock van AMD moeten vergelijken met "max clock" van nVidia?

Base Clock: 1395 MHz
Boost Clock: 1695 MHz
"Max Clock": mid 1800s MHz 4k, 1920MHz bij 1080p laten we zeggen 1885 MHz bij 1440p.
https://www.overclockersc...0_founders_edition/11.htm bij 4k.

Base Clock 1680 MHz XTX
Game Clock 1830 MHz XTX
Boost Clock 1980 MHz XTX
om te vergelijken:
Boost Clock 1905 MHz XT
Auto OC 1998 +75 MHz voor de anniversary edition
-> Auto OC 2073 MHz -> laten we zeggen 2050 MHz bij 1440p voor de top kaart XTX
https://www.overclockersc...ews/asus_rx_5700xt/19.htm ook 1440p.

Ik denk dat we beter Auto OC kunnen nemen dan, bij AMD. Gelijke monniken gelijke kappen.
Big navi 10% erbij (TSMC 7NFF -> 7NP) is 1885 versus 2255 MHz. Nog steeds +370 MHz

[ Voor 5% gewijzigd door sunsmountain op 18-09-2020 14:46 ]

[Xadeon]

There is a very interesting patent just published from AMD's graphics division. Note that it was filed awhile ago, and this kind of novel cache adaptation feature could be very useful for RDNA 2 and beyond. More thoughts soon. https://t.co/NnHeo1lsYj

— NerdTech (@nerdtechgasm) 18 september 2020

Alright, basic gist, makes the new shared L1 in RDNA more effective (higher hit rates) by dynamically clustering CUs together, to pool their cache lines, to minimize duplication of cache use (+effective capacity) and increase hit rate. This reduces pressure on LLC/L2.

This makes the L2 more effective, thereby reducing pressure on memory bandwidth. This kind of design is enabled by the change in RDNA 1, with a 128KB shared L1 for the CUs within a shader array.

I still think the 128KB is too small for so many CUs, so one of the key changes I expect to see in RDNA 2 is at least 2x L1 size. Combine with this dynamic L1 changes, would be much more potent cache system, both L1 & L2 effective capacity & hit rate up.

[Mars Warrior]

Misschien is dat dan de befaamde "Infinity Cache"?

Wat ik hier dan uit begrijp is dat volgens AMD de toename in benodigde bandbreedte bij het flink uitbreiden van het aantal CU's voor een deel komt doordat de verschillende CU's dezelfde informatie opvragen.

Door dat voor een deel te voorkomen met dit patent, neemt de vraag naar bandbreedte af, en zou je dus - afhankelijk van de geruchten die waar/niet waar zijn - met een smallere geheugenbus toekunnen zonder prestaties in te boeten.

Ik ben benieuwd!

[sunsmountain]

Mars Warrior schreef op vrijdag 18 september 2020 @ 16:04:
Misschien is dat dan de befaamde "Infinity Cache"?

Wat ik hier dan uit begrijp is dat volgens AMD de toename in benodigde bandbreedte bij het flink uitbreiden van het aantal CU's voor een deel komt doordat de verschillende CU's dezelfde informatie opvragen.

Door dat voor een deel te voorkomen met dit patent, neemt de vraag naar bandbreedte af, en zou je dus - afhankelijk van de geruchten die waar/niet waar zijn - met een smallere geheugenbus toekunnen zonder prestaties in te boeten.

Ik ben benieuwd!

Al ver-honderd-voudigen ze L0 en L1, kom je nog niet op de 128 MB

• L0 Cache = 2x16 KB per WGP
• 20 WGP in navi 10 = 640 KB (1 WGP = 2 CU)
• L1 Cache = 128 KB per Array
• 4 arrays in navi 10 = 512 KB
• L2 Cache = 8192 KB

~9MB

Het moet bijna wel de L2 cache zijn, als dat 128 MB gerucht ergens op slaat. Ik denk dat deze "adaptive cache reconfiguration via clustering" gewoon onderdeel is van Infinity Cache van Zen 2, QoS (Quality of Service) maar dan toegepast voor GPU's. https://www.anandtech.com...yzen-3000-and-epyc-rome/4

Interessant wel:
https://www.anandtech.com...zen-3000-and-epyc-rome/11

The L1-D cache is still 32KB 8-way, while the L2 cache is still 512KB 8-way. The L3 cache, which is a non-inclusive cache (compared to the L2 inclusive cache), has now doubled in size to 16 MB per core complex

Ruw gezegd is L1 L2 L3 CPU = L0 L1 L2 GPU, en dan kunnen we voorspellen voor big navi:

• L0 Cache = 2x16 KB per WGP
• 40 WGP in navi 21 = 1280 KB (1 WGP = 2 CU)
• L1 Cache = 512 KB per Array
• 8 arrays in navi 10 = 4096 KB, 2 shader engines
• L2 Cache = 16384 KB *2

~37MB.

Misschien is het de crossbar op sheet 3 van 8 van de PDF, die virtueel die 16 MB L2 cache aan elk 4 arrays "beschikbaar" stelt, waardoor het 4*16*2 = 128 MB lijkt, maar niet is. De voornaamste vraag is, is een zen 2 "core complex" behandeld als een "shader array" of als een "shader engine"? Ik denk het laatste. Beetje marketing sausje er overheen, AMD foei toch .

128MB echte L2 cache kan (per "shader array"), maar dan moeten ze wel proppen (zie mijn eerdere post) op TSMC 7NP (HPC), denk aan een design density à la Vega64.

[DJvL]

Is het jullie wel eens opgevallen dat er verschillen zitten in de 3 fan modellen?
Zouden er meerdere 3 fan modellen zijn?

B.v. de 6800 XT en de 6900XT.

[ Voor 41% gewijzigd door DJvL op 18-09-2020 22:27 . Reden: Typi ]

[Jumpiefox]

Ik begin steeds meer te geloven dat AMD echt wel met een verassing kan komen..gezien de 3080 helemaal niet zo spectaculair was..gezien het een node shrink is maar eigenlijk niks meer dan een brute force is kwa TDP->performance. Een unlocked 2080TI vs een 3080OC komt zo dichtbij mekaar dat het eigenlijk best gek is.

Gezien de kaarten ook gelijk uitverkocht waren en bijna een paper launch te noemen was heeft AMD denk ik ook niet echt veel verloren nog..maakt het allemaal alleen nog spannender.

[sunsmountain]

Jumpiefox schreef op vrijdag 18 september 2020 @ 23:10:
Ik begin steeds meer te geloven dat AMD echt wel met een verassing kan komen..gezien de 3080 helemaal niet zo spectaculair was..gezien het een node shrink is maar eigenlijk niks meer dan een brute force is kwa TDP->performance. Een unlocked 2080TI vs een 3080OC komt zo dichtbij mekaar dat het eigenlijk best gek is.

Gezien de kaarten ook gelijk uitverkocht waren en bijna een paper launch te noemen was heeft AMD denk ik ook niet echt veel verloren nog..maakt het allemaal alleen nog spannender.

Het was geen paper launch, maar mensen zijn gewoon gestoord nu en makkelijk gehyped *knip* offtopic en verwijderd voordat we deze discussie hier gaan voeren

Anyway, ik ben dieper gedoken in die infinite cache. Waarom? Is dit equivalent met een 384-bit bus? Nou misschien, maar niet waarom je denkt. Kijk ff naar dit plaatje:




Het is niet zozeer de bandwidth, nee het is gewoon latency verlagen. Dat zou best eens een eerste stap kunnen zijn in het uitdelen van een stevig portie poesklap van AMD op nVidia. Het grappige is dat GDDR6X zorgt voor meer latency, niet minder. Ik vind DLSS 2.0 nog steeds indrukwekkend, maar als de +50% performance per Watt wordt gehaald, dan is zelfs 320 W TDP al genoeg om de performance crown te winnen.

Totdat nVidia iets uitbrengt van TSMC 7nm+ EUV, en ik bedoel niet de GA100 professional editie. Q1 volgend jaar. Toch 2 maanden AMD aan de top, hoera, bravo!

[ Voor 8% gewijzigd door br00ky op 19-09-2020 07:09 ]

[Sp3ci3s8472]

DJvL schreef op vrijdag 18 september 2020 @ 21:55:
[YouTube: AMD’s RX 6900 XT BEATS The RTX 3090, 20GB RTX 3080 CONFIRMED?!]


Is het jullie wel eens opgevallen dat er verschillen zitten in de 3 fan modellen?
Zouden er meerdere 3 fan modellen zijn?

B.v. de 6800 XT en de 6900XT.

Hij herkauwd dus de leaks van Igor en Red Gaming Tech .

[Psyonara]

DJvL schreef op vrijdag 18 september 2020 @ 21:55:
[YouTube: AMD’s RX 6900 XT BEATS The RTX 3090, 20GB RTX 3080 CONFIRMED?!]


Is het jullie wel eens opgevallen dat er verschillen zitten in de 3 fan modellen?
Zouden er meerdere 3 fan modellen zijn?

B.v. de 6800 XT en de 6900XT.

Hoe betrouwbaar zijn die bronnen eigenlijks?

Gun het AMD van harte Maar wil non sponsored benchmarks zien graag aub.

[Mars Warrior]

Aan de hand van het latency verhaal maar weer wat termen in Google gegooid.

En daar kwam ik een oud onderzoek tegen uit 2016 dat ingaat op latency en bandwidth. Weliswaar voor (oude) nVidia GPU's, maar dat moet niet uitmaken lijkt me.

De throughput blijkt dus bij lage occupancy (bezetting van ALU's) voornamelijk afhankelijk te zijn van latency (instructie en memory), omdat men niet/nauwelijks aan latency-hiding kan doen bij lage bezettingsgraden.



De latency van instructies zijn minder van invloed dan geheugen latencies blijkt uit de volgende plaatjes.


Als AMD dus met hun patent en de Infinity L2 cache die latencies flink weet te verlagen, dan zal er dus automatisch (een stuk) meer performance uit de GPU gehaald kunnen worden bij lage(re) bezettingsgraden van de ALU's lijkt mij.

Ik vraag me af wat dan de impact is op sommige spellen die nu veel beter op nVidia lopen en andersom. Vaak heeft dat met architectuur te maken waardoor de "match" beter is, maar door dit soort architectuur wijzigingen kan dat natuurlijk flink omver geschopt worden .

De te behalen winst is dan dus wel afhankelijk van de bezettingsgraad, want als die altijd optimaal is, dan lost de memory latency hiding die problemen op en gaat het enkel nog om de bandbreedte.

Maar daar heb ik geen idee van eigenlijk. Zoveel kennis van GPU's heb ik niet

[sunsmountain]

Mars Warrior schreef op zaterdag 19 september 2020 @ 13:54:
Aan de hand van het latency verhaal maar weer wat termen in Google gegooid.

En daar kwam ik een oud onderzoek tegen uit 2016 dat ingaat op latency en bandwidth. Weliswaar voor (oude) nVidia GPU's, maar dat moet niet uitmaken lijkt me.

De throughput blijkt dus bij lage occupancy (bezetting van ALU's) voornamelijk afhankelijk te zijn van latency (instructie en memory), omdat men niet/nauwelijks aan latency-hiding kan doen bij lage bezettingsgraden.

[Afbeelding]

De latency van instructies zijn minder van invloed dan geheugen latencies blijkt uit de volgende plaatjes.
[Afbeelding]

Als AMD dus met hun patent en de Infinity L2 cache die latencies flink weet te verlagen, dan zal er dus automatisch (een stuk) meer performance uit de GPU gehaald kunnen worden bij lage(re) bezettingsgraden van de ALU's lijkt mij.

Ik vraag me af wat dan de impact is op sommige spellen die nu veel beter op nVidia lopen en andersom. Vaak heeft dat met architectuur te maken waardoor de "match" beter is, maar door dit soort architectuur wijzigingen kan dat natuurlijk flink omver geschopt worden .

De te behalen winst is dan dus wel afhankelijk van de bezettingsgraad, want als die altijd optimaal is, dan lost de memory latency hiding die problemen op en gaat het enkel nog om de bandbreedte.

Maar daar heb ik geen idee van eigenlijk. Zoveel kennis van GPU's heb ik niet

Interessant, de wet van Little geeft een gemiddeld aantal SM/CU dat gelijktijdig in gebruik is (aantal klanten in een winkel) = latency (hoe lang blijven de klanten in de winkel) * aantal verwerkte SM/CUs per tijdseenheid (hoeveel klanten komen er binnen/gaan er weg).

In het onderzoek breiden ze de begrenzing van Little uit naar niet alleen memory latency (prefetching, multi-threading), maar ook: "warp/thread concurrency, instruction concurrency, arithmetic instruction concurrency, and memory instruction concurrency."

Dit betekent dat er altijd een balans gevonden moet worden tussen latency en bandbreedte, snelheid. L1 en L2 cache is altijd sneller dan meer GDDR, maar de ruimte op de chip is beperkt, waardoor je minder SM/CU kwijt kunt. Eigenlijk niks nieuws dus.

Er zijn echter wel 2 voorwaarden aan het gebruik van de wet van Little:
"The only requirements are that the system be stable and non-preemptive;"

En laat nou met name dat tweede iets zijn waar infinity fabric/cache wat aan kan doen: wèl pre-empten, zoveel mogelijk. Als de ALU *weet* dat het niet verder hoeft te rekenen (de klant hoeft niet meer naar de winkel), dan heeft dat natuurlijk direct impact op de performance, terwijl de concurrency (gelijktijdig in gebruik zijnde CU/SMs) gelijk blijft. Anders gezegd, voor dezelfde frame zijn er minder threads nodig.

Hoe breder een CU resultaat gedeeld kan worden in L1 en L2 cache, hoe meer nodeloze threads bespaard kunnen worden. Daarvoor moeten CU's die van elkaar afhankelijke berekeningen doen, zoveel mogelijk dezelfde cache gebruiken. En dat is voor elke frame anders, ik vermoed dat de adaptive cache reconfiguration dat probeert te optimaliseren: the amount of work not done.

[DaniëlWW2]

Xadeon schreef op vrijdag 18 september 2020 @ 14:40:
[Twitter]

[...]

* DaniëlWW2 moppert iets over alweer de RDNA whitepaper erbij te hebben gepakt.
Maar het is iets dat ik graag in RDNA2 en verder zou zien. RDNA is namelijk erg centraal gericht in haar ontwerp en dat is ook zo met de cache structuur. Die eerst maar eens toelichten.

RDNA is op CU niveau georganiseerd in groepen van twee. Dat is de dual CU. Deze beschikt over een gedeelde 32kb. Dit noemt AMD de vector cache of L0, want AMD.


Een Shader Array, in Navi 10 bestaande uit tien CU's heeft dan haar eigen 128kb aan L1 cache. Deze functioneert voornamelijk als een read cache voor de CU's om informatie uit te halen indien nodig. Dit is niet veel voor zoveel ALU's die ook zo efficiënt zijn georganiseerd. L2 in RDNA is echt een centrale read/write cache waar de Shader Array's informatie uit kunnen halen voor de CU's.

---

Het punt van dit patent is om de druk op L1 cache te verlagen. De samenstelling van de CU clusters lijkt ook helemaal dynamisch te zijn en centraal gecontroleerd te worden met haar eigen feedbackloop. Het is dus niet dat het bepaalde CU's met elkaar moeten zijn wat dit minder flexibel zou maken.

Ik ben het ook eens met het idee dat L1 cache verdubbeld zou moeten worden voor RDNA2. Het zou wat druk van de L2 af moeten halen, L1 naar CU heeft veel snellere datapaden en het zou wat moeten schelen in geheugenbandbreedte en verbruik van de chip. Ik kijk alleen niet primair naar shaders, maar juist naar wat echt nieuw is in RDNA2, ray tracing.

Als er iets is dat echt baat zou moeten hebben van cache, dan is het hybrid RT. Hybrid RT zoals Nvidia en zeer waarschijnlijk AMD het doen, is uiteindelijk met BVH een beeld vormen waar daadwerkelijk de grenzen van door shaders gecreëerde objecten liggen en waar dus ray tracing plaats moet vinden. Dat vraagt om die objecten in cache te houden en om BVH op te slaan in cache totdat de berekeningen voltooid zijn. Daar lijkt het ook mis te zijn gegaan met Ampere. Ampere heeft geen extra cache binnen de SM en het resultaat lijken veel cache conflicten. Een van de meest duidelijke conflicten is RT toegang tot cache. Ampere RT is beter dan Turing RT, als de SM in RT only mode staat en niet ook nog shaders moet doen. Met shaders is het nauwelijks of niet beter dan Turing om dat de shaders ook die cache nodig hebben voor andere zaken.

RDNA1 heeft weliswaar een lokale 32kb gedeeld tussen twee CU's, maar voor tien CU's is het 128kb aan L1 cache. Turing/Ampere heeft 32+64kb aan L1 cache per SM. De details hoe snel deze caches precies zijn, tja. Blijft staan dat Turing/Ampere iets meer local cache heeft dan RDNA1. Dat lijkt me niet wenselijk aangezien het Ampere ook niet lukt om echt goed te presteren in mixed shaders en RT.

---

Hier komt het hele "Infinity cache" verhaal denk ik ook weer voorbij. Als AMD het zou doen, dan is het denk ik met RT in het achterhoofd. Een serieus grote L2 cache als buffer waar ze snel zaken vanuit naar de L1 van een Shader Array kunnen delegeren voor RT. Ze zullen L1 cache denk ik ook moeten vergroten en ideaal gezien ook L0 cache. Voor mij blijft er alleen een serieuze vraag hangen. Waar moet die 128MB precies passen want ik heb geen idee...

[DJvL]

[Dutchy007]

DJvL schreef op zondag 20 september 2020 @ 19:39:
[YouTube: How AMD Competes With Zen 3 & RDNA 2 | A Revolution Is Coming]

Het wordt tijd dat AMD met wat concretere info komt. Zeker nu aangezien ze een 'break' hebben gekregen met de botched RTX3080 launch.
Verder gaan de leaks wel erg ver uit elkaar. Paul van RDG zegt dus dat de mogelijkheid bestaat dat de 3080 wordt verslagen m.b.t. performance. (of tenminste, dat het vergelijkbaar is).
Terwijl MLID (Moore's Law Is Dead) aangeeft dat de top Navi kaart een 6800 wordt ipv 6900 aangezien ze de 3080 gewoonweg niet kunnen tackelen.

Ik heb mijn Radeon VII voor een leuk bedrag kunnen wegdoen recentelijk, en game nu op een R9 Fury. Een upgrade zou zeker niet verkeerd zijn. Echter ben ik wel terughoudend met een RTX3080 en wil graag zien dat AMD ook iets leuks kan neerzetten.

(Overigens vind ik het wel knap dat Paul eigenlijk bij elke AMD video hetzelfde zegt )

[DJvL]

Dutchy007 schreef op zondag 20 september 2020 @ 20:08:
[...]

(Overigens vind ik het wel knap dat Paul eigenlijk bij elke AMD video hetzelfde zegt )

Hij heeft eigenlijk een beetje zijn afgelopen videos samengevat..

[Psyonara]

Is hij wel een betrouwbare source?

[DJvL]

Psyonara schreef op zondag 20 september 2020 @ 21:01:
Is hij wel een betrouwbare source?

Dat zal blijken. Hetzelfde met MLID.

[Moopa]

Zit stiekem ook op AMD te hopen....maar zover ik hoor zijn de graffische drivers van AMD al tig jaar brak en zijn er veel problemen met diverse games.

Dat weerhoudt mij ervan om voor AMD te gaan...

[Psyonara]

Moopa schreef op maandag 21 september 2020 @ 01:52:
Zit stiekem ook op AMD te hopen....maar zover ik hoor zijn de graffische drivers van AMD al tig jaar brak en zijn er veel problemen met diverse games.

Dat weerhoudt mij ervan om voor AMD te gaan...

Die issues schijnen ondertussen op gelost te zijn. Voor mij ondertussen wel 9 jaar geleden dat ik een AMD GPU Had nooit problemen mee en diegene die ik ervoor had ook niet. Eerder altijd issues gehad met Nvidia.

[Xadeon]

N21 2100Mhz+ being run in batches to assess ASIC quality, final specs should be set next week pic.twitter.com/LcofvtUh1j

— coreteks (@coreteks) 20 september 2020

Kloksnelheid van +2Ghz ligt wel in de lijn der verwachting, toch? En een TDP van......?

[ Voor 57% gewijzigd door Xadeon op 21-09-2020 03:26 ]

[ZenTex]

Ik ben positief over RDNA2.

Het is meer een gevoel dan iets concreets,maar het feit dat AMD de lippen stijf op elkaar houdt, Nvidia de prijzen "redelijk" houdt, maar de kaarten opfokt tot de en onredelijk wattage, geruchten over cache en de "zen moment" uitspraak.

Mijn kristallen bol* zegt dat RDNA2 zich kan meten met Ampère, maar de prijzen navenant zijn, dwz, net iets onder Nvidia, en dat ik maar snel weer aandelen AMD kan kopen vandaag voordat iedereen hetzelfde realiseert.

* Mijn kristallen bol is van glas, niet helemaal rond en er zit een flinke barst in.

[DaniëlWW2]

Moopa schreef op maandag 21 september 2020 @ 01:52:
Zit stiekem ook op AMD te hopen....maar zover ik hoor zijn de graffische drivers van AMD al tig jaar brak en zijn er veel problemen met diverse games.

Dat weerhoudt mij ervan om voor AMD te gaan...

Ik heb de afgelopen 10+ jaar anders verdomd weinig problemen gehad.
Het was echt even waardeloos afgelopen winter, maar uiteindelijk heb ik dat grotendeels opgelost door betere DP kabels te kopen. De meeste black screens zijn waarschijnlijk ook toe te wijten aan een instabiliteit in je systeem, waarschijnlijk RAM of een brakke PSU. Maar na 20.2.2 is het meeste allang geplet. Met 20.9.1 is ook eindelijk de irritante switch tussen monitoren bug opgelost waardoor programma's soms vastliepen als ik op het tweede scherm iets van YT draaide. Gebeurde ook alleen in full screen wat een mooie workaround was. Dan heb ik nota bene een 1080p/75Hz terwijl het primaire scherm hier 1440p/165Hz is. Dat maakte het kennelijk erger want twee identieke schermen werkte blijkbaar beter.

Ik ben dus gewoon weer terug naar het oude niveau waar alles gewoon werkt. Als ik dan lees wat er keer op keer allemaal mis gaat bij Nvidia omtrent GPU naar monitor verbindingen, tja. Beide kampen zijn gewoon goed en zwaar waardeloos tegelijkertijd. Het probleem is dat er altijd word gescholden op Radeon, maar Nvidia met alles weg lijkt te komen.

[Sissors]

Wacht, je gaat nu serieus de schuld geven aan PSUs en RAM voor alle black screen bugs? Die grotendeels opgelost zijn door nieuwe GPU drivers? Dus AMD GPU Drivers kunnen mijn PSU en RAM problemen oplossen?

En ja, ondertussen werkt het allemaal weer behoorlijk. Al heb ik gisteren nog moeten herstarten omdat mijn scherm steeds zwart ging voor een seconde en weer terug kwam. Scherm aan en uit zetten loste het niet op, dus scherm is niet het probleem. Gezien de andere kant van de kabel in de GPU gaat, ga ik toch de GPU de schuld hiervan geven. En na die opnieuw op te starten (samen met de rest van de PC) was het probleem wel opgelost.

Over het algemeen zou ik nu drivers geen probleem meer vinden voor iemand die een 5700XT wil open (los van hoe verstandig dat is op dit moment). Maar moeten we dan bij RDNA2 weer een jaar wachten op fatsoenlijke drivers?

[Dennism]

Ik zou daar inderdaad ook niet zo lichtzinning mee omgaan, ik ben na eigenlijk altijd Ati / AMD kaarten te hebben gehad een aantal jaar geleden naar Nvidia overgestapt juist vanwege AMD's driver issues. De druppel was het niet oplossen van een incompatibiliteit tussen de HD7950 generatie drivers / chips en Intels X58 platform. Met als gevolg iedere dag random chrashes in o.a. WoW dat ik destijds veel speelde. Dit kon uren goedgaan, maar ook 3x crashen (met systeem reboot tot gevolg) binnen 15 minuten, niet handig wanneer je met groepscontent bezig bent.

Uiteindelijk heeft het AMD een jaar gekost om deze bug te vinden en op te lossen. Dat was het vrij bedroevend en voor mij de reden om uiteindelijk over te stappen.

Maar ook als ik kijk naar zakelijk zie ik eigenlijk veel vaker issues met AMD gpu's dan met Nvidia varianten, voordat bij multimonitor toepassingen.

Natuurlijk zijn die driver issues niet exclusief, en heeft ook Nvidia wel eens problemen, maar in ieder geval in de gevallen waarmee ik te maken heb voeren problemen met de AMD GPU drivers wel de boventoon.

Ik zou graag wel gaan draaien met een AMD kaart, maar juist de berichten overal (en deels ook mijn eigen ervaringen), maken me daarin wel terughoudend, wat jammer is.

[Help!!!!]

Ach heb met nvidia ook issues. Heb tijden lang na driver install de displayport kabel erin en eruit moeten doen anders bleef scherm zwart.

In de release notes staan ook bij nvidia genoeg bugs waarvan sommigen al tijden aanwezig zijn.

Ook probleem dat ik geen drivers meer kon installen en foutmelding kreeg. Eindeloos gezocht bleek dat ik op de een of andere manier ineens DCH drivers nodig had. Misschien niet echt nvidia's schuld maar heeft tijden geduurt voordat je in de driverdownload de keuze kreeg. Ze hadden al veel eerder daar duidelijk over kunnen zijn.

En Daniel heeft best een punt, los van duidelijke geverifieerde bugs wordt bij beide merken soms al snel naar drivers gewezen terwijl het systeem zelf wellicht instabiel is.

[Paprika]

Je kunt het wel ook omdraaien. Stel jij hoort als consument wel regelmatig dat er problemen zijn met de producten van merk X. Op een gegeven moment (5700 release) ga je het toch eens proberen en dan tref je een dergelijke situatie aan. Dan kun je het wel vergeten dat die persoon het binnenkort nog een keer gaat proberen. Het aantal 5700 eigenaren dat op zowel Tweakers als Reddit aangeeft er wel even klaar mee te zijn is wel hoger dan gemiddeld voor een jaar na aanschaf.

Uiteindelijk zal het antwoord wel ergens in het midden liggen. Zelf heb ik in HD4000-6000 series tijden geen problemen ervaren, maar die heb ik ook niet ervaren met de GeForce 4-9000 series, GTX 600-series, GTX 1000-series en RTX 2000-series. De RTX 3000-series beoordelen is het nog wat vroeg voor .

[DaniëlWW2]

En daar gaan we weer...
Werkelijk elke keer weer moet er na die vraag maar verkondigd worden hoe slecht het allemaal is want een ervaring. Daar zet ik gewoon 10+ jaren tegenover waar de ergste dingen die ik heb gehad de volgende zijn:
-Helemaal in het begin met mijn HD5850 moest ik de eerste maand een oudere driver gebruiken omdat de nieuwste mijn monitor niet goed herkende. Was snel opgelost.
-Ik heb met mijn RX Vega een tijdje HOI4 niet kunnen spelen, maar dat was een probleem vanuit de game dat het steeds crashte.
-Met Vega resette de UV vaak.
-RX5700XT black screens die ik dus grotendeels verhielp met nieuwe DP kabels.
-Freezes/crashes als ik in fullscreen op mijn tweede scherm YT draaide. Ook opgelost.

Dat was het, voor meer dan tien jaar. Ik kan me niet eens een probleem herinneren met de HD7950 die ik zoveel jaren heb gebruikt. Werkelijk verschrikkelijk die drivers. Voor zover ik weet heeft AMD het afgelopen decennium in ieder geval geen "laten we je videokaart slopen door de ventilatoren uit te schakelen" driver uitgebracht, meerdere keren...

De ironie is dat ik ook ooit een Nvidia heb gehad. De eerste paar maanden had ik een 9500GT tot het punt dat je werkelijk een HD5850 kon kopen. Daar had ik dus constant crashes mee en control panel crashte meestal bij openen. Idem voor de problemen in mijn oude laptop waar een GT 325M in zit. Volgens mijn ervaring is Nvidia dus compleet waardeloos, maar waar hoor je mij constant verkondigen dat het allemaal zo slecht is?

---

Realiteit is dat die videokaarten met de honderdduizenden verkocht worden en in letterlijk tienduizenden verschillende configuraties worden gebruikt en dan zijn er nog eens honderden games die allemaal complex in elkaar zitten waar een dingetje net mis kan gaan. Het idee dat het altijd goed zal werken is onzin. Als je dat echt wil, heel bot maar koop een console. Ik heb vernomen dat de aankomende modellen best krachtig zijn.
PC gaming is altijd zo geweest en dat gaat ook niet veranderen.

Nvidia en AMD krijgen waarschijnlijk de eerste 24 uur na een daadwerkelijke launch waar mensen de videokaarten echt kunnen kopen en installeren, meer informatie binnen dan in maanden van testen. Ze kunnen botweg niet alle configuraties testen. Daarom gaat het ook elke launch mis, met beide kampen.
Bijvoorbeeld: nieuws: Gebruikers hebben problemen met RTX 3080 in combinatie met oled-tv's ...

Verder laten we even naar het Nvidia topic gaan waar toevallig @Werelds met een mooi voorbeeld komt.
Werelds in "[Algemeen] NVIDIA Nieuwsdiscussie Topic - Deel 56" Kijk, ik heb de afgelopen maanden dus ook wat problemen gehad, maar mijn tweede scherm werkte altijd tenzij het echt crashte. Daar kon ik alleen makkelijk omheen werken. Ook nooit een kabel eruit hoeven te halen en terug te doen. Dat het om DP gaat doet me meteen ook vermoeden dat het misschien de kabels zijn. Er is een DP spec, maar vrijwel niemand volgt die. Resultaat zijn heel wat kabels met een DP connector, maar of ze ook goed werken met alle configuraties. Ik heb het zelf ervaren met mijn RX5700XT. Echt gecertificeerde DP kabels gekocht, onder scepsis hier want dat zou nooit werken en ja hoor, het werkte.

Op basis van die ervaring kan ik toch ook stellen dat Nvidia veel slechter is met multi monitor en DP omdat de problemen kennelijk steeds terugkomen. Dat zou net zo'n zinloze conclusie zijn als de persoonlijke ervaring voor Radeon.

Wat mis lijkt te zijn gegaan met RDNA1 is dat het een geheel nieuwe uArch is die te vroeg is gelanceerd. Dan krijg je dat. Maar zelf zelf nou eens. Die dingen zijn met de honderdduizenden verkocht. Als het werkelijk zo slecht was dat iedereen problemen had, dan zou elk AMD gerelateerd forum vorig jaar zijn afgebrand. Zelfs toen HardwareUnboxed het ging adresseren zei hij dat hij geen enkel probleem kon reproduceren, en hij heeft zo ongeveer elke RX5700XT op de markt gekocht en heeft ze kennelijk ook weggeven aan vrienden en in de systemen van zijn kinderen gestopt. Met twee vrienden had hij dus uiteindelijk wel problemen die respectievelijk zijn opgelost met PCI-E naar 3.0 zetten en de slechte DP kabel vervangen voor een HDMI kabel. De gebruikelijke fixes dus.

Inmiddels heb ik ook heel wat gevallen gezien waar er naar de drivers werd gewezen, en het een brakke PSU of instabiel RAM bleek te zijn. Zeker die tweede speelt al tijden omdat er nog steeds 3200C16 setjes in omloop zijn die dat nauwelijks stabiel kunnen draaien met het XMP profiel. Daarom doe ik in elke BBG ook zo moeilijk over Crucial E-die RAM. Qua PSU's vermoed ik dat het misschien wat te maken heeft met pieken. Radeon's willen wel eens enorme, zeer kortstondige piekstromen vragen. Dat ging bijvoorbeeld ook mis met die Seasonic Focus PSU's waar ook een dacht ik GTX980Ti van ASUS tussen zat die het probleem ook had. En dat is juist het punt. Zoiets kan je onmogelijk allemaal testen. Het zijn zoveel configuraties dat het ondoenlijk is. Om alles dan meteen op drivers te gooien is veel te makkelijk. Toch gebeurd dat hier steevast voor Radeon, maar niet voor Nvidia.

Wederom:

Beide kampen zijn gewoon goed en zwaar waardeloos tegelijkertijd. Het probleem is dat er altijd word gescholden op Radeon, maar Nvidia met alles weg lijkt te komen.

[Help!!!!]

@ vipeax
Inderdaad en ik geloof wel dat het bovengemiddeld was ttv de 5700 release. Over een wat langere tijd middelt het echter denk ik wel uit tussen beide merken.

Desalniettemin is hardware waardeloos zonder goede software dus daar is zeker gezien de perceptie duidelijk werk aan de winkel voor AMD. Het zal absoluut niet helpen als RDNA2 drivers niet op orde zijn straks.

[ Voor 3% gewijzigd door Help!!!! op 21-09-2020 12:26 ]

[Werelds]

Ach, ik bouw al dik 25 jaar zelf PC's en ik heb geen enkele videokaart gehad waar de drivers geen rare dingen deden. Met één uitzondering: m'n Voodoo, maar dat was omdat er amper iets van een driver was

Maakt geen reet uit of het Nvidia of AMD is, er zitten gewoon rare bugs in aan beide kanten. Dat AMD met RDNA wellicht even wat meer bugs had kan best, maar dat is dan tenminste een geheel nieuw product. Bij Nvidia gaat het vaak om bugs die al veel langer bestaan. Zoals ik in het groene topic zei, snapt Nvidia simpelweg helemaal niets van display outputs. Dat was 20 jaar geleden zo en dat is nog steeds zo. DisplayPort vinden ze maar moeilijk en de multi-monitor aansturing hangt aan een jojo vast qua stabiliteit. Het is al niet meer zo slecht als 10 jaar geleden, toen de Surround hacks duidelijk iets kapot hadden gemaakt in het geheel. En AMD had toen juist alles extreem goed op orde qua monitor aansturing, ik had althans 0 problemen met Cypress en Cayman. Ook niet verrassend van het bedrijf dat display spanning op de kaart heeft gezet

Het probleem is gewoon dat ze met een userbase te maken hebben met extreem uit elkaar lopende hardware. Vaak ook hardware die jaren ouder is dan de GPU die ze hebben, brakke voedingen en nog veel vaker met brakke kwaliteit kabels. Ik hoef maar naar mezelf te kijken. M'n primaire monitor (FG2421) is inmiddels iets meer dan 7 jaar oud en heeft er 33437 branduren op zitten. M'n secundaire monitor (FS2333) is 8,5 jaar oud en heeft er 28001 uren op zitten. De gebruikte kabels van beide waren dan wel kwaliteitskabels, maar in elk geval de DP kabel op m'n FG is ook al even oud als de monitor. De HDMI kabel van de FS kan best jonger zijn, ik heb te veel HDMI kabels rondslingeren dus ik weet niet of dit een oude is of niet

Verder heb je dan te maken met meerdere besturingssystemen; zelfs binnen Win10 kan het best iets uit maken op welk van de inmiddels 9 service packs iemand zit (waarvan de laatste 5 zeker nog relevant zijn en een grote userbase hebben).

Bugvrije software bestaat niet op deze schaal. Software kan alleen bugvrij zijn als het niets doet...en zelfs dan kan er nog iets mis gaan

[Sp3ci3s8472]

Sissors schreef op maandag 21 september 2020 @ 10:46:
Wacht, je gaat nu serieus de schuld geven aan PSUs en RAM voor alle black screen bugs? Die grotendeels opgelost zijn door nieuwe GPU drivers? Dus AMD GPU Drivers kunnen mijn PSU en RAM problemen oplossen?

En ja, ondertussen werkt het allemaal weer behoorlijk. Al heb ik gisteren nog moeten herstarten omdat mijn scherm steeds zwart ging voor een seconde en weer terug kwam. Scherm aan en uit zetten loste het niet op, dus scherm is niet het probleem. Gezien de andere kant van de kabel in de GPU gaat, ga ik toch de GPU de schuld hiervan geven. En na die opnieuw op te starten (samen met de rest van de PC) was het probleem wel opgelost.

Over het algemeen zou ik nu drivers geen probleem meer vinden voor iemand die een 5700XT wil open (los van hoe verstandig dat is op dit moment). Maar moeten we dan bij RDNA2 weer een jaar wachten op fatsoenlijke drivers?

Nee, probleem is dat sommige mensen hun timings te strak hebben met hun Ryzen systeem voornamelijk. Timings zoals TRFC and tFAW, als die te strak staan dan gaat het fout. Dus het systeem is al instabiel alleen zal een Nvidia kaart daar minder snel over klagen.
Tevens zijn deze fouten niet of nauwelijks te vinden met de standaard memtest, er zijn wel testen die het wel kunnen vinden.

Daarnaast, met een slechte voeding de vraag voor een klein moment te hoog zijn waardoor boem zwart scherm. Daarnaast altijd indien mogelijk een gelijk aantal kabels proberen te gebruiken als je hebt aan 6 en 8 pins.

Na deze dingen zelf te hebben aangepast.... is mijn 5700 XT wel stabiel los van de dode geheugen chip die erop zit . Het was dus een combinatie en van drivers en een slechte/kapotte voeding in mijn geval.

[DaniëlWW2]

Sp3ci3s8472 schreef op maandag 21 september 2020 @ 14:08:
[...]


Nee, probleem is dat sommige mensen hun timings te strak hebben met hun Ryzen systeem voornamelijk. Timings zoals TRFC and tFAW, als die te strak staan dan gaat het fout. Dus het systeem is al instabiel alleen zal een Nvidia kaart daar minder snel over klagen.
Tevens zijn deze fouten niet of nauwelijks te vinden met de standaard memtest, er zijn wel testen die het wel kunnen vinden.

Daarnaast, met een slechte voeding de vraag voor een klein moment te hoog zijn waardoor boem zwart scherm. Daarnaast altijd indien mogelijk een gelijk aantal kabels proberen te gebruiken als je hebt aan 6 en 8 pins.

Na deze dingen zelf te hebben aangepast.... is mijn 5700 XT wel stabiel los van de dode geheugen chip die erop zit . Het was dus een combinatie en van drivers en een slechte/kapotte voeding in mijn geval.

Wacht, die van jou had een kapotte GDDR6 chip?

[Sp3ci3s8472]

DaniëlWW2 schreef op maandag 21 september 2020 @ 14:12:
[...]


Wacht, die van jou had een kapotte GDDR6 chip?

Jup, maar dat merk ik vaak pas als hij een hele dag heeft aangestaan omdat ik er niet veel op game maar vooral op develop. Beeld krijgt mooie vierkante gekleurde blokjes en als je je muis beweegd of iets anders dan krijg je andere vierkantjes en kleurtjes . En in Final Fantasy 15 na een tijd spelen krijg ik flickering van sommige oppervlakten (worden 1 frame zwart). Geen idee of dit kan maar ik denk dat het de laatste chip is ofzo, omdat het probleem pas optreedt na een lange periode.
Probleem is ik kan geen RMA doen want ik heb er een eigen koeler op gezet (en heel knullig het dunne kabeltje van de fan kapot gemaakt). Dus ook weer geleerd, eerst een maand testen en dan pas een andere koeler erop zetten.
Ik ga er ook geen custom koeling opzetten bij RDNA 2, tenzij het HBM heeft. GDDR6 is erg slecht te koelen en zelfs met koperen heatsinks die met een speciale paste vastzitten worden ze warm. Nu wil ik ze graag onder de 85 graden houden maar dan moeten de Noctua's op 1500 RPM (van de 2100). De gpu is dan ondertussen onder load max 58 graden maar het geheugen zit dan tussen de 75-80.
Nu lees ik ook wel de gruwel verhalen van de non reference koelers die de mem chips niet goed koelen met geheugen dat 105 graden wordt.....
Een fullcover blok met goede fans zou ook een oplossing kunnen zijn maar losse heatsinks niet echt.

[ Voor 8% gewijzigd door Sp3ci3s8472 op 21-09-2020 14:23 ]

[Grotbewoner]

Big Navi lijkt 12gb en 16gb aan geheugen te hebben.

[MneoreJ]

Grotbewoner schreef op maandag 21 september 2020 @ 15:25:
Big Navi lijkt 12gb en 16gb aan geheugen te hebben.

Check ook altijd even de datum van wat je post. Dit is oud nieuws en dus al gemeld, ook al nemen sommige sites het nu pas over.

[DaniëlWW2]

Sp3ci3s8472 schreef op maandag 21 september 2020 @ 14:21:
[...]


Jup, maar dat merk ik vaak pas als hij een hele dag heeft aangestaan omdat ik er niet veel op game maar vooral op develop. Beeld krijgt mooie vierkante gekleurde blokjes en als je je muis beweegd of iets anders dan krijg je andere vierkantjes en kleurtjes . En in Final Fantasy 15 na een tijd spelen krijg ik flickering van sommige oppervlakten (worden 1 frame zwart). Geen idee of dit kan maar ik denk dat het de laatste chip is ofzo, omdat het probleem pas optreedt na een lange periode.
Probleem is ik kan geen RMA doen want ik heb er een eigen koeler op gezet (en heel knullig het dunne kabeltje van de fan kapot gemaakt). Dus ook weer geleerd, eerst een maand testen en dan pas een andere koeler erop zetten.

Dat verklaard in ieder geval jouw crashes dan. Maar deze is wel minder ja.

Ik ga er ook geen custom koeling opzetten bij RDNA 2, tenzij het HBM heeft. GDDR6 is erg slecht te koelen en zelfs met koperen heatsinks die met een speciale paste vastzitten worden ze warm. Nu wil ik ze graag onder de 85 graden houden maar dan moeten de Noctua's op 1500 RPM (van de 2100). De gpu is dan ondertussen onder load max 58 graden maar het geheugen zit dan tussen de 75-80.
Nu lees ik ook wel de gruwel verhalen van de non reference koelers die de mem chips niet goed koelen met geheugen dat 105 graden wordt.....
Een fullcover blok met goede fans zou ook een oplossing kunnen zijn maar losse heatsinks niet echt.

Gewoon een Sapphire Nitro+ kopen.
Maar wat je beschrijft heet de ASUS TUF. De RX5700 versie had helemaal geen GDDR6 heatsinks, de XT had een zeer dun plaatje dat geen contact maakte met wat dan ook. Die was zowaar erger dan helemaal niks.

[Enchantress]

Xadeon schreef op maandag 21 september 2020 @ 03:25:
[Twitter]
Kloksnelheid van +2Ghz ligt wel in de lijn der verwachting, toch? En een TDP van......?

Dat zal goed kunnen maar coreteks is nou niet bepaald betrouwbaar, die heeft het vaker fout dan dat hij goed zit.

[Xadeon]

@Enchantress Ik hoef denk ik hier toch niet erbij te vermelden dat je 't altijd met een korreltje zout moet nemen.

Sony and Microsoft are at maximum capacity, AMD allocated more 7n capacity at TSMC

AMD just got an extra 13K 7N wafer allocation at TSMC, from vacancy of another victim (Mediatek) of the Huawei sanctions. Journalist "sources" suggest AMD is devoting all these for PS5/SX production this quarter. https://t.co/5aqORjhwDf

— NerdTech (@nerdtechgasm) 21 september 2020

If this source is correct, one would have to assume, MS & Sony may have done a deal with AMD for priority access to wafers. Otherwise, AMD can put those 7N wafers to good use with their own product line up. Lisa Su likes higher margins.

— NerdTech (@nerdtechgasm) 21 september 2020

Following on, this could be quite bad news for "Big & Biggest Navi". The extra wafer supply is required for relatively big GPU dies to hit volumes, but if its all gone to consoles... I would be expecting a paper launch situation for the rest of Q4. https://t.co/fuRfAbQrLZ

— NerdTech (@nerdtechgasm) 21 september 2020

[Enchantress]

@Xadeon

Ik hoef denk ik hier toch niet erbij te vermelden dat je 't altijd met een korreltje zout moet nemen

Nee dat hoeft zeker niet, maar je hebt ''leakers'' en ''leakers''.
De ene heeft het heel vaak goed of zit er zeer dichtbij in de buurt die dus een goede track-record heeft, de ander heeft het vaak fout en zit er vaak totaal naast.

Coreteks valt in de tweede categorie, zo iemand zal ik zelf niet snel aanhalen als bron.

[DaniëlWW2]

Xadeon schreef op maandag 21 september 2020 @ 17:17:
@Enchantress Ik hoef denk ik hier toch niet erbij te vermelden dat je 't altijd met een korreltje zout moet nemen.

Sony and Microsoft are at maximum capacity, AMD allocated more 7n capacity at TSMC

[Twitter][Twitter]
[Twitter]

Mediatek ook uitgesloten? AMD moet dan echt op de helft of meer van de totale capaciteit zitten. Voor AMD is dit echt geweldig nieuws want nu kunnen ze langzaam maar zeker hun volumes maar blijven opschroeven. Dat Sony en Microsoft prioriteit krijgen, tja als ze ervoor willen betalen dan gebeurd dat natuurlijk. Voor ons het het alleen lastig om te zeggen wat er gebeurd. Radeon zal ergens onderaan de prioriteitenlijst bungelen omdat er simpelweg meer marge op Zen 3 zal zitten en Renoir waarschijnlijk ook veel belangrijker is, maar ergens denk ik dat AMD ook geen paperlaunch wil uitvoeren.

[ Voor 7% gewijzigd door DaniëlWW2 op 21-09-2020 18:11 ]

[Dennism]

@DaniëlWW2 ik verwacht niet dat Mediatek uitgesloten is, is immers Taiwanees voor zover ik weet. Maar ze leveren wel veel aan huawei. Dat kan natuurlijk Mediatek ook gaan voelen in de orders waardoor ze misschien de forecasts hebben aan moeten passen.

Aan de andere kant waren ze juist bezig om meer en meer te gaan leveren aan Huawei. Misschien dus met een korreltje zout nemen.

https://www.reuters.com/a...ei-mediatek-idUSKBN25O0SG

AMD zou trouwens ook een licentie hebben gekregen om toch te mogen blijven leveren aan Huawei.

[Xadeon]

@Enchantress Dat hangt eigenlijk af van in welke context je het plaatst. Overigens wordt Coreteks ondanks zijn 'trackrecord' vrij serieus genomen in het 'tech leak wereldje'.

Het is hier al eens besproken, maar nog eens een recap van Mark Cerny's persco die ik even langs zag komen.

***NVMe PCIe 4.0 m.2 expandability**
***"That feature set is malleable. ...and that can factor into what AMD roadmap becomes. So, collaboration is born. If we bring concepts to AMD that are felt to be widely useful then they can be adopted to RDNA2 and used broadly including in PC GPUs. If the ideas are sufficiently specific to what we're trying to accomplish like the GPU Cache Scrubbers I was talking about, then they end up being just for us. **If you see a similar discrete GPU available as a PC card at roughly the same time as we release our console**, that means our collaboration with AMD succeeded in producing technology useful in both worlds. It doesn't mean we at Sony simply incorporated the PC part into our console."
* "This continuous improvement in AMD technology means **it's dangerous to rely on TFLOPs as an absolute indicator of performance and CU count should be avoided as well.**"
* "Adding new features means adding lots of transistors. In fact **transistor count for PS5 CU is 62% larger than the transistor count for the PS4 CU.**"
* "...such as aborting the processing of a vertex, if all geometry that uses it is offscreen. PS5 has a new unit called the Geometry Engine which brings **handling of triangles and other primitives under full programatic control**."
* "More complex usage involves something called **Primitive Shaders which allow the game to synthesise the geometry on fly** **as it's being rendered**. It's a brand new capability. Using Primitive Shaders on PS5 will allow for a broad variety of techniques, incl. smoothly varying LOD, addition of procedural detail to close up objects and improvements to particle effects and other visual special effects."
* Using the same strategy as AMD's upcoming PC GPUs. ***The CUs contain a new specialised called The Intersection Engine**, which can calculate intersection of rays with boxes and triangles.
* "AMD SmartShift and send any unused power from the CPU to the GPU so it can squeeze out a few more pixels. Benefits of this strategy are quite large. Running a GPU at 2GHz was looking like an unreachable target with the old frequency strategy. With this new paradigm we are able to run way over that. **In fact we have to cap the GPU frequency at 2.23GHz** **so that we can guarantee that the on-chip logic operates properly**."

[Sp3ci3s8472]

Xadeon schreef op maandag 21 september 2020 @ 17:17:
@Enchantress Ik hoef denk ik hier toch niet erbij te vermelden dat je 't altijd met een korreltje zout moet nemen.

Sony and Microsoft are at maximum capacity, AMD allocated more 7n capacity at TSMC

[Twitter][Twitter]
[Twitter]

Is het niet zo dat GPU's nog altijd een hogere marge hebben dan wat ze aan Sony/MS leveren? CPU's hebben natuurlijk nog een hogere marge.

[Help!!!!]

Ja maar gaan ws stuk meer meer console chips uit zo'n waver dan big navi's.

Dus marge per waver zal misschien wel hoger liggen. Plus belangrijk om Sony en MS te vriend te houden

[ Voor 41% gewijzigd door Help!!!! op 21-09-2020 20:51 ]

[Xadeon]

@Sp3ci3s8472 Ik denk het wel, maar Sony/Microsoft krijgen ongetwijfeld voorrang.

RDNA2 verhaal begint vanaf 9:37.

Ter aanvulling;

I find this idea of 128 MB cache in NAVI 2x suspicious. NAVI 10 is ~250 mm2 (40 CUs), NAVI 2x is supposed to have 80 CUs that would be ~500 mm2. Now 128 MB cache (SRAM) at 7nm is between 30 (TSMC SRAM cell size) and 135 mm2 (based on Zen 2 L3). That would make NAVI 2x ~600 mm2.

— Filip Vaverka (@Deluxef) 20 september 2020

[Twitter: https://twitter.com/JirayD/status/1308041195843715072?s=19]

[Twitter: https://twitter.com/JirayD/status/1308042333015990278?s=19]

[Twitter: https://twitter.com/JirayD/status/1308044082250477570?s=19]

[DaniëlWW2]

Dan kan het misschien dus wel. Het zou dit verklaren.
[Twitter: https://twitter.com/KittyYYuko/status/1304252347871367171]

Ergens is het misschien ook wel een logische omdat we weten dat er Zen technici naar de RTG zijn overgeplaatst nadat Zen 1 voltooid was. Bij RDNA2 zou je dan hun werk verwachten. De logica is ook duidelijk voor de L2 cache want je bespaard er waarschijnlijk enorm veel geheugenbandbreedte mee. Het probleem bleef voor mij hoe moet het passen op de GPU die vanuit meerdere kanten als 505mm² is beschreven. Maar het zou wel wat zijn als ze het echt kunnen. Het scheelt immers niet alleen enorm veel geheugenbandbreedte naar VRAM, maar het zou ook pipeline stalls moeten verminderen. Misschien is dat ook wel de sleutel tot de verhalen dat we veel weten van de XSX GPU, maar niet van de PS5 waar al tijden de geruchten gaan dat juist die zeer innig met AMD is ontwikkeld en er bepaalde dingen inzitten waar Mark Cerny maanden geleden al op hintte.

---

edit: Nerdtechgasm lijkt het dus wel serieus te nemen, ook dat RGT dus wel bronnen binnen AMD zou hebben die hem bewust zaken lekken. Het lijkt dus langzaam toch gewoon te kunnen. In ieder geval iets om echt naar uit te kijken.
https://www.patreon.com/posts/on-possibility-41614524

[ Voor 13% gewijzigd door DaniëlWW2 op 21-09-2020 22:50 ]

[sunsmountain]

DaniëlWW2 schreef op maandag 21 september 2020 @ 21:10:
Dan kan het misschien dus wel. Het zou dit verklaren.
[Twitter]

Ergens is het misschien ook wel een logische omdat we weten dat er Zen technici naar de RTG zijn overgeplaatst nadat Zen 1 voltooid was. Bij RDNA2 zou je dan hun werk verwachten. De logica is ook duidelijk voor de L2 cache want je bespaard er waarschijnlijk enorm veel geheugenbandbreedte mee. Het probleem bleef voor mij hoe moet het passen op de GPU die vanuit meerdere kanten als 505mm² is beschreven. Maar het zou wel wat zijn als ze het echt kunnen. Het scheelt immers niet alleen enorm veel geheugenbandbreedte naar VRAM, maar het zou ook pipeline stalls moeten verminderen. Misschien is dat ook wel de sleutel tot de verhalen dat we veel weten van de XSX GPU, maar niet van de PS5 waar al tijden de geruchten gaan dat juist die zeer innig met AMD is ontwikkeld en er bepaalde dingen inzitten waar Mark Cerny maanden geleden al op hintte.

---

edit: Nerdtechgasm lijkt het dus wel serieus te nemen, ook dat RGT dus wel bronnen binnen AMD zou hebben die hem bewust zaken lekken. Het lijkt dus langzaam toch gewoon te kunnen. In ieder geval iets om echt naar uit te kijken.
https://www.patreon.com/posts/on-possibility-41614524

Dit is beter dan mijn eerdere berekening, omdat ik alle Navi 10 elementen twee keer geteld had, foutief ook de memory controller (terwijl ik uitging van 256-bit). Maar de conclusie is hetzelfde: het kan wel degelijk.

[DaniëlWW2]

De configuratie voor Navy Flounder is ook gelekt.
40CU's, twee Shader Engines, maar de geheugenbus is 192bit.

https://www.reddit.com/r/...us_and_192bit_bus_source/

Navy Flounder zou Navi 22 zijn. Ik denk dat ik het steeds zekerder ga weten. Die enorme L2 cache, die gaat komen. Het sluit simpelweg aan bij verschillende betrouwbare leakers en er zijn geen alternatieven die werken. 384bit en HBM2E kunnen gewoon niet met die configuratie.

🧐

I've now got confirmation for both :

> Navi21 16GB VRAM
> Navi22 12GB VRAM

I have no idea if these are full die or cut down SKUs

— _rogame 🇵🇸 (@_rogame) 17 september 2020

[Twitter: https://twitter.com/KittyYYuko/status/1304252347871367171]

Dit is Navi 21, niet Navi 22. Daarom zijn het twee 8 pin connectoren en is die chip zo groot. Ze gaan het gewoon echt doen. Een 80CU 505mm² chip met een 256bit bus.

[XWB]

DaniëlWW2 schreef op dinsdag 22 september 2020 @ 14:56:
Een 80CU 505mm² chip met en 256bit bus.

Zou je die smileys kunnen toelichten?

[DaniëlWW2]

XWB schreef op dinsdag 22 september 2020 @ 14:58:
[...]


Zou je die smileys kunnen toelichten?

Zeker.
Ze gaan Navi 10 verdubbelen in aantal ALU's, Shader Array's en Shader Engines. Daarnaast gaan ze RT toevoegen alsmede de DX12 ultimate functies. Maar qua geheugenbandbreedte gaan ze van 448GB/s naar 512GB/s. Het is compleet gestoord, totaal buiten elke realistische verwachting en vrijwel niemand zal dit aan hebben zien komen. En toch gaan ze het doen en ik denk niet omdat ze bij de RTG zo bizar incompetent zijn dat willekeurige mensen op het internet ze kunnen vertellen dat ze het verkeerd doen. Nee, dit gaat presteren en dit gaat waarschijnlijk een van de belangrijkste elementen van AMD haar 50% perf/watt claims worden. Immers verdubbelen ze de GPU zonder meer energie nodig te hebben aan geheugenbandbreedte. Dat zal circa 40W blijven net zoals Navi 10.

Het is echt compleet gestoord. Ik heb nog nooit van een GPU gehoord waar ze een verdubbeling van rekeneenheden ten opzichte van de voorganger hebben doorgevoerd zonder een gigantische stap in geheugenbandbreedte. Het kan gewoon niet zonder dat ze heel wat bijzonders gaan doen.

[flessuh]

Als ze dat lukt is het zeker een flinke sprong, en een verklaring voor het nu al lekken van 30x0 met meer VRAM.

Geeft mij weer twijfel of ik niet moet wachten (ondanks dat ik echt spuugzat ben van m'n onstabiele Vega 64)

[XWB]

DaniëlWW2 schreef op dinsdag 22 september 2020 @ 15:09:
[...]

Het is echt compleet gestoord. Ik heb nog nooit van een GPU gehoord waar ze een verdubbeling van rekeneenheden ten opzichte van de voorganger hebben doorgevoerd zonder een gigantische stap in geheugenbandbreedte. Het kan gewoon niet zonder dat ze heel wat bijzonders gaan doen.

Op zich kan dat prima als er betere compressie toegepast wordt. Daar is op zich weinig bijzonders aan.

Of we hebben het allemaal verkeerd en die kaart wordt een 4K bottleneck

[Psyonara]

Deze nieuwe zal dan ook nog wel Driver optimalisatie nodig hebben.

[flessuh]

Psyonara schreef op dinsdag 22 september 2020 @ 15:16:
Deze nieuwe zal dan ook nog wel Driver optimalisatie nodig hebben.

Nou ja dat lijkt nu met mijn Vega 64 het probleem ook te zijn. Sinds bepaalde update is het gewoon mis. Ook met eerdere AMD kaarten gehad. Volledige reinstall nodig om het te fixen laatste keer.

En dat maakt mij wel wat huiverig voor de komende generatie zegmaar.

Then again, deze navi kaarten zijn voor meer bulk productie dan Vega

[ Voor 7% gewijzigd door flessuh op 22-09-2020 15:22 ]

[XWB]

Je kan het ook een tijdje aankijken en een maandje na release alsnog de nieuwe Navi aanschaffen.

[RobinNL]

DaniëlWW2 schreef op dinsdag 22 september 2020 @ 15:09:
[...]


Zeker.
Ze gaan Navi 10 verdubbelen in aantal ALU's, Shader Array's en Shader Engines. Daarnaast gaan ze RT toevoegen alsmede de DX12 ultimate functies. Maar qua geheugenbandbreedte gaan ze van 448GB/s naar 512GB/s. Het is compleet gestoord, totaal buiten elke realistische verwachting en vrijwel niemand zal dit aan hebben zien komen. En toch gaan ze het doen en ik denk niet omdat ze bij de RTG zo bizar incompetent zijn dat willekeurige mensen op het internet ze kunnen vertellen dat ze het verkeerd doen. Nee, dit gaat presteren en dit gaat waarschijnlijk een van de belangrijkste elementen van AMD haar 50% perf/watt claims worden. Immers verdubbelen ze de GPU zonder meer energie nodig te hebben aan geheugenbandbreedte. Dat zal circa 40W blijven net zoals Navi 10.

Het is echt compleet gestoord. Ik heb nog nooit van een GPU gehoord waar ze een verdubbeling van rekeneenheden ten opzichte van de voorganger hebben doorgevoerd zonder een gigantische stap in geheugenbandbreedte. Het kan gewoon niet zonder dat ze heel wat bijzonders gaan doen.

Ik probeer het een beetje te volgen hier, maar hoe zou zo'n kaart dan ongeveer presteren? Het is allemaal nog niet zeker, dat weet ik, maar ik probeer er een beetje een beeld bij te krijgen.

[DJvL]

DaniëlWW2 schreef op dinsdag 22 september 2020 @ 15:09:
[...]


Zeker.
Ze gaan Navi 10 verdubbelen in aantal ALU's, Shader Array's en Shader Engines. Daarnaast gaan ze RT toevoegen alsmede de DX12 ultimate functies. Maar qua geheugenbandbreedte gaan ze van 448GB/s naar 512GB/s. Het is compleet gestoord, totaal buiten elke realistische verwachting en vrijwel niemand zal dit aan hebben zien komen. En toch gaan ze het doen en ik denk niet omdat ze bij de RTG zo bizar incompetent zijn dat willekeurige mensen op het internet ze kunnen vertellen dat ze het verkeerd doen. Nee, dit gaat presteren en dit gaat waarschijnlijk een van de belangrijkste elementen van AMD haar 50% perf/watt claims worden. Immers verdubbelen ze de GPU zonder meer energie nodig te hebben aan geheugenbandbreedte. Dat zal circa 40W blijven net zoals Navi 10.

Het is echt compleet gestoord. Ik heb nog nooit van een GPU gehoord waar ze een verdubbeling van rekeneenheden ten opzichte van de voorganger hebben doorgevoerd zonder een gigantische stap in geheugenbandbreedte. Het kan gewoon niet zonder dat ze heel wat bijzonders gaan doen.

Ik denk het ook. 128Mb cache. Verdubbeling van het aantal CU's (80). Zullen ook nog wel wat tweaks hier en daar in zitten van RDNA1 naar RDNA2.
256 Bits geheugenbus.

Niemand verwacht het, ik denk dat ze daarom ook alles zo angstvallig stil houden.

Ik denk dat ze leuke dingen hebben uitgevonden samen met Sony.

Ik denk ook dat Nvidia de bui al zag hangen en de 3090 echt hun max was en ze daarom voor de 3080 wat cores hebben moeten disabelen en onwijs veel power naar dat ding sturen. (Nu moet ik wel zeggen dat mijn Sapphire Vega64 Nitro+ LM ook aardig die richting op gaat).

Ze hebben gewoon een hele slimme oplossing gevonden.

We zullen het zien. AMD (not so) Big Navi.

[ Voor 3% gewijzigd door DJvL op 22-09-2020 16:29 . Reden: Typo ]

[DaniëlWW2]

XWB schreef op dinsdag 22 september 2020 @ 15:16:
[...]


Op zich kan dat prima als er betere compressie toegepast wordt. Daar is op zich weinig bijzonders aan.

Of we hebben het allemaal verkeerd en die kaart wordt een 4K bottleneck

Dit ga je er niet uithalen met compressie. Deze 80CU Navi 21 hoort gewoon rond de RTX3080, zo niet de RTX3090 uit te komen. Zoveel rekenkracht zit erop. We weten van de RX5700 en RX5700XT dat het procentenwerk is met de RTX2070 en RTX2070S met vergelijkbare clock speeds en dezelfde aantal FP32 capable ALU's, respectievelijk 2304 en 2560.

Ampere in de vorm van de RTX3080 met 68SM's (4352 ALU's + 4352 ALU's), lijkt maar 20 a 25% te winnen van die extra 4352 ALU's op respectievelijk 1440P en 4K. Immers had de RTX2080Ti ook 4352 ALU's. Dat is zeer karig voor een verdubbeling van FP32 ALU's en toen kwam er nog circa 45W extra verbruik bij. Het demonstreert dat Ampere met serieuze bottlenecks kampt in haar architectuur en dat was voor release eigenlijk al duidelijk.

RDNA2 lijkt dat probleem vooralsnog niet te hebben. Navi 21 verdubbeld de Shader Engines ten opzichte van Navi 10 en behoud ruwweg dezelfde Shader Array configuratie. Het is ruwweg 2x dit en dat is eigenlijk het enige dat we al maanden weten.


Dat gegeven alleen maakt al duidelijk dat deze chip met 5120 ALU's, ergens rond de GA102 chips van Nvidia moet uitkomen. Ik hou hier bewust geen rekening met hogere clock speeds of merkbare verbeteringen in architectuur die effectieve utilisatie van al die ALU's verhogen. Nee, alleen 2x Navi 10.

---

De vraag is alleen hoe het gaat schalen. Perfect lineair zit er meestal niet in en daar zal RDNA2 de winst over RDNA1 moeten maken in architectuur. Wat de meeste videokaarten doen is met brute force meer geheugenbandbreedte toevoegen met grotere chips. Daarom dacht ik HBM2E omdat je zo in theorie over de 1TB/s kan gaan. Dat is ruim 2x van Navi 10 en dat zou het realistisch maken om 100% te schalen.

Het lijkt er alleen op dat RDNA2 dit dus niet gaat doen. Nee, het idee lijkt te zijn om veel meer naar de "CPU hiërarchie" te gaan en een enorme hoeveelheid cache beschikbaar te stellen aan de GPU. Op het moment hebben zelfs high end GPU's maar enkele MB's aan L2 cache. AMD zou er blijkbaar 128MB van gaan maken. Het idee zal zijn om zoveel mogelijk data die misschien nog nodig is voor nieuwe clock cycles, snel beschikbaar te maken in die cache zodat je niet meer hoeft te wachten totdat het eindelijk uit het relatief langzame VRAM komt. Dat verhoogd de effectieve occupency van de GPU haar ALU's en dat is het enige in een GPU dat je zeer ruw kan vertalen met "IPC".

De VRAM zal op deze manier meer een framebuffer worden waar de taak van data terugsturen naar de GPU minder zal worden. Verder zou het goed kunnen dat data uit VRAM halen met minder prestatieproblemen gepaard zal gaan omdat ze die enorme cache hebben die als buffer dient. Als de aanvragen voor data maar afdoende clock cycles voordat de data nodig is, worden verstuurd, dan zou de data al in die enorme L2 kunnen zitten als het nodig is. Dit zal heel wat geheugenbandbreedte schelen omdat geheugenbandbreedte de term is voor de maximale snelheid tussen GPU en VRAM. De logica is dat juist SRAM zo goed schaalt met kleinere nodes en juist I/O zoals geheugencontrollers niet. Daarom kreeg je met Zen 2 ook een aparte I/O chiplet en nog meer cache voor de CPU chiplet.

[ocf81]

Ik ben wel benieuwd of ze ook met een kaart komen die infinity fabric gaat gebruiken voor een dual chip oplossing.

[sunsmountain]

DaniëlWW2 schreef op dinsdag 22 september 2020 @ 14:56:
De configuratie voor Navy Flounder is ook gelekt.
40CU's, twee Shader Engines, maar de geheugenbus is 192bit.

https://www.reddit.com/r/...us_and_192bit_bus_source/

Navy Flounder zou Navi 22 zijn. Ik denk dat ik het steeds zekerder ga weten. Die enorme L2 cache, die gaat komen. Het sluit simpelweg aan bij verschillende betrouwbare leakers en er zijn geen alternatieven die werken. 384bit en HBM2E kunnen gewoon niet met die configuratie.

[Twitter]
[Twitter]

Dit is Navi 21, niet Navi 22. Daarom zijn het twee 8 pin connectoren en is die chip zo groot. Ze gaan het gewoon echt doen. Een 80CU 505mm² chip met een 256bit bus.
[Afbeelding]
[Afbeelding]

Ik denk dat die foto met 8 chippies Navi 21 is ja. Maar als Navi Flounder met 40CU de Navi22 is, zou dat wel erg tegenvallen. Zeker met ook nog eens een memory controllertje minder. De XSX chip met vergelijkbaar formaat (groter maar met zen cpu er bij) heeft namelijk 4*14 CU = 56 CU, 40 CU is dan wel karig. Ik denk daarom dat Navi Flounder Navi23 is. En Navi22 56CU.

N21 : 505. (80 CU) le big navi
N22 : 340. (56 CU) copy paste full XSX die
N23 : 240. (40 CU) Flounder https://t.co/8GW19Ck9sm

Wat betreft de 128 MB infinity cache (fabric = cpu), zou inderdaad best een revolutionaire hardware stap zijn, en veel van de performance per Watt winst verklaren. Als de prestaties ook maar een beetje schalen per Watt (die +50%), dan verslaat Navi21 de RTX3090 al vanaf 300W. Bizar.

(2070 super = RX5700XT , laatste drivers, = 100%)
(RTX3080 is 180% van 2070 super, +10% RTX3090 is 200%)
(Big navi zou zijn, als waar, 1,5*(300W/225W) = 1,5*1,333333 = 200%)

Het verschil met Intel: nVidia vecht terug. DLSS 2.0 is een mooie feature die ik zou missen, ray tracing is misschien beter, en er komt mogelijk nog een 3080Ti aan. Maar ik denk als AMD wint, dan wordt het wachten voor nVidia op TSMC capaciteit volgend jaar.

De RTX3090 GA102 op een TSMC 7nm EUV node zou belachelijk veel beter zijn dan Samsung 8nm (als een refresh). Waarschijnlijker is denk ik echter een vervroegde node run van de GA100 (de Quadro chip) Q1/Q2 2021 als 'gamer kaart' om de performance crown terug te krijgen, omdat ik vermoed dat nVidia niet gaat wachten op de refresh via TSMC van de GA102, en dat Samsung niet een kwart/halfjaar contractje heeft gesloten met nVidia. Maar goed je weet nooit.

[Mars Warrior]

sunsmountain schreef op dinsdag 22 september 2020 @ 17:47:
[...]
N21 : 505. (80 CU) le big navi
N22 : 340. (56 CU) copy paste full XSX die
N23 : 240. (40 CU) Flounder https://t.co/8GW19Ck9sm

Ik zou nog wat meer varianten verwachten voor de basis en XT varianten.
Dit kan natuurlijk door toch nog meer CU varianten uit te brengen, maar ook door de max. boost te variëren.
Een N22 met 2.2Ghz max boost ipv de 1.8Ghz van de XSX zou zomaar een extra sku kunnen zijn.
N22 full die verwacht ik dan wel op max 60CU's. Dat middelt lekker namelijk

Als die cache het werkelijk goed doet, en daarmee de memory latencies sterk weet te bepreken bij beperkte bezetting van de GPU, dan kan het zomaar zijn dat de lagere varianten het(relatief) erg goed doen op 1080 en 1440p. Daar waar de 3080 - zeker op 1080p - maar weinig toevoegt.

[Sp3ci3s8472]

DaniëlWW2 schreef op dinsdag 22 september 2020 @ 16:32:
[...]


Dit ga je er niet uithalen met compressie. Deze 80CU Navi 21 hoort gewoon rond de RTX3080, zo niet de RTX3090 uit te komen. Zoveel rekenkracht zit erop. We weten van de RX5700 en RX5700XT dat het procentenwerk is met de RTX2070 en RTX2070S met vergelijkbare clock speeds en dezelfde aantal FP32 capable ALU's, respectievelijk 2304 en 2560.

Tegenwoordig niet meer, maar zowel de R9 285 en de Maxwell series (Kepler daarvoor) van Nvidia begonnen met Delta Color Compression. Zie ook:
https://www.anandtech.com/show/8526/nvidia-geforce-gtx-980-review/3

Tegenwoordig zal het inderdaad niet meer zo makkelijk kunnen tenzij er een nieuwe vorm van compressie wordt ontwikkeld.

[DaniëlWW2]

Sp3ci3s8472 schreef op dinsdag 22 september 2020 @ 19:32:
[...]


Tegenwoordig niet meer, maar zowel de R9 285 en de Maxwell series (Kepler daarvoor) van Nvidia begonnen met Delta Color Compression. Zie ook:
https://www.anandtech.com/show/8526/nvidia-geforce-gtx-980-review/3

Tegenwoordig zal het inderdaad niet meer zo makkelijk kunnen tenzij er een nieuwe vorm van compressie wordt ontwikkeld.

Dat was zeker geen 300GB/s+ aangezien GM200 een 384bit, 336GB/s geheugensysteem had. Dat is namelijk de schaal waar we hier over spreken. Nvidia heeft GDDR6X met Micron ontwikkeld omdat het gewoon keihard nodig was om er weer een paar honderd GB/s erbij te doen.

Wat AMD waarschijnlijk gaat doen, kan je niet bereiken met compressietechnieken. Als je weet hoe, tja ik zou deze informatie niet hier plaatsen, maar verkopen aan de hoogste bieder. Dat is het soort informatie dat je waarschijnlijk een vroegtijdige pensioennering zou opleveren.

sunsmountain schreef op dinsdag 22 september 2020 @ 17:47:
[...]


Ik denk dat die foto met 8 chippies Navi 21 is ja. Maar als Navi Flounder met 40CU de Navi22 is, zou dat wel erg tegenvallen. Zeker met ook nog eens een memory controllertje minder. De XSX chip met vergelijkbaar formaat (groter maar met zen cpu er bij) heeft namelijk 4*14 CU = 56 CU, 40 CU is dan wel karig. Ik denk daarom dat Navi Flounder Navi23 is. En Navi22 56CU.

N21 : 505. (80 CU) le big navi
N22 : 340. (56 CU) copy paste full XSX die
N23 : 240. (40 CU) Flounder https://t.co/8GW19Ck9sm

Wat betreft de 128 MB infinity cache (fabric = cpu), zou inderdaad best een revolutionaire hardware stap zijn, en veel van de performance per Watt winst verklaren. Als de prestaties ook maar een beetje schalen per Watt (die +50%), dan verslaat Navi21 de RTX3090 al vanaf 300W. Bizar.

(2070 super = RX5700XT , laatste drivers, = 100%)
(RTX3080 is 180% van 2070 super, +10% RTX3090 is 200%)
(Big navi zou zijn, als waar, 1,5*(300W/225W) = 1,5*1,333333 = 200%)

Het verschil met Intel: nVidia vecht terug. DLSS 2.0 is een mooie feature die ik zou missen, ray tracing is misschien beter, en er komt mogelijk nog een 3080Ti aan. Maar ik denk als AMD wint, dan wordt het wachten voor nVidia op TSMC capaciteit volgend jaar.

De RTX3090 GA102 op een TSMC 7nm EUV node zou belachelijk veel beter zijn dan Samsung 8nm (als een refresh). Waarschijnlijker is denk ik echter een vervroegde node run van de GA100 (de Quadro chip) Q1/Q2 2021 als 'gamer kaart' om de performance crown terug te krijgen, omdat ik vermoed dat nVidia niet gaat wachten op de refresh via TSMC van de GA102, en dat Samsung niet een kwart/halfjaar contractje heeft gesloten met nVidia. Maar goed je weet nooit.

56CU's zou mooi zijn, hoewel ik erbij blijf dat het waarschijnlijk wat "diep" is met 14CU's/7 dual CU's per Shader Array. Het kan, zeker, maar ik zou niet verbaast zijn als het 52CU's zou worden. Maar als ik erbij pak dat Navi 22 kennelijk ook maar 192bit is, tja, die zou ook een flinke L2 cache nodig hebben om dit te kunnen doen. Ik sluit het niet uit, maar ik weet het bij lange na niet zeker.

Oh en vergeet GA102 op een 7nm node van TSMC. Ik zie het simpelweg niet gebeuren omdat de chip vanaf de grond af is ontworpen voor Samsung 8N en je patentconflicten krijgt als je dezelfde chip ook bij TSMC hebt ontwikkeld. Verder is dit een heel erg duur voorstel. Het kost honderden miljoenen dollars om een architectuur productie gereed te maken. Het is dat de meeste GPU's simpelweg bouwblokken zijn en zeker Nvidia een blok maakt en naar beneden schaalt voor de goedkopere chips. Dat drukt die kosten omdat ze zo heel veel kunnen hergebruiken. Ik zie Nvidia niet honderden miljoenen uitgeven om Ampere eerst op Samsung te ontwerpen om een paar maanden later naar TSMC te gaan, met enorme patentconflicten te komen te zitten en ondertussen de kosten van de Samsung stap er niet uit te hebben gehaald. Nvidia zit gewoon op Samsung voor deze hele generatie.

Maar dit hoort in het Nvidia topic.

[Sp3ci3s8472]

DaniëlWW2 schreef op dinsdag 22 september 2020 @ 19:55:
[...]


Dat was zeker geen 300GB/s+ aangezien GM200 een 384bit, 336GB/s geheugensysteem had. Dat is namelijk de schaal waar we hier over spreken. Nvidia heeft GDDR6X met Micron ontwikkeld omdat het gewoon keihard nodig was om er weer een paar honderd GB/s erbij te doen.

Wat AMD waarschijnlijk gaat doen, kan je niet bereiken met compressietechnieken. Als je weet hoe, tja ik zou deze informatie niet hier plaatsen, maar verkopen aan de hoogste bieder. Dat is het soort informatie dat je waarschijnlijk een vroegtijdige pensioennering zou opleveren.


[...]

Dat was het wel, misschien niet in GB/s omdat alles tegenwoordig sneller gaat maar wel je naar de percentages kijkt.

https://www.anandtech.com...md-radeon-r9-285-review/3

[Xadeon]

AMD adds Dimgrey Cavefish (NAVI 23) to Linux OpenGL driver

AMD adds Dimgrey Cavefish (NAVI 23) to Linux OpenGL driver https://t.co/lzpcbJ2CAz

— VideoCardz.com (@VideoCardz) 22 september 2020

[Twitter: https://twitter.com/KOMACHI_ENSAKA/status/1308473475875528704?s=19]