CJ's AMD Radeon Info & Nieuwsdiscussietopic - Deel 144

[Werelds]

sunsmountain schreef op vrijdag 15 juli 2022 @ 19:29:
Jij bekijkt de units (als developer) vanuit de aansturing - ongeacht wat de capaciteiten zijn van wat je aanstuurt, ik bekijk de units (als natuurkundige) vanuit de uitvoer - ongeacht hoe de aansturing is.

Best, ik wil het ook vanuit die kant benaderen en alle aansturing en datapaden daarbij volledig negeren. Dan wordt het plaatje echter nog minder rooskleurig voor hetgeen Nvidia in theorie zou hebben en wat ze in de praktijk hebben.

Een GA102-225 (3080 Ti) heeft dan 10240 FP32 ALU's en 5120 INT32 ALU's voor een totaal van 15360 ALU's. Je moet de mixed datapaden dan ook niet mee in beschouwing nemen, want dat is al een stuk aansturing. AMD heeft er slechts 5120, die dan wel zowel FP32 als INT32 (alsmede enig ander data type) kunnen verwerken. Als je alles negeert en puur naar de ALU's kijkt, zou Nvidia zonder moeite minstens twee keer zo rap moeten zijn, met hun kleinere super-simpele ALU's.

Vanuit de "top" schedulers bekeken hebben we het in ieder geval over dezelfde units. Wat mij oneerlijk zou lijken en waar ik bang voor was, is als je 40 DCU met 40 SM's zou gaan vergelijken, maar dat doe je gelukkig niet.

Uit geen van beide perspectieven (aansturing, uitvoer) kan je performance direct afleiden. Het is van de specifieke workload afhankelijk. En als je de exacte workload weet, kan je zowel van uit aansturing als uitvoer perspectief, de performance berekenen voor het geheel.

Net als Techspot (Nick Evanson) doe ik uitspraken over de uitvoer capaciteiten per CU , per SM. Dat betekent niet dat capaciteit = performance. Maar net zo goed betekent het niet dat aansturing = performance. Op z'n best kunnen we performance schatten. Maar exact berekenen kunnen we geen van beide.

...


Verdeling en aansturing doet er toe, maar uitvoer capaciteit (in dit geval opslag capaciteit) doen er ook toe. We benadrukken verschillende zaken van dezelfde architecturen, ik meer de totale uitvoer capaciteiten per CU / SM, jij meer de aansturing van een dual CU en een SM.

Zoals ik hierboven echter al heel cru aan geef, kun je de aansturing simpelweg niet negeren. Het doet er weldegelijk toe dat de helft van Nvidia's FP32 ALU's slechts een deel van de tijd beschikbaar zijn. Het doet er ook weldegelijk toe dat 2 CU's een L0 delen, dat 10 DCU's een L1 cache delen, dat SM's niets delen. Dat zijn allemaal dingen die invloed hebben op de performance. Als ALU aantallen het enige relevante was dan zou Cypress 4 keer zo snel als GF100 geweest moeten zijn, Fiji 30% sneller dan GM200 en zelfs sneller dan GP102 (op gelijke kloksnelheden). Of simpelweg GA102 tegenover TU102, waarom komen die cijfertjes niet uit?

En juist aan de hand van AMD's GPU's kun je heel eenvoudig zien dat de aansturing cruciaal is, want hun ALU's doen al veel langer mixed data types. Zelfs in RV770 (!) konden de ALU's binnen een SP al meerdere data types aan. Ik zal het echter een stukje recenter houden en enkel naar GCN5 en RDNA1 kijken. Vega 20 en Navi 10 in hun Radeon VII en 5700 XT vormen draaien op relatief vergelijkbare kloksnelheden. V20 heeft echter 3840 ALU's, waar N10 er slechts 2560 heeft. Als je puur naar de ALU's in CU's kijkt, hebben ze allebei 64 ALU's per CU; allebei ALU's die meerdere data typen doen. In retail vorm doet V20 van 10,8 tot 13,8 TF. N10 komt niet verder dan 9,7 TF. Echt álle cijfers van V20 zijn beter dan die van N10: aantal ALU's, aantal CU's, TMU's, geheugengrootte/-bandbreedte, allebei op N7 gebakken. En toch houdt die V20 eenvoudig bij, met minder stroomverbruik. V20 is marginaal sneller (1-2%) totdat geheugen bandbreedte een probleem wordt (want HBM2 vs 256b-GDDR6), dus op 2160p zie je pas ~10% verschil, wat volgens de cijfertjes het minimále verschil zou moeten zijn. Op game clocks zou het verschil 40+% moeten zijn.

Ik benadruk niet het één of het ander, ik stel simpelweg dat je het één niet zonder het ander kúnt beoordelen.

Richt je feedback tot Techspot, ik heb alleen naar de plaatjes gekeken:

[Afbeelding]
[Afbeelding]

Het kan best dat dat in de whitepapers niet helemaal precies dezelfde L1 cache is. We benadrukken wederom verschillende zaken.

Nee, je kijkt enkel naar de blokjes en niet naar de lijntjes. Die afbeeldingen laten niet alle details zien, maar wel genoeg

Als je beide afbeeldingen even 90 graden met de klok mee draait en dan van boven naar beneden kijkt:

RDNA 2 heeft één set registers per CU, waarbij er data kan "vloeien" tussen CU's (lichtblauwe blok) via de LDS. Die LDS is gedeeld binnen de hele DCU en de DCU in z'n geheel heeft ook 16 KB L0$ voor constants, en 32 KB L0$I. De DCU's als geheel hangen vervolgens aan de L1$ binnen die SE (waarvan er overigens 4 zijn, geen 8; die 8 slaat op het aantal L1$). Die hangen op hun beurt pas weer aan de L2$.

Voor GA102 heeft elke partitie (lichtblauwe blok) een eigen set registers én een eigen L0$I (16 KB). Elke partitie hangt vervolgens rechtstreeks aan de L1$ bínnen die SM. Elke SM hangt vervolgens rechtstreeks aan de L2$.

Zelfs aan de hand van deze diagrammen is al duidelijk dat de L1$ op een geheel andere plek zit. Waar zij jammer genoeg niet op in gaan is wat de LDS doet en hoe de caches werken. De vector L0$ in elke CU hangt rechtstreeks aan de L1$. De LDS zit daar niet tussen. Sterker nog, elke SIMD kan per clock (halve cycle) los van elkaar 128 bytes uit de L0$ én 128 bytes uit de LDS lezen. De doel van de LDS is synchroniseren binnen een DCU; het zorgt er voor dat ze de output van de ene op meteen als input voor een andere op kunnen gebruiken aan de "andere" kant en geen clocks/cycles kwijt zijn aan het verplaatsen van/naar L1$. Het is dus niet zo dat het "niet precies dezelfde cache" is, de LDS is geen cache. De LDS kan niet van/naar de L1$ lezen/schrijven, dat kan enkel vanuit L0$.

Excuus, eerste Google resultaten gingen allemaal over compute, Assembly en ARM, niet games FPS...
https://www.google.com/search?q=ld+and+st+instructions
maar doet dit detail er toe voor de vergelijking tussen Ampere en RDNA2? Zo ja, wat zijn dan de capaciteiten / aanstuur mogelijkheden van elk?

Ja dat doet er toe, maar dan moet je ook veel dieper gaan kijken naar hoeveel data er per cycle alle kanten op gestuurd kan worden. Om het niet té lang te maken (sorry ), zijn het de LD/ST units die daadwerkelijk lezen (LD) en schrijven (ST) in de caches, rotzooien met geheugen adressen, enzovoort. In werkelijkheid doet het er zeker toe, in de praktijk is het echter al heel lang zo dat het vooral de texture units zijn die bepalen hoe veel LD/ST er is, omdat die units het meest veeleisend zijn als het op graphics aan komt. En die aantallen liggen al een hele tijd gelijk tussen de twee - op CU en SM niveau welteverstaan

En daarom moet ik mezelf ook even corrigeren, want AMD heeft die niet per SIMD zoals ik eerder zei, die zitten per CU (wat ook veel logischer is ivm de texture units ).

Zolang je die 40 DCU met 80 SM vergelijkt vind ik het best, maar hoe die warp of wave32 afgehandeld wordt, is na aansturing vervolgens van belang. En daarvoor kijk ik naar uitvoer capaciteit.

Nogmaals, capaciteit doet er niet toe als je het niet kan benutten. Zie V20 vs N10 - of beter nog, Cypress vs. Fermi. Met 1600 ALU's tegenover de GTX 480's 480 zou Cypress volledig gehakt moeten maken van dat ding. Die 1600 waren echter verdeeld in 320 groepen van 5 stuks (VLIW5), waarbij gemiddeld slechts 3/5 van de ALU's in een groep gebruikt werd. Vervolgens zaten ze ook nog met 16 stuks gegroepeerd, waar ook geen 100% bezetting te realiseren was. Maar heel af en toe kwam het er wel uit met heel specifieke toepassingen die er voor gebouwd waren, zoals SmallLux, waar een 5870 meer dan 40% sneller dan een 480 was.

Dat zou niet logisch zijn, als wat je zegt, waar zou zijn. 64 -4 FP32 en 64 -1 INT32 is nog steeds 63 FP32 en 60 INT32 bij Ampere. Bij RDNA2 moeten die 5 operaties door een SIMD32 heen, waarbij 27 stream processors niets doen. De overgebleven FP32 capaciteit van de 2 SIMD32 is dan 59, terwijl de overgebleven capaciteit bij de SM 60 is.

Ik zei 4x16FP32 (64 totaal) en 1xINT32, niet 4xFP32 en 1xINT32

Jij beschouwt het mixed datapad als 16 units, ik beschouw het als wat het is: 16xFP32 + 16xINT32. Ook al kun je slechts één van de twee sets ALU's aansturen, ze zijn er wel. En wederom door de aansturing moeten ze alle 4 partities schakelen tussen FP32 en INT32. Een SM heeft feitelijk gezien al 192 ALU's.

Wel apart dat je het "ideale" geval van Nvidia vervolgens het minst ideaal maakt, door na elke cycle te moeten schakelen in je workload om dat "ideale" geval te bereiken.

Dat deed ik heel bewust omdat dat "ideale" geval enkel ideaal is volgens jouw aanpak van de aansturing en beperkingen volledig negeren. Als je puur naar de aantallen kijkt zou dat ideaal zijn voor Nvidia. Maar dat is het dus niet, omdat de aantallen slechts een deel van het verhaal vertellen.

Als je Ampere een ideale workload geeft, dan is dat alleen 128+0 of alleen 64+64 FP32. Als je die laatste 64+64 workload vergelijkt met RDNA2, is RDNA2 gewoon 2x zo langzaam.

Hoe kom je bij dat laatste? Ik ga er even van uit dat die 64 in 4 groepen van 16 verdeeld is (anders werkt het niet voor Nvidia), wat betekent dat AMD dat er gewoon in dezelfde tijd als Nvidia doorheen kan jagen. Als het in 2x32 verdeeld kan worden doet AMD het zelfs in één cycle.

In 1 keer door dual CU ja, niet een enkele CU. Ampere zal inderdaad proberen de INT warp naar een andere SM te gooien. In de uitvoer gaat Ampere dus 2 SM's inzetten tegen 1 dual CU. En daarom dat ik liever dat pespectief kies.

Daar komt dus echter het data verhaal bij kijken. Twee SM's kunnen niet aan hetzelfde werken zonder daarbij de L2$ in te schakelen. Weg zijn je cycles

Goed om te horen dat het kàn en ik vermoed dat de Nvidia ingenieurs in de richting denken wat je hier beschrijft.

Ik deel dat vermoeden geheel niet. Het is onwaarschijnlijk dat Lovelace zo'n gigantisch verschil met Hopper (en dus Ampère + Volta) zou hebben. En Hopper is vooral meer van hetzelfde. Er zit wel wat clustering in (beetje zoals AMD's "clauses"), maar dat is vooral een CUDA (software) concept. Er zit wel wát hardware ondersteuning in (ze houden een cluster binnen een GPC wanneer mogelijk, SM's kunnen elkaars L1$ benaderen), maar dat gaat gepaard met latency. Voor HPC niet zo'n heel groot probleem, maar voor graphics wel.

Tot nu toe hebben de afgelopen Nvidia generaties telkens een wijziging in de SM structuur laten zien.

Uh, zet Maxwell en Ampère eens naast elkaar? Wijzigingen:

- Geometry (polymorph engine) is een niveau "omhoog" gegaan en zit nu buiten de SM(M) (zo veel geometry met huidige SM aantallen is er niet nodig)
- Een tensor core per partitie
- Minder texture units (en dus minder LD/ST) per SM
- Elke scheduler heeft nu slechts 1 dispatch unit (dus geen instruction-level parallelism meer; wat voor graphics maar zelden voorkwam)
- FP en INT zijn gescheiden datapaden
- L0$I is van SM naar partitie gegaan (Pascal en eerder hadden L0$I op SM niveau, met een buffer per partitie)
- L1$ vervult nu ook de functie van shared memory (komt vooral neer op 1 SRAM blok dat gepartitioneerd kan worden; voor graphics weinig relevant omdat de verdeling hetzelfde is als voorheen, maar voor compute kan er nu veel meer mee)

Dat is het zo'n beetje, zo ingrijpend is het niet. Nvidia zit met Ampère in feite op GCN4 (Polaris) qua evolutie vanaf Maxwell. Ze zijn absoluut niet hetzelfde, maar net als bij Polaris en Tahiti kun je Ampère en Maxwell naast elkaar leggen en lijken ze heel erg op elkaar. Je moet helemaal terug naar Kepler om een fundamenteel andere SM te zien.

Ik denk meer ruimte bij Nvidia, omdat de node jump hoger is, en omdat ze per ALU minder transistors nodig hadden.

Dat laatste moet je echt uit je hoofd zetten; hoewel het waarschijnlijk is, is dat niet eens zeker. Voordat ik dat uit leg, zal het aantal transistors hoogstwaarschijnlijk ook niet de helft van AMD's aantal zijn. Al was dat wel zo, hebben ze momenteel ook drie keer zo veel ALU's nodig om te doen wat ze doen; en vergeet niet dat elke ALU aan de registers moet hangen en dat daar dus óók ruimte verloren gaat.

Hoe groot die ALU's zijn kunnen wij nooit en te nimmer iets over zeggen. Er zijn vele algoritmes voor de verschillende wiskundige operaties die zo'n ALU uit moet kunnen voeren. Elk van die algoritmes heeft een geheel andere set logica nodig. Je zou sowieso de hele ISA's van beide architecturen moeten vergelijken om te zien of ze überhaupt allebei dezelfde ops ondersteunen en op welke manier ze dat doen (GCN had bijvoorbeeld geen FMA; simpel gezegd doen ze a + (b * c) nu sneller dan in GCN). Misschien zijn de ALU's van één van beide wel niet meer dan simpele adders van beginners niveau. Dat is uiteraard niet zo, maar hopelijk begrijp je waarom ik het aantal transistors per ALU niet echt wil benoemen. Het enige dat ik wel durf te stellen is dat AMD's ALU's complexer zijn

Ik zei 4nm

Weet ik, maar dat is het dus niet in de zin dat TSMC ook daadwerkelijk een "4nm-class" in ontwikkeling heeft

Het gaat bij Nvidia om 4N, een aangepast N5 procedé, niet het N4 dat nog in ontwikkeling is. Dat laatste is pas eind vorig jaar in risk production gegaan en zal dus pas op z'n vroegst eind dit jaar daadwerkelijk in gebruik genomen worden. Veel te laat voor Hopper en Lovelace.

Het is muggenzifterij, maar het doet er wel toe. Er wordt door zekere sites gedaan alsof Hopper/Lovelace N5 overslaat, maar dat is onzin. 4N is gewoon N5, net zoals 12FFN gewoon 12FF was. N4 is iets anders, vergelijkbaar met 12FF tegenover 16FF maar is voorlopig dus nog niet klaar. Het 4N waar Nvidia straks op zit is gewoon hetzelfde als het N5 waar AMD op komt te zitten, enkel met wat tweaks voor Nvidia - die niet bijster indrukwekkend zullen zijn. AMD haalde op Samsung's "inferieure" 14LPP een hogere dichtheid dan Nvidia op hun speciale 12FFN

---

@DaniëlWW2 ik heb de GCN whitepaper er even bij gepakt:

The GCN command processor is responsible for receiving high-level level API commands from the driver and mapping them onto the different processing pipelines. There are two main pipelines in GCN. The Asynchronous Compute Engines (ACE) are responsible for managing compute shaders, while a graphics command processor handles graphics shaders and fixed function hardware. Each ACE can handle a parallel stream of commands, and the graphics command processor can have a separate command stream for each shader type, creating an abundance of work to take advantage of GCN's multi-tasking

Is blijkbaar dus altijd al zo geweest!

Dan ga ik nu maar eens kijken wat er over Intel te zien was

[sunsmountain]

Werelds schreef op zaterdag 16 juli 2022 @ 15:21:
[...]

Best, ik wil het ook vanuit die kant benaderen en alle aansturing en datapaden daarbij volledig negeren. Dan wordt het plaatje echter nog minder rooskleurig voor hetgeen Nvidia in theorie zou hebben en wat ze in de praktijk hebben.

Een GA102-225 (3080 Ti) heeft dan 10240 FP32 ALU's en 5120 INT32 ALU's voor een totaal van 15360 ALU's. Je moet de mixed datapaden dan ook niet mee in beschouwing nemen, want dat is al een stuk aansturing. AMD heeft er slechts 5120, die dan wel zowel FP32 als INT32 (alsmede enig ander data type) kunnen verwerken. Als je alles negeert en puur naar de ALU's kijkt, zou Nvidia zonder moeite minstens twee keer zo rap moeten zijn, met hun kleinere super-simpele ALU's.

Dat is weer het andere uiterste. Als je schrijft, qua capaciteit:
64 FP32 of 64 INT32 , dus uitwisselbaar, of
128 FP32 of (64 FP32 + 64 INT32), dan hou je toch wel degelijk rekening met de aansturing? Nergens heb ik gezegd 192 FP32 of 192 INT32 voor Ampere.

Werelds schreef op zaterdag 16 juli 2022 @ 15:21:
Zoals ik hierboven echter al heel cru aan geef, kun je de aansturing simpelweg niet negeren. Het doet er weldegelijk toe dat de helft van Nvidia's FP32 ALU's slechts een deel van de tijd beschikbaar zijn. Het doet er ook weldegelijk toe dat 2 CU's een L0 delen, dat 10 DCU's een L1 cache delen, dat SM's niets delen. Dat zijn allemaal dingen die invloed hebben op de performance. Als ALU aantallen het enige relevante was dan zou Cypress 4 keer zo snel als GF100 geweest moeten zijn, Fiji 30% sneller dan GM200 en zelfs sneller dan GP102 (op gelijke kloksnelheden). Of simpelweg GA102 tegenover TU102, waarom komen die cijfertjes niet uit?

En juist aan de hand van AMD's GPU's kun je heel eenvoudig zien dat de aansturing cruciaal is, want hun ALU's doen al veel langer mixed data types. Zelfs in RV770 (!) konden de ALU's binnen een SP al meerdere data types aan. Ik zal het echter een stukje recenter houden en enkel naar GCN5 en RDNA1 kijken. Vega 20 en Navi 10 in hun Radeon VII en 5700 XT vormen draaien op relatief vergelijkbare kloksnelheden. V20 heeft echter 3840 ALU's, waar N10 er slechts 2560 heeft. Als je puur naar de ALU's in CU's kijkt, hebben ze allebei 64 ALU's per CU; allebei ALU's die meerdere data typen doen. In retail vorm doet V20 van 10,8 tot 13,8 TF. N10 komt niet verder dan 9,7 TF. Echt álle cijfers van V20 zijn beter dan die van N10: aantal ALU's, aantal CU's, TMU's, geheugengrootte/-bandbreedte, allebei op N7 gebakken. En toch houdt die V20 eenvoudig bij, met minder stroomverbruik. V20 is marginaal sneller (1-2%) totdat geheugen bandbreedte een probleem wordt (want HBM2 vs 256b-GDDR6), dus op 2160p zie je pas ~10% verschil, wat volgens de cijfertjes het minimále verschil zou moeten zijn. Op game clocks zou het verschil 40+% moeten zijn.

Ik benadruk niet het één of het ander, ik stel simpelweg dat je het één niet zonder het ander kúnt beoordelen.

Daar ben ik het mee eens. GCN er bij halen, met de beperking van 1 instructie per 4 clock cycles, is natuurlijk gekkenwerk qua aansturing, en verdraait het droge uitvoerbeeld, waar ik niet achter sta, totaal.

Maar inclusief aansturing en uitvoer, blijf ik het oneerlijk vinden qua capaciteiten vergelijken, om een dual CU met 1 SM te vergelijken. Ik doe dat niet, Techspot doet dat niet, en jij eigenlijk ook niet: op chip niveau vergelijk je 40 dual CU met 80 SM. Dat was mijn voornaamste drijfveer om capaciteit te benadrukken. Ik kijk liever met je naar de workloads.

Werelds schreef op zaterdag 16 juli 2022 @ 15:21:

Nee, je kijkt enkel naar de blokjes en niet naar de lijntjes. Die afbeeldingen laten niet alle details zien, maar wel genoeg

Als je beide afbeeldingen even 90 graden met de klok mee draait en dan van boven naar beneden kijkt:

RDNA 2 heeft één set registers per CU, waarbij er data kan "vloeien" tussen CU's (lichtblauwe blok) via de LDS. Die LDS is gedeeld binnen de hele DCU en de DCU in z'n geheel heeft ook 16 KB L0$ voor constants, en 32 KB L0$I. De DCU's als geheel hangen vervolgens aan de L1$ binnen die SE (waarvan er overigens 4 zijn, geen 8; die 8 slaat op het aantal L1$). Die hangen op hun beurt pas weer aan de L2$.

Voor GA102 heeft elke partitie (lichtblauwe blok) een eigen set registers én een eigen L0$I (16 KB). Elke partitie hangt vervolgens rechtstreeks aan de L1$ bínnen die SM. Elke SM hangt vervolgens rechtstreeks aan de L2$.

Zelfs aan de hand van deze diagrammen is al duidelijk dat de L1$ op een geheel andere plek zit. Waar zij jammer genoeg niet op in gaan is wat de LDS doet en hoe de caches werken. De vector L0$ in elke CU hangt rechtstreeks aan de L1$. De LDS zit daar niet tussen. Sterker nog, elke SIMD kan per clock (halve cycle) los van elkaar 128 bytes uit de L0$ én 128 bytes uit de LDS lezen. De doel van de LDS is synchroniseren binnen een DCU; het zorgt er voor dat ze de output van de ene op meteen als input voor een andere op kunnen gebruiken aan de "andere" kant en geen clocks/cycles kwijt zijn aan het verplaatsen van/naar L1$. Het is dus niet zo dat het "niet precies dezelfde cache" is, de LDS is geen cache. De LDS kan niet van/naar de L1$ lezen/schrijven, dat kan enkel vanuit L0$.

Het leek me dat de caches vergelijkbaar waren, maar Ampere heeft verhoudingsgewijs veel meer L0 L1 cache nodig:
GA102, 26880 L0 kB, 10752 L1 kB , bij elkaar 36,75 MB.
Navi21, 14880 L0, 8064 L1 kB, bij elkaar maar 22,4 MB.

Hoewel ik niet zo ver zou gaan om GA102 een GCN4 te noemen, knap gedaan van AMD.

Werelds schreef op zaterdag 16 juli 2022 @ 15:21:
Ja dat doet er toe, maar dan moet je ook veel dieper gaan kijken naar hoeveel data er per cycle alle kanten op gestuurd kan worden. Om het niet té lang te maken (sorry ), zijn het de LD/ST units die daadwerkelijk lezen (LD) en schrijven (ST) in de caches, rotzooien met geheugen adressen, enzovoort. In werkelijkheid doet het er zeker toe, in de praktijk is het echter al heel lang zo dat het vooral de texture units zijn die bepalen hoe veel LD/ST er is, omdat die units het meest veeleisend zijn als het op graphics aan komt. En die aantallen liggen al een hele tijd gelijk tussen de twee - op CU en SM niveau welteverstaan

En daarom moet ik mezelf ook even corrigeren, want AMD heeft die niet per SIMD zoals ik eerder zei, die zitten per CU (wat ook veel logischer is ivm de texture units ).

Ok, dus het doet er wel, maar is gelijkspel. Laten we dan kijken naar de andere elementen dan LD/ST.

Werelds schreef op zaterdag 16 juli 2022 @ 15:21:
Nogmaals, capaciteit doet er niet toe als je het niet kan benutten. Zie V20 vs N10 - of beter nog, Cypress vs. Fermi. Met 1600 ALU's tegenover de GTX 480's 480 zou Cypress volledig gehakt moeten maken van dat ding. Die 1600 waren echter verdeeld in 320 groepen van 5 stuks (VLIW5), waarbij gemiddeld slechts 3/5 van de ALU's in een groep gebruikt werd. Vervolgens zaten ze ook nog met 16 stuks gegroepeerd, waar ook geen 100% bezetting te realiseren was. Maar heel af en toe kwam het er wel uit met heel specifieke toepassingen die er voor gebouwd waren, zoals SmallLux, waar een 5870 meer dan 40% sneller dan een 480 was.

Capaciteit wordt niet altijd ten volle benut. Zodra je dat % weet, kan je alsnog weer capaciteiten vergelijken.

Werelds schreef op zaterdag 16 juli 2022 @ 15:21:
Ik zei 4x16FP32 (64 totaal) en 1xINT32, niet 4xFP32 en 1xINT32

Jij beschouwt het mixed datapad als 16 units, ik beschouw het als wat het is: 16xFP32 + 16xINT32. Ook al kun je slechts één van de twee sets ALU's aansturen, ze zijn er wel. En wederom door de aansturing moeten ze alle 4 partities schakelen tussen FP32 en INT32. Een SM heeft feitelijk gezien al 192 ALU's.

Werelds schreef op woensdag 13 juli 2022 @ 21:53:
Nee hoor, niet meer of minder dan bij Nvidia, omdat AMD per cycle kan schakelen. Het kan bij Nvidia best zo zijn dat ze 4x16 FP32 en 1xINT32 aan het doen zijn en op die manier dus 63 INT32 units én 64 FP32 units uit hun neus zitten te vreten. AMD zou dan 63 units stil hebben liggen. Bezetting is voor beide ruk in zo'n geval.

Laat ik er nog een keer op reageren dan: in de vergelijking van 1 SM met 1 CU (niet dual CU, wat je nu doet), heeft RDNA2 de 2e CU nodig, zodat er 63 units stil liggen. Bij Ampere heb je het nog steeds over 1 SM, waarvan er inderdaad meer ALU's onbezet blijven. Veel meer capaciteit dus als het wel gevuld zou worden. Dus eigenlijk heeft RDNA2 CU vrij snel genoeg en is 4x16FP32+1xINT32 al teveel voor 2 SIMD.

ed: bij Ampere blijven bij deze workload 63 INT32 onbenut, niet de 64 FP32 omdat het òf òf is.

Laten we kijken naar realistischere gevallen.

Werelds schreef op woensdag 13 juli 2022 @ 21:53:

Dat deed ik heel bewust omdat dat "ideale" geval enkel ideaal is volgens jouw aanpak van de aansturing en beperkingen volledig negeren. Als je puur naar de aantallen kijkt zou dat ideaal zijn voor Nvidia. Maar dat is het dus niet, omdat de aantallen slechts een deel van het verhaal vertellen.

Fair enough. Maar ik denk niet dat realistisch is dat de driver van Ampere elke cycle gaat schakelen. Dat wil Nvidia natuurlijk zo laag mogelijk houden.

Werelds schreef op woensdag 13 juli 2022 @ 21:53:
Hoe kom je bij dat laatste? Ik ga er even van uit dat die 64 in 4 groepen van 16 verdeeld is (anders werkt het niet voor Nvidia), wat betekent dat AMD dat er gewoon in dezelfde tijd als Nvidia doorheen kan jagen. Als het in 2x32 verdeeld kan worden doet AMD het zelfs in één cycle.

Ja wederom als je een dual CU met 1 SM vergelijkt. Maar vergelijk nou eens 40 dual CU met 80 SM? Dan doet Ampere toch 2x zoveel?

Nog een keer:
64FP32 + 64 INT32, verdeeld als 4x16FP32 + 4x16INT32.
1 SM = voert dit uit in 1 cycle
1 CU = voert dit uit in 2 cycles

Of begrijp ik deze zin van Techspot niet?

Nvidia's SMs can process instructions to handle integer and float values at the same time (e.g. 64 FP32 and 64 INT32), and has independent units for FP16 operations, tensor math, and ray tracing routines. AMD's CUs do the majority of the workload on the SIMD32 units, although they do have separate scalar units that support simple integer math.

Kunnen die scalars ook INT32, nee toch?

Werelds schreef op woensdag 13 juli 2022 @ 21:53:
Daar komt dus echter het data verhaal bij kijken. Twee SM's kunnen niet aan hetzelfde werken zonder daarbij de L2$ in te schakelen. Weg zijn je cycles

Klopt, maar wederom, hoe vaakt komt het voor? En de Ampere driver zal dit proberen te minimaliseren.

Werelds schreef op woensdag 13 juli 2022 @ 21:53:
Ik deel dat vermoeden geheel niet. Het is onwaarschijnlijk dat Lovelace zo'n gigantisch verschil met Hopper (en dus Ampère + Volta) zou hebben. En Hopper is vooral meer van hetzelfde. Er zit wel wat clustering in (beetje zoals AMD's "clauses"), maar dat is vooral een CUDA (software) concept. Er zit wel wát hardware ondersteuning in (ze houden een cluster binnen een GPC wanneer mogelijk, SM's kunnen elkaars L1$ benaderen), maar dat gaat gepaard met latency. Voor HPC niet zo'n heel groot probleem, maar voor graphics wel.

Ik denk inderdaad niet dat Nvidia de L0 L1 cache oplossing van AMD gaat evenaren, maar ze gaan hun L2 wel een stuk groter maken ter compensatie. Uiteindelijk draait het om performance, en je mag Ampere en Lovelace verouderd vinden, als ze goed presteren klaagt er niemand.

Werelds schreef op woensdag 13 juli 2022 @ 21:53:

Uh, zet Maxwell en Ampère eens naast elkaar? Wijzigingen:

- Geometry (polymorph engine) is een niveau "omhoog" gegaan en zit nu buiten de SM(M) (zo veel geometry met huidige SM aantallen is er niet nodig)
- Een tensor core per partitie
- Minder texture units (en dus minder LD/ST) per SM
- Elke scheduler heeft nu slechts 1 dispatch unit (dus geen instruction-level parallelism meer; wat voor graphics maar zelden voorkwam)
- FP en INT zijn gescheiden datapaden
- L0$I is van SM naar partitie gegaan (Pascal en eerder hadden L0$I op SM niveau, met een buffer per partitie)
- L1$ vervult nu ook de functie van shared memory (komt vooral neer op 1 SRAM blok dat gepartitioneerd kan worden; voor graphics weinig relevant omdat de verdeling hetzelfde is als voorheen, maar voor compute kan er nu veel meer mee)

Dat is het zo'n beetje, zo ingrijpend is het niet. Nvidia zit met Ampère in feite op GCN4 (Polaris) qua evolutie vanaf Maxwell. Ze zijn absoluut niet hetzelfde, maar net als bij Polaris en Tahiti kun je Ampère en Maxwell naast elkaar leggen en lijken ze heel erg op elkaar. Je moet helemaal terug naar Kepler om een fundamenteel andere SM te zien.

De SM's bij alle 3 deze architecturen zijn verschillend, dat is wat ik zei. Ik heb niet gezegd dat de SM's gronding zijn herbouwd en ik zie dat ze op elkaar lijken. Maar het punt is dat de gewijzigde SM telkens de performance heeft beïnvloed, qua IPC.

Werelds schreef op woensdag 13 juli 2022 @ 21:53:

Dat laatste moet je echt uit je hoofd zetten; hoewel het waarschijnlijk is, is dat niet eens zeker. Voordat ik dat uit leg, zal het aantal transistors hoogstwaarschijnlijk ook niet de helft van AMD's aantal zijn. Al was dat wel zo, hebben ze momenteel ook drie keer zo veel ALU's nodig om te doen wat ze doen; en vergeet niet dat elke ALU aan de registers moet hangen en dat daar dus óók ruimte verloren gaat.

Hoe groot die ALU's zijn kunnen wij nooit en te nimmer iets over zeggen. Er zijn vele algoritmes voor de verschillende wiskundige operaties die zo'n ALU uit moet kunnen voeren. Elk van die algoritmes heeft een geheel andere set logica nodig. Je zou sowieso de hele ISA's van beide architecturen moeten vergelijken om te zien of ze überhaupt allebei dezelfde ops ondersteunen en op welke manier ze dat doen (GCN had bijvoorbeeld geen FMA; simpel gezegd doen ze a + (b * c) nu sneller dan in GCN). Misschien zijn de ALU's van één van beide wel niet meer dan simpele adders van beginners niveau. Dat is uiteraard niet zo, maar hopelijk begrijp je waarom ik het aantal transistors per ALU niet echt wil benoemen. Het enige dat ik wel durf te stellen is dat AMD's ALU's complexer zijn

Ok, en een groter deel van de "transistors per SM" bij Nvidia zullen SRAM (L0 L1 cache zijn), die uitspraak durven we misschien ook nog wel aan. En dat ze meer ALU's in een SM proppen dan AMD in een CU. We kunnen het niet precies weten, maar we kunnen er wel uitspraken over doen, om te kijken waar de mogelijkheden zitten.

Werelds schreef op woensdag 13 juli 2022 @ 21:53:
Weet ik, maar dat is het dus niet in de zin dat TSMC ook daadwerkelijk een "4nm-class" in ontwikkeling heeft

Het gaat bij Nvidia om 4N, een aangepast N5 procedé, niet het N4 dat nog in ontwikkeling is. Dat laatste is pas eind vorig jaar in risk production gegaan en zal dus pas op z'n vroegst eind dit jaar daadwerkelijk in gebruik genomen worden. Veel te laat voor Hopper en Lovelace.

Het is muggenzifterij, maar het doet er wel toe. Er wordt door zekere sites gedaan alsof Hopper/Lovelace N5 overslaat, maar dat is onzin. 4N is gewoon N5, net zoals 12FFN gewoon 12FF was. N4 is iets anders, vergelijkbaar met 12FF tegenover 16FF maar is voorlopig dus nog niet klaar. Het 4N waar Nvidia straks op zit is gewoon hetzelfde als het N5 waar AMD op komt te zitten, enkel met wat tweaks voor Nvidia - die niet bijster indrukwekkend zullen zijn. AMD haalde op Samsung's "inferieure" 14LPP een hogere dichtheid dan Nvidia op hun speciale 12FFN

Ik ken het verschil en laat me niet foppen door Nvidia marketing speak. Concluderend:

1. Je kan capaciteit niet beoordelen zonder te kijken naar aansturing en uitvoer
2. Performance blijft van workload afhankelijk
3. De SM's van Ampere lijken krachtiger dan die van RDNA2, maar draaien langzamer, hebben minder occupancy en meer latency met bijna 2x zoveel L0 L1 cache

[DaniëlWW2]

En dit bedoelde ik dus met het MCM verhaal en L3 cache.
We hebben een inschatting van de centrale GCD op 350mm2+. Iets kleiner dan ik had verwacht, maar nog steeds goed mogelijk.
[Twitter: https://twitter.com/greymon55/status/1549190072204795911?]
Bij 3DCenter schatte ze Navi 21 minus de L3 cache en geheugencontrollers rond de 375mm2 zou zitten.

Navi 21 without IC und IF$ is ~375mm² (~28% of the 519mm² die is used for memory controller and Infinity Cache).

Thus, the GCD of Navi 31 is still quite small on ~350mm², but still somewhat better understandable.

— 3DCenter.org (@3DCenter_org) 20 juli 2022

De reden waarom het iets kleiner uit zou vallen is omdat AMD een aantal legacy features verwijderd alsmede zaken die niet nodig zijn. Dat haalt Kepler uit de linux patches, waardoor dit relatief geloofwaardig is.

Some people are surprised by Navi31 GCD size but note that a lot of old architectural bloat has been removed.

XGMI is gone, GDS is gone, Legacy Geometry pipeline is gone, Legacy Scan converter is gone...

— Kepler (@Kepler_L2) 19 juli 2022

We hebben het nog steeds over 2,5x de rekeneenheden, dus architecturale optimalisatie zal samen met de flinke logic shrink van N5 moeten komen om dit te halen. Maar het is mogelijk.

Wat je dus kan krijgen is een opvallend kleine centrale GPU chiplet en een aantal cache + geheugencontroller chiplets. Het totaalpakket zou alsnog richting de 600mm2 gaan, maar uitgesplitst over zeven chiplets is dit een behoorlijk economische manier om het te doen.

En dan lijkt het er zo ongeveer uit te gaan zien. Ik vermoed dat de MCD's inderdaad niet 3D stacked worden. Misschien 3D stacked AMD nog meer cache voor bepaalde SKU's op de MCD's, because why not?

https://videocardz.com/ne...-350-mm%25c2%25b2-in-size

Ja, ik wil dit geloven dus laat me.

---

Dan nog een implicatie van mij. Ik zeg nu al maanden dat ik vermoed dat Navi 32, veel interessanter gaat zijn dan Navi 31. En als Navi 32 dan 2/3 formaat van Navi 31 is en met vier MCD's komt zoals breder word vermoed, tja dan ga je onder de 300mm2 uitkomen voor de GCD. Misschien kijk je dan zelfs naar potentieel betaalbaar en alsnog fors sneller dan Navi 21.

Ik besef me ook heel goed dat dit een "eens en nooit meer" generatie kan worden. Want AMD lijkt forse innovatie in hun RDNA architectuur te combineren met goede node shrink en ook nog eens naar een chiplet based architectuur te gaan om de kosten te drukken terwijl ze alsnog het aantal fysieke rekeneenheden, fors kunnen verhogen. Dat is een combinatie van factoren die we volgens mij nog nooit hebben gezien in GPU land. Ik heb al eerder de vergelijking met G80 gemaakt en die is denk ook treffend als het werkelijk allemaal gebeurd. Want sinds G80 is er eigenlijk niks meer geweest dat zo radicaal beter lijkt te worden dan de vorige generatie.

[sunsmountain]

DaniëlWW2 schreef op donderdag 21 juli 2022 @ 12:09:
En dit bedoelde ik dus met het MCM verhaal en L3 cache.
We hebben een inschatting van de centrale GCD op 350mm2+. Iets kleiner dan ik had verwacht, maar nog steeds goed mogelijk.
[Twitter]
Bij 3DCenter schatte ze Navi 21 minus de L3 cache en geheugencontrollers rond de 375mm2 zou zitten.
[Twitter]

De reden waarom het iets kleiner uit zou vallen is omdat AMD een aantal legacy features verwijderd alsmede zaken die niet nodig zijn. Dat haalt Kepler uit de linux patches, waardoor dit relatief geloofwaardig is.
[Embed]
We hebben het nog steeds over 2,5x de rekeneenheden, dus architecturale optimalisatie zal samen met de flinke logic shrink van N5 moeten komen om dit te halen. Maar het is mogelijk.

Wat je dus kan krijgen is een opvallend kleine centrale GPU chiplet en een aantal cache + geheugencontroller chiplets. Het totaalpakket zou alsnog richting de 600mm2 gaan, maar uitgesplitst over zeven chiplets is dit een behoorlijk economische manier om het te doen.

En dan lijkt het er zo ongeveer uit te gaan zien. Ik vermoed dat de MCD's inderdaad niet 3D stacked worden. Misschien 3D stacked AMD nog meer cache voor bepaalde SKU's op de MCD's, because why not?
[Afbeelding]
https://videocardz.com/ne...-350-mm%25c2%25b2-in-size

Ja, ik wil dit geloven dus laat me.

---

Dan nog een implicatie van mij. Ik zeg nu al maanden dat ik vermoed dat Navi 32, veel interessanter gaat zijn dan Navi 31. En als Navi 32 dan 2/3 formaat van Navi 31 is en met vier MCD's komt zoals breder word vermoed, tja dan ga je onder de 300mm2 uitkomen voor de GCD. Misschien kijk je dan zelfs naar potentieel betaalbaar en alsnog fors sneller dan Navi 21.

Ik besef me ook heel goed dat dit een "eens en nooit meer" generatie kan worden. Want AMD lijkt forse innovatie in hun RDNA architectuur te combineren met goede node shrink en ook nog eens naar een chiplet based architectuur te gaan om de kosten te drukken terwijl ze alsnog het aantal fysieke rekeneenheden, fors kunnen verhogen. Dat is een combinatie van factoren die we volgens mij nog nooit hebben gezien in GPU land. Ik heb al eerder de vergelijking met G80 gemaakt en die is denk ook treffend als het werkelijk allemaal gebeurd. Want sinds G80 is er eigenlijk niks meer geweest dat zo radicaal beter lijkt te worden dan de vorige generatie.

Dit was wel de waarschijnlijkere van de 2 MCM ontwerpen, de andere was meerdere GCD's a la Epyc Milan met Navi23x2 ipv Zen3 CCD's.

Maar ja, meer dan 1 GCD blijft een probleem, hoeveel patenten je er ook tegen aan gooit...

[Ludewig]

DaniëlWW2 schreef op donderdag 21 juli 2022 @ 12:09:
Ik besef me ook heel goed dat dit een "eens en nooit meer" generatie kan worden. Want AMD lijkt forse innovatie in hun RDNA architectuur te combineren met goede node shrink en ook nog eens naar een chiplet based architectuur te gaan om de kosten te drukken terwijl ze alsnog het aantal fysieke rekeneenheden, fors kunnen verhogen. Dat is een combinatie van factoren die we volgens mij nog nooit hebben gezien in GPU land.

Je vergeet de kloksnelheid verhoging nog die TSMC 5 mogelijk maakt. Ik denk ook dat dit een erg goede serie wordt. Vergelijkbaar met hoe de 1000 serie van Nvidia ook een extreem sterke serie was.

[DaniëlWW2]

Ludewig schreef op donderdag 21 juli 2022 @ 19:33:
[...]


Je vergeet de kloksnelheid verhoging nog die TSMC 5 mogelijk maakt. Ik denk ook dat dit een erg goede serie wordt. Vergelijkbaar met hoe de 1000 serie van Nvidia ook een extreem sterke serie was.

Volgens mij heb ik het al vaker gezegd, maar nog een keer dan.
Nee, TSMC maakt geen clock speed verhoging mogelijk puur omdat het N5 is. Je hele architectuur moet eerst kunnen functioneren op een hogere clock speed zonder dat de boel crasht, de chip te heet word of je te veel energie verbruikt. Daar zit heel veel werk in.

Het is denk ik ook geen toeval dat opeens er interviews opdoken vanuit AMD over efficiëntie en clock speed verbeteringen. We zagen al dat Zen 4 fors over de 5GHz gaat en we weten dat de CPU en GPU divisies samenwerking over efficiëntie en clock speed verbeteringen. De eerste resultaten zagen we met Zen 3 en RDNA2 en nu gaan ze waarschijnlijk die volgende stap ook zetten.

[Ludewig]

DaniëlWW2 schreef op donderdag 21 juli 2022 @ 19:43:
[...]
Nee, TSMC maakt geen clock speed verhoging mogelijk puur omdat het N5 is.

Het is niet zo netjes om het woord 'puur' toe te voegen, wat ik niet gezegd heb en dat dan te bekritiseren. Dat heet een stoman-argument.

Feit is dat AMD heeft gezegd dat zowel Zen 4 en RDNA3 een (flink) hogere kloksnelheid halen. Aangezien beide naar N5 gaan, lijkt dat wel cruciaal om die hogere kloksnelheid te halen.

Of Nvidia ook een veel hogere klok kan halen op N5 is een andere discussie, die eigenlijk in het andere topic hoort.

[XWB]

Iemand heeft wat renders gemaakt van Navi 3x:

Here's some Renders of the RDNA 3 / Navi3X lineup

Navi33 = Monolithic
Navi32 = 1x GCD + 4x MCD
Navi31 = 1x GCD + 6x MCD pic.twitter.com/lyPoqtzo3t

— Wild_C (@_wildc) 21 juli 2022

Also, here are versions with Black / Fog Backgrounds because Twitter shows transparency as White for some reason pic.twitter.com/ZsMdh0mwlM

— Wild_C (@_wildc) 21 juli 2022

En de gebruikte die sizes voor de renders:

I should probably list the die sizes used as well:

Navi33 = 20.5 * 19.5 = 400mm²
Navi31/32 MCD = 4.68 * 9.36 = 44mm²
Navi32 GCD = 13.1 * 20.1 = 263mm²
Navi31 GCD = 13.1 * 28.2 = 369mm²
Navi32 Total = 439mm²
Navi31 Total = 633mm²

Don't expect these to be exact though

— Wild_C (@_wildc) 21 juli 2022

Met een slag om de arm:

(As in, these are only very rough approximations of what I personally expect the die sizes to end up being based on leaks and informed speculation)

— Wild_C (@_wildc) 21 juli 2022

[sunsmountain]

XWB schreef op vrijdag 22 juli 2022 @ 10:55:
Iemand heeft wat renders gemaakt van Navi 3x:

[Twitter]

[Twitter]

[Afbeelding]

En de gebruikte die sizes voor de renders:

[Twitter]

Met een slag om de arm:

[Twitter]

Mooie plaatjes, maar wel helemaal gebaseerd op de MCD lek van Kepler in de drivers. En die MCD lek sluit losse GCD chiplets nog steeds niet uit, of zelfs losse chiplets: zoals een Epyc server bestaat uit Zen3 chiplets.

In dat geval krijgen Navi31 en Nav32 een eigen I/O die met de PHY connectors, PCIexpress en VCN, etc. en kunnen ze dezelfde chiplets hergebruiken.

Optie 1: I/O die (150 mm2) + 4/6 ("Navi23") chiplets (~100 mm2)
voordelen:

• chiplets zijn goedkoper om te produceren
• afsplitsen van niet schaalbare elementen (maar infinity cache blijft op de chiplet)

nadelen:

• command frontend gedupliceerd per chiplet
• het moeder/dochter coördinatie probleem (latency)

Optie 2: GCD (350+ mm2) + 4/6 MCD's (40 mm2)
voordelen:

• geen gedupliceerde command frontend
• geen coördinatie probleem, monolitische aansturing

nadelen:

• GCD's zijn iets duurder om te produceren dan losse chiplets
• niet schaalbare elementen zitten dan nog steeds in de GCD

Misschien is er nog een derde optie

Optie 3: I/O die (150 mm2) + GCD (350+ mm2) + 4/6 MCD's (40 mm2)
dan valt het tweede nadeel weg van Optie 2.

Wat denken jullie?
https://www.strawpoll.me/46108132

[SG]

DaniëlWW2 schreef op donderdag 21 juli 2022 @ 19:43:
[...]


Volgens mij heb ik het al vaker gezegd, maar nog een keer dan.
Nee, TSMC maakt geen clock speed verhoging mogelijk puur omdat het N5 is. Je hele architectuur moet eerst kunnen functioneren op een hogere clock speed zonder dat de boel crasht, de chip te heet word of je te veel energie verbruikt. Daar zit heel veel werk in.

Het is denk ik ook geen toeval dat opeens er interviews opdoken vanuit AMD over efficiëntie en clock speed verbeteringen. We zagen al dat Zen 4 fors over de 5GHz gaat en we weten dat de CPU en GPU divisies samenwerking over efficiëntie en clock speed verbeteringen. De eerste resultaten zagen we met Zen 3 en RDNA2 en nu gaan ze waarschijnlijk die volgende stap ook zetten.

Ik vind dit toch rare gedachten gang.
Dieshrink van n7 naar n5 breng hogere kloks en lagere tdp bij gelijke performance. Dat is wat foundry aan klant bied. Zo niet dan hebben ze die procede verkloot. Zoals intel met hun 10nm.
En dat staat los van hoe of wat intel/AMD/nV met architectuur of tooling de zooi verkloten. Dat is de next step dat klant het verkloten kan.
Of dat samsung intel tsmc hun dieshrink verkloten. Dan heeft klant een handicap. Zoals AMD met global foundry.

Gemiddeld gezien is dat wat dieshrink brengen in de begin tijd van cpu naar 1000nm naar 2nm waarbij foundry en chip ontwerper uiteraard wel een procede of architectuur kunnen verkloten.

Het is wel zo dat refresh de klant architectuur kan verbeteren voor dezelfde procede en er meer uit kan halen. Zoals intel 14nm met zooi plusjes. Waar dezelfde procede ook subtiel verbeterd.

[DaniëlWW2]

SG schreef op zaterdag 23 juli 2022 @ 17:14:
[...]

Ik vind dit toch rare gedachten gang.
Dieshrink van n7 naar n5 breng hogere kloks en lagere tdp bij gelijke performance. Dat is wat foundry aan klant bied. Zo niet dan hebben ze die procede verkloot. Zoals intel met hun 10nm.
En dat staat los van hoe of wat intel/AMD/nV met architectuur of tooling de zooi verkloten. Dat is de next step dat klant het verkloten kan.
Of dat samsung intel tsmc hun dieshrink verkloten. Dan heeft klant een handicap. Zoals AMD met global foundry.

Gemiddeld gezien is dat wat dieshrink brengen in de begin tijd van cpu naar 1000nm naar 2nm waarbij foundry en chip ontwerper uiteraard wel een procede of architectuur kunnen verkloten.

Het is wel zo dat refresh de klant architectuur kan verbeteren voor dezelfde procede en er meer uit kan halen. Zoals intel 14nm met zooi plusjes. Waar dezelfde procede ook subtiel verbeterd.

Ik ageer dan ook niet tegen het idee dat de overstap naar N5, niet voor een verhoging van clock speed zal zorgen. Ik ageer tegen de gedachte dat het een automatisch gegeven is waaraan bepaalde verwachtingen worden gekoppeld, in het bijzonder voor Lovelace.

Hoe ik het altijd begrepen heb, heeft een foundry eigenlijk een kleine den simpele demonstratiechip waaruit ze hun claims halen. Hoe die claims zich vertalen naar een product van een klant, is altijd afwachten. We weten eigenlijk wel dat met N5 eigenlijk gaan zien dat SRAM en I/O niet veel kleiner meer kunnen worden en logic waarschijnlijk fors kleiner zal worden.

Komt bij dat Nvidia ook voor een forse toename aan L2 cache gekozen lijkt te hebben omdat VRAM gewoon niet snel genoeg is en die ontwikkeling al jaren achterblijft op de GPU zelf. AMD wordt natuurlijk helemaal radicaal anders met MCM waarbij de implicaties sterk op het afsplitsen van L3 hangen. Hierdoor krijg je waarschijnlijk chips die heel andere verhoudingen krijgen dan we gewend zijn. Bij Nvidia procentueel meer oppervlakte voor caches en I/O, samen met een flinke toename in dichtheid voor logic. Bij AMD lijk je een extreme dichtheid te kunnen gaan halen voor de centrale GCD en daaromheen een aantal andere chiplets met beduidend mindere grotere transistordichtheden.

Hoe hangt dit nu met clockspeeds samen?
Nou mijn begrip hiervoor hangt voornamelijk rond de vraag in hoeverre logic paden in die chip geoptimaliseerd worden voor de kortere afstanden tussen verschillende stukken logic op de chip. Immers als je een stuk data uit een local cache nodig hebt en de fysieke afstand is korter, dan kan je dit in een kortere tijdsspanne doen. Uiteindelijk is clockspeed een verdeling van het aantal handelingen per seconde die de hele GPU kan uitvoeren. Daaraan hangen twee randvoorwaarden:
1) Je moet geen instabiliteit of defecten krijgen omdat die stroompulsjes niet arriveren. (hierbij geef ik graag toe dat ik absoluut geen expert ben als het gaat om zaken zoals quantum tunneling, weerstanden van dunnere draden etc)
2) Het moet zinvol zijn omdat als data niet snel genoeg kan arriveren, extra clock speed zinloos is.

Hierin zien we dat Nvidia al drie generaties eigenlijk vastloopt rond de 1800-1900MHz. Dit terwijl de complexiteit van die chips, alleen maar toeneemt. Het was met GP102 nog 3840 ALU's met een relatief simpele cache structuur en de hardware kon vrij weinig doen. Het deed FP geweldig, de rest niet zo, maar dat maakte niet zoveel uit voor de meeste games destijds. Turing was meteen veel complexer met TU102 haar 4608FP + 4608INT + RT + Tensor Cores + complexere cache structuur op dezelfde node. Ik ga Nvidia niks verwijten dat ze hier geen winst in clockspeed lieten zien. Ik ben stiekem toch al wat minder hard op Turing dan veel anderen.

Ik ben juist negatiever over Ampere. Nieuwe node en eigenlijk alleen een tweede datapad naast het INT datapad geïntroduceerd. Hogere TDP's en GA102 schaalt gewoon slecht tot het punt dat ik me serieus afvraag wat het punt is van de 2048 FP32 ALU's extra die de RTX3090Ti over de RTX3080 heeft. 130W TDP extra is een enorme prijs om die schaling meer lineair te krijgen. En dan kijken we nu waarschijnlijk naar 18432FP ALU's voor AD102. Het is weer 70% groter en er zou veel meer L2 cache bijkomen. Die chip gaat zeer complex worden om te voorzien van workloads alsmede data binnen die chip verplaatsen naar waar het moet zijn. En die complexiteit loopt alleen maar op met clockspeed.

Mijn punt is dan ook niet dat clockspeedverbetering het niet kan. Mijn punt is dat het exponentieel complexer aan het worden is om het effectief te doen.

Dan hebben we los hiervan ook nog eens de problematiek van zoveel transistoren die met zoveel energie, een gigantische concentratie aan hitte gaan genereren die ook in de weg gaat zitten. Zeker als je met zeer hoge frequenties, veel data ver over de chip moet gaan verplaatsen. Als je datapulsjes laten we zeggen, tweemaal de afstand moeten afleggen als in een andere chip en beide chips hebben dezelfde clock speed, dan weet je dat die chip met de grotere afstanden tussen cache en rekeneenheden, meer pulsjes heeft die op weg zijn voor berekenen dus meer energie verbruikt. En daarom zal die chip ook meer hitte afgeven en dat gaat uiteindelijk de stabiliteit van de chip beïnvloeden.

En die alles bij elkaar, heel bot gesteld, komt neer op "ja maar AMD deed het dus Nvidia kan het ook met een betere node". Want ik kan me de indruk niet onttrekken dat dit zeker een rol speelt. Toen RDNA3 over de 3GHz gaan, begon het met Nvidia opeens met alsmaar oplopende clock speeds halen, hieraan gekoppelde steeds extremere TFLOP getallen. En dit werd gecombineerd met verklaringen van Nvidia hun veronderstelde superioriteit.

Dit zit me dan ook zo enorm dwars. Want AMD heeft een architectuur bijna volledig vanaf de grond af ontwikkeld om te doen wat ze deden met RDNA2. Er zit zoveel moeite in RDNA(2) om die hogere clock speeds te halen, het effectief te doen met veel hogere occupency waarden en om maar niet afhankelijk te zijn van langzame dataopslag, in het bijzonder VRAM of het verplaatsen van data, om vervolgens samen met hun CPU team hun logic te optimaliseren voor die clock speeds die ze halen. In RDNA zit cache waar een rekeneenheid direct haar data uit moet halen, zeer dichtbij de rekeneenheden en dat is geen toeval. Het hele L3 cache verhaal in RDNA2 lijkt voornamelijk een manier te zijn om een snellere opslag te creëren die snel data naar L2 en L1 cache kan pushen of heel veel data tijdelijk, op de chip kan opslaan zonder dat je terug hoeft te vallen op het langzame VRAM als er iets nodig is voor een andere berekening. En de hele structuur van RDNA vermijd ook de complexe SM + L2 cache structuur van Nvidia die als maar complexer aan het worden is. Een structuur die ook steeds meer vertragingen kan gaan opleveren omdat er nergens lokale caches zijn waaruit een SM direct kan putten. Als een SM nu iets nodig heeft, dan komt het uit L2 en L2 kan letterlijk bijna aan de andere kant van de chip zitten. Zie:



Los daarvan heb je dan ook nog eens de problematiek van de SM's zelf voorzien van rekeninstructies en de structuur van de SM zelf die weinig flexibel is. Je ziet dat Nvidia gewoon veel meer moeite moet doen om hun rekeneenheden elke clock cycle iets te laten berekenen. Dit tot het punt dat AMD vergelijkbaar kan presteren met de helft aan rekeneenheden. Dat is ook iets dat veel lastiger voor Nvidia gaat worden met nog eens 70% extra rekeneenheden.

Dat is het tweede punt meteen. Ik wil best geloven dat Nvidia door de 2GHz barrière gaat, maar daarvoor verwacht ik eigenlijk forse aanpassingen in architectuur te zien, waar je maar niks over hoort. We horen constant TFLOPS dit, maar die waarden zijn zinloos als ze in de praktijk niet opschalen. Want bijvoorbeeld 82TFLOPS zou 2x RTX3090Ti kunnen betekenen, of 65% zoals die TSE score suggereert. Dat is het punt. Het is geen gratis zoveel procent clockspeed = zoveel procent sneller en daar ageer ik tegen.

Ik zit dus echt te wachten op forse aanpassingen. Eentje waar ik bijvoorbeeld aan zou denken is dat Nvidia haar L2 cache, direct gaat verbinden aan GPCs. AD102 zou er 12 hebben en 96MB aan L2 cache. Dus 8MB per GPC waarbij een GPC bestaat uit 12 SM's. Zoiets zou kunnen helpen. Het zou ook verklaren waarom L2 cache misschien gaat verschillen per SKU. Als het verbonden is aan de GPC, dan is dat logisch. Maar ik hoor hier maar niks over in die leaks.

[ Voor 5% gewijzigd door DaniëlWW2 op 23-07-2022 19:10 ]

[Werelds]

SG schreef op zaterdag 23 juli 2022 @ 17:14:
Ik vind dit toch rare gedachten gang.
Dieshrink van n7 naar n5 breng hogere kloks en lagere tdp bij gelijke performance. Dat is wat foundry aan klant bied. Zo niet dan hebben ze die procede verkloot. Zoals intel met hun 10nm.

Het is juist jouw gedachtegang die raar is

Hogere clocks en gelijke performance kan niet. Hogere kloksnelheden betekent betere performance. Sterker nog, wanneer foundries het over "performance" hebben, bedoelen ze kloksnelheden.

Dit is wat een foundry aan geeft (TSMC in dit geval):

N5 technology provides about 20% faster speed than N7 technology or about 40% power reduction. N5 technology further expands our customer product portfolio and increases our addressable markets.

Dus als jij op N7 een chip bakt die 100W verbruikt en 2 GHz haalt, stellen zij dat je op N5 2,4 GHz kunt halen en bij die 100W blijft, of je blijft op 2 GHz hangen en verbruikt nog maar 60W. Ga je qua kloksnelheid er tussenin zitten is er geen garantie. Verbruik is immers niet lineair met klokfrequentie en spanning, dus het kan best zo zijn dat 2,2 GHz 95W nodig heeft.

Wat een foundry níet garandeert is dat je een specifieke kloksnelheid kunt halen, want dat is juist afhankelijk van jouw ontwerp. Vandaar dat Nvidia en AMD ook maar zelden dezelfde kloksnelheden halen. Ze garanderen ook niet dat je een bepaalde spanning kunt halen. Wederom afhankelijk van jouw ontwerp.

---

Muur tijd!

sunsmountain schreef op dinsdag 19 juli 2022 @ 00:20:
Het leek me dat de caches vergelijkbaar waren, maar Ampere heeft verhoudingsgewijs veel meer L0 L1 cache nodig:
GA102, 26880 L0 kB, 10752 L1 kB , bij elkaar 36,75 MB.
Navi21, 14880 L0, 8064 L1 kB, bij elkaar maar 22,4 MB.

Hoewel ik niet zo ver zou gaan om GA102 een GCN4 te noemen, knap gedaan van AMD.

Nvidia heeft vooral meer omdat ze meer cycles nodig hebben voor warps en dus dingen langer in cache moeten houden, wat betekent dat ze meer ruimte moeten laten voor verschillende threads. Met GCN4 bedoel ik overigens enkel dat dit inmiddels de 4e evolutie van grofweg dezelfde opzet is van Nvidia, niet dat het allemaal verder vergelijkbaar is. Van Maxwell naar Ampère is niet echt een grotere stap dan van GCN1 naar GCN4.

<ook stukjes vóór hetgeen ik hierboven quote>

Ja wederom als je een dual CU met 1 SM vergelijkt. Maar vergelijk nou eens 40 dual CU met 80 SM? Dan doet Ampere toch 2x zoveel?

Nog een keer:
64FP32 + 64 INT32, verdeeld als 4x16FP32 + 4x16INT32.
1 SM = voert dit uit in 1 cycle
1 CU = voert dit uit in 2 cycles

Goed, dan gaan we nu maar even een stapje verder, waarbij ik me in zal proberen te houden. Maar ik merk dat ik te veel geprobeerd heb alles te versimpelen, met name rondom cycles maar ook rondom instructies en hoe alles verwerkt wordt. Ik zal alsnog kort door de bocht gaan, want anders krijg ik een ban voor het overflowen van het forum

Laat ik eerst maar met de deur in huis vallen: dat "in X cycles" verhaal zoals wij het hier vaak zeggen, is niet hoe het daadwerkelijk werkt
Ik heb me daar vooral bij gehouden, omdat de meesten denken dat dat zo werkt en het qua theoretische throughput aardig dicht in de buurt komt. Hoe GPU's (en hun drivers!) dat in de praktijk doen is echter geheel anders.

Wat verder belangrijk is om te weten (en in je achterhoofd te houden) bij het onderstaande, is dat instructies voor datatypes gescheiden zijn. Optellen is bijvoorbeeld FADD voor floating point en IADD voor integers, of iets in die trant. In Nvidia's PTX ISA (is een niveau boven de daadwerkelijke GPU ISA) heb je bijvoorbeeld add.f32, add.u32 en add.s32 voor 32-bit floating point, unsigned integer en signed integers respectievelijk. Groottes anders dan 32-bits ga ik nu ook niet op in. Daarnaast moet je onthouden dat de GPU in principe aan het werk gezet wordt en de CPU (en dus OS, driver, game) er dan niet meer tussen komt; dus de GPU in z'n geheel krijgt een lijst met miljarden dingen te doen.

Per SM en per DCU (die we eigenlijk WGP horen te noemen wat ik dus maar vanaf nu ga doen) is er ruimte voor maximaal 64 warps respectievelijk 80 waves (wave32 voor het gemak) - ik zal het enkel bij Ampère en RDNA houden om de vergelijking zinvol te houden. Een warp danwel wave32 is een verzameling van maximaal 32 threads. Een thread is geen thread zoals jij dat kent vanuit het OS niveau; een thread is een stuk code dat achter elkaar uitgevoerd moet worden (threads in verschillende warps kunnen echter wel bij elkaar horen). Daarom noemt AMD ze ook work-items. Een warp/wave is dus ook niet slechts een reeks van 32 instructies; het is eerder een reeks van 32 pointers naar reeksen instructies (code ). Een SM danwel WGP werkt álle toegewezen warps/waves af vóór er een nieuwe set wordt toegewezen. Er zijn nog veel meer nuances (dingen als thread blocks) die ik nu even ga negeren, ik link onderaan wel wat leesvoer als je álle details wilt weten

Een warp/wave afwerken gebeurt níet door per thread een instructie te nemen en die aan één ALU toe te wijzen. Nee, er wordt juist een instructie gekozen en die wordt voor álle threads uitgevoerd (dus maximaal 32 ALU's aan het werk, allemaal aan dezelfde instructie maar andere data...SIMD); als een thread die instructie niet heeft (bijvoorbeeld door branching; if-else in code), wordt er voor die thread in die cycle dus niets gedaan. Dat doen zowel AMD als Nvidia.

Aan Nvidia's kant worden de 64 warps voor een SM verdeeld over de 4 warp schedulers (elk met 1 dispatch unit), dus 16 warps per partitie - dit is niet flexibel, warps worden aan één partitie toegewezen en blijven daar (vandaar de L0$I per partitie). Elke cycle zal de warp scheduler in een partitie proberen één instructie voor één warp uit te delen, mits er een warp klaar is voor de volgende instructie en de ALU's vrij zijn. En nu zie je ook meteen waarom Nvidia voorheen áltijd 2 cycles nodig had voor een warp: ze hadden immers slechts 16 ALU's per dispatch unit (er waren er voorheen 2, dus beide datapaden konden aan het werk gezet worden), dus ze konden per cycle maar de helft van de threads in een warp een stap vooruit laten zetten.

Als je een beetje mee hebt zitten rekenen, zie je ook al wat andere problemen. Het is één instructie per cycle, per partitie. Nvidia moet dus al vooraf (en dat doen ze grotendeels al in de driver/compiler!) zorgen dat ze de warps en blokken dusdanig indelen dat er per SM een relatief uniforme workload is, anders kan één partitie de andere partities blokkeren omdat de hele SM tussen "puur" en "mixed" moet schakelen. Een ander punt is dat Nvidia technisch gezien in één cycle onmogelijk 64 FP32 ALU's en 64 INT32 ALU's aan het werk kan zetten. Per partitie doen ze immers slechts één instructie per cycle en dat is óf INT, óf FP. In de cycles na elkaar kan dat wel; en als de "pure" FP32 ALU's al bezig zijn en meerdere cycles nodig hebben kan het andere datapad wel gewoon aan het werk gezet worden. Maar in één cycle kan dat niet. Het beste wat Nvidia in één cycle kan schedulen is alle 4 partities 100% aan FP32 en dus 128 FP32 ops per SM (ofwel 4 warps in 1 cycle afgewerkt), óf 1-3 partities half aan FP en de resterende aan INT - wat dus betekent dat ze 2 schedule cycles per warp nodig hebben. Het is pertinent onmogelijk voor Nvidia om in één cycle 64xFP32 én 64xINT32 aan het werk te zetten, dat vereist sowieso 2 cycles - ongeacht welke warps dat uit komt. Daarom hebben ze het met Volta/Ampère ook over concurrent FP32/INT32, niet parallel (zie de Golang presentatie hieronder voor de nuance tussen die twee termen ). Een "64+64" situatie bestaat eigenlijk dus ook niet; dat moet dan 32 + 32 + 32 + 32 zijn, uit 4 verschillende warps. Maar dan zie je ook meteen het bezetting probleem, je hebt 2 (scheduling) + 2 (uitvoering; uitgaande van instructies van 1 cycle) cycles nodig per warp en bezet elke partitie slechts voor de helft. Dat proberen ze op te lossen door in de tijd dat een datapad bezet is, het andere pad te bezetten met een andere warp (kunnen ze pas vanaf Volta en heeft enkele beperkingen). En zij proberen dit al in een heel vroeg stadium (driver) te plannen! Daarom hebben ze zo veel ALU's nodig, omdat er gewoon een te groot deel van de tijd een groot deel van de ALU's stil ligt.

AMD doet dat anders. De 80 waves worden in de instructie cache van de hele WGP gezet. Zij hebben ook één scheduler per SIMD, het verschil is dat de 4 schedulers (onder andere) een enkele instructie cache delen. Elke scheduler probeert op enig moment 20 waves af te werken, ongeveer zoals de schedulers in Nvidia's SM's er 16 doen. AMD kan hier wat meer mee dan Nvidia qua samenwerking tussen SIMD's, maar voor het gemak negeren we dat nu. Om maar meteen korte metten te maken met het voorbeeld hierboven van "64+64" (dus 4 warps, waarvan 2 met FP32 en 2 met INT32, 1 cycle per instructie): 1 cycle om alle 4 in één keer te schedulen. Klaar. Ze hoeven niet zoals Nvidia de 4 delen in 2 keer te schedulen, omdat ze gewoon 32 ALU's hebben die het allemaal aan kunnen. En ze kunnen per SIMD een andere instructie (ongeacht het data type) doen, zonder de andere SIMD's daarbij te beïnvloeden (GCN kon dat per SIMD en ze zeggen over RDNA nergens dat dat veranderd is dus dat kan nog steeds; grootste verschil is dat INT32 nu native is en dus full-rate gaat).

En als laatste dan maar even terug naar eerdere voorbeelden. Allereerst een voorbeeld waarbij er één warp/wave is die INT32 doet en de rest FP32. Nvidia heeft dan nog steeds 2 schedule cycles per warp nodig. Die ene wave INT32 blokkeert de andere 3 partities voor de helft. AMD heeft daar 100% schijt aan en doet het gewoon in 1 cycle per wave. Nvidia's workaround sinds Volta zorgt mogelijk ook voor balans problemen waardoor de warps niet evenredig afgewerkt worden, dus dat is nóg iets waar ze rekening mee moeten houden.

De andere voorbeelden (4x16 FP32 + 1x16 INT32, of 4x16 + 4x16) zijn een stuk lastiger en had ik niet moeten noemen omdat het uitzonderingen zijn. Het kán in de praktijk wel voor komen met branches, maar daar wil ik nu eigenlijk niet op in gaan want dan wordt dit verhaal nog langer. Qua scheduling zal het je inmiddels wel duidelijk zijn dat beide 2 cycles nodig hebben, omdat het FP en INT binnen dezelfde partitie/SIMD is. Uitvoering is een ander verhaal; voor FP32+INT32 zal het voor beide gelijk zijn, voor zover ik weet kan AMD gewoon de andere helft van een SIMD aan een ander data type zetten (zolang het binnen dezelfde wave is). Voor andere data types wordt het veel ingewikkelder wegens data packing, even los van het feit dat branching zoals gezegd een verhaal apart is.

Dit alles gezegd hebbende, zijn er nog veel meer factoren die invloed hebben. Niet alle integer ops zullen bijvoorbeeld door de "gewone" ALU's gedaan worden; beide zullen sommige dingen door andere units laten doen (en om je vraag over de scalar units te beantwoorden: ja, die units kunnen zelfs 64-bits integer aan; inclusief multiply-add). Het lezen/schrijven van data heb ik volledig genegeerd (laat staan de geheugen hiërarchie). Dan heb je ook nog SFU's voor dingen als sin/cos/tan/etc., doen ze branches anders, duurt niet elke instructie even lang, kun je je werk groeperen in workgroups/blocks op allerlei manieren en zo kan ik nog wel even door gaan. Ik heb het nog niet eens gehad over hoe AMD compute doet, of hoe beide geometry doen, hoe ze hun RT afhandelen. Of in Nvidia's geval, dat de tensor cores aan het werk zetten een cycle is waarin je de FP32/INT32 ALU's niet aan het werk zet. Er zijn zo veel dingen die ook invloed hebben op hoe de ALU's aan het werk worden gezet of blijven, daar kun je dagen over blijven lezen.

Het punt is dat de aansturing een cruciaal onderdeel is en dat je aantallen ALU's onmogelijk tussen de twee kan vergelijken. Sterker nog, die aantallen zijn tussen RDNA en GCN al niet meer te vergelijken (zie Navi 10 vs Vega), laat staan tussen de fabrikanten. Nvidia heeft ook zo veel units nodig omdat hun aansturing zo verrekte lastig is en ook niet zo eenvoudig op te lossen is (wat ik ze nog wel zie doen voor Lovelace is terug naar 2 dispatch units, één voor elk datapad). Ik hoop dat nu ook duidelijk is dat 100% bezetting volstrekt onmogelijk is (voor beide). Zelfs 100% van enkel de ALU's (alle andere units negerend) is enkel haalbaar met een compute workload die er specifiek op gericht is precies dat te doen. En hopelijk is nu ook duidelijk waarom je 1 WGP met 1 SM moet vergelijken; ongeacht het feit dat het vervolgens over 40 vs. 84 gaat op GPU niveau. Vooral voor AMD zit daar sowieso nog een niveau tussenin met shader engines. GPC's aan Nvidia's kant zijn meer voor de logische groepering, daar zit niet echt hardware aan verbonden.

Dan nu wat leesvoer voor als je écht diep wil gaan

- Concurrency isn't parallelism -> slides
- Whitepapers voor alle architecturen vanaf Fermi en GCN; maar vooral GCN, RDNA en Turing/Volta (independent thread scheduling) en Ampère voor het bovenstaande. Te lui om alle URLs te verzamelen, Google heeft ze zo te pakken
- Nvidia's CUDA programming en PTX docs (in de algemene CUDA docs vind je ook tuning guides, waar ook nuttige informatie in staat)
- RDNA ISA

Klopt, maar wederom, hoe vaakt komt het voor? En de Ampere driver zal dit proberen te minimaliseren.

Vaak zat. Een SM heeft maximaal 2048 threads (64 * 32) en een WGP 2560; bedenk eens even hoeveel pixels en vertices er alleen al zijn in een frame?

En dan krijg je hier mee te maken:



De sprong van L1 naar L2 is al erg groot (dat is eigenlijk al vanaf 64 KB; de 128 KB L1 van Nvidia is niet volledig beschikbaar tenzij je compute doet en expliciet de volle 128 KB aan zet) met 100ns (200 cycles op 2 GHz). En zoals je ziet heeft AMD nog wat meer trucjes in hoe ze met geheugen en adressen om gaan, waardoor je zelfs de L3 nog vrij lang sneller aan kan spreken dan Nvidia's L2 (!). Nu is deze test een extreem geval omdat pointer chasing het absolute worst case scenario naar boven haalt, maar AMD's geheugen en cache setup is best bijzonder. Zal Nvidia dat proberen te minimaliseren in de driver en compiler? Tuurlijk. Maar dacht je dat AMD niets doet?

Sterker nog, de beste game devs doen dit ook al vóór alles bij de compiler en driver komt. Bij het schrijven van shaders wordt vaak al nagedacht over dingen als branches, want de manier waarop je dat doet kan je zomaar twee keer zo veel cycles kosten, ook al doe je exact hetzelfde werk.

Ik denk inderdaad niet dat Nvidia de L0 L1 cache oplossing van AMD gaat evenaren, maar ze gaan hun L2 wel een stuk groter maken ter compensatie. Uiteindelijk draait het om performance, en je mag Ampere en Lovelace verouderd vinden, als ze goed presteren klaagt er niemand.

Zoals je hierboven ziet zal de grootte het probleem niet echt oplossen, het betekent vooral dat de lijn ná 256 KB langer horizontaal blijft lopen.

[Afbeelding]

De SM's bij alle 3 deze architecturen zijn verschillend, dat is wat ik zei. Ik heb niet gezegd dat de SM's gronding zijn herbouwd en ik zie dat ze op elkaar lijken. Maar het punt is dat de gewijzigde SM telkens de performance heeft beïnvloedt, qua IPC.

Die linker klopt niet (slecht werk van Techspot ), dat is GP100 en hoort dus niet bij de andere twee. GP100/Volta/GA100, of GP102/TU102/GA102.

Dit is de Pascal SM (GP102 en lager):



En uitgerekend de "IPC" is niet veranderd - althans niet per se verbeterd. Maxwell en Pascal hadden 2 dispatch units per scheduler, wat betekende dat 1 scheduler 2 instructies per cycle uit kon delen. Omdat elke dispatcher aan 16 ALU's hing, betekende dat 2 warps per cycle per partitie, maar ook 2 cycles per partitie om "klaar" te zijn (dus 2 warps in 2 cycles). Turing en Ampère kunnen beide slechts 4 instructies per cycle uitdelen, echter hangt die ene dispatch unit wel aan beide datapaden. Dus waar Pascal in 1 cycle 2 sets van 16 ALU's aan het werk zette en de volgende cycle weer, om op die manier 2 warps af te werken, kunnen Turing/Ampère data soms in slechts 1 cycle. Als het puur FP32 is, hebben ze slechts 1 schedule cycle nodig voor een hele warp, wat betekent dat ze net als Pascal 2 warps in 2 cycles schedulen. Gooi je er integer tussen wordt het lastiger, want dan "verliezen" ze cycles aan het schedulen van INT. Na het schedulen van INT zou de FP kant echter vrij kunnen zijn, waardoor ze verschillende warps door elkaar heen kunnen weven. Dus zo vangen ze dat verlies van "IPC scheduling" op. Daarom heb ik ook zo'n hekel aan "IPC". Het is een volstrekt zinloze term. Nvidia's scheduling IPC is gehalveerd door het verlies van een dispatch unit per scheduler, maar hun IPC uitvoering kán in sommige gevallen hoger liggen. En in andere gevallen lager of gelijk.

Ik zou heel graag willen zien hoe een 50% grotere (5376 ALU's, 42 SM's) GP102 het uit zou houden tegenover Ampère. Als je kijkt hoe een 3080 presteert betwijfel ik ten zeerste of er voor gaming daadwerkelijk meer throughput is. Het pure FP32 datapad bestaat al uit 4352 ALU's op ~10% hogere kloksnelheid; daar heb je al pakweg een derde van de extra performance te pakken. Een 3060 met hetzelfde aantal ALU's (als GP102) in totaal (1792 + 1792) presteert net iets minder. Pascal lijkt dus niet echt moeite te hebben met die 36% INT32.

Ja, de SM's zijn gewijzigd, maar dat zijn vooral tweaks. Er is geen dramatische verandering die de fundamentele werking verandert. Niet op dezelfde manier als RDNA tegenover GCN. En de splitsing in FP32/INT32 cores lijkt ook niet veel effect gehad te hebben voor graphics. Voor compute wel, maar dat is een heel ander verhaal.

[DaniëlWW2]

@Werelds En ik wou vandaag wat vroeger naar bed. Bedankt he.
Maar ik heb zojuist weer een paar uur doorgebracht met zaken op me laten inwerken en dingen opzoeken omdat ik in mijn hoofd dus een vrij stupide iets heb weten te doen. Ik heb het namelijk voor elkaar gekregen om te denken: warp/wave32 = 32 threads = 32 instructies. Dus thread = instructie. Dat moest eruit bij mij omdat een instructie natuurlijk een deel van een thread is. Immers heet het een thread.

Ik heb alleen een heel kleine, vervelende nitpick.

De andere voorbeelden (4x16 FP32 + 1x16 INT32, of 4x16 + 4x16) zijn een stuk lastiger en had ik niet moeten noemen omdat het uitzonderingen zijn. Het kán in de praktijk wel voor komen met branches, maar daar wil ik nu eigenlijk niet op in gaan want dan wordt dit verhaal nog langer. Qua scheduling zal het je inmiddels wel duidelijk zijn dat beide 2 cycles nodig hebben, omdat het FP en INT binnen dezelfde partitie/SIMD is. Uitvoering is een ander verhaal; voor FP32+INT32 zal het voor beide gelijk zijn, voor zover ik weet kan AMD gewoon de andere helft van een SIMD aan een ander data type zetten (zolang het binnen dezelfde wave is). Voor andere data types wordt het veel ingewikkelder wegens data packing, even los van het feit dat branching zoals gezegd een verhaal apart is.

De andere helft van een SIMD? Uh SIMD is toch Single Instruction Multiple Data? Oftewel een instructietype per cycle? Want volgens mij beschrijf je hier per ongeluk iets dat niet kan.

[Werelds]

DaniëlWW2 schreef op zondag 24 juli 2022 @ 01:28:
De andere helft van een SIMD? Uh SIMD is toch Single Instruction Multiple Data? Oftewel een instructietype per cycle? Want volgens mij beschrijf je hier per ongeluk iets dat niet kan.

Ja, maar als ik me niet vergis (zal kijken of ik de whitepapers er vandaag op na kan slaan, maar ik ga zo weg en zal pas laat terug zijn ) is AMD niet gebonden aan slechts één instructie per SIMD "array" tegelijkertijd. Dus als er 16 van de ALU's aan FP zitten en de andere 16 stil liggen (door een branch bijvoorbeeld) kan AMD volgens mij een tweede instructie uit diezelfde wave aan de andere 16 toekennen. Belangrijk is dat het om dezelfde wave moet gaan, vanwege dingen als de program counters, data in de registers, enzovoort. Het is nog steeds SIMD voor de ALU's die aan het werk gezet worden.

In "GCN mode" doen ze dat ook, dan splitsen ze elke SIMD in tweeën en gebruiken ze hem als 2xSIMD16.

[DaniëlWW2]

Werelds schreef op zondag 24 juli 2022 @ 09:38:
[...]

Ja, maar als ik me niet vergis (zal kijken of ik de whitepapers er vandaag op na kan slaan, maar ik ga zo weg en zal pas laat terug zijn ) is AMD niet gebonden aan slechts één instructie per SIMD tegelijkertijd. Dus als er 16 van de ALU's aan FP zitten en de andere 16 stil liggen (door een branch bijvoorbeeld) kan AMD volgens mij een tweede instructie uit diezelfde wave aan de andere 16 toekennen. Belangrijk is dat het om dezelfde wave moet gaan, vanwege dingen als de program counters, data in de registers, enzovoort. Het is nog steeds SIMD voor de ALU's die aan het werk gezet worden.

In "GCN mode" doen ze dat ook, dan splitsen ze elke SIMD in tweeën en gebruiken ze hem als 2xSIMD16.

Oke, als ze dat kunnen, dan hebben ze pas echt een gigantische voorsprong op Nvidia.

Maar als ik kijk in de RDNA whitepaper, dan betwijfel ik het of ze dit echt kunnen. Elke SIMD32 krijgt immers haar eigen set van twintig wave32 in een eigen wavefront controller. Ik zie nergens een indicatie dat ze verschillende instructies mixen. Niet in de tekst en ook niet in de voorbeelden.

Ik zie het ook niet in de RDNA optimalisatie guide. Alle voorbeelden daar gaan over een type instructie per SIMD, per clock. Ik vermoed dus dat de RDNA ALU's tegen veel minder problemen aanlopen omdat ze zoveel instructies ondersteunen en omdat het hele proces van draw calls decoderen tot wave32 of wave64 en vervolgens verstrekken aan een SIMD32, ook veel efficiënter gaat met veel hogere percentages aan ALU's die aan het werk zijn. Dus occupency.

Mij is alleen niet helemaal duidelijk hoe ze het doen omdat AMD hier juist zo weinig over lijkt te willen zeggen. De enige indicatie is dat RDNA juist probeert om een work group (een collectie van verschillende waves), gezamenlijk te berekenen en niet zoals eerder te proberen om de oudste wavefront in de que af te handelen, waarbij soms wavefronts van een andere workgroup begonnen werden.

---

Dat brengt me overigens tot een andere realisatie. In RDNA heb je als schrijver van een shader programma, geen controle of die een wave32 of wave64 dispatched. En als ze het hebben over shader optimalisatie, dan raden ze alsnog wave64 aan. En toen moest ik opeens denken aan hoe ze dat doen. Ze voeren nu een wavefront 64 in twee aparte scheduling cycles uit op een SIMD32.

Nu krijgt RDNA3 een dedicated wave64 single issue instructie. Zie:

😁 pic.twitter.com/Nf1PdayhYQ

— Kepler (@Kepler_L2) 6 juli 2022

The fun thing is that this was in the original SoC21 patch from 4 months ago! Hidden in plain sight 😂

You can also see the dual VALU wave32 mode mentioned a few lines below it.https://t.co/GeRTrExNLK

— Kepler (@Kepler_L2) 6 juli 2022

Het lijkt erop dat AMD dan twee SIMD32 direct gaat aansturen voor een wave64. Dan moet ik meteen denken aan het scenario waarin ze een grote wave64 nemen en instructies gaan splitsen en verdelen tussen twee SIMD32. De ene cycle kunnen beiden dan FP32 doen, de volgende cycle doet de ene FP32 en de ander FP16, weer de volgende cycle een FP32 en de ander INT32 etc.

Eigenlijk wat je dus wou zien met Nvidia. Een wave/warp, twee dispatchers met beiden hun eigen SIMD, maar dan 32 breed en niet 16. En dat zou wel eens de grote verandering/uplift kunnen zijn in RDNA3. Hopen dat ik gelijk heb, gewoon puur voor ego redenen.

[Werelds]

DaniëlWW2 schreef op zondag 24 juli 2022 @ 12:26:
Maar als ik kijk in de RDNA whitepaper, dan betwijfel ik het of ze dit echt kunnen. Elke SIMD32 krijgt immers haar eigen set van twintig wave32 in een eigen wavefront controller. Ik zie nergens een indicatie dat ze verschillende instructies mixen. Niet in de tekst en ook niet in de voorbeelden.

Even vanaf de telefoon (push notification!): kijk eens onder het stukje waar ze op de GCN compatibility en vector executie in gaan? Zoals gezegd kan RDNA in GCN mode werken, waarbij ze elke SIMD32 gebruiken als 2xSIMD16 om zo 100% compatible te blijven. Het is ook niet mixen van instructies in 1 cycle, ik heb het dan over 2 cycles. Binnen een SIMD hangt alles aan de VGPR, vector registers en scalar cache en dat kan allemaal cross-lane gebruikt worden (ALU kan bijv uit scalar cache lezen).

Ik kan het best fout hebben hoor, omdat ik er in m'n werk niets mee te maken heb lopen de fijnere details soms door elkaar als ik het enkele jaren niet gelezen heb!

[DaniëlWW2]

Werelds schreef op zondag 24 juli 2022 @ 12:46:
[...]

Even vanaf de telefoon (push notification!): kijk eens onder het stukje waar ze op de GCN compatibility en vector executie in gaan? Zoals gezegd kan RDNA in GCN mode werken, waarbij ze elke SIMD32 gebruiken als 2xSIMD16 om zo 100% compatible te blijven. Het is ook niet mixen van instructies in 1 cycle, ik heb het dan over 2 cycles. Binnen een SIMD hangt alles aan de VGPR, vector registers en scalar cache en dat kan allemaal cross-lane gebruikt worden (ALU kan bijv uit scalar cache lezen).

Ik kan het best fout hebben hoor, omdat ik er in m'n werk niets mee te maken heb lopen de fijnere details soms door elkaar als ik het enkele jaren niet gelezen heb!

Ik heb net nog een keer gekeken, maar ik zie het echt niet.
Ik zie wel dat de wave64 modus op een SIMD32 werkt en dan de threads in twee delen verdeeld.
Ik zou ook denken dat als AMD een SIMD32 zou kunnen verdelen in twee SIMD16, ze dit zouden zeggen.

[Sp3ci3s8472]

Voor wie de interview over FSR (2.0) van DigitalFoundry en AMD's Nicolas Thibieroz had gemist.
Rond de 11 minuten een vraag waar ik het antwoord wel op zou willen weten. Helaas kon hij deze niet beantwoorden, behalve met de generieke "we will improve" leus (had graag iets meer voorbereiding willen zien want deze vraag zag je van verre al aankomen na de DF reviews van God of War FSR).
Opvallend is dat AMD niet van plan is om Nvidia's Streamline te gebruiken (dat er voor moet zorgen dat upscale technieken zoals DLSS, XSR en FSR) op een generiek manier kunnen worden geimplementeerd. De grote reden en eentje waar ik achtersta is dat Nvidia's ding waarschijnlijk weer closed source is en dat AMD daar niet aan wil beginnen; naast dat dat niet bij hun filosofie past. Het zou goed voor de markt zijn als Nvidia eens stop met closed source ellende.

[ Voor 6% gewijzigd door Sp3ci3s8472 op 25-07-2022 23:19 ]

[Ludewig]

Sp3ci3s8472 schreef op maandag 25 juli 2022 @ 23:17:
De grote reden en eentje waar ik achtersta is dat Nvidia's ding waarschijnlijk weer closed source is en dat AMD daar niet aan wil beginnen; naast dat dat niet bij hun filosofie past.

Streamline is open source en beschikbaar op Github. Dat het open source is betekent niet dat het project ook neutraal is. De eigenaren van het github project zijn allemaal van Nvidia en die bepalen dus wat in het project komt. Open source betekent dat AMD zijn eigen versie kan maken, maar het hele idee is juist dat er maar 1 versie is, anders heeft het project geen zin.

Dus als Nvidia dit project echt neutraal zou willen maken, dan zouden ze het moeten overdragen aan Khronos o.i.d.

Dan nog is de vraag of Streamline genoeg voordelen bied, want het werk zit vooral in het testen en tunen van de configuratie, wat weer kan verschillen per implementatie. Dus zal je vermoedelijk alsnog specifieke aanpassingen moeten doen als je zowel FSR 2 als DLSS wil ondersteunen.

Overigens is Streamline slechts een API, de daadwerkelijke implementatie moet door AMD gedaan worden. Dat kost extra werk. Het is niet zo vreemd dat AMD blijkbaar heeft besloten dat ze de tijd liever steken in FSR 2.1.

[XanderDrake]

Sp3ci3s8472 schreef op maandag 25 juli 2022 @ 23:17:
Voor wie de interview over FSR (2.0) van DigitalFoundry en AMD's Nicolas Thibieroz had gemist.
Rond de 11 minuten een vraag waar ik het antwoord wel op zou willen weten. Helaas kon hij deze niet beantwoorden, behalve met de generieke "we will improve" leus (had graag iets meer voorbereiding willen zien want deze vraag zag je van verre al aankomen na de DF reviews van God of War FSR).
Opvallend is dat AMD niet van plan is om Nvidia's Streamline te gebruiken (dat er voor moet zorgen dat upscale technieken zoals DLSS, XSR en FSR) op een generiek manier kunnen worden geimplementeerd. De grote reden en eentje waar ik achtersta is dat Nvidia's ding waarschijnlijk weer closed source is en dat AMD daar niet aan wil beginnen; naast dat dat niet bij hun filosofie past. Het zou goed voor de markt zijn als Nvidia eens stop met closed source ellende.
[YouTube: Inside FSR 2.0 – The Making of FSR 2.0, AMD's Future Upgrades + the Xbox Connection]

Ik hoop dat ze er iets aan doen. Momenteel is de QI van FSR 2.0 alleen goed bij 4K upscaling. Bij lagere resoluties zou ik zelfs liever FSR 1.0 gebruiken door al de smearing
Ik ben eigenlijk een beetje teleurgesteld; AMD zag al die ghosting, smearing en issues met "vacht" textures toch van mijlen ver aankomen? Nvidia moest ook stevig aan de bak om sommige problemen tot een acceptabel niveau te verlagen.
Ik vind het zelfs een beetje misleidend: de eerste game die uitkwam met FSR2.0 was Deathloop en die was juist esthetisch zo gemaakt dat ze minder problemen hebben met de dingen die ik boven meldde. Dus iedereen geloofde de hype, en nu zijn we een paar games verder en daarmee komt nu ook de teleurstelling...

[Sp3ci3s8472]

Ludewig schreef op dinsdag 26 juli 2022 @ 11:03:
[...]


Streamline is open source en beschikbaar op Github. Dat het open source is betekent niet dat het project ook neutraal is. De eigenaren van het github project zijn allemaal van Nvidia en die bepalen dus wat in het project komt. Open source betekent dat AMD zijn eigen versie kan maken, maar het hele idee is juist dat er maar 1 versie is, anders heeft het project geen zin.

Dus als Nvidia dit project echt neutraal zou willen maken, dan zouden ze het moeten overdragen aan Khronos o.i.d.

Dan nog is de vraag of Streamline genoeg voordelen bied, want het werk zit vooral in het testen en tunen van de configuratie, wat weer kan verschillen per implementatie. Dus zal je vermoedelijk alsnog specifieke aanpassingen moeten doen als je zowel FSR 2 als DLSS wil ondersteunen.

Overigens is Streamline slechts een API, de daadwerkelijke implementatie moet door AMD gedaan worden. Dat kost extra werk. Het is niet zo vreemd dat AMD blijkbaar heeft besloten dat ze de tijd liever steken in FSR 2.1.

Onverwachts van Nvidia; dan nog zou ik het als AMD er nog niet op gokken totdat het inderdaad door een derde partij gemanaged is. Als Nvidia de API aanpast dan kan dat nadelig zijn voor AMD; daarnaast heeft AMD een aantal parameters die gezet moeten worden, geen idee of dat nog via die Streamline API kan.

Niet elke developer heeft de kennis om aan dezelfde dingen te werken. Ik vermoed dat het prima mogelijk is om een aantal developers aan integratie te laten werken zonder dat het de vooruitgang van FSR 2.1 vertraagd. Je hebt voor beide andere kennis nodig.

[Paprika]

Sp3ci3s8472 schreef op maandag 25 juli 2022 @ 23:17:
De grote reden en eentje waar ik achtersta is dat Nvidia's ding waarschijnlijk weer closed source is en dat AMD daar niet aan wil beginnen; naast dat dat niet bij hun filosofie past. Het zou goed voor de markt zijn als Nvidia eens stop met closed source ellende.

Als je die mening al hebt voordat je ook maar 1 zoekpoging doet, dan zijn dat wel snelle conclusies ja. Misschien heeft AMD ook zo hun besluit gemaakt.

De GitHub link staat letterlijk met een grote knop prominent bovenaan de pagina in de vorm van een call to action: https://developer.nvidia.com/rtx/streamline

[Paprika]

Sp3ci3s8472 schreef op dinsdag 26 juli 2022 @ 23:24:
[...]
Als Nvidia de API aanpast dan kan dat nadelig zijn voor AMD; daarnaast heeft AMD een aantal parameters die gezet moeten worden, geen idee of dat nog via die Streamline API kan.

Ook dan is de vraag of er gesprekken zijn geweest. Als ze niet met Nvidia hebben gepraat, dan weet je ook niet of ze niet andere partijen evenveel rechten zouden geven.

Zolang AMD niet zegt waarom niet, is het allemaal vissen op basis van aannames. Sowieso zijn ownership discussies onzinnig, gezien de MIT license. De code is gewoon voor eeuwig te fokken:
https://github.com/NVIDIA...ine/blob/main/license.txt

* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:

...

Adding some weight to the value of its work, at this early stage, Nvidia already has Intel onboard. In the diagram above you can see Intel plugins are being prepared for Streamline, and this will enable Intel XeSS with just a modicum of effort from devs who have the framework ready, especially compared to pre-Streamline days. Last but not least, Nvidia has left the door open to "Hardware Vendor #3," (aka, He Who Must Not Be Named, aka AMD) to play ball and produce a plugin, to speed integration of their super-resolution technology alongside the green and blue team choices.

...

"Intel believes strongly in the power of open interfaces," said Andre Bremer, VP of AXG and director of game engineering at Intel. "We are excited to support Streamline, an open, cross-IHV framework for new graphics effects. This will simplify game developers’ integration efforts and accelerate the adoption of new technology."

...

https://www.tomshardware....-for-upscaling-algorithms

De enige vraag is of het niet GFX-API gedreven zou moeten zijn (DirectX, Vulkan, ...) of zelfs engine gedreven, maar schijnbaar vinden 2 van de 3 vendors voor alsnog van niet.

Uiteindelijk kun je ook de good guy Nvidia en de bad guy AMD bal spelen:
AMD sponsored games met FSR-only: AC Valhalla, Dirt 5 en Far Cry bv.
Nvidia sponsored games waar wel FSR in zit: Cyberpunk, God of War, Dying Light 2 etc.

Wanneer AMD open source ondersteunt en Nvidia niet dan is Nvidia "the bad company".
Wanneer Nvidia open source ondersteunt en AMD niet dan is Nvidia alsnog "the bad company".

[ Voor 114% gewijzigd door Paprika op 27-07-2022 11:09 ]

[DaniëlWW2]

Ik vermoed hier dat AMD geen zin heeft om zich aan te sluiten bij een Nvidia initiatief omdat ze bij AMD, waarschijnlijk terecht, denken dat ze het zonder Nvidia zelf kunnen doen. Het helpt ook niet dat Nvidia, Intel wel betrokken heeft bij hun RTX Streamline. Intel moet wel omdat die nul relevant marktaandeel hebben waarop XeSS moet groeien. AMD werd meteen al afgeserveerd als "derde vendor" en die hebben geen reden om hier aansluiting bij Nvidia te zoeken. Immers heeft AMD bewust gekozen voor een strategie om DLSS overbodig te maken door FSR 2.0 expliciet open source te maken en ervoor te zorgen dat het ook op Nvidia videokaarten werkt die geen DLSS ondersteunen.

En inmiddels gaat de FSR 2.0 implementatie ook aardig door omdat het in games met DLSS 2.0 te modden blijkt te zijn. Ik heb toevallig gisteren zelf die mod gedownload voor RDR2. Klein probleempje gehad met artifacts wat kwam door een instelling, maar toen werkte het ook. En dat is meteen iets van 20fps erbij terwijl ik het verschil echt niet zie. Daarvoor moet je screenshots gaan maken en vergelijken met FSR aan en uit. Dit is dan FSR 2.0 eigenlijk in de game "hacken", zeker geen goede implementatie. It just works.

En dat is uiteindelijk ook het hele punt. DLSS 2.0 is een gesloten standaard die Nvidia gebruikt als verkoopargument. Dat ze nu met een open source platform komen om DLSS te implementeren, heeft niks te maken met DLSS 2.0 open source maken en alles met DLSS 2.0 alsnog in games proberen te krijgen zodat het geen dode technologie word. Dit omdat FSR 2.0 er nu ook is en veel aantrekkelijker is voor developers om te implementeren. Want het werkt op een veel grotere installatiebasis dan DLSS ooit zal halen. Hierin heeft AMD niks te winnen door een Nvidia branded tool te gaan promoten terwijl je FSR 2.0 ook kan implementeren met een handleiding van AMD en het daarbij kan laten.

[Sp3ci3s8472]

Paprika schreef op woensdag 27 juli 2022 @ 10:33:
[...]

Als je die mening al hebt voordat je ook maar 1 zoekpoging doet, dan zijn dat wel snelle conclusies ja. Misschien heeft AMD ook zo hun besluit gemaakt.

De GitHub link staat letterlijk met een grote knop prominent bovenaan de pagina in de vorm van een call to action: https://developer.nvidia.com/rtx/streamline

Beetje jammer, je zit hier net zo lang als ik op het forum en in meer dan 9 van de 10 keer onderbouw ik mijn argumenten met een bron. Nu heb ik dit als waar overgenomen van een video; dus ja ik kan fout zitten. Daarnaast ben ik de laatste jaar veel neutraler geworden op het gebied van hardware vendors, AMD zal vaak nog mijn voorkeur hebben maar dat komt ik dat ik een groot voorstander ben van Linux en open source. Dat is iets wat bij AMD veel meer leeft dan bij Nvidia; sla Phoronix er maar eens op open. Daarnaast heeft AMD zich tot nu toe nog steeds netter gedragen in de concurentie strijd dan Intel en Nvidia; waar ik bij Intel momenteel wel meer positieve stappen zie.

In een call to action verwacht ik dat AMD gewoon bij naam wordt genoemd. Op die slide van Nvidia staat naast het Intel blokje "Hardware Vendor 3". Dat noem ik nu niet een actie in goed vertrouwen.

Paprika schreef op woensdag 27 juli 2022 @ 10:39:
[...]

Ook dan is de vraag of er gesprekken zijn geweest. Als ze niet met Nvidia hebben gepraat, dan weet je ook niet of ze niet andere partijen evenveel rechten zouden geven.

Dan moeten ze zelf de hand uit reiken naar AMD. Nvidia heeft voor mij gewoon nog niet de reputatie daarvoor, daar zullen ze hard aan moeten werken. Voor ons is het giswerk; je ziet vaak dat de drie hardware vendors een slappe hand uitreiken naar de concurentie waar te veel haken en ogen aan zitten die de andere partijen bij voorbaat niet accepteren maar dat er wel voor zorgt dat de vendor die de slappe hand uitsteekt een vit voetje bij de media haalt.

Zolang AMD niet zegt waarom niet, is het allemaal vissen op basis van aannames. Sowieso zijn ownership discussies onzinnig, gezien de MIT license. De code is gewoon voor eeuwig te fokken:
https://github.com/NVIDIA...ine/blob/main/license.txt

De MIT license zegt dus werkelijk niks. Stel dat AMD meewerkt en Nvidia geen code accepteerd of de code zodanig aanpast in het nadeel van AMD. Wat moet AMD dan doen? De MIT license laat ze een fork maken; dan krijg je dus alsnog meerdere versies van Streamline, een van AMD en een van Nvidia en wellicht dus nog een van Intel. Dan heb je exact hetzelfde probleem als eerst.

De reden waarom ik zo negatief ben over Nvidia als het aankomt op open source is Linux; die open-source GPU kernel modules zijn een kleine stap vooruit om het te verbeteren. Laten we voorop stellen dat deze stap voornamelijk voordelig voor Nvidia zelf is en niet gedaan omdat ze zo graag open source gaan.

Uiteindelijk kun je ook de good guy Nvidia en de bad guy AMD bal spelen:
AMD sponsored games met FSR-only: AC Valhalla, Dirt 5 en Far Cry bv.
Nvidia sponsored games waar wel FSR in zit: Cyberpunk, God of War, Dying Light 2 etc.

Wanneer AMD open source ondersteunt en Nvidia niet dan is Nvidia "the bad company".
Wanneer Nvidia open source ondersteunt en AMD niet dan is Nvidia alsnog "the bad company".

Als dat meespeelt dan is het percentage van invloed heel erg klein en om de volgende reden. De grootste reden dat FSR 2 in DLSS titels komt is omdat de pipeline al geschikt hiervoor is en je dit in hele korte tijd kan implementeren; dit is niet waar voor titels waar FSR 1 in zit. Daar DLSS inbouwen kost een stuk meer tijd van de developers.
Daarnaast is FSR 1 in een game inbouwen een fluitje van een cent want het is niet meer dan een spatial filter; die je doet voordat de GUI wordt gerenderd.
Laatste punt wat waarschijnlijk nog zwaarder weegt dan jou reden is dat AMD de consoles heeft.

[Sp3ci3s8472]

DaniëlWW2 schreef op woensdag 27 juli 2022 @ 11:52:
Hierin heeft AMD niks te winnen door een Nvidia branded tool te gaan promoten terwijl je FSR 2.0 ook kan implementeren met een handleiding van AMD en het daarbij kan laten.

Nog een toevoeging is dat met elke tussen API je altijd de afweging moet maken tussen performance, compatibiliteit of de kwaliteit van de uitkomst. Een native implementatie zal altijd mooier of sneller zijn dan een die compatible moet zijn met andere oplossingen.
AMD had het in de presentatie en in de video met DF over een aantal parameters die de developer kan zetten; het zou goed kunnen dat dat lastiger is met een extra API of dat ze daardoor een performance penalty krijgen. Nu programeer ik voornamelijk in C# maar, als je op een generieke extra parameters meeleverd moet je die casten wat een overhead geeft. Dat is voor een stukje code wat zo vaak moet worden uitgevoerd eigenlijk geen stap die je wilt nemen als dat niet hoeft.
Ik heb hier het niet over "generics" maar gewoon een "object" wat als extra data wordt meegeleverd.

[Werelds]

DaniëlWW2 schreef op zondag 24 juli 2022 @ 13:11:
[...]


Ik heb net nog een keer gekeken, maar ik zie het echt niet.
Ik zie wel dat de wave64 modus op een SIMD32 werkt en dan de threads in twee delen verdeeld.
Ik zou ook denken dat als AMD een SIMD32 zou kunnen verdelen in twee SIMD16, ze dit zouden zeggen.

Ik kan het nu ook niet vinden. Dat is wel wat ze doen voor wave64. Ze raden aan om "gewoon" in thread groups van 64 te blijven programmeren, want dan blijf je backward compatible met GCN. Zij maken daar vervolgens "gewoon" () 2 wave32's van. Zolang je je actieve threads groepeert (branches), slaan zij de inactieve threads ook over en zetten ze de tweede SIMD aan de ándere branch, om zo occupancy te behouden. Ik dacht dat ze dat ook binnen een wave32 konden doen, maar ik kan het nu niet vinden dus zal wel niet

---

Paprika schreef op woensdag 27 juli 2022 @ 10:39:
[...]

Ook dan is de vraag of er gesprekken zijn geweest. Als ze niet met Nvidia hebben gepraat, dan weet je ook niet of ze niet andere partijen evenveel rechten zouden geven.

Zolang AMD niet zegt waarom niet, is het allemaal vissen op basis van aannames. Sowieso zijn ownership discussies onzinnig, gezien de MIT license. De code is gewoon voor eeuwig te fokken:
https://github.com/NVIDIA...ine/blob/main/license.txt

Dat betekent helemaal niets

De Linux drivers zijn ook "open source", met MIT license. Maar er zit nog steeds een blob onder waar je niets mee kunt of mag en dat is bij Streamline ook het geval.

De enige vraag is of het niet GFX-API gedreven zou moeten zijn (DirectX, Vulkan, ...) of zelfs engine gedreven, maar schijnbaar vinden 2 van de 3 vendors voor alsnog van niet.

Intel moeten we nog zien. Ze hebben wel "ja" gezegd, maar gezien XeSS nog steeds niet in het wild is gespot moeten we dat nog maar af wachten

Het probleem is verder niet het idee van Streamline, maar de manier waarop het gebracht wordt. Het is een API die rondom Nvidia's blobs is gebouwd, waarbij die blobs ook in het repo zitten. Vervolgens vereist de daadwerkelijke implementatie van een "plugin" alsnog plugin-specifieke checks en integratie. Nu zullen plugins vergelijkbaar zijn voor vergelijkbare features, maar de winst voor devs is nu al grotendeels weg. Als ze er serieus over waren geweest, hadden ze op z'n minst een voorbeeld voor bijvoorbeeld FSR1 gemaakt. Het is gewoon niet vendor-agnostisch. Je doet niet dit:

code:

uint32_t adapterBitMask = 0;
if (slIsFeatureSupported(sl::Feature::eFeatureAdvancedUpscaling, sl::Vendor::Nvidia::DLSS | sl::Vendor::GPUOpen::FSR2 | SL::Vendor::Intel:XeSS, &adapterBitMask))
{
    // Interface implementatie
}

Maar dit (rechtstreeks uit hun voorbeelden):

code:

uint32_t adapterBitMask = 0;
if(!slIsFeatureSupported(sl::Feature::eFeatureDLSS, &adapterBitMask))
{
    // DLSS is not supported on the system, fallback to the default up-scaling method
}

Je moet dus alsnog ondersteuning voor elke "feature" controleren en expliciet implementeren. In theorie zou je een plugin kunnen schrijven die als wrapper voor DLSS, FSR en XeSS fungeert - maar Nvidia heeft niet eens een poging daartoe gedaan. Ik kijk naar dat repo en zie niets meer dan een marketing tool voor Nvidia's technieken. Ik weet ook niet helemaal wat de runtime performance hiervan is, maar er zit zo te zien aardig wat overhead in (niet in het minst omdat alles via DLL's gebeurt).

Wat engines betreft hebben ze (Nvidia, AMD en hoogstwaarschijnlijk ook Intel) al lang plugins voor UE en Unity voor veel van hun features. Streamline biedt 0,0 meerwaarde over die plugins als je die engines al gebruikt. En daarom hebben geen van hen hierover gerept. Even los van Epic's eigen TSR bijvoorbeeld.

En als laatste: "Hardware Vendor #3"? Dat is gewoon kinderachtig, noem ze gewoon bij naam. AMD heeft daar geen moeite mee en als je ook door de verschillende SDK's van beide neust zul je zien dat AMD gewoon Nvidia optimalisaties in hun SDK's heeft (FSR2 slaat FP16 bijvoorbeeld over op Nvidia omdat dat voor lagere occupancy zorgt), maar andersom zul je dat niet vinden.

Overigens is God of War een AMD titel

[Paprika]

Sp3ci3s8472 schreef op woensdag 27 juli 2022 @ 12:00:
[...]
Beetje jammer, je zit hier net zo lang als ik op het forum en in meer dan 9 van de 10 keer onderbouw ik mijn argumenten met een bron. Nu heb ik dit als waar overgenomen van een video; dus ja ik kan fout zitten. Daarnaast ben ik de laatste jaar veel neutraler geworden op het gebied van hardware vendors, AMD zal vaak nog mijn voorkeur hebben maar dat komt ik dat ik een groot voorstander ben van Linux en open source. Dat is iets wat bij AMD veel meer leeft dan bij Nvidia; sla Phoronix er maar eens op open. Daarnaast heeft AMD zich tot nu toe nog steeds netter gedragen in de concurentie strijd dan Intel en Nvidia; waar ik bij Intel momenteel wel meer positieve stappen zie.

Ik lees hier niet meer dagelijks, omdat (zie mijn laatste post hier) ik de belangrijkste toepassing van de producten waar we in dit deel van het forum over discussiëren de afgelopen jaren niet meer heb gevonden: relevante games. Mag ik het verwijten aan mijn slechte timing gevolgd door excuses ?

Sp3ci3s8472 schreef op woensdag 27 juli 2022 @ 12:00:
Laatste punt wat waarschijnlijk nog zwaarder weegt dan jou reden is dat AMD de consoles heeft.

Daarmee wint AMD zeker een grote markt. Wanneer ik puur naar de resultaten van de Steam survey kijk (en dus pc-first), dan valt de verhouding Nvidia vs AMD mij nog altijd wat tegen. Zowel wat betreft alle DX12 compatible GPUs als wanneer ik alleen op "RTX" filter en dit vergelijk met de AMD percentages.

Qua nieuws zal AMD voorlopig, zoals al heel wat jaren, nog wel even interessanter blijven, want de Nvidia kant van het verhaal blijft eentonig, voorspelbaar en behalve discutabele geruchten over cijfers niet interessant.

Sp3ci3s8472 schreef op woensdag 27 juli 2022 @ 12:07:
[...]

Nu programeer ik voornamelijk in C# maar, als je op een generieke extra parameters meeleverd moet je die casten wat een overhead geeft.

In native talen speelt dit sowieso niet, want gecompileerde code deelt of alleen een pointer naar het object of waardes worden altijd compileert naar simpele waardes zoals integers (denk aan enums).

Werelds schreef op woensdag 27 juli 2022 @ 12:17:
[...]
Je moet dus alsnog ondersteuning voor elke "feature" controleren en expliciet implementeren. In theorie zou je een plugin kunnen schrijven die als wrapper voor DLSS, FSR en XeSS fungeert - maar Nvidia heeft niet eens een poging daartoe gedaan. Ik kijk naar dat repo en zie niets meer dan een marketing tool voor Nvidia's technieken. Ik weet ook niet helemaal wat de runtime performance hiervan is, maar er zit zo te zien aardig wat overhead in (niet in het minst omdat alles via DLL's gebeurt).

Ik heb hier niet naar gekeken, maar dat had voorheen ook niemand gedaan, dus waarschijnlijk is dit inderdaad als Nvidia-only POC gebouwd. Dat zegt alleen nog niet veel over het initiatief en de beweegredenen.

edit:

C++:

uint32_t adapterBitMask = 0;
if(!slIsFeatureSupported(sl::Feature::eFeatureNIS, &adapterBitMask))
{
    // NIS is not supported on the system, fallback to the default upscaling or sharpening method
}
// Now check your adapter
if((adapterBitMask & (1 << myAdapterIndex)) != 0)
{
    // It is ok to create a device on this adapter since feature we need is supported
}

Er is dus geen eenzijdige interface die alles oplost, maar dan hoeven we ook niet te praten over API calls die niet mogelijk hoeven te zijn. Laten we het er voor nu op houden dat de implementatie vast wel wat verbeteringen kan gebruiken.

Werelds schreef op woensdag 27 juli 2022 @ 12:17:
[...]
Wat engines betreft hebben ze (Nvidia, AMD en hoogstwaarschijnlijk ook Intel) al lang plugins voor UE en Unity voor veel van hun features. Streamline biedt 0,0 meerwaarde over die plugins als je die engines al gebruikt. En daarom hebben geen van hen hierover gerept. Even los van Epic's eigen TSR bijvoorbeeld.

Zoals ik al zei: de discussie zou voor mij eerder zijn of je dit wel buiten de engines en ook nog eens buiten de APIs wil oplossen, maar misschien waren de heren van AMD wel erg onvoorbereid het gesprek aangegaan, want hun antwoorden scoren geen punten in het filmpje.

Werelds schreef op woensdag 27 juli 2022 @ 12:17:
[...]
Overigens is God of War een AMD titel

Tot zover mijn kennis van games dit decennium .

[ Voor 7% gewijzigd door Paprika op 27-07-2022 12:35 ]

[XanderDrake]

DaniëlWW2 schreef op woensdag 27 juli 2022 @ 11:52:
En dat is uiteindelijk ook het hele punt. DLSS 2.0 is een gesloten standaard die Nvidia gebruikt als verkoopargument. Dat ze nu met een open source platform komen om DLSS te implementeren, heeft niks te maken met DLSS 2.0 open source maken en alles met DLSS 2.0 alsnog in games proberen te krijgen zodat het geen dode technologie word. Dit omdat FSR 2.0 er nu ook is en veel aantrekkelijker is voor developers om te implementeren. Want het werkt op een veel grotere installatiebasis dan DLSS ooit zal halen. Hierin heeft AMD niks te winnen door een Nvidia branded tool te gaan promoten terwijl je FSR 2.0 ook kan implementeren met een handleiding van AMD en het daarbij kan laten.

Ik hoop dat dit klopt. Ik ben ook meer voor open standaarden want daarmee ondersteun je ook legacy hardware, etc etc.

Maar wat als Nvidia iets doet met zijn Tensor cores in DLSS2.3 waardoor het al die artifacts en ghosting effecten onderdrukt die we in DLSS 1.0 en FSR 2.0 op lagere resoluties zien terug komen? Dan maakt het niet uit of het open of closed source is, want dan gaat het over hardware.

[DaniëlWW2]

Werelds schreef op woensdag 27 juli 2022 @ 12:17:
[...]

Ik kan het nu ook niet vinden. Dat is wel wat ze doen voor wave64. Ze raden aan om "gewoon" in thread groups van 64 te blijven programmeren, want dan blijf je backward compatible met GCN. Zij maken daar vervolgens "gewoon" () 2 wave32's van. Zolang je je actieve threads groepeert (branches), slaan zij de inactieve threads ook over en zetten ze de tweede SIMD aan de ándere branch, om zo occupancy te behouden. Ik dacht dat ze dat ook binnen een wave32 konden doen, maar ik kan het nu niet vinden dus zal wel niet

Dat dacht ik dus ook.
Maar voor mij is dit ook interessant omdat uit Linux patches dus gehaald is dat RDNA3 een single issue wave64 modus krijgt bovenop wave32 modi. SIMD32 zal dus blijven. Ik vermoed dan ook dat AMD in RDNA3 het mogelijk gaat maken om een wavefront van 64 threads klaar te zetten voor twee SIMD32 waarna beide SIMD32's hieraan beginnen. De truc is dat ik vermoed dat ze type instructies gaan uitsplitsen en een thread haar serie aan instructies niet meer gebonden zijn aan een SIMD32. Dat zou impliceren dat de eerste SIMD32 in principe door kan blijven gaan met FP32 en de tweede SIMD32 gebruikt kan worden voor andere berekeningen om occupency percentages nog verder te verhogen.
Dus bijvoorbeeld:
Instructielijn 1: Alles FP32.
Instructielijn 2: Oh hier zitten twee INT32 instructies tussen waarbij een alternatief gecodeerd is --> branching.
Instructielijn 3: Wederom een paar.
Instructielijn 4: Oh het zijn er nu wel een aantal, een van de SIMD32s gaat even een cycle naar INT32.

Dit in plaats van wat je nu hebt met een wavefront32 op een SIMD32 die af en toe moet switched naar een ander type instructie, waardoor de FP32 berekeningen even stil komen te liggen. En voor wave64 waar AMD nog steeds een zekere voorkeur voor lijkt te hebben, gebeurd dit nu tweemaal omdat wave64 nu in 2x wavefront32 word omgezet. Want als je die andere type instructies beter kan verzamelen en overhevelen naar een SIMD32, dan gaat je occupency nog verder omhoog.

Dat is wat ik denk dat AMD van plan is. Dit gecombineerd met waarschijnlijk nog betere decoding en compiling van draw calls naar specifiek wave32 of wave 64 (welke het meest efficient is), is wat ze denk ik zeker een deel van wat ze bedoelen met Rearchitected CU en Optimised Graphics Pipeline.

XanderDrake schreef op woensdag 27 juli 2022 @ 13:08:
[...]

Ik hoop dat dit klopt. Ik ben ook meer voor open standaarden want daarmee ondersteun je ook legacy hardware, etc etc.

Maar wat als Nvidia iets doet met zijn Tensor cores in DLSS2.3 waardoor het al die artifacts en ghosting effecten onderdrukt die we in DLSS 1.0 en FSR 2.0 op lagere resoluties zien terug komen? Dan maakt het niet uit of het open of closed source is, want dan gaat het over hardware.

Ik vermoed dat Nvidia met hun tensor cores gewoon veel meer rekenkracht heeft om bepaalde effecten te verminderen. Maar de verschillen zijn niet zo enorm en Nvidia heeft erg veel tijd genomen om hun ghosting problemen te minimaliseren. Dat gaat nog wel minder worden met FSR 2.x denk ik.

Komt bij dat RDNA3 ook bepaalde matrix instructies gaat ondersteunen. Ik vermoed dan ook dat AMD iets van een matrix core gaat introduceren binnen een WGP en dan is de eerste implicatie waarschijnlijk een versnelling voor FSR. FSR 2.0 zal legacy ondersteuning blijven houden op ALU's vanwege RDNA1/2, APU's, consoles en natuurlijk Nvidia, maar ik denk dat ze wel iets van plan zijn qua versnelling van FSR berekeningen. Want nu krijg je een beetje het effect dat FSR 2.0 heel dichtbij DLSS 2 komt, maar met minder framerate winst. En ik denk zo dat ze dit ook willen gaan dichten.

[XanderDrake]

DaniëlWW2 schreef op woensdag 27 juli 2022 @ 13:21:
Want nu krijg je een beetje het effect dat FSR 2.0 heel dichtbij DLSS 2 komt, maar met minder framerate winst. En ik denk zo dat ze dit ook willen gaan dichten.

Dicht bij DLSS 2.0? Misschien op 4k, maar in games op lagere resoluties en bij normale (1080p) resoluties met veel beweging is FSR 2.0 niet dicht bij DLSS 2.0, hoor.
En gebruikmakend van die resoluties heb je vooral de minder krachtige systemen zoals laptop APU's, de Steam Deck en de Xbox series S. Dan wil je juist ook compatible FSR 2.0 blijven gebruiken, want legacy support is handig bij toekomstige zwaardere games.

[sunsmountain]

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:
Muur tijd!

Dank je! Met al 5 likes op je post, denk ik dat de lezers hier veel van je leren inclusief mijzelf. Een muur van tekst is voor mij geen probleem, en als je het gevoel hebt dat je de discussie met mij ervaart als het beuken van je hoofd tegen een muur, laat het me vooral weten (via pb'tje of zo).

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:
Nvidia heeft vooral meer omdat ze meer cycles nodig hebben voor warps en dus dingen langer in cache moeten houden, wat betekent dat ze meer ruimte moeten laten voor verschillende threads. Met GCN4 bedoel ik overigens enkel dat dit inmiddels de 4e evolutie van grofweg dezelfde opzet is van Nvidia, niet dat het allemaal verder vergelijkbaar is. Van Maxwell naar Ampère is niet echt een grotere stap dan van GCN1 naar GCN4.

Eens, wat dan in hun strategie ook betekent dat Nvidia minder vaak dingen naar die cache hoeft te schrijven. Waar ik naartoe wil is een volgende soort begrip: Als Nvidia 2x zoveel ALU operaties doet, maar 30% gaat verloren aan data die er niet op tijd is (latency, cache management), en 30% gaat verloren aan INT32 instructies waar de FP32 ALU's niks mee kunnen, dan doen ze nog altijd 1,4x zoveel (nuttige) operaties.

In vergelijking tussen de 6900XT en de 3080 Ti, weten we dat de relatieve game performance van 1 DCU/WGP in RDNA2, vergelijkbaar is 2 SM's in Ampere. Je schreef een aantal posts terug:

Dat is juist waardoor game performance bepaald wordt. AMD gooit 80 wave32's naar een DCU, Nvidia gooit 64 warps naar een SM.

Dus hoeveel nuttige operaties er uiteindelijk op die warps/waves worden uitgevoerd door de ALU's, voor een game workload, bepaalt de performance. (Die ik probeer te begrijpen zodat ik die beter kan voorspellen voor RDNA3 en Lovelace.)

Als verder het enige verschil kloksnelheid is, verlies door branching buiten beschouwing (omdat ze er allebei last van hebben), nemen even aan dat de RDNA2 units 100% nuttige operaties doen, kunnen we schatten, dat:

• (6900XT) 5120 shading units, 2250 MHz boost clock = 11,52 T nuttige OPs
• (3080 Ti) 10240 shading units, 1665 MHz boost clock = 11,52 T nuttige OPs (67,6%) van de 17,05 T theoretische OPs.

Terugrekenen komt dat neer op 6918 shading units Ampere die equivalent zijn met 5120 RDNA2 shading units. 2 SM's doen dan 35% meer nuttige operaties dan 1 DCU of WGP.

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:
Goed, dan gaan we nu maar even een stapje verder, waarbij ik me in zal proberen te houden. Maar ik merk dat ik te veel geprobeerd heb alles te versimpelen, met name rondom cycles maar ook rondom instructies en hoe alles verwerkt wordt. Ik zal alsnog kort door de bocht gaan, want anders krijg ik een ban voor het overflowen van het forum

Laat ik eerst maar met de deur in huis vallen: dat "in X cycles" verhaal zoals wij het hier vaak zeggen, is niet hoe het daadwerkelijk werkt
Ik heb me daar vooral bij gehouden, omdat de meesten denken dat dat zo werkt en het qua theoretische throughput aardig dicht in de buurt komt. Hoe GPU's (en hun drivers!) dat in de praktijk doen is echter geheel anders.

Op het niveau van 1 cycle of 1 ALU is dat inderdaad niet hoe het werkt, maar op het totale niveau van een GPU, zullen de benodigde ALU operaties toch echt binnen een bepaald aantal cycles voltooid moeten worden. Hoe het verder ook "daadwerkelijk werkt".

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:
Wat verder belangrijk is om te weten (en in je achterhoofd te houden) bij het onderstaande, is dat instructies voor datatypes gescheiden zijn. Optellen is bijvoorbeeld FADD voor floating point en IADD voor integers, of iets in die trant. In Nvidia's PTX ISA (is een niveau boven de daadwerkelijke GPU ISA) heb je bijvoorbeeld add.f32, add.u32 en add.s32 voor 32-bit floating point, unsigned integer en signed integers respectievelijk. Groottes anders dan 32-bits ga ik nu ook niet op in. Daarnaast moet je onthouden dat de GPU in principe aan het werk gezet wordt en de CPU (en dus OS, driver, game) er dan niet meer tussen komt; dus de GPU in z'n geheel krijgt een lijst met miljarden dingen te doen.

Precies, en daarom kan je wel kijken naar het totaal van nuttige operaties per seconde voor dezelfde gaming workload.

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:
Per SM en per DCU (die we eigenlijk WGP horen te noemen wat ik dus maar vanaf nu ga doen) is er ruimte voor maximaal 64 warps respectievelijk 80 waves (wave32 voor het gemak) - ik zal het enkel bij Ampère en RDNA houden om de vergelijking zinvol te houden. Een warp danwel wave32 is een verzameling van maximaal 32 threads. Een thread is geen thread zoals jij dat kent vanuit het OS niveau; een thread is een stuk code dat achter elkaar uitgevoerd moet worden (threads in verschillende warps kunnen echter wel bij elkaar horen). Daarom noemt AMD ze ook work-items. Een warp/wave is dus ook niet slechts een reeks van 32 instructies; het is eerder een reeks van 32 pointers naar reeksen instructies (code ). Een SM danwel WGP werkt álle toegewezen warps/waves af vóór er een nieuwe set wordt toegewezen. Er zijn nog veel meer nuances (dingen als thread blocks) die ik nu even ga negeren, ik link onderaan wel wat leesvoer als je álle details wilt weten

Een warp/wave afwerken gebeurt níet door per thread een instructie te nemen en die aan één ALU toe te wijzen. Nee, er wordt juist een instructie gekozen en die wordt voor álle threads uitgevoerd (dus maximaal 32 ALU's aan het werk, allemaal aan dezelfde instructie maar andere data...SIMD); als een thread die instructie niet heeft (bijvoorbeeld door branching; if-else in code), wordt er voor die thread in die cycle dus niets gedaan. Dat doen zowel AMD als Nvidia.

Ok, ik heb die warps en waves even goed moeten bestuderen, voordat ik er op kon antwoorden. Omdat een instructie niet altijd in 1 cycle kan worden uitgevoerd, heb je niet elke cycle volledige instructies nodig. Nvidia doet dan ook SIMT, single instruction, multiple threading. Niet SIMD.

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:
Aan Nvidia's kant worden de 64 warps voor een SM verdeeld over de 4 warp schedulers (elk met 1 dispatch unit), dus 16 warps per partitie - dit is niet flexibel, warps worden aan één partitie toegewezen en blijven daar (vandaar de L0$I per partitie). Elke cycle zal de warp scheduler in een partitie proberen één instructie voor één warp uit te delen, mits er een warp klaar is voor de volgende instructie en de ALU's vrij zijn. En nu zie je ook meteen waarom Nvidia voorheen áltijd 2 cycles nodig had voor een warp: ze hadden immers slechts 16 ALU's per dispatch unit (er waren er voorheen 2, dus beide datapaden konden aan het werk gezet worden), dus ze konden per cycle maar de helft van de threads in een warp een stap vooruit laten zetten.

Die 1 cycle per warp halen de 128 ALU's alleen in de pure FP32 modus, een modus die ze op een gaming workload niet vaak innemen. Verder kan èlke thread(instructie) uit de 16 warps gescheduled worden, het hoeft niet per se de eerste of de laatste te zijn, en is in die zin wèl flexibel.

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:
Als je een beetje mee hebt zitten rekenen, zie je ook al wat andere problemen. Het is één instructie per cycle, per partitie. Nvidia moet dus al vooraf (en dat doen ze grotendeels al in de driver/compiler!) zorgen dat ze de warps en blokken dusdanig indelen dat er per SM een relatief uniforme workload is, anders kan één partitie de andere partities blokkeren omdat de hele SM tussen "puur" en "mixed" moet schakelen.

Ik zie verschillen, maar niet per se problemen. Als de andere partities/subcores geblokkeerd worden om een INT32 operatie te doen, waarvoor een schakeling naar "mixed" nodig is, dan nog kun je zoveel mogelijk INT32 instructies uit alle 64 warps achter elkaar zetten om het aantal keer schakelen tussen "puur" en "mixed" te minimaliseren ten opzichte van de totale uitvoer cycles.

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:
Een ander punt is dat Nvidia technisch gezien in één cycle onmogelijk 64 FP32 ALU's en 64 INT32 ALU's aan het werk kan zetten. Per partitie doen ze immers slechts één instructie per cycle en dat is óf INT, óf FP. In de cycles na elkaar kan dat wel; en als de "pure" FP32 ALU's al bezig zijn en meerdere cycles nodig hebben kan het andere datapad wel gewoon aan het werk gezet worden. Maar in één cycle kan dat niet. Het beste wat Nvidia in één cycle kan schedulen is alle 4 partities 100% aan FP32 en dus 128 FP32 ops per SM (ofwel 4 warps in 1 cycle afgewerkt), óf 1-3 partities half aan FP en de resterende aan INT - wat dus betekent dat ze 2 schedule cycles per warp nodig hebben. Het is pertinent onmogelijk voor Nvidia om in één cycle 64xFP32 én 64xINT32 aan het werk te zetten, dat vereist sowieso 2 cycles - ongeacht welke warps dat uit komt. Daarom hebben ze het met Volta/Ampère ook over concurrent FP32/INT32, niet parallel (zie de Golang presentatie hieronder voor de nuance tussen die twee termen ).

Leuke video van Rob Pike (voor de Golang programmeertaal), hij legt het verschil goed uit met goffers (wangzakratten, familie van de bever) en kruiwagentjes met boeken die verbrand moeten worden, zo efficiënt mogelijk. Hij geeft echter ook aan dat concurrent (bijna) net zo krachtig kan zijn als parallel, met veel minder middelen. Immers, 4 goffers, 2 kruiwagentjes, 1 stapel boeken en 1 verbrander is minder transistors dan 4 goffers, 4 kruiwagentjes, 4 stapels boeken en 4 verbranders (maar allebei zijn ze ongeveer 4x zo snel als 1 goffer, 1 kruiwagentje, 1 stapel boeken en 1 verbrander). Ook als je de instructies niet parallel uitdeelt, je voert de operaties wel concurrent uit, dus in dezelfde tijdsperiode.

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:
Een "64+64" situatie bestaat eigenlijk dus ook niet; dat moet dan 32 + 32 + 32 + 32 zijn, uit 4 verschillende warps. Maar dan zie je ook meteen het bezetting probleem, je hebt 2 (scheduling) + 2 (uitvoering; uitgaande van instructies van 1 cycle) cycles nodig per warp en bezet elke partitie slechts voor de helft. Dat proberen ze op te lossen door in de tijd dat een datapad bezet is, het andere pad te bezetten met een andere warp (kunnen ze pas vanaf Volta en heeft enkele beperkingen). En zij proberen dit al in een heel vroeg stadium (driver) te plannen! Daarom hebben ze zo veel ALU's nodig, omdat er gewoon een te groot deel van de tijd een groot deel van de ALU's stil ligt.

Alle threads binnen 1 warp voeren dezelfde instructie uit, maar de 4 pure FP32 datapaden kunnen nog bezig zijn met een FP instructie (met 64 FP32 ALU's op 4 threads), terwijl de 4 mixed datapaden vrij zijn voor een INT32 instructie werkend op 64 INT32 ALU's en 4 andere threads, uit dezelfde 4x16 64 warps. Over meerdere cycles genomen, doet een SM dan wel degelijk (gemiddeld) 64+64 per cycle. De instructie daartoe is alleen niet in 1 cycle gegeven.

Overigens, de verschillende artikelen lezende, vraag ik me af waardoor je 2 schedule cycle en 2 uitvoer cycles apart benadrukt: het klinkt dan alsof dat bij elkaar 4 cycles aan tijd kost, maar de uitvoer cycle kan direct met de schedule cyle een instructie uit de threads uitvoeren op de ALU's, in dezelfde cycle. In de volgende cycle kan de andere instructie worden uitgedeeld, en als die instructie 1 uitvoer cycle uitvoer kost, heb je over 2 uitvoer cycles in totaal. Als je meerdere van dit soort cycles achter elkaar doet in "mixed" mode zonder te schakelen, liggen de helft van de ALU's alleen stil aan het begin en het eind van dat tijdsinterval.

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:
AMD doet dat anders. De 80 waves worden in de instructie cache van de hele WGP gezet. Zij hebben ook één scheduler per SIMD, het verschil is dat de 4 schedulers (onder andere) een enkele instructie cache delen. Elke scheduler probeert op enig moment 20 waves af te werken, ongeveer zoals de schedulers in Nvidia's SM's er 16 doen. AMD kan hier wat meer mee dan Nvidia qua samenwerking tussen SIMD's, maar voor het gemak negeren we dat nu. Om maar meteen korte metten te maken met het voorbeeld hierboven van "64+64" (dus 4 warps, waarvan 2 met FP32 en 2 met INT32, 1 cycle per instructie): 1 cycle om alle 4 in één keer te schedulen. Klaar. Ze hoeven niet zoals Nvidia de 4 delen in 2 keer te schedulen, omdat ze gewoon 32 ALU's hebben die het allemaal aan kunnen. En ze kunnen per SIMD een andere instructie (ongeacht het data type) doen, zonder de andere SIMD's daarbij te beïnvloeden (GCN kon dat per SIMD en ze zeggen over RDNA nergens dat dat veranderd is dus dat kan nog steeds; grootste verschil is dat INT32 nu native is en dus full-rate gaat).

Ok, dus ze doen de 64+64 in 1 cycle in plaats van 2. Heb je het nog steeds over 2 CU's / WGP / DCU versus 1 SM. De Ampere ALU's liggen veel minder dan de helft van de tijd stil, en daardoor doen de 80 SM's van GA102 denk ik 35% meer nuttige operaties bij een 35% lagere kloksnelheid dan de 40 DCU's van Navi21.

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:
En als laatste dan maar even terug naar eerdere voorbeelden. Allereerst een voorbeeld waarbij er één warp/wave is die INT32 doet en de rest FP32. Nvidia heeft dan nog steeds 2 schedule cycles per warp nodig. Die ene wave INT32 blokkeert de andere 3 partities voor de helft. AMD heeft daar 100% schijt aan en doet het gewoon in 1 cycle per wave. Nvidia's workaround sinds Volta zorgt mogelijk ook voor balans problemen waardoor de warps niet evenredig afgewerkt worden, dus dat is nóg iets waar ze rekening mee moeten houden.

De andere voorbeelden (4x16 FP32 + 1x16 INT32, of 4x16 + 4x16) zijn een stuk lastiger en had ik niet moeten noemen omdat het uitzonderingen zijn. Het kán in de praktijk wel voor komen met branches, maar daar wil ik nu eigenlijk niet op in gaan want dan wordt dit verhaal nog langer. Qua scheduling zal het je inmiddels wel duidelijk zijn dat beide 2 cycles nodig hebben, omdat het FP en INT binnen dezelfde partitie/SIMD is. Uitvoering is een ander verhaal; voor FP32+INT32 zal het voor beide gelijk zijn, voor zover ik weet kan AMD gewoon de andere helft van een SIMD aan een ander data type zetten (zolang het binnen dezelfde wave is). Voor andere data types wordt het veel ingewikkelder wegens data packing, even los van het feit dat branching zoals gezegd een verhaal apart is.

Al deze voorbeelden zijn niet echt realistisch voor een gaming workload. We moeten ons beperken tot een 64 FP32 + 32 INT32 achtige verdeling, het af en toe onnauwkeurige (dank!) Techspot artikel geeft wel terecht aan:

When Nvidia released Turing in 2018, they pointed out that on average about a 36% of the instructions processed by a GPU involved INT32 routines.

Dus 92 FP32 + 32 INT32 komt het dichtste bij, alle andere instructies en operaties even buiten beschouwing latende.

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:
Dit alles gezegd hebbende, zijn er nog veel meer factoren die invloed hebben. Niet alle integer ops zullen bijvoorbeeld door de "gewone" ALU's gedaan worden; beide zullen sommige dingen door andere units laten doen (en om je vraag over de scalar units te beantwoorden: ja, die units kunnen zelfs 64-bits integer aan; inclusief multiply-add). Het lezen/schrijven van data heb ik volledig genegeerd (laat staan de geheugen hiërarchie). Dan heb je ook nog SFU's voor dingen als sin/cos/tan/etc., doen ze branches anders, duurt niet elke instructie even lang, kun je je werk groeperen in workgroups/blocks op allerlei manieren en zo kan ik nog wel even door gaan. Ik heb het nog niet eens gehad over hoe AMD compute doet, of hoe beide geometry doen, hoe ze hun RT afhandelen. Of in Nvidia's geval, dat de tensor cores aan het werk zetten een cycle is waarin je de FP32/INT32 ALU's niet aan het werk zet. Er zijn zo veel dingen die ook invloed hebben op hoe de ALU's aan het werk worden gezet of blijven, daar kun je dagen over blijven lezen.

Ja al deze meuk dus, laten we buiten beschouwing. De FP32 en INT32 instructies, werkende op 32 threads per warp, met 16 of 20 warps/waves per subcore (SIMT) respectievelijk SIMD zijn al ingewikkeld genoeg.

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:
Het punt is dat de aansturing een cruciaal onderdeel is en dat je aantallen ALU's onmogelijk tussen de twee kan vergelijken. Sterker nog, die aantallen zijn tussen RDNA en GCN al niet meer te vergelijken (zie Navi 10 vs Vega), laat staan tussen de fabrikanten.

Directe vergelijking van ALU's is niet mogelijk, maar je kunt ze wel beoordelen op het aantal nuttige operaties dat ze (per seconde) uitvoeren op een gaming workload.

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:
Nvidia heeft ook zo veel units nodig omdat hun aansturing zo verrekte lastig is en ook niet zo eenvoudig op te lossen is (wat ik ze nog wel zie doen voor Lovelace is terug naar 2 dispatch units, één voor elk datapad). Ik hoop dat nu ook duidelijk is dat 100% bezetting volstrekt onmogelijk is (voor beide). Zelfs 100% van enkel de ALU's (alle andere units negerend) is enkel haalbaar met een compute workload die er specifiek op gericht is precies dat te doen. En hopelijk is nu ook duidelijk waarom je 1 WGP met 1 SM moet vergelijken; ongeacht het feit dat het vervolgens over 40 vs. 84 gaat op GPU niveau. Vooral voor AMD zit daar sowieso nog een niveau tussenin met shader engines. GPC's aan Nvidia's kant zijn meer voor de logische groepering, daar zit niet echt hardware aan verbonden.

Ik begrijp nu een stuk beter waardoor je 1 WGP met 1 SM vergelijkt. Ik heb ook stuk meer respect gekregen voor de driver van Nvidia, die de bovenstaande concurrent aansturing dus op zo'n manier voor elkaar krijgt, dat ze maar 32,4% van hun maximale OPs kwijt raken aan de suboptimale aansturing, gedwongen door de 1 instructie per cycle beperking, of de data die niet op de juiste plek staat. Waar AMD geen of minder last van heeft.

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:
Dan nu wat leesvoer voor als je écht diep wil gaan

- Concurrency isn't parallelism -> slides
- Whitepapers voor alle architecturen vanaf Fermi en GCN; maar vooral GCN, RDNA en Turing/Volta (independent thread scheduling) en Ampère voor het bovenstaande. Te lui om alle URLs te verzamelen, Google heeft ze zo te pakken
- Nvidia's CUDA programming en PTX docs (in de algemene CUDA docs vind je ook tuning guides, waar ook nuttige informatie in staat)
- RDNA ISA

Ik ga geen programmeur worden en al die instructies leren, maar jouw tekst heeft verder geholpen om te zoeken en warps en waves beter te begrijpen:
https://jonathan-hui.medi...architecture-3034ed685e6e
https://www.nvidia.com/co...rchitectureWhitepaper.pdf (pagina 10)
en
https://stackoverflow.com...e-hardware-warp-scheduler

Voorheen en momenteel lijkt concurrency sterker: Nvidia doet meer nuttige operaties per cycle, maar minder cycles per seconde (kloksnelheid). De nutteloze operaties (wachten, niks doen, etc.) kosten wel stroom, wat tot nu toe geen blocking issue was. Maar in de limiet van maximale stroomverbruik per GPU kàn een "pure" paralelle architectuur zoals RDNA2 en straks RDNA3 meer operaties per cycle doen èn meer cycles per seconde, doordat zij niet wordt afgeremd door die nutteloze operaties. Dat is wat het gevecht tussen RDNA3 en Lovelace zo spannend gaat maken.

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:

Vaak zat. Een SM heeft maximaal 2048 threads (64 * 32) en een WGP 2560; bedenk eens even hoeveel pixels en vertices er alleen al zijn in een frame?

En dan krijg je hier mee te maken:

[Afbeelding]

De sprong van L1 naar L2 is al erg groot (dat is eigenlijk al vanaf 64 KB; de 128 KB L1 van Nvidia is niet volledig beschikbaar tenzij je compute doet en expliciet de volle 128 KB aan zet) met 100ns (200 cycles op 2 GHz). En zoals je ziet heeft AMD nog wat meer trucjes in hoe ze met geheugen en adressen om gaan, waardoor je zelfs de L3 nog vrij lang sneller aan kan spreken dan Nvidia's L2 (!). Nu is deze test een extreem geval omdat pointer chasing het absolute worst case scenario naar boven haalt, maar AMD's geheugen en cache setup is best bijzonder. Zal Nvidia dat proberen te minimaliseren in de driver en compiler? Tuurlijk. Maar dacht je dat AMD niets doet?

Sterker nog, de beste game devs doen dit ook al vóór alles bij de compiler en driver komt. Bij het schrijven van shaders wordt vaak al nagedacht over dingen als branches, want de manier waarop je dat doet kan je zomaar twee keer zo veel cycles kosten, ook al doe je exact hetzelfde werk.

Hey, dat plaatje had ik zelf gelinkt maar eens, dat data schuiven komt vanaf 128kB vaker voor bij Ampere dan bij RDNA2. Daaronder profiteert Ampere er juist van dat ze meerdere cycles nodig hebben voor een instructie, maar daarboven niet en duurt het gewoon echt langer (met meer verloren operaties tot gevolg).

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:

Zoals je hierboven ziet zal de grootte het probleem niet echt oplossen, het betekent vooral dat de lijn ná 256 KB langer horizontaal blijft lopen.

Grootte kan bufferen, maar het probleem is natuurlijk ook dat de L1 cache voor de subcores onderverdeeld is in verschillende stukken data, die niet dezelfde L1 cache kunnen delen zoals AMD's SIMD's dat kunnen.

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:

Die linker klopt niet (slecht werk van Techspot ), dat is GP100 en hoort dus niet bij de andere twee. GP100/Volta/GA100, of GP102/TU102/GA102.

Dit is de Pascal SM (GP102 en lager):

[Afbeelding]

En uitgerekend de "IPC" is niet veranderd - althans niet per se verbeterd.

De daadwerkelijke winst in een game workload is/was beperkt tussen de generaties, door de TFLOP toename per SM, maar die lijkt er wel telkens te zijn.

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:
Maxwell en Pascal hadden 2 dispatch units per scheduler, wat betekende dat 1 scheduler 2 instructies per cycle uit kon delen. Omdat elke dispatcher aan 16 ALU's hing, betekende dat 2 warps per cycle per partitie, maar ook 2 cycles per partitie om "klaar" te zijn (dus 2 warps in 2 cycles). Turing en Ampère kunnen beide slechts 4 instructies per cycle uitdelen, echter hangt die ene dispatch unit wel aan beide datapaden. Dus waar Pascal in 1 cycle 2 sets van 16 ALU's aan het werk zette en de volgende cycle weer, om op die manier 2 warps af te werken, kunnen Turing/Ampère data soms in slechts 1 cycle. Als het puur FP32 is, hebben ze slechts 1 schedule cycle nodig voor een hele warp, wat betekent dat ze net als Pascal 2 warps in 2 cycles schedulen. Gooi je er integer tussen wordt het lastiger, want dan "verliezen" ze cycles aan het schedulen van INT. Na het schedulen van INT zou de FP kant echter vrij kunnen zijn, waardoor ze verschillende warps door elkaar heen kunnen weven. Dus zo vangen ze dat verlies van "IPC scheduling" op. Daarom heb ik ook zo'n hekel aan "IPC". Het is een volstrekt zinloze term. Nvidia's scheduling IPC is gehalveerd door het verlies van een dispatch unit per scheduler, maar hun IPC uitvoering kán in sommige gevallen hoger liggen. En in andere gevallen lager of gelijk.

Ik snap je gemis van een dispatch unit per scheduler, maar voor een gaming workload zal de IPC uitvoering gemiddeld wat hoger liggen bij Ampere dan bij Turing. Waarbij ik IPC dan maar even vertaal als die "meer nuttige operaties" per cycle.

Werelds schreef op zaterdag 23 juli 2022 @ 21:24:
Ik zou heel graag willen zien hoe een 50% grotere (5376 ALU's, 42 SM's) GP102 het uit zou houden tegenover Ampère. Als je kijkt hoe een 3080 presteert betwijfel ik ten zeerste of er voor gaming daadwerkelijk meer throughput is. Het pure FP32 datapad bestaat al uit 4352 ALU's op ~10% hogere kloksnelheid; daar heb je al pakweg een derde van de extra performance te pakken. Een 3060 met hetzelfde aantal ALU's (als GP102) in totaal (1792 + 1792) presteert net iets minder. Pascal lijkt dus niet echt moeite te hebben met die 36% INT32.

Ja, de SM's zijn gewijzigd, maar dat zijn vooral tweaks. Er is geen dramatische verandering die de fundamentele werking verandert. Niet op dezelfde manier als RDNA tegenover GCN. En de splitsing in FP32/INT32 cores lijkt ook niet veel effect gehad te hebben voor graphics. Voor compute wel, maar dat is een heel ander verhaal.

For what it's worth, hetzelfde Techspot artikel vergelijkt precies dat:

This means the likes of the GeForce RTX 3080 only has a 11% FP32 advantage over the 2080 Ti, when operating in INT+FP mode.

En ik ben het met je eens dat RDNA een stuk radicaler gewijzigd is ten op zichte van GCN. Ik zie dat voor Nvidia niet als een probleem, maar als een andere strategie. Die binnenkort kan mislukken, door thermische beperkingen van de stroom die ze daardoor nodig hebben.

Een beetje vergelijkbaar met hoe de FX5800 Ultra een stofzuiger was t.o.v. de 9700 PRO

https://www.anandtech.com/show/1062/3

Nvidia's pixel shaders konden veel meer:

https://www.anandtech.com/show/1034/4

maar ATi had als eerste 8 pixel shaders en Nvidia leerde toen dat meer performance behaald kon worden met meer maar beperktere shaders. Ik zie dezelfde filosofie terug in Nvidia's architecturen vandaag de dag. Het zou wel ironisch zijn als uitgerekend die filosofie nu weer voor een kacheltje gaat zorgen.

Sp3ci3s8472 schreef op dinsdag 17 mei 2022 @ 01:47:
Je wordt haast impotent zoveel hete lucht er langs je ballen omhoog blaast .

Het lijkt me wel verstandig om je broek aan te doen en niet precies boven je PC te gaan zitten.

[ Voor 100% gewijzigd door sunsmountain op 28-07-2022 02:00 ]

[Help!!!!]

AMD Introduces Radeon Raytracing Analyzer 1.0

'Today, the AMD GPUOpen announced that AMD developed a new tool for game developers using ray tracing technologies to help organize the model geometries in their scenes. Called Radeon Raytracing Analyzer (RRA) 1.0, it is officially available to download for Linux and Windows and released as a part of the Radeon Developer Tool Suite.
With rendering geometries slowly switching from rasterization to ray tracing, developers need a tool that will point out performance issues and various workarounds in the process. With RRA, AMD has enabled all Radeon developers to own a tool that will answer many questions like: how much memory is the acceleration structure using, how complex is the implemented BVH, how many acceleration structures are used, does geometry in the BLAS axis align enough, etc. Developers will find it very appealing for their ray tracing workloads.'

[ Voor 75% gewijzigd door Help!!!! op 28-07-2022 19:57 ]

[DaniëlWW2]

Iedereen pak de popcorn erbij, maar zorg ervoor dat die extra gezouten is.
Dit zou de hele RDNA3 line-up zijn:

Navi 31
7975XT = 96CU/48WGP/384bit bus/24GB VRAM
7950XT = 92-88CU/46-44WGP/384bit bus/24GB VRAM
7900XT = 80CU/40WGP/320bit bus/20GB VRAM

Navi 32
7800XT = 64CU/32WGP/256bit bus/16GB VRAM
7800 = 56CU/28WGP/256-192bit bus/16-12GB VRAM
7700XT = 48CU/24WGP/192bit bus/12GB VRAM

Navi 33
7600XT = 40CU/20WGP/128bit bus/8GB VRAM
7600 = 32CU/16WGP/128bit bus/8GB VRAM
7500XT = 20CU/10WGP/128-96bit bus/8-6GB VRAM

Zeker met extra zout nemen, maar er is denk ik een test om te achterhalen in hoeverre dit accuraat kan zijn. AMD werkt met RDNA1/2 met shader arrays en shader engines die uit twee arrays bestaan. Ik vermoed dat dit niet gaat veranderen. Tweede is dat AMD een array niet al te diep wil maken omdat de hardware en cache rondom de WGP's anders niet afdoende zijn.

Ergo, ik vermoed dat AMD met de overstap naar een tweemaal zo grote WGP, ook impliceert dat het aantal WGP per shader array, van vijf naar maximaal vier zal gaan. En vier komt precies uit als je gaat doorrekenen voor elke SKU behalve die "92/46" optie voor de "7950XT". Dat zou dus 88/44 moeten worden.

Daarnaast wat dingetjes:
-Navi 31 zou gepland staan voor half oktober tot november.
-Navi 31 clockspeed 3 a 3,2GHz, onduidelijk of boost of gameclock. TDP 375/450W.
-Navi 33 Q4 of 2023.
-GCN legacy features verdwijnen.

[ParaWM]

Kan niet wachten om weer bij 6 webshops in de wachtrij te gaan staan, maanden te wachten, te klagen over scalpen, wekelijkse AMD website stress te ervaren en al die discord en telegram groepen. Heb het gemist!

[sunsmountain]

DaniëlWW2 schreef op donderdag 28 juli 2022 @ 22:05:
Zeker met extra zout nemen, maar er is denk ik een test om te achterhalen in hoeverre dit accuraat kan zijn. AMD werkt met RDNA1/2 met shader arrays en shader engines die uit twee arrays bestaan. Ik vermoed dat dit niet gaat veranderen. Tweede is dat AMD een array niet al te diep wil maken omdat de hardware en cache rondom de WGP's anders niet afdoende zijn.

Ergo, ik vermoed dat AMD met de overstap naar een tweemaal zo grote WGP, ook impliceert dat het aantal WGP per shader array, van vijf naar maximaal vier zal gaan. En vier komt precies uit als je gaat doorrekenen voor elke SKU behalve die "92/46" optie voor de "7950XT". Dat zou dus 88/44 moeten worden.

Je zegt elke SKU, hoe verklaar je dan Navi33 met 20 WGP, 2 Shader Engines en 4 Shader Arrays? Dan is die toch nog steeds vijf (5) WGP per shader array?

Hij was ook niet helemaal zeker over de 92 CU, en misschien snijden ze niet per Shader Array maar per Shader Engine? Anders is 72CU van de 6800XT ook raar per SA bekeken:

Navi21 (2 CU per WGP, 2 SIMD per CU):
80 CU , 40 WGP , 4 Shader Engines , 8 Shader Arrays , 10 WGP/SE , 5 WGP/SA
72 CU , 36 WGP , 4 Shader Engines , 8 Shader Arrays , 9 WGP/SE , 4,5? WGP/SA
60 CU , 30 WGP , 3 Shader Engines , 6 Shader Arrays , 10 WGP/SE , 5 WGP/SA

Maar dan klopt de 88 CU / 44 WGP niet, je krijgt 7,33 WGP/SE.

Alle 4 CU stapjes bekeken,
Navi31 (2 CU per WGP, 4 SIMD per CU):
96 CU , 48 WGP , 6 Shader Engines , 12 Shader Arrays , 8 WGP/SE , 4 WGP/SA
?92 CU , 46 WGP , 6 Shader Engines , 12 Shader Arrays , 7,66? WGP/SE , 3,83? WGP/SA
?88 CU , 44 WGP , 6 Shader Engines , 11 Shader Arrays , 7,33? WGP/SE , 4 WGP/SA
?84 CU , 42 WGP , 6 Shader Engines , 12 Shader Arrays , 7 WGP/SE , 3,5? WGP/SA
80 CU , 40 WGP , 5 Shader Engines , 10 Shader Arrays , 8 WGP/SE , 4 WGP/SA

De 92 CU / 46 WGP blijft raar hoe je hem ook bekijkt. ^^

---

Navi31:
Keuze A: Als je uit gaat van Shader Engines (doet Navi21 ook):
96 CU , 48 WGP , 6 Shader Engines , 12 Shader Arrays , 8 WGP/SE
84 CU , 42 WGP , 6 Shader Engines , 12 Shader Arrays , 7 WGP/SE
80 CU , 40 WGP , 5 Shader Engines , 10 Shader Arrays , 8 WGP/SE

Keuze B: Hou je vast aan Shader Arrays (lijkt evenrediger verdeeld):
96 CU , 48 WGP , 6 Shader Engines , 12 Shader Arrays , 4 WGP/SA
88 CU , 44 WGP , 6 Shader Engines , 11 Shader Arrays , 4 WGP/SA
80 CU , 40 WGP , 5 Shader Engines , 10 Shader Arrays , 4 WGP/SA

---

Navi32:
Keuze A: Shader Engines
64 CU , 32 WGP , 4 Shader Engines , 8 Shader Arrays , 8 WGP/SE
56 CU , 28 WGP , 4 Shader Engines , 8 Shader Arrays , 7 WGP/SE
48 CU , 24 WGP , 3 Shader Engines , 6 Shader Arrays , 8 WGP/SE

Keuze B: Shader Arrays
64 CU , 32 WGP , 4 Shader Engines , 8 Shader Arrays , 4 WGP/SA
56 CU , 28 WGP , 4 Shader Engines , 7 Shader Arrays , 4 WGP/SA
48 CU , 24 WGP , 3 Shader Engines , 6 Shader Arrays , 4 WGP/SA

---

Navi33:
Keuze A: Shader Engines
40 CU , 20 WGP , 2 Shader Engines , 4 Shader Arrays , 10 WGP/SE
32 CU , 16 WGP , 2 Shader Engines , 4 Shader Arrays , 8 WGP/SE
20 CU , 10 WGP , 1 Shader Engines , 2 Shader Arrays , 10 WGP/SE

Keuze B: Shader Arrays
40 CU , 20 WGP , 2 Shader Engines , 4 Shader Arrays , 5 WGP/SA
32 CU , 16 WGP , 2 Shader Engines , 4 Shader Arrays , 4 WGP/SA
20 CU , 10 WGP , 1 Shader Engines , 2 Shader Arrays , 5 WGP/SA

Ik ben met je eens 88/44 dus keuze B lijkt wat logischer, dan snijden ze dit keer RDNA3 per Shader Array ipv per Shader Engine zoals bij RDNA2. En voor Navi31 en Navi32 klopt je 4 WGP per SA (niet voor Navi33).

[ Voor 14% gewijzigd door sunsmountain op 30-07-2022 19:06 ]

[Werelds]

sunsmountain schreef op donderdag 28 juli 2022 @ 01:56:
Een muur van tekst is voor mij geen probleem, en als je het gevoel hebt dat je de discussie met mij ervaart als het beuken van je hoofd tegen een muur, laat het me vooral weten (via pb'tje of zo).

Nee hoor, jij leest tenminste en hebt oprecht interesse, dat is hier door de jaren heen wel eens anders geweest

sunsmountain schreef op donderdag 28 juli 2022 @ 01:56:
Eens, wat dan in hun strategie ook betekent dat Nvidia minder vaak dingen naar die cache hoeft te schrijven. Waar ik naartoe wil is een volgende soort begrip: Als Nvidia 2x zoveel ALU operaties doet, maar 30% gaat verloren aan data die er niet op tijd is (latency, cache management), en 30% gaat verloren aan INT32 instructies waar de FP32 ALU's niks mee kunnen, dan doen ze nog altijd 1,4x zoveel (nuttige) operaties.

Dat zou met een perfecte bezetting wellicht zo zijn, maar ik zal je zometeen laten zien dat dat niet het geval is en dat Ampère juist grandioos onderbezet is.

Dus hoeveel nuttige operaties er uiteindelijk op die warps/waves worden uitgevoerd door de ALU's, voor een game workload, bepaalt de performance. (Die ik probeer te begrijpen zodat ik die beter kan voorspellen voor RDNA3 en Lovelace.)

Yep. Misschien eenvoudiger als je de ALU's even negeert en enkel naar de workloads kijkt: GA102 kan op enig moment 84 * 64 = 5376 warps in flight hebben, goed voor 172032 ops. Navi 21 daarentegen heeft 40 * 80 = 3200 waves, goed voor voor 102400 ops. Met andere woorden, AMD heeft slechts 59,5% van de capaciteit per cycle.

Als verder het enige verschil kloksnelheid is, verlies door branching buiten beschouwing (omdat ze er allebei last van hebben), nemen even aan dat de RDNA2 units 100% nuttige operaties doen, kunnen we schatten, dat:

• (6900XT) 5120 shading units, 2250 MHz boost clock = 11,52 T nuttige OPs
• (3080 Ti) 10240 shading units, 1665 MHz boost clock = 11,52 T nuttige OPs (67,6%) van de 17,05 T theoretische OPs.

Terugrekenen komt dat neer op 6918 shading units Ampere die equivalent zijn met 5120 RDNA2 shading units. 2 SM's doen dan 35% meer nuttige operaties dan 1 DCU of WGP.

Kleine nuance hierop: ALU's werken al heel lang op beide "kanten" (clocks) van een cycle; dat wil zeggen, ze voeren een op uit bij zowel de 0->1 tik, als de 1->0 tik. Technisch gezien dus 2 ops per cycle*. Specifiek voor FP komt dat ook mooi uit met (F)MA, waarschijnlijk de meest gebruikte instructie. Dat gebeurt dus wel in 1 cycle, maar is eigenlijk 2 ops en gebruikt dus 2 clocks. Dat is waarom een 6900 XT @ 2250 op 23 TF wordt gezet (11,5 * 2) en waarom Nvidia voor een 3090 Ti 40 TF op geeft (10752 * 1860 = 20 TF * 2 = 40 TF). Het maakt voor jouw rekenwerk verder niet veel uit omdat je het aan beide kanten achterwege laat.

Kloksnelheden zijn een lastig verhaal, maar je moet sowieso Nvidia's opgegeven (base/boost) kloksnelheden negeren. Geen van hun chips komt ooit in de buurt van de base clock, de boost clock is bijna de base clock. GPU's van beide fabrikanten draaien zo snel als de verschillende limieten (verbruik, temperatuur, spanning) toe laten, maar de manier waarop ze er mee adverteren is heel anders. AMD's boost clock is de gemiddelde kloksnelheid tijdens een "typical workload" (lees: graphics). Nvidia's boost clock is...uhm...niets. Hun gemiddelde kloksnelheid ligt eigenlijk standaard zo'n 120-150 MHz hoger dan de boost clock. De maxima liggen voor beide ook hoger; in dit specifieke geval (6900 XT vs 3080 Ti, laten we dan maar de FE nemen) heb je het over respectievelijk 2233 en 1780 gemiddeld (bron: TPU, gemeten over hun hele 1440p test suite). Dus dat verschil is in werkelijkheid een stukje minder.

Hoe je er vervolgens bij komt dat 2 SM's 35% meer doen snap ik niet helemaal (ze spelen juist quitte?) - en al zeker niet hoe dat positief zou zijn. Je moet juist stellen dat ze 65% meer hardware nodig hebben om even veel ops klaar te spelen. Vergeet niet dat je met 2 SM's 256 ALU's/128 warps/4096 threads hebt. Een WGP zit op 128/80/2560. Nogal wiedes dat er dus meer performance uit 2 SM's komt, maar er komt niet uit wat op papier zou moeten en er wordt dus ruimte verspild. Op hun respectievelijke kloksnelheden kan AMD met die ene WGP in theorie dus zo'n 576 miljard ops per seconde doen, waar Nvidia met 2 SM's maar liefst 911 miljard ops zou moeten kunnen doen.


* Ik hoor je al denken: liggen de ALU's soms dan niet stil als een op maar 1 clock nodig heeft? Het antwoord weten we niet zonder de logische (gate) ontwerpen van hun ALU's te zien. In theorie wel, want zowel de M als de A in (F)MA zouden in 1 clock kunnen. De ALU's zijn hoogstwaarschijnlijk echter dusdanig complex dat ze alsnog 2 clocks nodig hebben, omdat de ontwerpen geoptimaliseerd zijn voor dingen als FMA en ze de rest gewoon daar doorheen jagen.

Ok, ik heb die warps en waves even goed moeten bestuderen, voordat ik er op kon antwoorden. Omdat een instructie niet altijd in 1 cycle kan worden uitgevoerd, heb je niet elke cycle volledige instructies nodig. Nvidia doet dan ook SIMT, single instruction, multiple threading. Niet SIMD.

"Meh". Hoewel Nvidia zelf graag zegt dat ze SIMT doen en niet SIMD, is de werkelijkheid dat beide in verschillende mate SIMT toepassen op SIMD units. GPU's zijn wat dat betreft sinds programmable shaders rare beesten. Het komt uiteindelijk neer op de manier waarop ze data proberen te verwerken. Om het heel cru te stellen, Nvidia probeert alles te verwerken alsof het arrays van data zijn, terwijl AMD juist alles als vectors probeert te verwerken. Nvidia's aanpak werkt van nature heel goed voor compute werk en kán ook voor vectors werken omdat je die ook als arrays kunt verwerken. AMD's aanpak daarentegen blijft dichter bij de aard van de data en werkt van nature dus beter voor graphics. Geen van beide is goed of slecht, in de praktijk zit er maar weinig verschil in de uitvoering. Je moet het zo zien: voor een gegeven shader (software) bekijkt Nvidia hoe ze die shader zo veel mogelijk uit kunnen voeren (SIMT) en pas daarna naar de shader zelf (SIMD), terwijl AMD kijkt hoe ze de shader zo snel mogelijk uit kunnen voeren (SIMD) en pas daarna hoe ze die shader zo veel mogelijk in parallel kunnen doen (SIMT). Andere kant van dezelfde medaille

Die 1 cycle per warp halen de 128 ALU's alleen in de pure FP32 modus, een modus die ze op een gaming workload niet vaak innemen. Verder kan èlke thread(instructie) uit de 16 warps gescheduled worden, het hoeft niet per se de eerste of de laatste te zijn, en is in die zin wèl flexibel.

Correctie: niet elke thread (work-item) kan gescheduled worden; de volgende instructie voor die warp kan gescheduled worden, wat vervolgens betekent dat 1-32 threads actief zijn. Er wordt geen individue(e)l(e) thread/work-item gescheduled. Als dat gebeurt, is dat een artefact van een (pijnlijke) branch binnen die wave. Daarnaast hebben zowel Nvidia als AMD meerdere algoritmes voor het bepalen van welke wave er gekozen wordt en staat dat niet vast. Het was vroeger altijd [abbr=Loosely Round Robin]LRR[/i] (om de beurt dus) maar tegenwoordig zijn er meer opties die je als dev kunt forceren en schakelen AMD en Nvidia zelf ook intelligenter. Bij stalls slaan ze waves over en dergelijke, maar beide proberen alle toegewezen waves zo veel mogelijk in gelijke stappen vooruit te laten gaan. Ook een onderwerp waar na al die jaren nog steeds regelmatig onderzoeken over gepubliceerd worden, omdat zulke simpele aanpakken als LRR uiteraard heel erg inefficiënt worden met stalls

Het is overigens wellicht makkelijker om warps/waves ongeveer hetzelfde als een CPU thread te beschouwen; en binnen die thread zijn dan 32 ops die tegelijk uitgevoerd kunnen worden (branches en dergelijke negerend). De scheduler schakelt tussen warps, niet threads - net zoals een OS tussen (CPU) threads schakelt, niet tussen instructies binnen die thread. Misschien dat ik gewoon permanent AMD's terminologie ga gebruiken, want die is veel minder verwarrend. Nvidia's keuze voor thread is heel ongelukkig.

Ik zie verschillen, maar niet per se problemen. Als de andere partities/subcores geblokkeerd worden om een INT32 operatie te doen, waarvoor een schakeling naar "mixed" nodig is, dan nog kun je zoveel mogelijk INT32 instructies uit alle 64 warps achter elkaar zetten om het aantal keer schakelen tussen "puur" en "mixed" te minimaliseren ten opzichte van de totale uitvoer cycles.

Ja, maar dat is juist lastig om vooraf te bepalen. Als je de instructies voor een shader aan het verzamelen bent (compiler) weet je nog niet of die shader branch A of branch B gaat kiezen, dat weet je pas als de uitvoering al begonnen is.

Leuke video van Rob Pike (voor de Golang programmeertaal), hij legt het verschil goed uit met goffers (wangzakratten, familie van de bever) en kruiwagentjes met boeken die verbrand moeten worden, zo efficiënt mogelijk. Hij geeft echter ook aan dat concurrent (bijna) net zo krachtig kan zijn als parallel, met veel minder middelen. Immers, 4 goffers, 2 kruiwagentjes, 1 stapel boeken en 1 verbrander is minder transistors dan 4 goffers, 4 kruiwagentjes, 4 stapels boeken en 4 verbranders (maar allebei zijn ze ongeveer 4x zo snel als 1 goffer, 1 kruiwagentje, 1 stapel boeken en 1 verbrander). Ook als je de instructies niet parallel uitdeelt, je voert de operaties wel concurrent uit, dus in dezelfde tijdsperiode.

Ik heb nooit gezegd dat concurrency slecht is - integendeel, er zijn zat workloads waar concurrency efficiënter is, juist ook in graphics. Maar het is wel belangrijk het verschil te beseffen. Net zoals het belangrijk is om te beseffen dat GPU's zowel massively-parallel als massively-concurrent zijn, ongeacht welke fabrikant het is.

Alle threads binnen 1 warp voeren dezelfde instructie uit, maar de 4 pure FP32 datapaden kunnen nog bezig zijn met een FP instructie (met 64 FP32 ALU's op 4 threads waves), terwijl de 4 mixed datapaden vrij zijn voor een INT32 instructie werkend op 64 INT32 ALU's en 4 andere threads waves, uit dezelfde 4x16 64 warps. Over meerdere cycles genomen, doet een SM dan wel degelijk (gemiddeld) 64+64 per cycle. De instructie daartoe is alleen niet in 1 cycle gegeven.

Even een paar correcties in de terminologie gefixt in de quote.

Als partitie 1A voor warp 1 FP aan het doen is (16 ops dus), kan die niet meteen de cycle er na voor dezelfde warp een INT instructie uitdelen. Dat zou de program counter voor die warp veranderen, wat niet kan omdat de andere helft van de 32 threads nog verwerkt moet worden. Wél kan voor een andere warp de eerste helft INT ops gedaan worden, als die er zijn.

Overigens, de verschillende artikelen lezende, vraag ik me af waardoor je 2 schedule cycle en 2 uitvoer cycles apart benadrukt: het klinkt dan alsof dat bij elkaar 4 cycles aan tijd kost, maar de uitvoer cycle kan direct met de schedule cyle een instructie uit de threads uitvoeren op de ALU's, in dezelfde cycle. In de volgende cycle kan de andere instructie worden uitgedeeld, en als die instructie 1 uitvoer cycle uitvoer kost, heb je over 2 uitvoer cycles in totaal. Als je meerdere van dit soort cycles achter elkaar doet in "mixed" mode zonder te schakelen, liggen de helft van de ALU's alleen stil aan het begin en het eind van dat tijdsinterval.

Ik stel dat heel expliciet omdat de uitvoering niet per se binnen dezelfde cycle klaar is - ik had wellicht 2/2 moeten zeggen, in plaats van 2+2. De instructie an sich kan meerdere cycles kosten, maar het kan ook zijn dat de data niet aanwezig is en dat daar op gewacht moet worden. Het was vooral bedoeld als verduidelijking dat ik even uit ging van perfecte/ideale executie; single-cycle instructie met alle data present.

Ok, dus ze doen de 64+64 in 1 cycle in plaats van 2. Heb je het nog steeds over 2 CU's / WGP / DCU versus 1 SM. De Ampere ALU's liggen veel minder dan de helft van de tijd stil, en daardoor doen de 80 SM's van GA102 denk ik 35% meer nuttige operaties bij een 35% lagere kloksnelheid dan de 40 DCU's van Navi21.

In werkelijkheid liggen Ampère ALU's juist een veel groter deel van de tijd stil door de aansturing en memory layout, het ding is veel te groot en breed

Ik zal even moeten zoeken naar de blog post/het artikel, maar vorig jaar heeft iemand Superposition 8K gedraaid op een 3090, 1080 (!) en volgens mij een mobiele 1080 en dat door Nsight gehaald om te zien waar de performance verloren ging. Los van prestaties (waarbij een 3090 meer dan 2x zo snel als een 1080 is), kwamen daar wat boeiende cijfers uit. Even de snelle datapunten (SM/ALU/warps/threads): 82/10496/5248/167936 en 20/2560/1280/40960 (3090 en 1080 respectievelijk). Zo maakte de 1080 veel meer gebruik van z'n VRAM bandbreedte, en had daardoor minder TMU's bezet. Het frappante was dat beide memory-bound waren, maar op volledig andere manieren. De 3090 kwam slechts tot een SM occupancy van ik meen 30%, terwijl de 1080 op iets van 45% uit kwam. De SM's in de 3090 lagen veel te veel stil doordat er data uit de L2 of hoger moest komen. Ja, veel meer SM's en ALU's enzo, maar omdat ze bijna niets delen zijn ze veel te afhankelijk van de L2, waardoor Ampère dus op een erg lage bezetting uit komt. Theoretisch meer potentiëel, maar in de praktijk niet voor graphics.

Laat ik het eens anders stellen: voor compute is Ampère hartstikke efficiënt en effectief. Maar voor graphics overduidelijk niet, omdat de workload niet homogeen is.

Al deze voorbeelden zijn niet echt realistisch voor een gaming workload. We moeten ons beperken tot een 64 FP32 + 32 INT32 achtige verdeling, het af en toe onnauwkeurige (dank!) Techspot artikel geeft wel terecht aan:

[...]

Dus 92 FP32 + 32 INT32 komt het dichtste bij, alle andere instructies en operaties even buiten beschouwing latende.

Ah, maar dat is waar jij die 36% te letterlijk en te netjes neemt. Die 36% zullen niet zo netjes gegroepeerd zitten. Neem 4 shaders van elk exact 10 instructies gevolgd door een barrier (wat betekent dat je pas verder kan als alles verwerkt is): twee met enkel FP32, één met 2 vaste INT instructies, één met 6 INT instructies in een branch. Waar ga je die laatste shader dan vooraf schedulen, als je dus nog niet weet welke branch genomen wordt? Cluster je ze bij elkaar, dan heb je een situatie waar die clusters de vooruitgang van het hele programma op zouden kunnen houden, omdat de SM's die daar mee bezig zijn mogelijk veel langer nodig zullen hebben dan de SM's waar je de rest hebt geparkeerd. Maar misschien ook niet, als die branch helemaal nooit genomen wordt. Als je ze evenredig verdeelt krijg je alsnog een situatie waar je pech kunt hebben omdat je toevallig in een derde van je groepjes alle branches te pakken hebt, waardoor je alsnog lang moet wachten; en je zult dan groepjes krijgen waar net iets meer INT in zit omdat je ook die shader met vaste INT instructies hebt.

Dat is het probleem waar Nvidia tegenaan loopt. Ze weten vooraf niet hoeveel werk een partitie kan verzetten, omdat de beschikbare bronnen variëren. AMD weet exact wat er beschikbaar is, dat staat gewoon vast. Het is een beetje alsof Nvidia's hardware team gewoon ontwerpt wat in theorie perfect zou moeten schalen en vervolgens tegen het software team roept "regel het maar".

Ja al deze meuk dus, laten we buiten beschouwing. De FP32 en INT32 instructies, werkende op 32 threads per warp, met 16 of 20 warps/waves per subcore (SIMT) respectievelijk SIMD zijn al ingewikkeld genoeg.

Topje van de ijsberg, wat ik je dus ook duidelijk probeer te maken

Directe vergelijking van ALU's is niet mogelijk, maar je kunt ze wel beoordelen op het aantal nuttige operaties dat ze (per seconde) uitvoeren op een gaming workload.

Ja, je kunt berekenen hoeveel ops er in theorie doorheen kunnen. Dat is wat TFLOPS, TIOPS en dergelijke zijn. Maar het mag wel duidelijk zijn dat uitgerekend graphics (gaming) workloads dusdanig variëren dat die theoretische performance er voor niemand ooit ook echt uit komt. Het is voor Nvidia en AMD vooral zaak de schade te beperken en zo min mogelijk tijd te verliezen.

Ik begrijp nu een stuk beter waardoor je 1 WGP met 1 SM vergelijkt. Ik heb ook stuk meer respect gekregen voor de driver van Nvidia, die de bovenstaande concurrent aansturing dus op zo'n manier voor elkaar krijgt, dat ze maar 32,4% van hun maximale OPs kwijt raken aan de suboptimale aansturing, gedwongen door de 1 instructie per cycle beperking, of de data die niet op de juiste plek staat. Waar AMD geen of minder last van heeft.

Respect voor Nvidia's driver, of respect voor AMD's hardware?

Nvidia's driver is een heel pijnlijk stuk werk voor de programmeurs er achter, wat ook betekent dat ze daar een geweldig team hebben zitten. Bij AMD daarentegen is de hardware juist heel indrukwekkend, wat niet betekent dat hun driver niets doet, het is echter niet zo idioot veel als bij Nvidia. Ze hoeven ook niet zo extreem veel in een kristallen bol te kijken. De twee pakken het verschillend aan en ik ben van mening dat AMD's oplossing niet alleen eleganter is, maar ook effectiever. Bij de kleinere GPU's ligt het een stuk dichter bij elkaar, maar over de gehele linie tussen Ampère en Navi zet AMD meer van de theoretische performance van een chip om in daadwerkelijke performance.

Ik ga geen programmeur worden en al die instructies leren, maar jouw tekst heeft verder geholpen om te zoeken en warps en waves beter te begrijpen:
https://jonathan-hui.medi...architecture-3034ed685e6e
https://www.nvidia.com/co...rchitectureWhitepaper.pdf (pagina 10)
en
https://stackoverflow.com...e-hardware-warp-scheduler

Voorheen en momenteel lijkt concurrency sterker: Nvidia doet meer nuttige operaties per cycle, maar minder cycles per seconde (kloksnelheid). De nutteloze operaties (wachten, niks doen, etc.) kosten wel stroom, wat tot nu toe geen blocking issue was. Maar in de limiet van maximale stroomverbruik per GPU kàn een "pure" paralelle architectuur zoals RDNA2 en straks RDNA3 meer operaties per cycle doen èn meer cycles per seconde, doordat zij niet wordt afgeremd door die nutteloze operaties. Dat is wat het gevecht tussen RDNA3 en Lovelace zo spannend gaat maken.

Bedenk wel dat twee van die links over Fermi gaan; de CUDA cores hadden toen nog een FP én een INT ALU, de SM was niet gepartitioneerd maar had wel 2 schedulers/dispatchers gekoppeld aan 2 SIMD16 arrays van CUDA cores. Voor het idee van waves best, maar de uitvoering van waves is inmiddels geheel anders.

Daarnaast focus je nu weer iets te veel op concurrency vs. parallelism. Dat geldt enkel voor FP en INT binnen een partitie; op papier lijkt het alsof dat parallel kan, maar in werkelijkheid is dat dus niet zo. Maar zowel Nvidia als AMD voeren FP en INT parallel uit tussen verschillende partities/SIMD's. Ze voeren ook meerdere waves en work-items uit in parallel.

Daarnaast stel je wederom dat Nvidia meer ops per cycle doet, maar het correcte statement is dat ze dat in theorie kúnnen doen. De praktijk laat zien dat dat voor graphics niet geldt.

Grootte kan bufferen, maar het probleem is natuurlijk ook dat de L1 cache voor de subcores onderverdeeld is in verschillende stukken data, die niet dezelfde L1 cache kunnen delen zoals AMD's SIMD's dat kunnen.

Juist. Het grote probleem is gewoon dat Nvidia's L2 al meteen trager is dan dat je bij AMD's nog vrij lang de L3 aan kunt spreken. Nvidia's L1 is iets sneller (7ns), maar zodra je de L2 aanspreekt kost het 50ns meer tot aan 512 KB, en daarna alsnog ~40-45ns. Bij AMD moet je dan al richting de 64 MB (!) kijken voordat je aan die latency komt, wat gewoon bizar is - dat is al ruim in de L3. En als je die tijden dan omzet in cycles, verliest AMD met die 7ns pakweg 17-18 cycles op 2250 MHz...maar besparen ze dus ook 100-125 cycles zodra het buiten de "eigen" cache van een WGP gaat.

Ik snap je gemis van een dispatch unit per scheduler, maar voor een gaming workload zal de IPC uitvoering gemiddeld wat hoger liggen bij Ampere dan bij Turing. Waarbij ik IPC dan maar even vertaal als die "meer nuttige operaties" per cycle.

Wederom precies waarom ik zo'n hekel heb aan die term, want er is geen vaste interpretatie voor en als je hem gebruikt moet je ook specificeren wat je er mee bedoelt

FP32 IPC? INT32 IPC? Gemiddelde totale IPC? Jij benoemt nu duidelijk dat laatste, maar er zijn helaas ook genoeg mensen die enkel naar FP32 kijken.

En ik ben het met je eens dat RDNA een stuk radicaler gewijzigd is ten op zichte van GCN. Ik zie dat voor Nvidia niet als een probleem, maar als een andere strategie. Die binnenkort kan mislukken, door thermische beperkingen van de stroom die ze daardoor nodig hebben.

Een beetje vergelijkbaar met hoe de FX5800 Ultra een stofzuiger was t.o.v. de 9700 PRO

https://www.anandtech.com/show/1062/3

Nvidia's pixel shaders konden veel meer:

https://www.anandtech.com/show/1034/4

maar ATi had als eerste 8 pixel shaders en Nvidia leerde toen dat meer performance behaald kon worden met meer maar beperktere shaders. Ik zie dezelfde filosofie terug in Nvidia's architecturen vandaag de dag. Het zou wel ironisch zijn als uitgerekend die filosofie nu weer voor een kacheltje gaat zorgen.

Hah, NV30. Los van de stofzuiger, was dat "PS2.0+" verhaal een beetje als Turing. Kijk wat wij kunnen! Maar voorlopig kan niemand er iets mee want niemand heeft de hardware dus devs kunnen niets testen, gebruikers kunnen het niet gebruiken en onze hardware is ook slecht te verkrijgen. En in het geval van NV30 was het ding dus ook nog een stofzuiger én was die theoretische performance niet haalbaar. ATI kwam vervolgens 3 maanden later met RV350, maakte stilletjes gehakt van zowel NV30 als hun eigen R300 en Nvidia kwam daar pas een jaar later bij in de buurt. Een generatie later was R400 nog steeds sneller dan NV4x maar lag het tenminste weer dicht bij elkaar.

Maar nu je het ter sprake brengt, het grote probleem met NV3x was eigenlijk niet zo heel anders als nu. Het was een probleem van scheduling en data. Net zoals dat het "probleem" van AMD's TeraScale was. AMD's TeraScale kreeg ook gewoon 40% van de rekeneenheden meestal niet aan het werk gezet. Verschil was dan weer wel dat TeraScale rete-efficiënt was, waardoor zich dat niet in in een gigantische chip of een bizar verbruik uitte.


Blog post met die Superposition analyse blijf ik je nog even schuldig, moet ik even goed naar zoeken

---

Wat het snijden in GPU's betreft: dat hoeft niet op dezelfde manier over de gehele linie. Zie RX 6800, dat zijn 30 WGP's (60 CU's) in een chip met 4 SE's van 10 WGP's elk. Daar hebben ze ofwel individuele WGP's uitschakeld op asymmetrische manier (2 WGP's in 2 SE's, 3 WGP's in de andere 2 SE's) of een gehele SE.

[Paprika]

...

The leaker now claims that RX 7900 series will feature 20 Gbps memory, which is higher than previously rumored 18 Gbps. Additionally, he notes that 24 Gbps memory may appear in RX 7x50XT refresh later.

...

[Twitter: https://twitter.com/greymon55/status/1553309628196274183?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1553309628196274183%7Ctwgr%5E44d78ed5b28bf95ec305f25ed79803b64d566a1d%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fvideocardz.com%2Fnewz%2Famd-radeon-rx-7900-navi-31-series-rumored-to-feature-20-gbps-memory-launch-in-november]

https://videocardz.com/ne...memory-launch-in-november

[ Voor 20% gewijzigd door Paprika op 01-08-2022 15:35 ]

[DaniëlWW2]

Dat kan omdat Samsung als het goed is, eind vorig jaar al begon met die chips samplen.

[sunsmountain]

Werelds schreef op zondag 31 juli 2022 @ 10:25:
[...]

Nee hoor, jij leest tenminste en hebt oprecht interesse, dat is hier door de jaren heen wel eens anders geweest

Dank je. Door perspectieven naast elkaar te zetten kom je vaak tot een beter begrip, zo ook hier (voor mij).

Werelds schreef op zondag 31 juli 2022 @ 10:25:
Dat zou met een perfecte bezetting wellicht zo zijn, maar ik zal je zometeen laten zien dat dat niet het geval is en dat Ampère juist grandioos onderbezet is.

Ik heb dat verlies te weinig benadrukt, maar die 30% wachtend op data en 30% INT32 instructies zonder volledige data = juist hoe ik de enorme onderbezetting probeerde te beschrijven. We zijn het eens, zoals zal blijken.

Werelds schreef op zondag 31 juli 2022 @ 10:25:
Yep. Misschien eenvoudiger als je de ALU's even negeert en enkel naar de workloads kijkt: GA102 kan op enig moment 84 * 64 = 5376 warps in flight hebben, goed voor 172032 ops. Navi 21 daarentegen heeft 40 * 80 = 3200 waves, goed voor voor 102400 ops. Met andere woorden, AMD heeft slechts 59,5% van de capaciteit per cycle.

Komt voor mij op hetzelfde neer, en inderdaad GA102 zou 100% meer moeten kunnen (per cycle) dan Navi21, maar doet veel minder (zelfs geen 35% wat ik dacht).

Werelds schreef op zondag 31 juli 2022 @ 10:25:
Kleine nuance hierop: ALU's werken al heel lang op beide "kanten" (clocks) van een cycle; dat wil zeggen, ze voeren een op uit bij zowel de 0->1 tik, als de 1->0 tik. Technisch gezien dus 2 ops per cycle*. Specifiek voor FP komt dat ook mooi uit met (F)MA, waarschijnlijk de meest gebruikte instructie. Dat gebeurt dus wel in 1 cycle, maar is eigenlijk 2 ops en gebruikt dus 2 clocks. Dat is waarom een 6900 XT @ 2250 op 23 TF wordt gezet (11,5 * 2) en waarom Nvidia voor een 3090 Ti 40 TF op geeft (10752 * 1860 = 20 TF * 2 = 40 TF). Het maakt voor jouw rekenwerk verder niet veel uit omdat je het aan beide kanten achterwege laat.

Ah, dan had ik geluk in m'n analyse en dat streept tegen elkaar weg. Maar nu begrijp ik ook wat ze met die "double clock" bedoelen. En waarom je TFLOPS berekent door met 2 te vermenigvuldigen. Ik dacht klok * ALU's = OPs, * 2 ? ok zal wel.

Werelds schreef op zondag 31 juli 2022 @ 10:25:
Kloksnelheden zijn een lastig verhaal, maar je moet sowieso Nvidia's opgegeven (base/boost) kloksnelheden negeren. Geen van hun chips komt ooit in de buurt van de base clock, de boost clock is bijna de base clock. GPU's van beide fabrikanten draaien zo snel als de verschillende limieten (verbruik, temperatuur, spanning) toe laten, maar de manier waarop ze er mee adverteren is heel anders. AMD's boost clock is de gemiddelde kloksnelheid tijdens een "typical workload" (lees: graphics). Nvidia's boost clock is...uhm...niets. Hun gemiddelde kloksnelheid ligt eigenlijk standaard zo'n 120-150 MHz hoger dan de boost clock. De maxima liggen voor beide ook hoger; in dit specifieke geval (6900 XT vs 3080 Ti, laten we dan maar de FE nemen) heb je het over respectievelijk 2233 en 1780 gemiddeld (bron: TPU, gemeten over hun hele 1440p test suite). Dus dat verschil is in werkelijkheid een stukje minder.

Ai, en hier heb ik wat minder geluk in m'n analyse. Die 1665 MHz boost clock vervang ik bij deze door wat TPU zelf gemeten had op de 3080 Ti FE (80 SM): 1822 MHz, 1815 to 1830 MHz (Cyberpunk 2077).
https://www.techpowerup.c...-founders-edition/35.html

Dan doen de 80 SM's in de 3080 Ti FE evenredig minder, om dezelfde game performance als een 6900XT te halen (4k even buiten beschouwing, GDDR6X speelt daar teveel mee).

Werelds schreef op zondag 31 juli 2022 @ 10:25:
Hoe je er vervolgens bij komt dat 2 SM's 35% meer doen snap ik niet helemaal (ze spelen juist quitte?) - en al zeker niet hoe dat positief zou zijn. Je moet juist stellen dat ze 65% meer hardware nodig hebben om even veel ops klaar te spelen. Vergeet niet dat je met 2 SM's 256 ALU's/128 warps/4096 threads hebt. Een WGP zit op 128/80/2560. Nogal wiedes dat er dus meer performance uit 2 SM's komt, maar er komt niet uit wat op papier zou moeten en er wordt dus ruimte verspild. Op hun respectievelijke kloksnelheden kan AMD met die ene WGP in theorie dus zo'n 576 miljard ops per seconde doen, waar Nvidia met 2 SM's maar liefst 911 miljard ops zou moeten kunnen doen.

Ja, ze spelen quitte in totaal. Nee, ze spelen niet quitte per SM/CU. Als 80 SM bij 1822 MHz gelijk presteren een 80 CU bij 2250 MHz, dan moeten de SM's aan "nuttige" TOPs (FP32+IN32) 23,5% beter presteren dan de CU's. Dat is veel minder dan de 100% die de SM's op een theoretische 50%-50% FP32 INT32 workload zouden kunnen. Maar het is nog steeds, even sec genomen, meer per SM per cycle (2 clocks) dan per CU per cycle, simpelweg omdat Navi21 op een hogere clock cycle draait.

De boost frequentie van de 6900XT van 2250MHz klopt daarbij beter voor dezelfde Cyberpunk 2077: https://www.thefpsreview....ng-amd-radeon-rx-6900-xt/

Werelds schreef op zondag 31 juli 2022 @ 10:25:

* Ik hoor je al denken: liggen de ALU's soms dan niet stil als een op maar 1 clock nodig heeft? Het antwoord weten we niet zonder de logische (gate) ontwerpen van hun ALU's te zien. In theorie wel, want zowel de M als de A in (F)MA zouden in 1 clock kunnen. De ALU's zijn hoogstwaarschijnlijk echter dusdanig complex dat ze alsnog 2 clocks nodig hebben, omdat de ontwerpen geoptimaliseerd zijn voor dingen als FMA en ze de rest gewoon daar doorheen jagen.

Ik wist niet dat er 2 clocks in 1 cycle zaten, dus dat dacht ik niet. Maar ik zou inderdaad denken dat 2 clocks dan de nieuwe 1 clock worden.

Werelds schreef op zondag 31 juli 2022 @ 10:25:
"Meh". Hoewel Nvidia zelf graag zegt dat ze SIMT doen en niet SIMD, is de werkelijkheid dat beide in verschillende mate SIMT toepassen op SIMD units. GPU's zijn wat dat betreft sinds programmable shaders rare beesten. Het komt uiteindelijk neer op de manier waarop ze data proberen te verwerken. Om het heel cru te stellen, Nvidia probeert alles te verwerken alsof het arrays van data zijn, terwijl AMD juist alles als vectors probeert te verwerken. Nvidia's aanpak werkt van nature heel goed voor compute werk en kán ook voor vectors werken omdat je die ook als arrays kunt verwerken. AMD's aanpak daarentegen blijft dichter bij de aard van de data en werkt van nature dus beter voor graphics. Geen van beide is goed of slecht, in de praktijk zit er maar weinig verschil in de uitvoering. Je moet het zo zien: voor een gegeven shader (software) bekijkt Nvidia hoe ze die shader zo veel mogelijk uit kunnen voeren (SIMT) en pas daarna naar de shader zelf (SIMD), terwijl AMD kijkt hoe ze de shader zo snel mogelijk uit kunnen voeren (SIMD) en pas daarna hoe ze die shader zo veel mogelijk in parallel kunnen doen (SIMT). Andere kant van dezelfde medaille

Mooi beeld, maar ik vind de goffers met kruiwagentjes die heen en weer rennen altijd leuker. Ik hou me dan ook bij hoe ze het zelf noemen: Nvidia SIMT, AMD SIMD. Ik ben wel met je eens dat de DCU een soort SIMT doet, maar dan met veel minder verlies dan de subcores/partities van de SM.

Werelds schreef op zondag 31 juli 2022 @ 10:25:
Correctie: niet elke thread (work-item) kan gescheduled worden; de volgende instructie voor die warp kan gescheduled worden, wat vervolgens betekent dat 1-32 threads actief zijn. Er wordt geen individue(e)l(e) thread/work-item gescheduled. Als dat gebeurt, is dat een artefact van een (pijnlijke) branch binnen die wave. Daarnaast hebben zowel Nvidia als AMD meerdere algoritmes voor het bepalen van welke wave er gekozen wordt en staat dat niet vast. Het was vroeger altijd [abbr=Loosely Round Robin]LRR[/i] (om de beurt dus) maar tegenwoordig zijn er meer opties die je als dev kunt forceren en schakelen AMD en Nvidia zelf ook intelligenter. Bij stalls slaan ze waves over en dergelijke, maar beide proberen alle toegewezen waves zo veel mogelijk in gelijke stappen vooruit te laten gaan. Ook een onderwerp waar na al die jaren nog steeds regelmatig onderzoeken over gepubliceerd worden, omdat zulke simpele aanpakken als LRR uiteraard heel erg inefficiënt worden met stalls

Het is overigens wellicht makkelijker om warps/waves ongeveer hetzelfde als een CPU thread te beschouwen; en binnen die thread zijn dan 32 ops die tegelijk uitgevoerd kunnen worden (branches en dergelijke negerend). De scheduler schakelt tussen warps, niet threads - net zoals een OS tussen (CPU) threads schakelt, niet tussen instructies binnen die thread. Misschien dat ik gewoon permanent AMD's terminologie ga gebruiken, want die is veel minder verwarrend. Nvidia's keuze voor thread is heel ongelukkig.

Ah ok, dan ben je afhankelijk van de volgende instructie van de warps, of dit een FP32 of INT32 is. En die benaming threads vond ik al een beetje verwarrend, maar voor GPUs zijn de warps/waves dus wat threads zijn voor een CPU.

Werelds schreef op zondag 31 juli 2022 @ 10:25:
Ja, maar dat is juist lastig om vooraf te bepalen. Als je de instructies voor een shader aan het verzamelen bent (compiler) weet je nog niet of die shader branch A of branch B gaat kiezen, dat weet je pas als de uitvoering al begonnen is.

Vandaar dan dus de voorspellende gave van de Nvidia driver... eens.

Werelds schreef op zondag 31 juli 2022 @ 10:25:
Ik heb nooit gezegd dat concurrency slecht is - integendeel, er zijn zat workloads waar concurrency efficiënter is, juist ook in graphics. Maar het is wel belangrijk het verschil te beseffen. Net zoals het belangrijk is om te beseffen dat GPU's zowel massively-parallel als massively-concurrent zijn, ongeacht welke fabrikant het is.

Goed om te weten, aangezien Nvidia (met de SM) zeker dat concurrency pad meer bewandelt dan dat AMD (met de CU) dat doet (subcores/SIMDs even buiten beschouwing latende).

Werelds schreef op zondag 31 juli 2022 @ 10:25:
Even een paar correcties in de terminologie gefixt in de quote.

Als partitie 1A voor warp 1 FP aan het doen is (16 ops dus), kan die niet meteen de cycle er na voor dezelfde warp een INT instructie uitdelen. Dat zou de program counter voor die warp veranderen, wat niet kan omdat de andere helft van de 32 threads nog verwerkt moet worden. Wél kan voor een andere warp de eerste helft INT ops gedaan worden, als die er zijn.

Ah ok, het liefste pak je als 4 partities zijnde dan dus alle FPs uit alle warps die een FP instructie "aan de beurt" hebben, en daarna alle INTs uit alle warps die een INT instructie "aan de beurt" hebben. Vervolgens hoop je dat je niet te vaak hoeft te wisselen tijdens de warp.

Werelds schreef op zondag 31 juli 2022 @ 10:25:
Ik stel dat heel expliciet omdat de uitvoering niet per se binnen dezelfde cycle klaar is - ik had wellicht 2/2 moeten zeggen, in plaats van 2+2. De instructie an sich kan meerdere cycles kosten, maar het kan ook zijn dat de data niet aanwezig is en dat daar op gewacht moet worden. Het was vooral bedoeld als verduidelijking dat ik even uit ging van perfecte/ideale executie; single-cycle instructie met alle data present.

Met 2/2 ben ik het meer eens dan 2+2 voor het ideale geval, maar als de uitvoering niet binnen dezelfde cycle klaar is, is het al niet ideaal en kost het meer cycles (en 2x ops). Het is me nu duidelijk wat je bedoelde.

Werelds schreef op zondag 31 juli 2022 @ 10:25:
In werkelijkheid liggen Ampère ALU's juist een veel groter deel van de tijd stil door de aansturing en memory layout, het ding is veel te groot en breed

Eens! Maar dat kan een bewust keuze zijn

Werelds schreef op zondag 31 juli 2022 @ 10:25:
Ik zal even moeten zoeken naar de blog post/het artikel, maar vorig jaar heeft iemand Superposition 8K gedraaid op een 3090, 1080 (!) en volgens mij een mobiele 1080 en dat door Nsight gehaald om te zien waar de performance verloren ging. Los van prestaties (waarbij een 3090 meer dan 2x zo snel als een 1080 is), kwamen daar wat boeiende cijfers uit. Even de snelle datapunten (SM/ALU/warps/threads): 82/10496/5248/167936 en 20/2560/1280/40960 (3090 en 1080 respectievelijk). Zo maakte de 1080 veel meer gebruik van z'n VRAM bandbreedte, en had daardoor minder TMU's bezet. Het frappante was dat beide memory-bound waren, maar op volledig andere manieren. De 3090 kwam slechts tot een SM occupancy van ik meen 30%, terwijl de 1080 op iets van 45% uit kwam. De SM's in de 3090 lagen veel te veel stil doordat er data uit de L2 of hoger moest komen. Ja, veel meer SM's en ALU's enzo, maar omdat ze bijna niets delen zijn ze veel te afhankelijk van de L2, waardoor Ampère dus op een erg lage bezetting uit komt. Theoretisch meer potentiëel, maar in de praktijk niet voor graphics.

Laat ik het eens anders stellen: voor compute is Ampère hartstikke efficiënt en effectief. Maar voor graphics overduidelijk niet, omdat de workload niet homogeen is.

Ok, Superposition 8K zal geen vriendelijke workload zijn, maar ik ben het sowieso eens dat Nvidia's GA102 het veel minder goed doet met alles wat niet homogeen verdeeld is, dan wat theoretisch "verkocht" wordt.

Werelds schreef op zondag 31 juli 2022 @ 10:25:
Ah, maar dat is waar jij die 36% te letterlijk en te netjes neemt. Die 36% zullen niet zo netjes gegroepeerd zitten. Neem 4 shaders van elk exact 10 instructies gevolgd door een barrier (wat betekent dat je pas verder kan als alles verwerkt is): twee met enkel FP32, één met 2 vaste INT instructies, één met 6 INT instructies in een branch. Waar ga je die laatste shader dan vooraf schedulen, als je dus nog niet weet welke branch genomen wordt? Cluster je ze bij elkaar, dan heb je een situatie waar die clusters de vooruitgang van het hele programma op zouden kunnen houden, omdat de SM's die daar mee bezig zijn mogelijk veel langer nodig zullen hebben dan de SM's waar je de rest hebt geparkeerd. Maar misschien ook niet, als die branch helemaal nooit genomen wordt. Als je ze evenredig verdeelt krijg je alsnog een situatie waar je pech kunt hebben omdat je toevallig in een derde van je groepjes alle branches te pakken hebt, waardoor je alsnog lang moet wachten; en je zult dan groepjes krijgen waar net iets meer INT in zit omdat je ook die shader met vaste INT instructies hebt.

Ja, die 36% heb ik al moeten vervangen door 23,5% en staan inderdaad los van de gemiddelde verdeling FP32 INT32, wat inderdaad helemaal niks zegt over de daadwerkelijke verdeling.

Werelds schreef op zondag 31 juli 2022 @ 10:25:
Dat is het probleem waar Nvidia tegenaan loopt. Ze weten vooraf niet hoeveel werk een partitie kan verzetten, omdat de beschikbare bronnen variëren. AMD weet exact wat er beschikbaar is, dat staat gewoon vast. Het is een beetje alsof Nvidia's hardware team gewoon ontwerpt wat in theorie perfect zou moeten schalen en vervolgens tegen het software team roept "regel het maar".

Gelukkig heeft Nvidia een sterk software team

Werelds schreef op zondag 31 juli 2022 @ 10:25:
Topje van de ijsberg, wat ik je dus ook duidelijk probeer te maken

Dat maakt het wel leuk en interessant juist. Maar ja, ik ga wel vereenvoudigen anders kan ik er niks over zeggen.

Werelds schreef op zondag 31 juli 2022 @ 10:25:
Ja, je kunt berekenen hoeveel ops er in theorie doorheen kunnen. Dat is wat TFLOPS, TIOPS en dergelijke zijn. Maar het mag wel duidelijk zijn dat uitgerekend graphics (gaming) workloads dusdanig variëren dat die theoretische performance er voor niemand ooit ook echt uit komt. Het is voor Nvidia en AMD vooral zaak de schade te beperken en zo min mogelijk tijd te verliezen.

Duidelijk, eens.

Werelds schreef op zondag 31 juli 2022 @ 10:25:
Respect voor Nvidia's driver, of respect voor AMD's hardware?

Allebei!

Werelds schreef op zondag 31 juli 2022 @ 10:25:
Nvidia's driver is een heel pijnlijk stuk werk voor de programmeurs er achter, wat ook betekent dat ze daar een geweldig team hebben zitten. Bij AMD daarentegen is de hardware juist heel indrukwekkend, wat niet betekent dat hun driver niets doet, het is echter niet zo idioot veel als bij Nvidia. Ze hoeven ook niet zo extreem veel in een kristallen bol te kijken. De twee pakken het verschillend aan en ik ben van mening dat AMD's oplossing niet alleen eleganter is, maar ook effectiever. Bij de kleinere GPU's ligt het een stuk dichter bij elkaar, maar over de gehele linie tussen Ampère en Navi zet AMD meer van de theoretische performance van een chip om in daadwerkelijke performance.

Hoeveel je uit van theoretische performance omzet in daadwerkelijke performance, komt uiteindelijk neer op daadwerkelijke performance voor de meeste gebruikers die niets weten van theoretische performance. Ze kijken naar de FPS grafieken en denken: die koop ik.

Als ingenieur ben ik het wel met je eens dat het duurzamer is om je silicon zo efficiënt mogelijk te gebruiken, en voorstander van de aanpak van AMD.

Maar hier probeer ik door systeem-analyse en benadering een voorspelling als gamer te doen, zonder partijdigheid voor team rood of groen.

Werelds schreef op zondag 31 juli 2022 @ 10:25:

Bedenk wel dat twee van die links over Fermi gaan; de CUDA cores hadden toen nog een FP én een INT ALU, de SM was niet gepartitioneerd maar had wel 2 schedulers/dispatchers gekoppeld aan 2 SIMD16 arrays van CUDA cores. Voor het idee van waves best, maar de uitvoering van waves is inmiddels geheel anders.

Daarnaast focus je nu weer iets te veel op concurrency vs. parallelism. Dat geldt enkel voor FP en INT binnen een partitie; op papier lijkt het alsof dat parallel kan, maar in werkelijkheid is dat dus niet zo. Maar zowel Nvidia als AMD voeren FP en INT parallel uit tussen verschillende partities/SIMD's. Ze voeren ook meerdere waves en work-items uit in parallel.

Daarnaast stel je wederom dat Nvidia meer ops per cycle doet, maar het correcte statement is dat ze dat in theorie kúnnen doen. De praktijk laat zien dat dat voor graphics niet geldt.

Ik denk dat het concurrency vs. parallelism ook geldt op warps/waves binnen een SM / DCU niveau, en juist minder van belang binnen een partitie/SIMD. AMD stuurt gelijktijdig 4 warps naar 4 SIMD toe = parallel. Nvidia stuurt 1-4 FP32 òf 1-4 FP INT32 uit 4 warps naar de 4 subcores, die in dezelfde tijd maar niet tegelijkertijd = concurrent. Toch?

Nvidia doet meer ops per cycle, omdat ze bij een lagere clock cycle, dezelfde game performance neerzetten. Zie boven, 23,5% meer per cycle (met dus 76,5% verlies) per 2 SM's vergeleken met 1 DCU.

Werelds schreef op zondag 31 juli 2022 @ 10:25:

Juist. Het grote probleem is gewoon dat Nvidia's L2 al meteen trager is dan dat je bij AMD's nog vrij lang de L3 aan kunt spreken. Nvidia's L1 is iets sneller (7ns), maar zodra je de L2 aanspreekt kost het 50ns meer tot aan 512 KB, en daarna alsnog ~40-45ns. Bij AMD moet je dan al richting de 64 MB (!) kijken voordat je aan die latency komt, wat gewoon bizar is - dat is al ruim in de L3. En als je die tijden dan omzet in cycles, verliest AMD met die 7ns pakweg 17-18 cycles op 2250 MHz...maar besparen ze dus ook 100-125 cycles zodra het buiten de "eigen" cache van een WGP gaat.

En toch wint Nvidia in 4k met 6%. Zou dat komen door de overgrote hoeveelheid LD/ST operaties en GDDR6X?

Werelds schreef op zondag 31 juli 2022 @ 10:25:

Wederom precies waarom ik zo'n hekel heb aan die term, want er is geen vaste interpretatie voor en als je hem gebruikt moet je ook specificeren wat je er mee bedoelt

FP32 IPC? INT32 IPC? Gemiddelde totale IPC? Jij benoemt nu duidelijk dat laatste, maar er zijn helaas ook genoeg mensen die enkel naar FP32 kijken.

Heb je gewoon mijn benadering een nette definitie gegeven, dank je gemiddelde totale effectieve FP32+INT32 ja. Die stel je gelijk bij allebei voor gelijk presterende kaarten. Vervolgens deel je die terug door het aantal CU of SM, verrekend met de kloksnelheid. En dan krijg je hopelijk iets wat je kan extrapoleren.

Zouden Navi21 en GA102 allebei op 3 GHz draaien? Dan zou Nvidia winnen. Maar in Lovelace vs RDNA3:
192 > 144*1,235 = 177,8. Ik ben er nu minder zeker van dat AMD gaat verliezen met Navi31, ze zouden echt kunnen winnen, met 8%.

Geen rekening houdend met:

• diminishing returns voor meer CU's (192 ipv 80), meer SM's (144 ipv 80)
• het effect van sneller GDDR6X ipv GDDR6

Werelds schreef op zondag 31 juli 2022 @ 10:25:

Hah, NV30. Los van de stofzuiger, was dat "PS2.0+" verhaal een beetje als Turing. Kijk wat wij kunnen! Maar voorlopig kan niemand er iets mee want niemand heeft de hardware dus devs kunnen niets testen, gebruikers kunnen het niet gebruiken en onze hardware is ook slecht te verkrijgen. En in het geval van NV30 was het ding dus ook nog een stofzuiger én was die theoretische performance niet haalbaar. ATI kwam vervolgens 3 maanden later met RV350, maakte stilletjes gehakt van zowel NV30 als hun eigen R300 en Nvidia kwam daar pas een jaar later bij in de buurt. Een generatie later was R400 nog steeds sneller dan NV4x maar lag het tenminste weer dicht bij elkaar.

Maar nu je het ter sprake brengt, het grote probleem met NV3x was eigenlijk niet zo heel anders als nu. Het was een probleem van scheduling en data. Net zoals dat het "probleem" van AMD's TeraScale was. AMD's TeraScale kreeg ook gewoon 40% van de rekeneenheden meestal niet aan het werk gezet. Verschil was dan weer wel dat TeraScale rete-efficiënt was, waardoor zich dat niet in in een gigantische chip of een bizar verbruik uitte.

Eens, en ook een mooie vergelijking. Hun pixel shader van de NV3x toen kon teveel, net zoals een SM nu teveel ALU's heeft en daar te weinig van gebruikt in de praktijk.

---

Werelds schreef op zondag 31 juli 2022 @ 10:25:

Wat het snijden in GPU's betreft: dat hoeft niet op dezelfde manier over de gehele linie. Zie RX 6800, dat zijn 30 WGP's (60 CU's) in een chip met 4 SE's van 10 WGP's elk. Daar hebben ze ofwel individuele WGP's uitschakeld op asymmetrische manier (2 WGP's in 2 SE's, 3 WGP's in de andere 2 SE's) of een gehele SE.

De RX 6800 was juist de eerste die een Shader Engine uitschakelde, wat volgens Locuza voor AMD redelijk uniek was.

If I remember correctly AMD never disabled a whole Shader Engine before, so the 6800 configuration should be a 1st.
3 Shader Engines, 3 Rasterizer, 96 ROPs, 256-Bit GDDR6 and 128MB Last Level Cache. pic.twitter.com/at1vtQGWiZ

— Locuza (@Locuza_) 29 oktober 2020

[Werelds]

sunsmountain schreef op maandag 1 augustus 2022 @ 23:56:
Ja, ze spelen quitte in totaal. Nee, ze spelen niet quitte per SM/CU. Als 80 SM bij 1822 MHz gelijk presteren een 80 CU bij 2250 MHz, dan moeten de SM's aan "nuttige" TOPs (FP32+IN32) 23,5% beter presteren dan de CU's. Dat is veel minder dan de 100% die de SM's op een theoretische 50%-50% FP32 INT32 workload zouden kunnen. Maar het is nog steeds, even sec genomen, meer per SM per cycle (2 clocks) dan per CU per cycle, simpelweg omdat Navi21 op een hogere clock cycle draait.

Echter zijn de CU's ook slechts half zo groot als SM's wat betreft capaciteit. Half zo veel ALU's, 40 tegenover 48* waves, enzovoort en dat neem jij niet mee in je benadering, dus de vergelijking is en blijft krom. SM's en CU's zijn geen rekeneenheden. Het zijn logische clusters van rekeneenheden en volstrekt andere groeperingen daaraan toe. Prestaties per "SM" of "CU" zijn gewoon geen nuttige vergelijking

Kloksnelheid schaalt overigens ook maar hoogstzelden lineair met performance; vaak heb je 3-4% hogere kloksnelheden nodig voor 2% meer performance. Ook dat heeft weer met aansturing en workloads te maken; dat de ALU's sneller hun werk kunnen doen wil niet zeggen dat dat ook gebeurt, want je bottleneck kan elders zitten. Het is een balans spelletje. Ik zou eigenlijk wel eens willen zien wat er gebeurt als je een 6900 XT vast zet op 2 GHz of lager. Ik betwijfel of je dan even veel zakt als de vermindering in kloksnelheid.


* kleine correctie op mezelf, GA102 en "kleiner" doen slechts 48 warps per SM. Het is GA100 die nog steeds 64 doet. Het betekent dat de overcapaciteit qua waves uit m'n vorige post een stuk kleiner is, maar nog steeds in het voordeel van Nvidia.

Ah ok, het liefste pak je als 4 partities zijnde dan dus alle FPs uit alle warps die een FP instructie "aan de beurt" hebben, en daarna alle INTs uit alle warps die een INT instructie "aan de beurt" hebben. Vervolgens hoop je dat je niet te vaak hoeft te wisselen tijdens de warp.

Precies en dat moet Nvidia dus vooraf proberen te plannen. Als de warps eenmaal in de partities zitten kunnen ze er weinig meer mee.

Ok, Superposition 8K zal geen vriendelijke workload zijn, maar ik ben het sowieso eens dat Nvidia's GA102 het veel minder goed doet met alles wat niet homogeen verdeeld is, dan wat theoretisch "verkocht" wordt.

Heb hem gevonden, het was een 3090, 1080 en 1070 Max-Q
https://chipsandcheese.co...-impact-and-updated-test/

De highlights:



Geen van de drie loopt tegen een harde bottleneck aan, maar de 1080 gebruikt wel z'n geheugen meer dan de andere twee, terwijl er juist minder texture gebruik is. Maar de SM's zijn zwaar onderbenut in de 3090. Waarom? Volgende plaatje:



"Long Scoreboard" betekent dat er lang gewacht moet worden op data (cache of VRAM). Dat betekent ofwel latency, ofwel bandbreedte; bandbreedte hebben we net gezien dat niet het probleem is, dus het is latency. Je zou zeggen dat de 1080 dus vaker stil zou moeten liggen, maar vergeet niet dat de 3090 vier keer zo groot is.

Eindresultaat (weergegeven als gemiddeld aantal actieve warps per SM cycle - denk er wederom aan dat de 3090 vier keer zo groot is):



Als bonus zat er ook een geüpdate latency test in die ik vergeten was:



De test is iets anders dan voorheen in het nadeel van AMD, maar zoals je ziet is GA102 gewoon traag. Wederom: grotere L2 zal de lijn vanaf 6 MB langer door laten lopen (ligt stijgend, net als nu), maar dan nog zitten ze op AMD's "L3" niveau; de pijn zit ook vooral in de eerste paar MB, want dat komt bij graphics vaker voor.

Ik denk dat het concurrency vs. parallelism ook geldt op warps/waves binnen een SM / DCU niveau, en juist minder van belang binnen een partitie/SIMD. AMD stuurt gelijktijdig 4 warps naar 4 SIMD toe = parallel. Nvidia stuurt 1-4 FP32 òf 1-4 FP INT32 uit 4 warps naar de 4 subcores, die in dezelfde tijd maar niet tegelijkertijd = concurrent. Toch?

Bijna. Binnen een partitie moet Nvidia dat concurrently doen, maar tussen twee partities kan dat gerust in parallel - en tussen twee SM's uiteraard ook. Waves, scalar en geheugen werk doen zowel AMD als Nvidia ook in parallel. Zoals ik al zei zijn het hele fijne nuances.

* stukje meer van de ijsberg: technisch gezien doet zo'n scheduler in 1 cycle ook dingen als scalar ALU's en dergelijke aan het werk zetten. Ik zou het op moeten zoeken voor een precies antwoord, maar ik meen dat het bij AMD iets van 7 verschillende dingen zijn. Vector (compute + mem), scalar (compute + mem), branch units...en nog iets wat ik me even niet kan herinneren

SFU's daarentegen niet, die zijn volgens mij bij allebei bij het "SIMD" gedeelte geschaard. En qua geheugen toegang verschilt het ook tussen de twee door de manier waarop het aan elkaar hangt. IJsberg

Nvidia doet meer ops per cycle, omdat ze bij een lagere clock cycle, dezelfde game performance neerzetten. Zie boven, 23,5% meer per cycle (met dus 76,5% verlies) per 2 SM's vergeleken met 1 DCU.

Maar zoals ik eerder aan gaf, met het dubbele aan daadwerkelijke rekeneenheden per genomen cluster. Dat kun je niet negeren, want uitgerekend die toename is wat Ampère zo matig maakt.

Zet de 2070S eens tegenover de 3060 Ti. Nagenoeg identiek; laatste heeft 2 SM's minder, maar verder hebben ze dezelfde kloksnelheden (allebei ~1880), even veel L2, enzovoort. Verschil is dat de 3060 Ti dus 90% meer ALU's heeft, maar slechts 15% beter presteert. Leveren die 38 SM's meer dan de 40 in Turing? Zeker. Maar met bijna het dubbele aan mankracht moet er ook meer uit komen; wat er echter uit komt is waardeloos.

Uitleggen aan de hand van Go's presentatie is ook eenvoudig: wat ze met Turing hádden is één goffer die 2 stapeltjes klaar zet, met een goffer per stapel om hem te verbranden. Met Ampère hebben ze nu een 2e goffer voor één van die stapels toegevoegd, maar omdat die eerste goffer de stapeltjes niet sneller klaar kan zetten staat die nieuwe goffer alsnog 80% van de tijd stil met z'n kruiwagen. De FP32 kant is zoals slide 26, maar dan met slechts één goffer aan de linkerkant van de stapel. Het is gewoon niet in balans.

En toch wint Nvidia in 4k met 6%. Zou dat komen door de overgrote hoeveelheid LD/ST operaties en GDDR6X?

LD/ST betwijfel ik, geheugen zou kunnen. De 3080 Ti heeft bijna twee keer zo veel bandbreedte, dus als dat ergens voordeel oplevert is dat wel op 2160p

Het is verder moeilijk te zeggen zonder specifieke workloads te analyseren, zou ook best kunnen dat de bezetting voor Nvidia op lagere resoluties nóg minder is. Ik denk het niet, want het grootste verschil tussen de resoluties zullen de pixel shaders en druk op texture units zijn, maar het zou best kunnen.

Heb je gewoon mijn benadering een nette definitie gegeven, dank je gemiddelde totale effectieve FP32+INT32 ja. Die stel je gelijk bij allebei voor gelijk presterende kaarten. Vervolgens deel je die terug door het aantal CU of SM, verrekend met de kloksnelheid. En dan krijg je hopelijk iets wat je kan extrapoleren.

Zouden Navi21 en GA102 allebei op 3 GHz draaien? Dan zou Nvidia winnen. Maar in Lovelace vs RDNA3:
192 > 144*1,235 = 177,8. Ik ben er nu minder zeker van dat AMD gaat verliezen met Navi31, ze zouden echt kunnen winnen, met 8%.

En dan doet AMD, zoals een tijd geleden werd gesuggereerd, voortaan 4xSIMD32 per CU (inclusief een extra scheduler per SIMD, grotere L0 etc.), behouden ze de 40 WGP's, blijkt dat ze dat probleemloos aan kunnen sturen met de huidige 80 waves per WGP en mag die aanname de deur uit

De RX 6800 was juist de eerste die een Shader Engine uitschakelde, wat volgens Locuza voor AMD redelijk uniek was.

[Twitter]

Klopt, maar dat is het punt juist wat betreft het knippen: AMD lijkt nu meer opties dan voorheen te hebben

[DaniëlWW2]

@sunsmountain Je hebt gelijk over hoe AMD RDNA opsplitst. Niet mijn meest heldere moment.

---

Ik wou eigenlijk nog een factor extra aandragen om dit verhaal nu helemaal duidelijk te maken. Hoe snel kan een individuele Nvidia of AMD ALU, in een SIMD32, nu precies een bepaald type instructie afhandelen?

Eerst maar eens de meest voorkomende instructies.
Bij RDNA werken FP16, INT16/8/4 op hogere op/s dan native 32bit instructies. Bij Nvidia lijkt het niet verder te gaan dan elke instructie behandelen alsof die 32bit breed is. Er is geen versnelling voor FP16, INT16 etc voor een normale ALU. Elke instructie is dus 2 ops/cycle per ALU.

Je krijgt voor een RDNA SIMD32 dus:
FP32 = 2 x 32 ops/cycle
FP16 = 4 x 32 ops/cycle
INT32 = 2 x 32 ops/cycle
INT16 = 4 x 32 ops/cycle
INT8 = 8 x 32 ops/cycle
INT4 = 16 x 32 ops/cycle

Dit zijn maximale waarden (packed mode). RDNA kan immers ook bijvoorbeeld INT8 combineren met INT16 (mixed precision). Dan schikt de SIMD32 zich naar de verhoudingen om geen overflow aan instructies te krijgen die de SIMD32 niet aankan. Dat is voordeel een over Ampere.


Tweede voordeel is dat AMD hierop kan anticiperen. Zowel AMD als Nvidia nemen immers draw calls die ze ontvangen van de CPU en maken er zelf hun respectievelijk wave32/64 of Warp32 van. Wat ze daar precies doen is echt "voodoomagic" en zeker AMD gaat ze ons nooit vertellen wat ze daar precies doen. Duidelijk mag alleen wel zijn dat AMD hier een flink deel van hun occupency voordeel haalt over Nvidia. Want hier worden instructies die nodig zijn om een object te renderen, gedecodeerd en ingedeeld in threads en geclusterd in thread blocks die bestaan uit een aantal wave32/64 of Warp32. En die zullen geoptimaliseerd worden in hoeverre dit mogelijk is, om in zo weinig cycles berekend te worden. Omdat AMD haar individuele ALU, veel capabeler is en beter aangestuurd, kunnen ze waarschijnlijk ook meer doen met hun waves. Dat ze zowel wave32 als wave64 aanhouden is daarvan al een eerste indicatie. En dit is niet beïnvloedbaar door de developer, dit bepaalde de GPU zelf.

Derde voordeel is dat AMD die ALU's die eigenlijk elke relevante berekening voor graphics hebben en lagere precisie ook betekent dat ze meer ops/cycle kunnen doen. Ze hoeven zich geen zorgen te maken over lage precisie instructies, de 2x FP32 en 1x INT32 datapaden of switching problematiek.

Dat is ook een vraag waarmee ik zit. Hoe lang heeft Nvidia nu precies nodig voor een context switch? Want ik heb wat moeite om te geloven dat het de volgende cycle al gedaan is. Immers heeft Nvidia tweemaal de FP32 ALU's + een vergelijkbaar aantal dedicated INT32 ALU's. Het is heel erg veel om dan ongeveer vergelijkbaar te presteren met AMD. Tweede is dat ik me ook afvraag wat de percentages zijn van instructies zoals FP16 of INT8 in moderne games? Want die houden een Ampere GPU flink op, terwijl het voor een RDNA GPU een versnelling is.

[sunsmountain]

Werelds schreef op dinsdag 2 augustus 2022 @ 16:24:
[...]

Echter zijn de CU's ook slechts half zo groot als SM's wat betreft capaciteit. Half zo veel ALU's, 40 tegenover 48* waves, enzovoort en dat neem jij niet mee in je benadering, dus de vergelijking is en blijft krom. SM's en CU's zijn geen rekeneenheden. Het zijn logische clusters van rekeneenheden en volstrekt andere groeperingen daaraan toe. Prestaties per "SM" of "CU" zijn gewoon geen nuttige vergelijking

Money walks, b*llsh*t talks
Of het 100% eerlijk is, misschien niet. Het chip oppervlak en het aantal transistors is bijvoorbeeld verschillend. Maar voor een bepaald bedrag koop je 40 CU of 40 SM, met eenzelfde performance. Voor een hoger bedrag krijg je 80 CU of 80 SM, met eenzelfde performance.

Ik vind het daarom geen kromme vergelijking. Het is tenminste een manier om ze te kùnnen vergelijken, want wat is volgens jou het alternatief? Zelf gaf je aan 40 DCU met 80 SM fair te vinden, is dat opeens niet meer zo?

Werelds schreef op dinsdag 2 augustus 2022 @ 16:24:
Kloksnelheid schaalt overigens ook maar hoogstzelden lineair met performance; vaak heb je 3-4% hogere kloksnelheden nodig voor 2% meer performance. Ook dat heeft weer met aansturing en workloads te maken; dat de ALU's sneller hun werk kunnen doen wil niet zeggen dat dat ook gebeurt, want je bottleneck kan elders zitten. Het is een balans spelletje. Ik zou eigenlijk wel eens willen zien wat er gebeurt als je een 6900 XT vast zet op 2 GHz of lager. Ik betwijfel of je dan even veel zakt als de vermindering in kloksnelheid.

Klopt, maar dat probleem treft allebei. Ik probeer niet een exacte performance te voorspellen (is toch onmogelijk), maar meer wie er gaat winnen

Werelds schreef op dinsdag 2 augustus 2022 @ 16:24:

Heb hem gevonden, het was een 3090, 1080 en 1070 Max-Q
https://chipsandcheese.co...-impact-and-updated-test/

De highlights:

[Afbeelding]

Geen van de drie loopt tegen een harde bottleneck aan, maar de 1080 gebruikt wel z'n geheugen meer dan de andere twee, terwijl er juist minder texture gebruik is. Maar de SM's zijn zwaar onderbenut in de 3090. Waarom? Volgende plaatje:

[Afbeelding]

"Long Scoreboard" betekent dat er lang gewacht moet worden op data (cache of VRAM). Dat betekent ofwel latency, ofwel bandbreedte; bandbreedte hebben we net gezien dat niet het probleem is, dus het is latency. Je zou zeggen dat de 1080 dus vaker stil zou moeten liggen, maar vergeet niet dat de 3090 vier keer zo groot is.

Eindresultaat (weergegeven als gemiddeld aantal actieve warps per SM cycle - denk er wederom aan dat de 3090 vier keer zo groot is):

[Afbeelding]

Interessante meting, maar ik heb geen overtuiging meer nodig dat de 3090 SM's onderbezet zijn en de latency hoog: dan nog vergelijk ik 1 SM met 1 CU, vanuit game performance (niet Superposition 8K)

Werelds schreef op dinsdag 2 augustus 2022 @ 16:24:

Als bonus zat er ook een geüpdate latency test in die ik vergeten was:

[Afbeelding]

De test is iets anders dan voorheen in het nadeel van AMD, maar zoals je ziet is GA102 gewoon traag. Wederom: grotere L2 zal de lijn vanaf 6 MB langer door laten lopen (ligt stijgend, net als nu), maar dan nog zitten ze op AMD's "L3" niveau; de pijn zit ook vooral in de eerste paar MB, want dat komt bij graphics vaker voor.

Ja, dit is wel het bewijs waardoor het redesign van RDNA nodig was en slim is. Zeker als je bedenkt dat het wachten en het niks doen op een GA102 wel stroom kost. Nog even los van dat een SM maar 123,5% haalt terwijl ze 200% theoretisch zouden kunnen halen, slurpt een 3080 Ti: 350 W TDP, terwijl een 6900XT maar 300 W TDP nodig heeft. Die extra 23,5% OPs per SM kost ook 16,7% extra stroom. Naarmate de klokfrequentie hoger wordt, wordt dit alleen maar erger voor Nvidia.

Maar goed de sprong van 84 naar 144 (SM) is kleiner dan de sprong van 80 naar 192 (CU). Deze stroom factor is dan ook lastig mee te nemen in de vergelijking.

Werelds schreef op dinsdag 2 augustus 2022 @ 16:24:

Bijna. Binnen een partitie moet Nvidia dat concurrently doen, maar tussen twee partities kan dat gerust in parallel - en tussen twee SM's uiteraard ook. Waves, scalar en geheugen werk doen zowel AMD als Nvidia ook in parallel. Zoals ik al zei zijn het hele fijne nuances.

* stukje meer van de ijsberg: technisch gezien doet zo'n scheduler in 1 cycle ook dingen als scalar ALU's en dergelijke aan het werk zetten. Ik zou het op moeten zoeken voor een precies antwoord, maar ik meen dat het bij AMD iets van 7 verschillende dingen zijn. Vector (compute + mem), scalar (compute + mem), branch units...en nog iets wat ik me even niet kan herinneren

SFU's daarentegen niet, die zijn volgens mij bij allebei bij het "SIMD" gedeelte geschaard. En qua geheugen toegang verschilt het ook tussen de twee door de manier waarop het aan elkaar hangt. IJsberg

Als de pure FP32 SM partities bezig zijn met een FP32, en de mixed partities krijgen ze een INT32, doen ze zoveel mogelijk samen concurrently, per SM. Ja je stuurt 4 partities "parallel" aan, maar het verlies van cycles, zit hem in de poging de instructies concurrently te doen: dat gaat gewoon niet zo goed. De SIMDs van AMD zijn daarentegen veel flexibeler en pakken parallel verschillende of dezelfde instructies op, ze geven zoals je zei, geen f*ck. Dat klinkt mij als efficiënte parallele aansturing in de oren. Dat er binnen een SIMD concurrently instructies gecombineerd worden, kan, maar dat is niet waar de efficiëntie slag geslagen wordt als ik het goed begrijp.

Werelds schreef op dinsdag 2 augustus 2022 @ 16:24:

Maar zoals ik eerder aan gaf, met het dubbele aan daadwerkelijke rekeneenheden per genomen cluster. Dat kun je niet negeren, want uitgerekend die toename is wat Ampère zo matig maakt.

Doe ik ook niet en heb ik telkens vermeld, maar dan nog presteren de slecht presterende SM's, naar schatting 23,5% meer OPs voor een game fps, dan de flexibele CU's.

Werelds schreef op dinsdag 2 augustus 2022 @ 16:24:
Zet de 2070S eens tegenover de 3060 Ti. Nagenoeg identiek; laatste heeft 2 SM's minder, maar verder hebben ze dezelfde kloksnelheden (allebei ~1880), even veel L2, enzovoort. Verschil is dat de 3060 Ti dus 90% meer ALU's heeft, maar slechts 15% beter presteert. Leveren die 38 SM's meer dan de 40 in Turing? Zeker. Maar met bijna het dubbele aan mankracht moet er ook meer uit komen; wat er echter uit komt is waardeloos.

Eens, maar verandert niks aan de methode om performance te schatten voor de nieuwe generatie.

Werelds schreef op dinsdag 2 augustus 2022 @ 16:24:
Uitleggen aan de hand van Go's presentatie is ook eenvoudig: wat ze met Turing hádden is één goffer die 2 stapeltjes klaar zet, met een goffer per stapel om hem te verbranden. Met Ampère hebben ze nu een 2e goffer voor één van die stapels toegevoegd, maar omdat die eerste goffer de stapeltjes niet sneller klaar kan zetten staat die nieuwe goffer alsnog 80% van de tijd stil met z'n kruiwagen. De FP32 kant is zoals slide 26, maar dan met slechts één goffer aan de linkerkant van de stapel. Het is gewoon niet in balans.

Ja ze missen een dispatch goffer, ik ben met je eens dat een 2e dispatcher slim zou zijn voor Lovelace. Who knows. Maar met goffers snapt iedereen het

Werelds schreef op dinsdag 2 augustus 2022 @ 16:24:

LD/ST betwijfel ik, geheugen zou kunnen. De 3080 Ti heeft bijna twee keer zo veel bandbreedte, dus als dat ergens voordeel oplevert is dat wel op 2160p

Het is verder moeilijk te zeggen zonder specifieke workloads te analyseren, zou ook best kunnen dat de bezetting voor Nvidia op lagere resoluties nóg minder is. Ik denk het niet, want het grootste verschil tussen de resoluties zullen de pixel shaders en druk op texture units zijn, maar het zou best kunnen.

Ja ik vermoed ook een soort texture unit bottleneck, waar Ampere op de een of andere manier minder last van heeft. Misschien zijn 4k textures gewoon groot, en is de sequential read van GDDR6X gewoon beter. Dan heb je minder met latency te maken.

Werelds schreef op dinsdag 2 augustus 2022 @ 16:24:

En dan doet AMD, zoals een tijd geleden werd gesuggereerd, voortaan 4xSIMD32 per CU (inclusief een extra scheduler per SIMD, grotere L0 etc.), behouden ze de 40 WGP's, blijkt dat ze dat probleemloos aan kunnen sturen met de huidige 80 waves per WGP en mag die aanname de deur uit

Ja dat dacht ik op basis van wat Kepler in de driver zag en ik was degene die eerst zo verontwaardigd was dat "leakers de leaks niet combineren!" Maar, in de laatste geruchten van RDNA3 zie je dat het aantal CU's voor een Navi33 verlaagd zijn naar 40 CU. Betekent dat dat het geen 6900XT meer is? Nee, natuurlijk niet. Maar ik vermoed dat ze dan niet de SIMDs hebben verhoogd, zoals ik had gehoopt. Alleen anders gegroepeerd.... dus in plaats van 80 CU met 2 SIMD, 40 CU met 4 SIMD. Bij elkaar nog steeds 160 SIMD voor een Navi21 of Navi33.

Meanwhile, bij Lovelace: de kopite7kimi mijmeringen zijn geen geruchten die hij heeft opgevangen, maar zijn eigen mijmeringen: van jou geleerd. Dus dan is het meest rationele aan te nemen dat de nieuwe SM's zullen zijn als de oude SM's... hoe graag wij ook een 2e dispatcher zouden zien voor Lovelace.

Anders gezegd, ik kan helemaal niks voorspellen als de SM's of CU's inhoudelijk echt wijzigen. Maar als ze qua FP32 en INT32 hetzelfde zijn als de huidige generatie, ben ik weer een beetje voorzichtig optimistisch over RDNA3:
RDNA3 192 > 144*1,235 = 177 Lovelace... +8% voor AMD.
(was ik de vorige keer ook met +10% voor Navi21, en toen speelden ze quitte op 1080p, 1440p, maar verloren ze 4k nipt).

Werelds schreef op dinsdag 2 augustus 2022 @ 16:24:
Klopt, maar dat is het punt juist wat betreft het knippen: AMD lijkt nu meer opties dan voorheen te hebben

Ah op die manier. Ik was eerst teleurgesteld in de RX 6800 omdat ik een 64 CU knip had verwacht/gehoopt. Maar voor een goede prijs is dat ding beter dan een RTX 3070 of RX 6700XT.

[sunsmountain]

DaniëlWW2 schreef op dinsdag 2 augustus 2022 @ 21:56:
@sunsmountain Je hebt gelijk over hoe AMD RDNA opsplitst. Niet mijn meest heldere moment.

---

Ik wou eigenlijk nog een factor extra aandragen om dit verhaal nu helemaal duidelijk te maken. Hoe snel kan een individuele Nvidia of AMD ALU, in een SIMD32, nu precies een bepaald type instructie afhandelen?

Eerst maar eens de meest voorkomende instructies.
Bij RDNA werken FP16, INT16/8/4 op hogere op/s dan native 32bit instructies. Bij Nvidia lijkt het niet verder te gaan dan elke instructie behandelen alsof die 32bit breed is. Er is geen versnelling voor FP16, INT16 etc voor een normale ALU. Elke instructie is dus 2 ops/cycle per ALU.

Je krijgt voor een RDNA SIMD32 dus:
FP32 = 2 x 32 ops/cycle
FP16 = 4 x 32 ops/cycle
INT32 = 2 x 32 ops/cycle
INT16 = 4 x 32 ops/cycle
INT8 = 8 x 32 ops/cycle
INT4 = 16 x 32 ops/cycle

Dit zijn maximale waarden (packed mode). RDNA kan immers ook bijvoorbeeld INT8 combineren met INT32 (mixed precision). Dan schikt de SIMD32 zich naar de verhoudingen om geen overflow aan instructies te krijgen die de SIMD32 niet aankan. Dat is voordeel een over Ampere.
[Afbeelding]

Tweede voordeel is dat AMD hierop kan anticiperen. Zowel AMD als Nvidia nemen immers draw calls die ze ontvangen van de CPU en maken er zelf hun respectievelijk wave32/64 of Warp32 van. Wat ze daar precies doen is echt "voodoomagic" en zeker AMD gaat ze ons nooit vertellen wat ze daar precies doen. Duidelijk mag alleen wel zijn dat AMD hier een flink deel van hun occupency voordeel haalt over Nvidia. Want hier worden instructies die nodig zijn om een object te renderen, gedecodeerd en ingedeeld in threads en geclusterd in thread blocks die bestaan uit een aantal wave32/64 of Warp32. En die zullen geoptimaliseerd worden in hoeverre dit mogelijk is, om in zo weinig cycles berekend te worden. Omdat AMD haar individuele ALU, veel capabeler is en beter aangestuurd, kunnen ze waarschijnlijk ook meer doen met hun waves. Dat ze zowel wave32 als wave64 aanhouden is daarvan al een eerste indicatie. En dit is niet beïnvloedbaar door de developer, dit bepaalde de GPU zelf.

Derde voordeel is dat AMD die ALU's die eigenlijk elke relevante berekening voor graphics hebben en lagere precisie ook betekent dat ze meer ops/cycle kunnen doen. Ze hoeven zich geen zorgen te maken over lage precisie instructies, de 2x FP32 en 1x INT32 datapaden of switching problematiek.

Dat is ook een vraag waarmee ik zit. Hoe lang heeft Nvidia nu precies nodig voor een context switch? Want ik heb wat moeite om te geloven dat het de volgende cycle al gedaan is. Immers heeft Nvidia tweemaal de FP32 ALU's + een vergelijkbaar aantal dedicated INT32 ALU's. Het is heel erg veel om dan ongeveer vergelijkbaar te presteren met AMD. Tweede is dat ik me ook afvraag wat de percentages zijn van instructies zoals FP16 of INT8 in moderne games? Want die houden een Ampere GPU flink op, terwijl het voor een RDNA GPU een versnelling is.

De moderne AAA games gebruiken vooral FP32 en INT32 instructies. Dus het is mooi dat de AMD SIMD dubbele snelheid haalt op FP16, maar oudere games zijn vaak niet leading voor performance. En vaak gebruikt een game òf FP16 òf FP32, niet allebei. En het is niet alsof de FP16 performance van Ampere onderdoet.

Was het bij de draw calls niet zo dat Nvidia dit lekker neerlegt bij de CPU, en op die manier veel meer draw calls kan doen? YouTube: Intel's Alchemist Problems: Bad Drivers or Hardware Flaw? Is Battlem...
Dit blijft in DirectX 11 een gemeen voordeel van Nvidia, waar AMD dit netjes op de GPU blijft doen (Command frontend?)

En ondanks de RDNA flexibiliteit, zien we op basis van game performance dat per SM Ampere toch meer ops/cycle doet. Zo'n 23,5% meer per SM, als je game performance gelijk stelt en dan verrekent met kloksnelheid (zie mijn eerdere post).

Ampere heeft alléén tweemaal de ALU's, voor een 50% FP32 50% INT32 workload, of een 100% FP32 workload. Beide niet realistisch voor games. Ik vermoed in een SM met 4 partities:
- dat het uitvoeren van een INT32 instructie in een cycle uit de warps niet 4x16 (maximaal benut) uitgevoerd wordt, maar veel minder (misschien 2x16? 2x12?), en
- dat de partities veel meer wachten op de juiste data, wat ook cycles kost: de L0 moet tjidens een warp meer husselen om de data goed te krijgen voor de FP of INT instructies, waar de SIMDs bij AMD de data veel meer kunnen delen en hergebruiken.

[Ludewig]

Hier is een samenvatting van de informatie die AMD heeft gedeeld met investeerders, inclusief een mooie grafiek die aangeeft hoe enorm de omzet is gegroeid:

https://morethanmoore.substack.com/p/amd-financials-q2

Ze beloven Zen 4 in Q3 en de nieuwe videokaarten in Q4. Ze hebben nog steeds te weinig productiecapaciteit, maar verwachten dat dit de tweede helft van het jaar beter wordt. Daarom denken ze nog meer te gaan verkopen.

[Help!!!!]

^
Heel snel gekeken maar jammer dat ze niet (kunnen) laten zien in de grafiek ~welk deel vd omzet Xilinx overname gerelateerd is.

[ Voor 6% gewijzigd door Help!!!! op 03-08-2022 12:31 ]

[Ludewig]

Help!!!! schreef op woensdag 3 augustus 2022 @ 11:47:
^
Heel snel gekeken maar jammer dat ze niet (kunnen) laten zien in de grafiek ~welk deel Xilinx overname gerelateerd is.

1,3 miljard van de totale 6,6 miljard omzet komt van embedded en die is gigantisch gegroeid, dus dat kan je min of meer allemaal toewijzen aan Xilinx. Dus dan is nu 1/5 van de totale omzet afkomstig door Xilinx.

[ Voor 30% gewijzigd door Ludewig op 03-08-2022 12:04 ]

[Werelds]

DaniëlWW2 schreef op dinsdag 2 augustus 2022 @ 21:56:
Dat is ook een vraag waarmee ik zit. Hoe lang heeft Nvidia nu precies nodig voor een context switch? Want ik heb wat moeite om te geloven dat het de volgende cycle al gedaan is. Immers heeft Nvidia tweemaal de FP32 ALU's + een vergelijkbaar aantal dedicated INT32 ALU's. Het is heel erg veel om dan ongeveer vergelijkbaar te presteren met AMD.

In principe: niets. De switch van datapad 2 tussen FP32 en INT32 is in principe "gratis", ware het niet dat het aantal registers identiek is ten opzichte van Turing, wat het iets lastiger maakt.

Per partitie wordt voor álle waves álle data bijgehouden (doen zowel AMD als Nvidia). Dat is waar die register groottes ook op gebaseerd zijn. Probleem is echter dat ze met Ampère niet meer registers toe hebben gevoegd, maar wel meer ALU's dus de druk op de registers zal hoger zijn dan voorheen. Voor "platte" shaders zonder branches is het een no-cost op, de data is dan al aanwezig. Maar met branches kan het ze een volle load/store cyclus kosten, omdat de integer data niet voorhanden is.

Dat gezegd hebbende, zullen veel INT ops ook constanten gebruiken die bij Nvidia volgens mij sowieso niet in de registers zitten, maar dat zou ik even op moeten zoeken in de CUDA docs om zeker te weten

DaniëlWW2 schreef op dinsdag 2 augustus 2022 @ 21:56:
Tweede is dat ik me ook afvraag wat de percentages zijn van instructies zoals FP16 of INT8 in moderne games? Want die houden een Ampere GPU flink op, terwijl het voor een RDNA GPU een versnelling is.

sunsmountain schreef op dinsdag 2 augustus 2022 @ 23:47:
En vaak gebruikt een game òf FP16 òf FP32, niet allebei.

Even jullie allebei beantwoorden: FP16 wordt langzaamaan iets meer gebruikt, maar is nog heel weinig. Op Pascal is FP16 volstrekt onbruikbaar en op Maxwell en ouder wordt FP16 "opgewaardeerd" naar FP32 (1:1), dus biedt daar geen voordeel. Op Turing was er voordeel, met Ampère is dat weer weg, FP16 is weer 1:1. INT8 is te verwaarlozen.

Games gebruiken echter wel allebei. Ze gebruiken nóóit enkel FP16, er is altijd FP32. FP16 wordt ingezet voor dingen waar je simpelweg geen 24 bits aan precisie nodig hebt. Kleuren, normal maps - vooral een hoop dingen met textures. Met name in post-processing.

Dat is graphics uiteraard, compute is een heel ander verhaal

[napata]

DaniëlWW2 schreef op dinsdag 2 augustus 2022 @ 21:56:
Tweede is dat ik me ook afvraag wat de percentages zijn van instructies zoals FP16 of INT8 in moderne games? Want die houden een Ampere GPU flink op, terwijl het voor een RDNA GPU een versnelling is.

Waarom worden er geen Tensor cores gebruikt voor FP16 of INT8 bij Nvidia GPUs? Ik dacht juist dat ze daarvoor dienden.

[Werelds]

napata schreef op woensdag 3 augustus 2022 @ 19:31:
[...]

Waarom worden er geen Tensor cores gebruikt voor FP16 of INT8 bij Nvidia GPUs? Ik dacht juist dat ze daarvoor dienden.

Tensor Cores dienen voor matrix vermenigvuldiging, dus dat is iets heel anders. Die hebben 4x4 matrixes als input, niet slechts 1 FP16 waarde

[DaniëlWW2]

napata schreef op woensdag 3 augustus 2022 @ 19:31:
[...]

Waarom worden er geen Tensor cores gebruikt voor FP16 of INT8 bij Nvidia GPUs? Ik dacht juist dat ze daarvoor dienden.

Zoals Werelds al zegt.
Dat is ook meteen een van de grote kritiekpunten op Nvidia. Ze hebben heel veel fysieke rekeneenheden, maar de ondersteuning van die hardware met scheduling van instructies, caches alsmede de werkelijke capaciteiten van die hardware, vallen eigenlijk behoorlijk tegen. Het zijn eigenlijk een paar gescheiden datapaden in een SM waarbij altijd geld dat sommige iets doen, nooit dat alles iets doet.

Het stomme is ook dat vrijwel niemand dit door had gehad als Ampere niet direct tegenover RDNA2 was komen te staan. Want RDNA2 laat Ampere er gewoon slecht uitzien als je naar de details gaat kijken. Het is competitief, maar Nvidia moet het eigenlijk al van DLSS + RTX + mindshare hebben en niet omdat ze echt de betere rasterization architectuur hebben. Daarin is RDNA2 al beter over het spectrum van resoluties, in combinatie met mindere processoren, qua verbruik, regelmatig ook in frametimes etc.

[sunsmountain]

DaniëlWW2 schreef op woensdag 3 augustus 2022 @ 23:16:
[...]


Zoals Werelds al zegt.
Dat is ook meteen een van de grote kritiekpunten op Nvidia. Ze hebben heel veel fysieke rekeneenheden, maar de ondersteuning van die hardware met scheduling van instructies, caches alsmede de werkelijke capaciteiten van die hardware, vallen eigenlijk behoorlijk tegen. Het zijn eigenlijk een paar gescheiden datapaden in een SM waarbij altijd geld dat sommige iets doen, nooit dat alles iets doet.

Het stomme is ook dat vrijwel niemand dit door had gehad als Ampere niet direct tegenover RDNA2 was komen te staan. Want RDNA2 laat Ampere er gewoon slecht uitzien als je naar de details gaat kijken. Het is competitief, maar Nvidia moet het eigenlijk al van DLSS + RTX + mindshare hebben en niet omdat ze echt de betere rasterization architectuur hebben. Daarin is RDNA2 al beter over het spectrum van resoluties, in combinatie met mindere processoren, qua verbruik, regelmatig ook in frametimes etc.

Een kleine nuance graag.

Eens dat de architectuur van Ampere verkwistend, niet geoptimaliseerd en niet elegant is. Maar ga je nou negeren dat Nvidia's kaarten qua rasterization *gelijk* presteren met AMD plus dat ze 2 jaar lang DLSS hebben gehad waar AMD pas dit jaar FSR2 biedt? En dat ze nog steeds een stuk beter in RTX, encoding/decoding en streaming zijn? Als je er een gratis zou krijgen, zou jij een RTX 3080 of een RX 6800XT kiezen? 8 van de 10 kiezen de RTX 3080.

Een GPU verkoper moet het niet hebben van een "architectuur". Ze moeten het hebben van performance, goede prijs, en lage productie kosten. Pas wanneer de architectuur zodanig faalt dat het teveel Watt slurpt, zo luid is als een stofzuiger, of anderszins vastloopt in een gaming workload (slechte performance), dan pas merk je de factor architectuur. En zelfs dan, bij die eerste twee kun je undervolten als de prijs goed is, en alsnog een goeie deal krijgen

[Ludewig]

sunsmountain schreef op woensdag 3 augustus 2022 @ 23:44:
[...]
Een GPU verkoper moet het niet hebben van een "architectuur". Ze moeten het hebben van performance, goede prijs, en lage productie kosten.

De prijs past hier niet zo in het rijtje, want de prijs wordt bepaald op basis van hoe aantrekkelijk de kaart is voor consumenten. Het is eerder zo dat performance, features (encoding, DLSS, CUDA, etc), drivers en reputatie bepalen hoeveel de consument bereid is te betalen en dus de prijs in de winkel. De productiekosten bepalen dan de marge en dus de winst per kaart.

AMD heeft volgens mij de lagere productiekosten.

[Dennism]

DaniëlWW2 schreef op woensdag 3 augustus 2022 @ 23:16:
Het is competitief, maar Nvidia moet het eigenlijk al van DLSS + RTX + mindshare hebben en niet omdat ze echt de betere rasterization architectuur hebben. Daarin is RDNA2 al beter over het spectrum van resoluties, in combinatie met mindere processoren, qua verbruik, regelmatig ook in frametimes etc.

Dit is wat ik juist eerder de zwakte van AMD vind tot op heden, ja AMD haakt eindelijk aan qua rasterization, maar op feature gebied voelt het nog steeds als of ze nog altijd jaren achter lopen, en dat zeg ik als eigenaar van een RDNA2 kaart.

Terwijl juist rasterization alleen niet zo interessant lijkt, immers quasi iedere kaart heeft OK rasterization performance voor de tier waar de kaart in zit. Het zijn juist de andere zaken waarvan ik verwacht dat ze sales driven in een markt waar niet iedere kaart verkocht wordt.

[Dennism]

Ludewig schreef op donderdag 4 augustus 2022 @ 00:53:

AMD heeft volgens mij de lagere productiekosten.

Dat vraag ik me wel af, ik denk dat AMD eerder genoegen neemt met minder marge. Ik heb niet direct het idee dat een RDNA2 die op 7nm veel goedkoper is dan een Samsung 8N die, die Nvidia volgens de geruchten 'zowat' (uiteraard gechargeerd) voor niets zou krijgen.

[DaniëlWW2]

Dennism schreef op donderdag 4 augustus 2022 @ 02:44:
[...]


Dit is wat ik juist eerder de zwakte van AMD vind tot op heden, ja AMD haakt eindelijk aan qua rasterization, maar op feature gebied voelt het nog steeds als of ze nog altijd jaren achter lopen, en dat zeg ik als eigenaar van een RDNA2 kaart.

Terwijl juist rasterization alleen niet zo interessant lijkt, immers quasi iedere kaart heeft OK rasterization performance voor de tier waar de kaart in zit. Het zijn juist de andere zaken waarvan ik verwacht dat ze sales driven in een markt waar niet iedere kaart verkocht wordt.

Mindshare.
Want de overgrote meerderheid van games heeft geen DLSS of RT ondersteuning. De overgrote meerderheid van gebruikers zal nooit NVENC gebruiken, heeft niks aan RTX voice etc. Verreweg de belangrijkste factor voor een videokaart is nog steeds shader inputs veranderen in mooie plaatjes.

Wel vermoed ik dat meer mensen Chill zouden willen gebruiken als ze wisten wat het was. Immers heeft zo ongeveer iedereen in de videokaarttopics, de laatste dagen verklaard dat ze eigenlijk helemaal niet zitten te wachten op 300W+ videokaarten. En Chill scheelt heel wat en werkt in vrijwel elke game. In online shooters wil je het waarschijnlijk niet, in vrijwel elke andere game kan het wel. Maar daar hoor je nooit iets over omdat zodra AMD betere perf/watt had, opeens perf/watt irrelevant geworden lijkt te zijn in de meeste discussies.

Overigens waar loopt AMD nog achter? FSR2.0 pareert DLSS aardig, RT is nog steeds nauwelijks relevant omdat de games en de capabele hardware ontbreken, AMD heeft haar RTX voice tegenhanger en qua encoding zit AV1 eraan te komen en RDNA3 lijkt AV1 ook te ondersteunen. Nvidia hun voordelen verdwijnen de laatste tijd.

[Dennism]

DaniëlWW2 schreef op donderdag 4 augustus 2022 @ 10:31:
[...]


Mindshare.
Want de overgrote meerderheid van games heeft geen DLSS of RT ondersteuning. De overgrote meerderheid van gebruikers zal nooit NVENC gebruiken, heeft niks aan RTX voice etc. Verreweg de belangrijkste factor voor een videokaart is nog steeds shader inputs veranderen in mooie plaatjes.

Uiteraard, wat ik meer bedoel is dat wanneer raster performance een wash is binnen een bepaalde tier je naar andere zaken kijkt of wanneer je voldoende raster performance hebt voor je doel. Bijvoorbeeld mijn kaart is ruim voldoende voor mijn doelen (hoge settings op 1440P bij 144Hz in de games die ik speel), zou ik dus nu toch naar een andere kaart gaan kijken zal een hogere raster performance het niet direct doen voor mij, ik ben immers tevreden met wat ik nu heb, de overige features moeten dan de doorslag geven bij gelijke beschikbaarheid. De laatste 2 jaar was natuurlijk beschikbaarheid alleen al een van de grootste doorslaggevende zaken, maar nu is dat anders.

Wel vermoed ik dat meer mensen Chill zouden willen gebruiken als ze wisten wat het was. Immers heeft zo ongeveer iedereen in de videokaarttopics, de laatste dagen verklaard dat ze eigenlijk helemaal niet zitten te wachten op 300W+ videokaarten. En Chill scheelt heel wat en werkt in vrijwel elke game. In online shooters wil je het waarschijnlijk niet, in vrijwel elke andere game kan het wel. Maar daar hoor je nooit iets over omdat zodra AMD betere perf/watt had, opeens perf/watt irrelevant geworden lijkt te zijn in de meeste discussies.

Dat denk ik ook zeker, chill is wel een leuke feature, maar inderdaad niet voor iedere game

Overigens waar loopt AMD nog achter? FSR2.0 pareert DLSS aardig, RT is nog steeds nauwelijks relevant omdat de games en de capabele hardware ontbreken, AMD heeft haar RTX voice tegenhanger en qua encoding zit AV1 eraan te komen en RDNA3 lijkt AV1 ook te ondersteunen. Nvidia hun voordelen verdwijnen de laatste tijd.

Zoals ik het zie:

FSR is nog steeds niet op niveau DLSS, het komt dichterbij, maar AMD is er nog niet, voor zover ik begrijp uit reviews e.d. is eigenlijk alleen het hogere resolutie werk op orde.
AMD's Encoding kwaliteit is / was lange tijd niet op orde v.s. nvenc (daar is nu volgens mij vorige maand een update op geweest, dus misschien dat dit nu eindelijk op gelijk niveau is).
AMD's noise supression is nu uit, betere reviews zullen vast nog komen, maar uit de eerste indrukken die ik kreeg op reddit en youtube verslaat het RTX voice niet.

Daar komt voor mij bij dat AMD in de GPU markt de challenger is, niet de marktleider. En dan moet je mijn inziens als challenger voorlopen qua features, niet 2 jaar in een generatie in de buurt komen.

Misschien dat AMD het gat kan dichten, en dat ze met RDNA3 qua performance eens duidelijk de betere gaan zijn, en daarnaast ook vanaf dag 1 in een generatie feature pariteit hebben (of hopelijk zelfs een voorsprong, ze zijn immers de challenger, dus ze moeten mensen overhalen hun product te kopen).

Naast deze consumenten zaken zie ik echter ook dat in ieder geval binnen onze klantenkring (en bijv. ZZPérs e.d. in mijn persoonlijke omgeving) dat AMD het op de prosumer en zakelijke workstation segment ook nog steeds niet geweldig doet. Uiteraard hebben ze ook daar initiatieven om o.a. Cuda na te streven, maar de indruk die ik daar krijg is dat AMD ook daar nog een lange weg te gaan heeft.

[ Voor 7% gewijzigd door Dennism op 04-08-2022 11:27 ]

[Ludewig]

Dennism schreef op donderdag 4 augustus 2022 @ 02:46:
[...]
Dat vraag ik me wel af, ik denk dat AMD eerder genoegen neemt met minder marge. Ik heb niet direct het idee dat een RDNA2 die op 7nm veel goedkoper is dan een Samsung 8N die, die Nvidia volgens de geruchten 'zowat' (uiteraard gechargeerd) voor niets zou krijgen.

AMD heeft over de hele linie kleinere die sizes, wat betekent dat de chips bij dezelfde waferkosten goedkoper zijn. Zo heeft AMD 520/335/237 mm2, terwijl Nvidia zit op 628/492/392 mm2. Ik kan me moeilijk voorstellen dat Nvidia zoveel minder betaald aan Samsung dat ze goedkoper uit zijn.

Dan gebruikt Nvidia ook nog duurder geheugen, al doen ze wel minder geheugen op de kaarten. Nvidia heeft ook een bredere bus, wat ook weer duurder is.

[ Voor 3% gewijzigd door Ludewig op 04-08-2022 11:41 ]

[Dennism]

Ludewig schreef op donderdag 4 augustus 2022 @ 11:10:
[...]


AMD heeft over de hele linie kleinere die sizes, wat betekent dat de chips bij dezelfde waferkosten goedkoper zijn. Zo heeft AMD 520/335/237 mm2, terwijl Nvidia zit op 628/492/392 mm2. Ik kan me moeilijk voorstellen dat Nvidia zoveel minder betaald aan Samsung dat ze goedkoper uit zijn.

Dan gebruikt Nvidia ook nog duurder geheugen, al doen ze wel minder geheugen op de kaarten.

De geruchten gingen destijds (2020 voor / rondom de launch van Ampere en RDNA2) dat een 8N wafer van Samsung +- de helft zou kosten van een 7nm wafer van TSMC voor Nvidia. Dat zou dan ook de grootste reden geweest zijn dat Nvidia naar de mindere Samsung node zou zijn gegaan, Samsung zou Nvidia verleid hebben met enorme kortingen.

[ Voor 3% gewijzigd door Dennism op 04-08-2022 11:15 ]

[Ludewig]

DaniëlWW2 schreef op donderdag 4 augustus 2022 @ 10:31:
[...]
De overgrote meerderheid van gebruikers zal nooit NVENC gebruiken

Met het succes van de Quest is dit wel relevanter, want voor PCVR moet een H.264 stream ge-encodeerd worden. En met de toename van het thuiswerken wordt er ook meer aan videobellen gedaan. Dat gaat ook over de encoder. En steeds meer mensen hebben de ambitie om te streamen.

Overigens waar loopt AMD nog achter? FSR2.0 pareert DLSS aardig

In theorie dan, want in de praktijk zijn er nu volgens mij 3 FSR 2.0 spellen en 200+ DLSS spellen.

Nvidia hun voordelen verdwijnen de laatste tijd.

Het wordt wel steeds beter, omdat AMD op allerlei punten toch teveel achterloopt hebben heel veel mensen wel een reden om een sterke voorkeur te hebben voor Nvidia:

• Heeft 1 van je favoriete spellen DLSS en geen FSR 2?
• Doe je aan PCVR
• Ben je een streamer of wil je dat gaan doen
• Doe je soms aan video-editing e.d.

Ik zou graag zien dat AMD voor mij en voor veel anderen een betere keuze wordt.

[Ludewig]

Dennism schreef op donderdag 4 augustus 2022 @ 11:14:
[...]
De geruchten gingen destijds (2020 voor / rondom de launch van Ampere en RDNA2) dat een 8N wafer van Samsung +- de helft zou kosten van een 7nm wafer van TSMC voor Nvidia. Dat zou dan ook de grootste reden geweest zijn dat Nvidia naar de mindere Samsung node zou zijn gegaan, Samsung zou Nvidia verleid hebben met enorme kortingen.

Het is moeilijk om dat te geloven. Waarom zou Samsung zo absurd veel korting geven?

Wat ik begrepen had was dat Nvidia mogelijk alleen betaalde voor elke werkende chip, ook omdat de yields bij Samsung nogal laag waren. Als je dat omrekent naar de kosten per wafer betaalden ze dan misschien de helft, maar dat is appels met peren vergelijken, want de yield bij Samsung was lager. Het kostenverschil per chip is dan niet zo extreem.

Ik verwacht dat de yields bij Samsung ondertussen een stuk zijn verbeterd, al lijkt de defect rate van TSMC extreem laag aangezien AMD heel weinig 6800 kaarten verkocht, dus blijkbaar konden ze bijna alle Navi 21 chips in de 6900 stoppen. Bij Nvidia hebben ze juist heel veel 3080 en 3060 Ti kaarten verkocht, die beide chips gebruiken waarvan een deel uitgeschakeld is.

[ Voor 17% gewijzigd door Ludewig op 04-08-2022 13:04 ]

[napata]

Ludewig schreef op donderdag 4 augustus 2022 @ 12:01:
[...]


Het is moeilijk om dat te geloven. Waarom zou Samsung zo absurd veel korting geven?

Omdat hun node gewoon veel slechter is. Er is een rede waarom Nvidia gekozen heeft voor Samsung en dat is omdat het hun een pak geld bespaard. Anders hadden ze wel bij TSMC gebleven voor alle GPUs ipv enkel A100. De kosten bij TSMC 7 zijn omhoog geschoten dus ik kan wel begrijpen dat ze naar goedkopere oplossingen gingen. Uiteindelijk is Samsung 8 gewoon een aangepaste versie van hun "10nm" node dus een "oude" node.

Het interessante is dat ze ook een Ampere GPU hebben op TSMC dus je kan wel een ruwe vergelijking maken.

A100: 54.200M tranistors op 826mm² dus een density van 65,6M/mm²
GA102: 28.300M op 628mm² dus een density van 45M/mm².

TSMC 7 heeft dus een 45% hogere density. Als je dezelfde density als A100 aanhoudt dan zou een GA102 op TSMC 7 431mm² zijn.
Die 431 mm² zou sowieso meer kosten dan de 628mm² die Nvidia momenteel betaalt bij Samsung want anders zouden we dus een GA102 op TSMC 7 hebben. Performance/W zou ook een stuk beter zijn.

[DaniëlWW2]

Dus dit dook toevallig op dankzij het machtige algoritme.
Het is echt zoals verwacht. Je hebt Jon Peddy die heel goed weet waar hij het over heeft en je hebt iemand die vooral erg goed is in doen alsof die weet waarover die het heeft, maar door de mand valt als je zelf wat achtergrondkennis hebt en erop let. Dat kan gaan irriteren...

Afijn, omdat het Jon Peddy is.

Het eerste stuk gaat over Intel en de vele, vele problemen met ARC. Jon Peddy vermoedt daar eigenlijk dat er problemen zijn met afdelingen die niet met elkaar praten omdat Intel zo groot is. Veel personeel aangenomen die elkaar niet kennen terwijl AMD en Nvidia juist heel hechte bedrijven schijnen te zijn. Ook speelt mee dat ARC geen core business is, het geld bij Intel opeens op is omdat ze klappen krijgen van AMD en dat het hele ARC project ook wel eens onnodige politieke inmenging kan hebben gehad. Want het gaat blijkbaar nu zo dramatisch dat er achter de schermen ook problemen zijn met informatieverstrekking aan AIB's, zowel over producten als materialen en er heel wat twijfel zou zijn over ARC haar toekomst. En als het geen toekomst meer heeft, dan vermoed hij dat Intel de boel wel eens aan Dell of HP zou kunnen verkopen.

Volgens hem is het in ieder geval niet de kunde van de ingenieurs bij Intel of het gebrek aan een driver team. Dat doen ze immers al vele jaren.

Ook liet Peddy iets vallen over Apple dat ze niet geïnteresseerd zouden zijn ARC omdat ze blijkbaar iets plannen met een andere GPU fabrikant. Dat was verder alleen onder NDA. Gezien de notoire slechte relatie tussen Apple en Nvidia, lijkt me duidelijk wie dat is. Daar gaat misschien nog een verrassing uitkomen.

Tweede stuk gaat over RDNA3 vs Lovelace. Wat hier denk ik het belangrijkst is, is de nadruk op betrouwbaarheid als bedrijf naar je partners. Blijkbaar beginnen AMD en Nvidia al een jaar van te voren met informeren van prestatiedoelen van hun modellen aan partners. Vervolgens worden ze up to date gehouden over de tijd voor launches, meer specifieke zaken, uiteindelijk configuraties zodat de AIB partners hun maanden hebben om hun PCB's te ontwerpen etc.

Ook gaat het erover dat Nvidia eigenlijk wel echt een mindshare heeft vergelijkbaar met Apple. Uitgesplitst in workstation en gaming. Voor workstation denkt Peddy dat er nog wel 30% marktaandeel te halen is voor AMD omdat die markt zelf een concurrent wil. Meer ook niet. Het probleem is dat Nvidia daar te diep ingegraven zit en goede ondersteuning bied. Ironisch want ATi begon ooit met parallel computing, niet Nvidia. Gaming is een iets ander verhaal. Daar is het probleem dat AMD volgend Peddy gewoon over de hele linie moet winnen. Dus ook alles van rasterisation tot efficiëntie, RT, drivers, features, goedkoper etc.

Vervolgens nog wat over monolitisch vs MCM. Peddy zit vol in de MCM kant dat dit uiteindelijk gaat winnen. Hij heeft het vaker over yields en hoe complex het aan het worden is om nog goede yields te halen uit moderne chips, zeker grote. AMD kan op deze manier goedkopere chips maken. En het lukt AMD ook omdat ze het grote probleem, de interconnect, zo goed voor elkaar hebben met IF. Nvidia lijkt ook voor Blackwell nog te wedden op monolitisch omdat Jensen heeft gezegd dat "Nvidia hier heel erg goed in is". Dat kan je natuurlijk op twee manieren nemen. Nvidia is daadwerkelijk heel erg goed, of ze hebben geen alternatief. In ieder geval gaat Peddy er vanuit dat er een moment gaat komen dat Nvidia ook moet omdat yields alsmede de efficiëntie van de chip gewoon niet meer gaat. Op een gegeven moment is een monolithische chip te groot geworden en dan maakt het niet meer uit hoeveel vermogen je erdoorheen jaagt, je gaat niks meer winnen.

Ook zei hij al eerder dat die grote bedrijven geen flauw idee hebben hoeveel transistoren hun chips werkelijk bevatten. Het zijn inschattingen gebaseerd op computermodellen. Ze hebben alleen geen idee omdat ze zomaar een circuit kunnen hebben van tien jaar geleden, waarvan ze na een paar node shrinks al helemaal geen idee meer hebben hoeveel transistoren het nu is. Zeker omdat er ook redundancy inzit. Het proces van ontwerpen lijkt ook grotendeels neer te komen op maar iets proberen en hopen dat het werkt.

Laatste is dat Peddy een beetje klaar lijkt te zijn met game developers die maar achter de GPU ontwikkeling aanlopen en niks doen met de verbeteringen in rekenkracht. Hij is verder echt onder de indruk van UE5 haar technieken en wil dat soort dingen meer zien. Ook wil hij graag betere schermen hebben alsmede vorderingen in audio om de steeds meer levensechte graphics meer betekenis en immersie te geven.

---

Nog een laatste observatie van mij. Peddy zei dat Jensen zijn achtergrond in procestechnologie zit. Ik bedacht me alleen opeens dat Lisa Su haar achtergrond zit in interconnects. Toch opvallend.

[NitroX infinity]

DaniëlWW2 schreef op dinsdag 9 augustus 2022 @ 22:24:
...

Ook liet Peddy iets vallen over Apple dat ze niet geïnteresseerd zouden zijn ARC omdat ze blijkbaar iets plannen met een andere GPU fabrikant. Dat was verder alleen onder NDA. Gezien de notoire slechte relatie tussen Apple en Nvidia, lijkt me duidelijk wie dat is. Daar gaat misschien nog een verrassing uitkomen.

...

Vergeet jij Imagination (Technologies) niet? Ik meen enkele jaren geleden gelezen hebben dat die in de etalage stonden.

[Ludewig]

DaniëlWW2 schreef op dinsdag 9 augustus 2022 @ 22:24:
Ook liet Peddy iets vallen over Apple dat ze niet geïnteresseerd zouden zijn ARC omdat ze blijkbaar iets plannen met een andere GPU fabrikant. Dat was verder alleen onder NDA. Gezien de notoire slechte relatie tussen Apple en Nvidia, lijkt me duidelijk wie dat is. Daar gaat misschien nog een verrassing uitkomen.

AMD is ook logischer omdat die veel expertise hebben met APU's, waar Apple een sterke voorkeur voor heeft. Dan kan AMD een ARM APU maken en daarmee mogelijk nieuwe markten aanboren, terwijl Apple dan niet meer zoveel kosten hoeft te maken voor het design.

Peddy zit vol in de MCM kant dat dit uiteindelijk gaat winnen. [...] En het lukt AMD ook omdat ze het grote probleem, de interconnect, zo goed voor elkaar hebben met IF.

Er is ook nog gigantisch veel te verbeteren met interconnects, inclusief 3D chips.

Overigens zat Peddy nog wel gigantisch uit zijn nek te kletsen toen hij beweerde dat mining-kaarten maar een paar weken meegaan.

[Werelds]

DaniëlWW2 schreef op dinsdag 9 augustus 2022 @ 22:24:
Nog een laatste observatie van mij. Peddy zei dat Jensen zijn achtergrond in procestechnologie zit. Ik bedacht me alleen opeens dat Lisa Su haar achtergrond zit in interconnects. Toch opvallend.

Hmm, ik weet niet waarom hij zegt dat Jensen's achtergrond in procestechnologie zit, dat heb ik nog nooit gehoord. Hij is juist een chip ontwerper, terwijl Su de procestechnologie ervaring heeft, dat is waar ze bij IBM aan werkte. Misschien dat hij daar iets mee gedaan heeft in z'n tijd bij AMD, want toen hadden ze nog fabs? Van huis uit zit hij echter in electrotechniek en is hij een chip ontwerper.

Daar zit echter wel een groot verschil tussen de twee. Huang weet echt wel waar hij mee bezig is, maar hij is eigenlijk al 25 jaar geen chip ontwerper meer. Hij is ondernemer. En het is ook niet zo dat hij bergen ervaring heeft opgebouwd vóór hij Nvidia startte - hij heeft naam gemaakt als oprichter van Nvidia, niet als ontwerper. Wat dat betreft is het juist Su die écht diep in de materie zit, daar hebben ze bij IBM wel voor gezorgd door haar op SOI te zetten, waar ze schijnbaar behoorlijk belangrijk was voor het oplossen van de problemen. Cell (PS processor) kwam ook uit haar koker (nou ja, haar en haar team bij IBM)

Ze heeft niet voor niks de Noyce award gekregen vóór Huang. Huang's prijzenkast hangt vol met "businessman of the year" dingen, Su's kast heeft juist allerlei "innovator" prijzen.

NitroX infinity schreef op dinsdag 9 augustus 2022 @ 22:55:
Vergeet jij Imagination (Technologies) niet? Ik meen enkele jaren geleden gelezen hebben dat die in de etalage stonden.

Dat stonden ze...een jaar of 5 geleden

Het bedrijf is inmiddels eigendom van een Chinese groep, wat waarschijnlijk is waarom je PowerVR nauwelijks meer ziet en waarom Apple hoogstwaarschijnlijk elders aan klopt.

[DaniëlWW2]

Werelds schreef op woensdag 10 augustus 2022 @ 11:11:
[...]

Hmm, ik weet niet waarom hij zegt dat Jensen's achtergrond in procestechnologie zit, dat heb ik nog nooit gehoord. Hij is juist een chip ontwerper, terwijl Su de procestechnologie ervaring heeft, dat is waar ze bij IBM aan werkte. Misschien dat hij daar iets mee gedaan heeft in z'n tijd bij AMD, want toen hadden ze nog fabs? Van huis uit zit hij echter in electrotechniek en is hij een chip ontwerper.

Daar zit echter wel een groot verschil tussen de twee. Huang weet echt wel waar hij mee bezig is, maar hij is eigenlijk al 25 jaar geen chip ontwerper meer. Hij is ondernemer. En het is ook niet zo dat hij bergen ervaring heeft opgebouwd vóór hij Nvidia startte - hij heeft naam gemaakt als oprichter van Nvidia, niet als ontwerper. Wat dat betreft is het juist Su die écht diep in de materie zit, daar hebben ze bij IBM wel voor gezorgd door haar op SOI te zetten, waar ze schijnbaar behoorlijk belangrijk was voor het oplossen van de problemen. Cell (PS processor) kwam ook uit haar koker (nou ja, haar en haar team bij IBM)

Ze heeft niet voor niks de Noyce award gekregen vóór Huang. Huang's prijzenkast hangt vol met "businessman of the year" dingen, Su's kast heeft juist allerlei "innovator" prijzen.

Inderdaad wat vreemd. Misschien is er achter de schermen iets veranderd.
Uiteindelijk heeft Nvidia een groot deel van hun succes ook te danken aan de relatie die ze met TSMC aangingen. Daar moet een zeker besef zijn geweest dat TSMC hun zaken qua fabricage op orde had. Het vertrouwen heeft zichzelf ook eindeloos terugbetaald en zelfs met de uitstapjes naar Samsung, blijven de echt belangrijke chips op TSMC zitten. Uiteindelijk is de keuze voor productieleverancier ook een van de belangrijkste die Nvidia kan maken, waardoor die vrijwel gegarandeerd door Jensen gedaan zal worden.

Van Su weet ik dat ze nauw betrokken was bij Cell en dus ook heel wat gedaan heeft met semi-custom. Dat zien we ook steeds terug bij AMD en het verdient zich inmiddels ook terug. maar Su haar achtergrond was oorspronkelijk copper connects. En connections is nu waar AMD onbetwist marktleider in is. We horen al jaren bijvoorbeeld Intel over Foveros, maar AMD levert gewoon hun producten.

Dat blijft denk ik ook een van de grootste raadsels voor RDNA3. Ze gaan het doen, maar hoe precies en met welke effecten.

[...]

Dat stonden ze...een jaar of 5 geleden

Het bedrijf is inmiddels eigendom van een Chinese groep, wat waarschijnlijk is waarom je PowerVR nauwelijks meer ziet en waarom Apple hoogstwaarschijnlijk elders aan klopt.

Yup en daarom moest ik weer aan AMD denken die wel vaker werk voor Apple doet. Want sinds bumpgate, is er geen Nvidia chip meer in een Apple product gekomen.

---

Iets anders. Ik wil eigenlijk nog eens kijken of ik tijd heb om beter naar AMD en Nvidia hun kwartaalcijfers kan kijken. Want zeker Nvidia lijkt misschien slechter te zijn dan je eerst zou denken. Dit omdat hun werkelijke inventaris van videokaarten, echt enorm zou kunnen zijn. Nog erger dan in 2018 met de Turing lancering waar je beter een Pascal kon kopen. Dit in tegenstelling tot AMD waar ze misschien voorzichtiger waren en productie hebben beperkt omdat ze al eerder met enorme mining overschotten te maken hebben gehad.

[Ludewig]

DaniëlWW2 schreef op woensdag 10 augustus 2022 @ 11:31:
[...]
Want zeker Nvidia lijkt misschien slechter te zijn dan je eerst zou denken. Dit omdat hun werkelijke inventaris van videokaarten, echt enorm zou kunnen zijn. Nog erger dan in 2018 met de Turing lancering waar je beter een Pascal kon kopen. Dit in tegenstelling tot AMD waar ze misschien voorzichtiger waren en productie hebben beperkt omdat ze al eerder met enorme mining overschotten te maken hebben gehad.

Ik vind het opvallend dat juist AMD meer kortingen lijkt te geven, wat erop duidt dat het juist AMD is die met (nog) grotere overschotten zit.

En de overschotten lijken sowieso meer bij de AIBs te zitten, dan direct bij Nvidia. Dat is natuurlijk wel hun probleem, want AIBs moeten eerst hun voorraad grotendeels kwijt voordat ze aan de 4000 serie kunnen beginnen.

Ik wil eigenlijk nog eens kijken of ik tijd heb om beter naar AMD en Nvidia hun kwartaalcijfers kan kijken.

Ik vond dit heel interessant:

“The significant charges incurred in the quarter reflect previous long-term purchase commitments we made during a time of severe component shortages and our current expectation of ongoing macroeconomic uncertainty,”

Betekent dit dat de betalingen aan TSMC zijn begonnen voor de N4P productie?

[Help!!!!]

Ludewig schreef op woensdag 10 augustus 2022 @ 14:02:
[...]


Ik vind het opvallend dat juist AMD meer kortingen lijkt te geven, wat erop duidt dat het juist AMD is die met (nog) grotere overschotten zit.

AMD heeft juist aangegeven in hun Q2 call dat hun overschotten soort van meevallen.

"So I do think we've appropriately derisked the PC business. As it relates to inventory, as we look at the current situation, given some of the COVID lockdowns and things in the second quarter. I think there was a bit of buildup in PC inventory, and we've taken that into account in the second half. We think the AMD portion of that is modest.

And as a result, it will rebalance itself in the second half of the year. So overall, I think we feel very good about the second half. And again, with the portfolio that we have, one of the things that has been important is we were still supply constrained in several of the areas. Certainly, on the embedded side, we were supply constrained in the second quarter."

Ik vond dit heel interessant:

“The significant charges incurred in the quarter reflect previous long-term purchase commitments we made during a time of severe component shortages and our current expectation of ongoing macroeconomic uncertainty,”

Betekent dit dat de betalingen aan TSMC zijn begonnen voor de N4P productie?

Volgensmij koopt nvidia (en AMD?) zelf de gpu's en het geheugen in en levert dit als pakketje door aan AIB's. Daarnaast verkopen ze natuurlijk ook gewoon FE's en zakelijke kaarten. Dus daarvoor neem ik even aan dat ze alle onderdelen zelf inkopen.

Blijkbaar is het ook zo dat AMD/nVidia etc (een deel) vd bestelling moeten vooruitbetalen.

[ Voor 28% gewijzigd door Help!!!! op 10-08-2022 15:15 ]

[DaniëlWW2]

Het verschil is ook enorm.
Want Nvidia heeft moeten toegeven dat hun verwachte Q2 omzet van $8,1 miljard, maar $6,7 miljard is gezakt. Dit terwijl ze niet veel aan prijsdalingen hebben gedaan. Ergo je mag er vanuit gaan dat Nvidia iets van $1 miljard aan GPU inventaris niet heeft kunnen verkopen. Dat is GPU inventaris, dus GPU chips en VRAM, niet hele videokaarten.

Dit zijn chips die Nvidia niet wist te verkopen aan hun partners. Partners zullen chips pas weigeren als ze hun eigen inventaris niet kunnen verkopen. Daarbij is het ook de vraag in hoeverre ze geen boetes moeten betalen omdat ze niet afnemen. Verder zitten er ook andere kostenposten verbonden aan niet afnemen. Omdat als ze minder chips afnemen, zullen de fabrieken ook op lagere capaciteit gaan draaien en waarschijnlijk verliesgevend worden. De ellende in de keten moet dan ook fors zijn als Nvidia zoveel omzet verliest. We zagen EVGA een paar dagen geleden nog stunten met extreme kortingen voor high end chips.
https://www.tomshardware....us-starting-at-dollar1149
Komt er ook nog eens bij dat menig consument een tweedehands kaart zal kopen of deze generatie nu zal overslaan. Iedereen is inmiddels ook lekker gemaakt met geruchten over enorme prestatiewinsten waarbij ik zeker bij Nvidia, steeds meer twijfel of ze er echt gaan komen.

---

Zet het af tegen AMD. Daar gaan de prijzen al tijden omlaag over de hele linie. maar juist Navi 22, 23 en 24 zijn al een tijdje redelijk goed te verkrijgen voor prijzen waarbij je niet eens naar Nvidia hoeft te kijken. Navi 21 is juist nog steeds problematisch. Ik vermoed dan ook dat AMD specifiek de Navi 21 productie allang heeft afgeschaald, de kleinere chips verkoopt met relatief licht verlies van verwachte omzet en de watercapaciteit heeft verschoven naar producten zoals Rembrandt, consoles of RDNA3. Dat verklaard voor mij AMD hun cijfers ook.

[XWB]

DaniëlWW2 schreef op woensdag 10 augustus 2022 @ 16:10:
Komt er ook nog eens bij dat menig consument een tweedehands kaart zal kopen of deze generatie nu zal overslaan. Iedereen is inmiddels ook lekker gemaakt met geruchten over enorme prestatiewinsten waarbij ik zeker bij Nvidia, steeds meer twijfel of ze er echt gaan komen.

Dat is nog het minste, de aanstaande krimp van de wereldeconomie zal veel grotere gevolgen hebben.

[DaniëlWW2]

XWB schreef op woensdag 10 augustus 2022 @ 16:40:
[...]


Dat is nog het minste, de aanstaande krimp van de wereldeconomie zal veel grotere gevolgen hebben.

Yup, zeker als je ook bekend dat AMD een kostenbesparende strategie heeft met hun MCM ontwerp en waarschijnlijk Navi 33 op de oudere node, Nvidia niet.

[XWB]

AMD lijkt ook succesvol onderhandeld te hebben met TSMC om minder chips te kunnen afnemen:

nieuws: 'AMD, Apple en Nvidia willen minder chips afnemen van TSMC'

Nvidia daarentegen moet blijven afnemen.

[DaniëlWW2]

XWB schreef op woensdag 10 augustus 2022 @ 17:25:
AMD lijkt ook succesvol onderhandeld te hebben met TSMC om minder chips te kunnen afnemen:

nieuws: 'AMD, Apple en Nvidia willen minder chips afnemen van TSMC'

Nvidia daarentegen moet blijven afnemen.

Ik betwijfel alleen of AMD daadwerkelijk minder wil afnemen. Want ze gaven met de kwartaalcijfers wederom aan dat ze eigenlijk meer willen produceren dan ze nu kunnen doen. AMD heeft ook inmiddels zoveel echt goede producten die maar moeilijk te krijgen zijn. De gaming videokaarten behoren eigenlijk nog tot de minder goede producten en die zijn al goed.

Het moment om meer te produceren is ook H2/2202 omdat ze dan eindelijk flink wat RDNA en Zen productie naar N5 kunnen brengen en de consoles, embedded, APU's etc op N7 houden. En een deel daarvan is inmiddels N7 + EUV voor wat kostenbesparing op complexe zaken op een chip. Dat is N6 namelijk.

[Paprika]

XWB schreef op woensdag 10 augustus 2022 @ 17:25:
AMD lijkt ook succesvol onderhandeld te hebben met TSMC om minder chips te kunnen afnemen:

nieuws: 'AMD, Apple en Nvidia willen minder chips afnemen van TSMC'

Nvidia daarentegen moet blijven afnemen.

AMD wil ook niet van de 5nm productie af. Dat zal ook niet heel erg helpen. Voor de andere lijnen hebben ze misschien nog wel alternatieven.

[DaniëlWW2]

Dit is laten we zeggen interessant.
Kwam deze site tegen via r/AMD. En ik weet eigenlijk niet wat ik ervan moet denken. Aan de ene kant lijkt de auteur daadwerkelijk te beschikken over het soort basale kennis dat zo pijnlijk afwezig is bij de meeste "leakers". Aan de andere kant is het een beetje een compleet uit het niks site die toch behoorlijk stellig en specifiek is.

Zeker omdat dit op zijn zachts gezegd opvallende claims te noemen zijn. Zo durf ik de claim van 308mm voor 12288 ALU's op N5 in ieder geval wel te noemen. Dit zou vooral komen omdat AMD heel veel legacy ondersteuning verwijderd zou hebben, waardoor een WGP met 2x de ALU's, kleiner is dan met RDNA2 op dezelfde node, dus Navi 33. Dit is potentieel geloofwaardig omdat een dergelijk beeld ook een beetje begon op te duiken uit linux patches.

Idem voor de claims dat er minder L3 cache is, sommige SKU's 3D stacked cache krijgen, maar ook dat er flink wat werk verzet is om toegang tot L3 cache vanuit de shaders te optimaliseren om VRAM impacts te verminderen.

Navi 31
gfx1100 (Plum Bonito)
Chiplet - 1x GCD + 6x MCD (0-hi or 1-hi)
48 WGP (96 legacy CUs, 12288 ALUs)
6 Shader Engines / 12 Shader Arrays
Infinity Cache 96MB (0-hi), 192MB (1-hi)
384-bit GDDR6
GCD on TSMC N5, ~308 mm²
MCD on TSMC N6, ~37.5 mm²

Navi32
gfx1101 (Wheat Nas)
Chiplet - 1x GCD + 4x MCD (0-hi)
30 WGP (60 legacy CUs, 7680 ALUs)
3 Shader Engines / 6 Shader Arrays
Infinity Cache 64MB (0-hi)
256-bit GDDR6
GCD on TSMC N5, ~200 mm²
MCD on TSMC N6, ~37.5 mm²

Navi33
gfx1102 (Hotpink Bonefish)
Monolithic
16 WGP (32 legacy CUs, 4096 ALUs)
2 Shader Engines / 4 Shader Arrays
Infinity Cache 32MB
128-bit GDDR6
TSMC N6, ~203 mm²

Ook zou voor Navi 31 de cut vallen op 320bit bus/80MB L3 cache (5xMCD) en 42 WGP i.p.v. 48. Navi 31 zou het verder doen met twee 8 pin connectoren. Dat alleen al is zeer opvallend te noemen omdat het een relatief gematigd verbruik impliceert.

Navi 33 zou vervolgens passen op een Navi 23 PCB en voornamelijk gericht zijn om in laptops te krijgen met "AMD Advantage". Verbruik van deze chip zou ook bescheiden blijven.
https://www.angstronomics.com/p/amds-rdna-3-graphics

[Damic]

@DaniëlWW2 dat zou wel leuk zijn als AMD het verbruik zodanig onder controle heeft bij hun grote monsters dat je maar 2x 8 pins nodig hebt (ziet naar zijn vega 64 )

[DJvL]

Mijn Vega 64 heeft 3x8 pins (Sapphire Nitro+ LE).

Maar inderdaad, dat zou erop duiden dat ze zeker goed bezig zijn.

[Damic]

DJvL schreef op vrijdag 12 augustus 2022 @ 21:33:
Mijn Vega 64 heeft 3x8 pins (Sapphire Nitro+ LE).

Maar inderdaad, dat zou erop duiden dat ze zeker goed bezig zijn.

Dat is geen ref design en ik lieg het is een Vega FE

[sunsmountain]

DaniëlWW2 schreef op vrijdag 12 augustus 2022 @ 21:02:
Dit is laten we zeggen interessant.
Kwam deze site tegen via r/AMD. En ik weet eigenlijk niet wat ik ervan moet denken. Aan de ene kant lijkt de auteur daadwerkelijk te beschikken over het soort basale kennis dat zo pijnlijk afwezig is bij de meeste "leakers". Aan de andere kant is het een beetje een compleet uit het niks site die toch behoorlijk stellig en specifiek is.

Zeker omdat dit op zijn zachts gezegd opvallende claims te noemen zijn. Zo durf ik de claim van 308mm voor 12288 ALU's op N5 in ieder geval wel te noemen. Dit zou vooral komen omdat AMD heel veel legacy ondersteuning verwijderd zou hebben, waardoor een WGP met 2x de ALU's, kleiner is dan met RDNA2 op dezelfde node, dus Navi 33. Dit is potentieel geloofwaardig omdat een dergelijk beeld ook een beetje begon op te duiken uit linux patches.

Idem voor de claims dat er minder L3 cache is, sommige SKU's 3D stacked cache krijgen, maar ook dat er flink wat werk verzet is om toegang tot L3 cache vanuit de shaders te optimaliseren om VRAM impacts te verminderen.

[...]


Ook zou voor Navi 31 de cut vallen op 320bit bus/80MB L3 cache (5xMCD) en 42 WGP i.p.v. 48. Navi 31 zou het verder doen met twee 8 pin connectoren. Dat alleen al is zeer opvallend te noemen omdat het een relatief gematigd verbruik impliceert.

Navi 33 zou vervolgens passen op een Navi 23 PCB en voornamelijk gericht zijn om in laptops te krijgen met "AMD Advantage". Verbruik van deze chip zou ook bescheiden blijven.
https://www.angstronomics.com/p/amds-rdna-3-graphics

Die bron Angstronomics was ik eerder al tegen gekomen toen ik de daadwerkelijke density van 5nm zocht:
https://www.angstronomics.com/p/the-truth-of-tsmc-5nm


De nieuwe GCD oppervlakten zijn klein zoals AMD zou willen en klinken erg klein, maar zouden kunnen als je 80% (32/40 CU) van het oppervlakte van een Navi21 Shader Engine neemt, dat is maar 86 mm².

Voor Navi31 dat x6 , delen door 1,518 voor 5nm (zie de link van Angstronomics hierboven), kom je op 340 mm² voor Navi31. Als je dan bedenkt dat ze het een en ander aan legacy ondersteuning hebben weggesneden, zou 308 mm² realistisch kunnen zijn. Er komt nog wel wat command frontend bij, maar dat is niet zo groot.

Voor Navi33 dat x2 , keer (96,27/114,2) voor 6nm, is 145 mm², maar daar moet je naast de command frontend, de L2, infinity cache, infinity fabric en PHY controllers nog bij optellen, dan klinkt 203 mm² redelijk.

Maar waar ze de xGMI infinity link, VCN display en PCIe5 connecties laten is me een raadsel. Misschien een aparte I/O controller chip? Het is ongeveer 62,5 mm² op 7nm en het schaalt voor geen meter.


Voor de MCD's was ik uitgegaan van 32 MB net zoals Navi23, maar het lijken dus 16 MB MCD's te zijn. Als je de huidige 7nm oppervlakten bij elkaar optelt voor Navi23:
https://pbs.twimg.com/med...sKg?format=jpg&name=large

• 2x 16 MB infinity cache
• 2048 kB L2 cache
• 2x 64-bit PHY controllers
• het streepje infinity fabric

kom je precies op ~38 mm², niet per MCD, maar per 2 MCD's (en 128-bit). Mogelijk dat ze per 2 verbonden worden met de GCD. Of Ze hebben de MCD's gehalveerd qua cache grootte 2x 8 MB op hetzelfde oppervlakte. Bedenk dat de cache latency dan ook omlaag gaat, wat kan helpen bij het nieuwe chiplet design (latency is altijd een uitdaging bij chiplets).
edit: dit was Angstronomics ook bevestigt.

The Memory Attached Last Level (MALL) Cache blocks are each halved in size, doubling the number of banks for the same cache amount. There are also changes and additions that increase graphics to MALL bandwidth and reduce the penalty of going out to VRAM.

De nieuwe CUs hebben qua SIMD capaciteit: 1 "legacy CU" heeft 4 SIMD, 1 huidige CU heeft 2 SIMD:
96 legacy CU = 192 huidige CU
60 legacy CU = 120 huidige CU
32 legacy CU = 64 huidige CU

Dat is nog steeds een hoop vergeleken met de 80 huidige CU Navi21 top die.
https://videocardz.com/ne...vi-32-is-up-to-7680-cores

De hogere kloksnelheden (conservatief: 2500 MHz, 2750 MHz en 3000 MHz) en lineaire schaling van de CU's - voor het gemak - impliceren dan vergeleken met Navi21 (2250 MHz, 80 CU):

Navi31 = max 267% Navi21 performance
Navi32 = max 183% Navi21 performance
Navi33 = max 107% Navi21 performance

Alle andere factoren buiten beschouwing gelaten, daadwerkelijke performance zal in de praktijk minder zijn. Maar toch, zeer positief. Overigens kom ik met dezelfde methode voor Lovelace op:

factor	AD102	GA102
1,714	144 SM	84 SM
1,383	2520 MHz	1822 MHz

AD102 = max 237% GA102 performance.

Een kleine voorsprong van 12,5% voor AMD, voor zover de laatste geruchten geloofd mogen worden.

[ Voor 3% gewijzigd door sunsmountain op 13-08-2022 11:35 ]

[sunsmountain]

Update van de AMD SKU's op basis van de nauwkeurigere Angstronomics:

Thus, the main Navi31 SKU will have 96MB of Infinity Cache (0-hi). This is lower than the 128MB in Navi21. A cut-down SKU will offer 42 WGP and 5x MCD (80MB Cache, 320-bit GDDR6).

---

Navi31:
96 legacy CU , 48 WGP , 6 SE , 12 SA , 8 WGP/SE , 6 MCD , 96MB IC, 384-bit
84 legacy CU , 42 WGP , 6 SE , 12 SA , 7 WGP/SE , 5 MCD , 80MB IC, 320-bit

Navi32:
60 legacy CU , 30 WGP , 3 SE , 6 SA , 10 WGP/SE , 4 MCD , 64MB IC, 256-bit

Navi33:
32 legacy CU , 16 WGP , 2 SE , 4 SA , 8 WGP/SE , 32 MB IC, 128-bit

waarbij 1 legacy CU = 2 huidige CU.

[Werelds]

@DaniëlWW2 @sunsmountain ik heb die angstronomics site een tijd geleden ook al gezien en heb hem een beetje in de gaten gehouden, want in tegenstelling tot andere "leakers" zitten er hardere details in. Het is ofwel iemand met een heel goede duim die goed is in het verzinnen van technische details, of het klopt gewoon. Zoiets als dat OREO (briljante naam als het waar is ) verhaal is zo'n detail - en ook een behoorlijke wijziging. OoO pixel shaders? Niet misselijk als het waar is én ze het werkend hebben.

@sunsmountain je oppervlakte berekeningen missen een aantal dingen. Je focust heel erg op de SE's , maar de rest is zeker niet verwaarloosbaar. Interconnects gaan ook niet weg. Daarnaast zit je denk ik mis met je 86mm² voor 80% van een SE in N21, waar heb je dat op gebaseerd?

- N10: https://preview.redd.it/j...a33134adca797063ba3f622f5
- N21: https://tpucdn.com/gpu-specs/images/g/923-cgi-die-shot.jpg
- N21: https://tpucdn.com/gpu-specs/images/g/923-block-diagram.jpg
- N21: https://i.redd.it/3uijc23junf81.jpg

Die van TPU zijn "fakes", in de zin dat het in feite gewoon CGI is, maar wel afkomstig van AMD en gebaseerd op de echte chip. Zie het als een opgeschoonde versie van hoe het ding er in het echt uit ziet. Het N10 shot is een écht infrarood shot (en een prachtig plaatje).

Met wat snel meetwerk op de pixels, zal een volledige (geen 80%, wat ik ook niet helemaal begrijp) SE volgens mij eerder rond de 55mm² komen (voor zowel N10 als N21, wat logisch is); alles binnen IF in N21 (waarvan het merendeel binnen de GCD zal komen) komt uit op ergens rond de 265mm². Voeg 50% voor 2 extra shader engines en je komt op net geen 400mm². Of doe dat gewoon niet, want als je dan Angstronomics' 1,518 toe past kom je gewoon terug rond die 265mm²

Let wel dat dit dus met WGP's van 128 ALU's is, dus daar gaat meer ruimte nodig zijn. Maar aangezien N21 al bijna voor de helft uit IF, L3$ en MC's bestaat is is 308mm² inderdaad niet geheel onrealistisch voor de GCD, hoewel daar volgens mij ook de I/O in gaat komen en dat is ook een behoorlijk stuk "real estate" wat die 308 dan weer iets krapper maakt. Hele package (GCD + MCD's) gaat uiteindelijk toch nog groot worden.

[sunsmountain]

Werelds schreef op zaterdag 13 augustus 2022 @ 12:24:
@sunsmountain je oppervlakte berekeningen missen een aantal dingen. Je focust heel erg op de SE's , maar de rest is zeker niet verwaarloosbaar. Interconnects gaan ook niet weg. Daarnaast zit je denk ik mis met je 86mm² voor 80% van een SE in N21, waar heb je dat op gebaseerd?

- N10: https://preview.redd.it/j...a33134adca797063ba3f622f5
- N21: https://tpucdn.com/gpu-specs/images/g/923-cgi-die-shot.jpg
- N21: https://tpucdn.com/gpu-specs/images/g/923-block-diagram.jpg
- N21: https://i.redd.it/3uijc23junf81.jpg

Die van TPU zijn "fakes", in de zin dat het in feite gewoon CGI is, maar wel afkomstig van AMD en gebaseerd op de echte chip. Zie het als een opgeschoonde versie van hoe het ding er in het echt uit ziet. Het N10 shot is een écht infrarood shot (en een prachtig plaatje).

Met wat snel meetwerk op de pixels, zal een volledige (geen 80%, wat ik ook niet helemaal begrijp) SE volgens mij eerder rond de 55mm² komen (voor zowel N10 als N21, wat logisch is); alles binnen IF in N21 (waarvan het merendeel binnen de GCD zal komen) komt uit op ergens rond de 265mm². Voeg 50% voor 2 extra shader engines en je komt op net geen 400mm². Of doe dat gewoon niet, want als je dan Angstronomics' 1,518 toe past kom je gewoon terug rond die 265mm²

Let wel dat dit dus met WGP's van 128 ALU's is, dus daar gaat meer ruimte nodig zijn. Maar aangezien N21 al bijna voor de helft uit IF, L3$ en MC's bestaat is is 308mm² inderdaad niet geheel onrealistisch voor de GCD, hoewel daar volgens mij ook de I/O in gaat komen en dat is ook een behoorlijk stuk "real estate" wat die 308 dan weer iets krapper maakt. Hele package (GCD + MCD's) gaat uiteindelijk toch nog groot worden.

Ik heb voor de oppervlaktes gekeken naar 2 Shader Engines, zowel die van Navi21 als Navi23. Interconnects heb ik niet in de GCD opgenomen, ook geen infinity fabric. Dat zit volgens mij allemaal op N6, niet N5.

https://pbs.twimg.com/med...sKg?format=jpg&name=large
https://tpucdn.com/gpu-specs/images/g/923-block-diagram.jpg

Navi21 plaatje
1401 pixels
856 pixels
1199256 pixels kwadraat = 520 mm2

2 SE Navi21
441 pixels
562 pixels
247842 pixels kwadraat = 107,46 mm2

Navi23 plaatje
1232 pixels
1058 pixels
1303456 pixels kwadraat = 237 mm2

2 SE Navi23
840 pixels
700 pixels
588000 pixels kwadraat = 106,91 mm2

Je komt dan bij allebei uit op 107 mm² , wat niet logisch is, omdat Nav21 20 CU per SE heeft en Navi23 16 CU per SE. Dat klopt goed genoeg met jouw 55 mm² per SE.

Die 2 Shader Engines zijn al te groot, want Navi31 heeft er 6, dus 12 in de oude Shader Engines gerekend. Dan kom je op 644,7 mm2 of 424,7 mm2 op 5N, is te groot. Dus vandaar de foezelfactor van 80%, 16CU delen door 20CU van een Navi21 SE is 80%. Waarschijnlijk is het AMD gelukt om nog veel meer te snijden, als je die OREO en weggooien van legacy stuff leest.

Some people are surprised by Navi31 GCD size but note that a lot of old architectural bloat has been removed.

XGMI is gone, GDS is gone, Legacy Geometry pipeline is gone, Legacy Scan converter is gone...

— Kepler (@Kepler_L2) 19 juli 2022

Misschien wel genoeg ruimte voor de VCN , display en PCIe5 controllers, want die moeten er ook nog bij en mag ik suggereren N6 voor alle niet-schaalbare meuk.



Het zit dicht bij elkaar in de buurt, maar het is toch echt duurder voor Nvidia en het lukt AMD om er meer CU in te proppen dan SM:

Navi31 ~533 mm² (192 huidige CU)
Navi32 ~350 mm² (120 huidige CU)
Navi33 ~203 mm² (64 huidige CU)

https://videocardz.com/ne...vi-32-is-up-to-7680-cores

GA102 ~611 mm² (144 SM)
GA103 ~380 mm² (84 SM)
GA104 ~300 mm² (60 SM)

https://semianalysis.subs...ace-leaked-specifications

[ Voor 6% gewijzigd door sunsmountain op 13-08-2022 13:08 ]

[XWB]

DaniëlWW2 schreef op woensdag 10 augustus 2022 @ 17:34:
[...]


Ik betwijfel alleen of AMD daadwerkelijk minder wil afnemen. Want ze gaven met de kwartaalcijfers wederom aan dat ze eigenlijk meer willen produceren dan ze nu kunnen doen. AMD heeft ook inmiddels zoveel echt goede producten die maar moeilijk te krijgen zijn. De gaming videokaarten behoren eigenlijk nog tot de minder goede producten en die zijn al goed.

Het moment om meer te produceren is ook H2/2202 omdat ze dan eindelijk flink wat RDNA en Zen productie naar N5 kunnen brengen en de consoles, embedded, APU's etc op N7 houden. En een deel daarvan is inmiddels N7 + EUV voor wat kostenbesparing op complexe zaken op een chip. Dat is N6 namelijk.

Wie gaat al die spullen kopen? De PC-markt is al twee kwartalen op een rij gekrompen, Corsair heeft recent mensen moeten ontslagen en overal rommelt het. Volgens Micron en SMIC ziet het er allemaal niet rooskleurig uit:

quote: https://www.standaard.be/cnt/dmf20220812_97534635

Maar na twee jaar van ongeziene ontwrichting herstellen de aanvoerlijnen zich stilaan. Dat komt onder meer doordat de vraag naar halfgeleiders snel daalt, rapporteerde Micron Technology deze week, nadat de Amerikaanse chipproducent net als concurrent Nvidia had gewaarschuwd voor een verwachte omzetdaling. ­Micron ziet hoe steeds meer klanten minder chips bestellen en hun voorraden ‘aanpassen’. Het aandeel verloor prompt 4,7 procent op de beurs, en sleurde sectorgenoten mee in zijn val – waaronder ook het Nederlandse ASML, een toeleverancier van producenten die al bij de voorstelling van de laatste kwartaalresultaten in juli de groei­verwachtingen voor dit jaar bijstelde en zag hoe ‘sommige klanten signalen zien van een vertragende vraag in consumentengoederen’.

Spreken de Amerikaanse en ­Europese chipproducenten nog in voorzichtige termen van een terugval, dan is Zhao Haijun, de co-ceo van Semiconductor Manufacturing International Corp (SMIC) – de grootste ­ Chinese producent van halfgeleiders – meer uitgesproken. In een gesprek met investeerders zei hij vrijdag dat de wereldwijde economische neergang tot een ‘snelle bevriezing’ en ‘plotse stop van bestellingen’ leidt. De SMIC-topman wees daarbij naar de ­dalende vraag van consumentengoederen, zoals smartphones of spelconsoles, die tijdens corona erg gegeerd waren, maar sinds het opheffen van de restricties vaker aan de kant blijven liggen.

[DaniëlWW2]

Ik wou toch eens doorrekenen. Helaas is de (erg fijne) CALY wafer calculator op het moment offline.

Als ik met een mindere calculator dan reken met 20mm breed en 16mm hoog (320mm2) kom je uit op iets v van 170 chips uit een wafer. Met defect density van 0,1sq.cm kom je op ongeveer 120 goede chips.
Vervolgens voor de MCD neem ik 5mm x 8mm (40mm2) en hier kijk je naar 1400+ goede chips per wafer. Navi 21 is 520mm waarmee je iets van 100 chips uit een wafer haalt, waarvan circa 60 goed zijn.
Ook maar Navi 32 gedaan omdat ik interessanter blijf vinden. 16mm x 13mm (208mm2) genomen en dan kom ik op ongeveer 220 goede chips.

Vervolgens ga ik Navi 21 elk voordeel geven door te stellen dat N7 wafers nog $9000 kosten. Het was voor corona blijkbaar $9300 en met de prijsstijgingen is het waarschijnlijk fors meer geworden. Ook geef ik Navi 21 80 chips per wafer. N5 was destijds bijna $17000, maar ik maak er $20.000 van. Ook maak ik $12.000 voor de MCD wafers op N6.

Krijg je dus:
Navi 31: $217
GCD = $166
MCD (6x) = $51
Navi 32: $124
GCD = $90
MCD (4x) = $34
Navi 21 = $112

Dit is alles behalve eerlijk. Ik gaf Navi 21 twintig extra salvage chips en Navi 31 niets. Ook zijn de kosten oneerlijk in het voordeel van Navi 21 verlaagd/potentieel te hoog voor Navi 31/32.

Eigenlijk zou ik nog wat verder willen doorrekenen als de CALY wafer calculator weer online is. Want een snelle inschatting zegt ook wel dat AMD zelfs met nadelige berekeningen, al snel goedkoper uit moet vallen dan Nvidia.

[ZenTex]

XWB schreef op zaterdag 13 augustus 2022 @ 13:32:
[...]


Wie gaat al die spullen kopen? De PC-markt is al twee kwartalen op een rij gekrompen,

De PC markt ja.

Maar AMD levert ook console chips, server, doet het heel goed ten koste van Intel. Oh, en de nieuwe CPU's met IGPU kan een geheel nieuwe OEM client markt aanboren.
Ohja, AMD heeft ook nog eens Xilinx erbij, dat is heel wat silicon.

[XWB]

@ZenTex Het rommelt in alle markten, de vraag naar consoles neemt ook af. De verwachting is dat de wereldeconomie gaat krimpen, de gevolgen zullen dan overal doorsijpelen.

[DaniëlWW2]

ZenTex schreef op zaterdag 13 augustus 2022 @ 13:37:
[...]


De PC markt ja.

Maar AMD levert ook console chips, server, doet het heel goed ten koste van Intel. Oh, en de nieuwe CPU's met IGPU kan een geheel nieuwe OEM client markt aanboren.
Ohja, AMD heeft ook nog eens Xilinx erbij, dat is heel wat silicon.

En AMD lijkt behoorlijk gelimiteerd te zijn in productiecapaciteit met als slachtoffers zeker de videokaarten en waarschijnlijk ook laptop APU's. Dat probleem is ook verdwenen. Waar Nvidia en Intel erg negatief waren, was AMD juist positief over H2/2022. En dat begrijp ik wel als je een beetje ziet wat hun portfolio op het moment is. Ze zijn bijna overal competitief of zeer competitief. De strategie daar lijkt te zijn om in een krimpende markt, alsnog marktaandeel te pakken.

[ZenTex]

DaniëlWW2 schreef op zaterdag 13 augustus 2022 @ 13:41:
[...]


als je een beetje ziet wat hun portfolio op het moment is. Ze zijn bijna overal competitief of zeer competitief. De strategie daar lijkt te zijn om in een krimpende markt, alsnog marktaandeel te pakken.

Inderdaad.

Intel is de lul, want ondanks de excuses van het Intel management over economic headwinds is het AMD dat groeit ten koste van Intel.

@XWB Consoles zaten tot voor kort nog steeds met tekorten. Verder is de verwachting dat consoles verder groeien, evt ten koste van PC gaming, wat de laatste tijd wel erg duur geworden is.
Enfin, consoles levert niet veel op, maar zorgt wel voor een enorme vraag naar console chips.

Waar Client en PC gaming het nu slecht doen, blijft de vraag naar server enorm, die groeit door en wederom groeit AMD hier flink in en voor een deel ten koste van Intel, dt nog steeds geen antwoord op Epyc heeft.
Hiervan pikt Xilinx natuurlijk ook een graantje van mee, wederom, heel wat silicon.

Heb je de Q2 resultaten van Intel en Nvidia gezien? Huilen met de pet op, maar AMD bleef gewoon groei rapporteren. Ja, de gouden tijden zijn voorbij, maar AMD zat met een fiks capaciteitsprobleem. Nu zullen ze kunnen leveren wat de markt vraagt ipv nee te moeten verkopen, en omwille van continuiteit zal AMD het waarschijnlijk liever met wat minder marge doen dan nee te moeten verkopen, vooral in server.

[XWB]

Juist SMIC ziet dat de vraag naar (onder andere) consoles afneemt, ik zou dan ook vraagtekens zetten bij een verwachte groei in deze markt.

De SMIC-topman wees daarbij naar de ­dalende vraag van consumentengoederen, zoals smartphones of spelconsoles, die tijdens corona erg gegeerd waren, maar sinds het opheffen van de restricties vaker aan de kant blijven liggen.

Ook Micron constateert minder vraag naar chips:

­Micron ziet hoe steeds meer klanten minder chips bestellen en hun voorraden ‘aanpassen’. Het aandeel verloor prompt 4,7 procent op de beurs, en sleurde sectorgenoten mee in zijn val – waaronder ook het Nederlandse ASML, een toeleverancier van producenten die al bij de voorstelling van de laatste kwartaalresultaten in juli de groei­verwachtingen voor dit jaar bijstelde en zag hoe ‘sommige klanten signalen zien van een vertragende vraag in consumentengoederen’.

Dit gaat dan over chips die overal en nergens inzitten, van smartphones en consoles tot auto's en switches. Helaas is niet duidelijk hoeveel Micron chips AMD afneemt, alleen dat er een globale trend zichtbaar is.

De verwachting is dat de VS, China en Europa straks gezamenlijk in een economische recessie zitten. Veel mensen zullen dan hun baan verliezen, en dus ook minder spullen kopen. De weg hiernaartoe lijkt al ingezet te zijn.

De servermarkt is er eentje om in de gaten te houden, want die loopt vaak achter op de rest. Zodra de vraag naar diensten (etc) daalt, zullen ook de investeringen in servers afnemen. Ik denk dat dit pas volgend jaar aan de orde zal zijn.

[ZenTex]

Smic levert geen consolechips, misschien in china, maar het is niet echt hun markt. Sowieso doet SMIC het niet echt best QoQ tov 2021, net zoals INTC en NVDA.
Micron produceert vooral geheugen.

Server draait als een tierelier, en zal dit waarschijnlijk nog wel een tijdje blijven doen. En zoals ik al zei, een groot gedeelte van AMD's groei is ten koste van intel. En daar komt Xilinx nog bij.

Dus nogmaals, voorlopig heeft AMD nog heel wat wafers nodig. En hoeveel orders AMD heeft uitstaan bij TSMC en of (en hoeveel) daar in gesneden is zullen we misschien nooit achterkomen.

For the third quarter of 2022, AMD expects revenue to be approximately $6.7 billion, plus or minus $200 million, an increase of approximately 55% year-over-year led by growth in the Data Center and Embedded segments. AMD expects non-GAAP gross margin to be approximately 54% in the third quarter of 2022.

For the full year 2022, AMD continues to expect revenue to be approximately $26.3 billion, plus or minus $300 million, an increase of approximately 60% over 2021 led by growth in the Data Center and Embedded segments. AMD continues to expect non-GAAP gross margin to be approximately 54% for 2022.

Voor Q3 verwacht AMD nog steeds groei, wel flink afgezwakt. Voor Q2 was de guidance bijna spot on met een kleine beat. AMD voelt de markt dus goed aan.

We zijn overgigens flink offtopic aan het gaan, dus ik laat het hierbij.

[Werelds]

sunsmountain schreef op zaterdag 13 augustus 2022 @ 12:58:
Ik heb voor de oppervlaktes gekeken naar 2 Shader Engines, zowel die van Navi21 als Navi23. Interconnects heb ik niet in de GCD opgenomen, ook geen infinity fabric. Dat zit volgens mij allemaal op N6, niet N5.

IF kun je 100% negeren, maar interconnects niet - dat gaat gewoon op hetzelfde procedé en zal blijven (alles moet aan elkaar blijven hangen ).

Als je meteen met de 8 WGP's per SE wil rekenen, zou ik N21 volledig negeren en dan gewoon 1 N23 SE tegelijk nemen, dat rekent makkelijker. Ik denk overigens dat die ~107mm² voor beide te maken heeft met hoeveel pixels je meet, is lastig als je niet 2 identieke afbeeldingen hebt dus doe je niet veel aan. Daarnaast zal een N23 SE meer dan 80% van een N21 SE zijn, omdat het stukje RB/primitive/L1$ identiek is tussen de twee en dat neemt meer ruimte in dan 2 WGP's, dus die 80% is iets te optimistisch. Zal eerder 85-90% zijn.

Die 2 Shader Engines zijn al te groot, want Navi31 heeft er 6, dus 12 in de oude Shader Engines gerekend. Dan kom je op 644,7 mm2 of 424,7 mm2 op 5N, is te groot.

Ik had hier iets anders staan, maar ik besef zojuist wat je hier doet

Je verwart shader engines en shader arrays! Die laatste is een reeks van 5 (of 4 in N23) WGP's, 16 ROPs, een stukje L1$ en een primitive unit. Twee van die dingen maken samen één SE.

- N23 = 2 SE = 4 SA @ 4 WGP elk, totaal van 4 * 4 = 16 WGP (32 CU)
- N21 = 4 SE = 8 SA @ 5 WGP elk, totaal van 8 * 5 = 40 WGP (80 CU)
- N31 = 6 SE = 12 SA @ 4 WGP elk, totaal van 12 * 4 = 48 WGP (96 CU) volgens angstronomics

Dus die 645 van je is het dubbele gerekend


Edit: arrays heeft AMD het overigens niet echt meer over. Met RDNA1 benoemden ze ze wel, maar daarna eigenlijk niet meer. Is ook logisch, omdat die 2 arrays een aantal dingen delen (L1$ bijvoorbeeld). Ik kijk persoonlijk enkel naar SE's en wat daar in zit, want de arrays zijn vooral conceptueel.

[ Voor 9% gewijzigd door Werelds op 13-08-2022 15:42 ]

[sunsmountain]

Werelds schreef op zaterdag 13 augustus 2022 @ 15:38:
[...]

IF kun je 100% negeren, maar interconnects niet - dat gaat gewoon op hetzelfde procedé en zal blijven (alles moet aan elkaar blijven hangen ).

Als je meteen met de 8 WGP's per SE wil rekenen, zou ik N21 volledig negeren en dan gewoon 1 N23 SE tegelijk nemen, dat rekent makkelijker. Ik denk overigens dat die ~107mm² voor beide te maken heeft met hoeveel pixels je meet, is lastig als je niet 2 identieke afbeeldingen hebt dus doe je niet veel aan. Daarnaast zal een N23 SE meer dan 80% van een N21 SE zijn, omdat het stukje RB/primitive/L1$ identiek is tussen de twee en dat neemt meer ruimte in dan 2 WGP's, dus die 80% is iets te optimistisch. Zal eerder 85-90% zijn.


[...]

Ik had hier iets anders staan, maar ik besef zojuist wat je hier doet

Je verwart shader engines en shader arrays! Die laatste is een reeks van 5 (of 4 in N23) WGP's, 16 ROPs, een stukje L1$ en een primitive unit. Twee van die dingen maken samen één SE.

- N23 = 2 SE = 4 SA @ 4 WGP elk, totaal van 4 * 4 = 16 WGP (32 CU)
- N21 = 4 SE = 8 SA @ 5 WGP elk, totaal van 8 * 5 = 40 WGP (80 CU)
- N31 = 6 SE = 12 SA @ 4 WGP elk, totaal van 12 * 4 = 48 WGP (96 CU) volgens angstronomics

Dus die 645 van je is het dubbele gerekend


Edit: arrays heeft AMD het overigens niet echt meer over. Met RDNA1 benoemden ze ze wel, maar daarna eigenlijk niet meer. Is ook logisch, omdat die 2 arrays een aantal dingen delen (L1$ bijvoorbeeld). Ik kijk persoonlijk enkel naar SE's en wat daar in zit, want de arrays zijn vooral conceptueel.

Hoe groot zijn interconnects dan in Navi21/Navi23? Ik zie ze niet direct aangegeven.

Ik deel de pixels die ik meet door de pixels van die afbeelding, dus dat zou tegen elkaar weg moeten strepen. Mogelijk zijn de SE's op het Navi21 plaatje eigenlijk groter dan ingekleurd, of op het Navi23 plaatje eigenlijk kleiner dan ingekleurd. Anyway, het lijkt er op dat 16 CU ongeveer 55 mm2 kost (Navi23) volgens jouw berekening (1 shader engine).

Dan kost 192 CU 660 mm2, 6 nieuwe shader engines = 6x32 = 12x16 = 12 oude shader engines. Ik ken het verschil tussen SE en SA, en dat is hier niet fout gegaan. Belangrijk in het verhaal is de die shrink factor van 1.518, en vervolgens de foezelfactor, waarmee we het snijden van AMD in de CU's zelf proberen te verklaren.

Angstronomics schrijft daar over zelf:

In fact, at the same node, an RDNA 3 WGP is slightly smaller in area than an RDNA 2 WGP, despite packing double the ALUs.

Je kan ook zeggen dat 64 CU a la RDNA3 ongeveer 110 mm2 kost op 7nm, en dan kom je nog veel lager uit op 5nm. Dan heb je wel ruimte voor VCN en PCIe5, command frontend en zo. En interconnects.

[DaniëlWW2]

Er zou nog iets spelen. Niet alleen lijkt Navi 32 een aparte SE configuratie te krijgen, maar het vermoeden bestaat ook dat Navi 31/32 ook een vergrote register file per SIMD32 krijgen. Als dit ook klopt dan gaan we denk ik helemaal iets interessants zien. We zijn gewend geraakt aan het idee van een aantal blokken die worden gedupliceerd op een node. Maar op deze manier begint het erop te lijken dat Navi 31/32/33 allemaal uniek gaan zijn met hun eigen kleine optimalisaties en aanpassingen per chip. Dit verdeeld over twee nodes en MCM voor twee van de chips.

Another amazing leak from SkyJuice! The perf/area of RDNA3 looks incredible, even down to min-maxing N32 as 3SE * 10WGP vs 4SE *8WGP. The die area of N33 also lends credence to my previous leak of different design CU designs... https://t.co/ZQ6GGguhwS

— Kepler (@Kepler_L2) 13 augustus 2022

...with N33/PHX having a Vector Register File of 128KB (same as all RDNA1/2 GPUs) and N31/N32 having a beefier VRF at 192KB. This could allow for some very interesting perf scaling at the high end. I'm also looking forward to the clock speeds being leaked soon, fun times ahead😉

— Kepler (@Kepler_L2) 13 augustus 2022

[ Voor 34% gewijzigd door DaniëlWW2 op 13-08-2022 18:59 ]

[Werelds]

sunsmountain schreef op zaterdag 13 augustus 2022 @ 15:59:
Hoe groot zijn interconnects dan in Navi21/Navi23? Ik zie ze niet direct aangegeven.

Die zijn ook niet aangegeven. Al die "loze" ruimte zit vol met lijntjes tussen verschillende onderdelen. Met andere woorden, die loze ruimte zul je min of meer in z'n geheel mee moeten nemen. Niet alleen tussen WGP's en hun RB's/primitives, maar ook tussen SE's en GCP/L2$. Op zichzelf is dat nergens veel, maar het telt wel vrij rap door.

Ik deel de pixels die ik meet door de pixels van die afbeelding, dus dat zou tegen elkaar weg moeten strepen. Mogelijk zijn de SE's op het Navi21 plaatje eigenlijk groter dan ingekleurd, of op het Navi23 plaatje eigenlijk kleiner dan ingekleurd. Anyway, het lijkt er op dat 16 CU ongeveer 55 mm2 kost (Navi23) volgens jouw berekening (1 shader engine).

Zelfs met AMD's CGI afbeeldingen zit er verschil in hoe ze het inkleuren. Neem deze voor N23 (dat is waar dat opgetekende plaatje vandaan komt) en deze van AMD zelf. Merk op hoe de WGP's volledig anders ingekleurd zijn: bij N23 hebben ze een lang blok aan 1 kant en vervolgens 2-3-2-3-2 kleinere blokjes. Bij N21 is dat lange blok omsingeld door 7 kleinere blokjes en zijn er nog eens 2 aan het eind. Neem dat dus nooit te letterlijk, tenzij het een IR shot is. Helaas zijn die er maar zelden

Dan kost 192 CU 660 mm2, 6 nieuwe shader engines = 6x32 = 12x16 = 12 oude shader engines. Ik ken het verschil tussen SE en SA, en dat is hier niet fout gegaan. Belangrijk in het verhaal is de die shrink factor van 1.518, en vervolgens de foezelfactor, waarmee we het snijden van AMD in de CU's zelf proberen te verklaren.

Angstronomics schrijft daar over zelf:

Maar dat is juist waarom ik je van die CU's af probeer te krijgen

Het zijn niet 192 CU's; het zijn 96 CU's, waar enkel het aantal ALU's verdubbeld is, wat ze zelfs in RDNA2 niet meteen dubbel zo groot had gemaakt, omdat niet álles verdubbeld wordt (meer registers en een grotere L0$ voor vectors zou het minimale zijn; denk dat je dan ~40% meer ruimte nodig zou hebben). Net zoals één RDNA1/2 WGP kleiner is dan 2 GCN CU's samen - laat staan de ruimte die 2 CU's in GCN daadwerkelijk in nemen omdat je niet elke CU aan de rest van de die hoeft te koppelen. Om bij angstronomics te blijven, voor N31 zeggen zij:

48 WGP (96 legacy CUs, 12288 ALUs)
6 Shader Engines / 12 Shader Arrays

Het equivalent voor N21 is:

40 WGP (80 legacy CUs, 5120 ALUs)
4 Shader Engines / 8 Shader Arrays

Ik weet ook niet wat je met "oude" en "nieuwe" shader engines bedoelt, maar er zijn er gewoon geen 12, bij geen van beide; N31 heeft wel 12 arrays, maar daar heeft N21 er dus ook al 8 van. Wat angstronomics zegt is dat er 128 ALUs per "CU" zijn; of beter gezegd, 256 per WGP, tegenover 128 in RDNA2. En volgens andere geruchten is dat gewoon 8xSIMD32, in plaats van 4. Niet 4 "CU" in een WGP, want dan zou ook texture units, scalar units + registers, LDS, enzovoort verdubbelen en daar heeft nog niemand naar gehint.

Juist met die quote over de grootte betekent dat dat je in principe een N23 SE kunt nemen en dat maal 6 doen en dan heb je wat N31 op N7 geweest zou zijn, volgens angstronomics. Als je echt heel precies wil gaan doen kun je ook 1 WGP meten, dat maal 48 doen, grootte van de RB/L1$/primitives er bij optellen en je hebt grofweg je nieuwe SE. Die 12 en 192 zijn gewoon niet correct in het hele verhaal, als je naar angstronomics kijkt

De enige reden dat AMD bij RDNA überhaupt CU's noemt is om de backward compatibility met GCN aan te geven. Het is echter geen losstaand blok zoals in GCN en je kunt die dus ook niet vermenigvuldigen. Zelfs qua logische indeling klopt er van alles niet: een RDNA CU bevat 2 schedulers in plaats van 1 (maar wel veel kleiner), heeft wél een lokale L0$I die GCN níet had (maar deelt die met de andere helft van de WGP; in GCN zat de L0$I er buiten en was gedeeld tussen 4 CU's), 2 sets scalar register die 2,5 keer zo groot zijn als in GCN voor de 2 (in plaats van 1) scalar units, vector registers die volledig anders in elkaar steken, een vector L0$ in plaats van lokale L1$ (die nu buiten de WGP's zit), en zo kan ik nog wel even door gaan

[sunsmountain]

Werelds schreef op zaterdag 13 augustus 2022 @ 18:43:
[...]

Die zijn ook niet aangegeven. Al die "loze" ruimte zit vol met lijntjes tussen verschillende onderdelen. Met andere woorden, die loze ruimte zul je min of meer in z'n geheel mee moeten nemen. Niet alleen tussen WGP's en hun RB's/primitives, maar ook tussen SE's en GCP/L2$. Op zichzelf is dat nergens veel, maar het telt wel vrij rap door.

Ah, ik vroeg me al af wat er in de loze ruimte zou zitten, want het is best een oppervlak, iets van 10%.

Werelds schreef op zaterdag 13 augustus 2022 @ 18:43:
Maar dat is juist waarom ik je van die CU's af probeer te krijgen

Het blijven dual CU's, ik weet het alleen krijgen ze RDNA3 8 SIMDs ipv 4 SIMDs, in mijn CU-wereld 4 en 2

Werelds schreef op zaterdag 13 augustus 2022 @ 18:43:

Ik weet ook niet wat je met "oude" en "nieuwe" shader engines bedoelt, maar er zijn er gewoon geen 12, bij geen van beide; N31 heeft wel 12 arrays, maar daar heeft N21 er dus ook al 8 van. Wat angstronomics zegt is dat er 128 ALUs per "CU" zijn; of beter gezegd, 256 per WGP, tegenover 128 in RDNA2. En volgens andere geruchten is dat gewoon 8xSIMD32, in plaats van 4. Niet 4 "CU" in een WGP, want dan zou ook texture units, scalar units + registers, LDS, enzovoort verdubbelen en daar heeft nog niemand naar gehint.

Volgens heb ik geen 4CU per WGP gezegd, zo wel, sorry. Als je niet weet wat ik bedoel, laat ik het toelichten: als Navi31 opgebouwd zou zijn uit RDNA2 dual CU's en Shader Engines, te weten Navi23 = 2 Shader Engines en 16 dual CU's, dan zou Navi31 bestaan uit 6x dat, dus 12 Shader Engines en 96 dual CU's, oude stijl. De CU's kloppen wel, de SE's niet, maar daar ging het niet om. Het ging om 6x het oppervlakte vermenigvuldigen van een deel van Navi23 voor de GCD. Vandaar.

Werelds schreef op zaterdag 13 augustus 2022 @ 18:43:
... en zo kan ik nog wel even door gaan

Weet ik, vind ik leuk, leer ik van.

[sunsmountain]

DaniëlWW2 schreef op zaterdag 13 augustus 2022 @ 17:04:
Er zou nog iets spelen. Niet alleen lijkt Navi 32 een aparte SE configuratie te krijgen, maar het vermoeden bestaat ook dat Navi 31/32 ook een vergrote register file per SIMD32 krijgen. Als dit ook klopt dan gaan we denk ik helemaal iets interessants zien. We zijn gewend geraakt aan het idee van een aantal blokken die worden gedupliceerd op een node. Maar op deze manier begint het erop te lijken dat Navi 31/32/33 allemaal uniek gaan zijn met hun eigen kleine optimalisaties en aanpassingen per chip. Dit verdeeld over twee nodes en MCM voor twee van de chips.

[Embed]
[Twitter]

Waarvoor zou een 192 KB Vector Register L0 cache nuttig zijn? Op zich als de SIMD van 4 naar 8 gaan voor een dual CU, heb je het al over 8x128 = 1024 KB L0 register cache ipv de huidige 4x128 KB. Zou de extra 64 KB bijvoorbeeld nuttig zijn voor ray tracing berekeningen?

[Werelds]

sunsmountain schreef op zaterdag 13 augustus 2022 @ 19:34:
Volgens heb ik geen 4CU per WGP gezegd, zo wel, sorry.

Je had het over 192 CU's, wat met 48 WGP's op 4 CU per WGP uit zou komen

Als je niet weet wat ik bedoel, laat ik het toelichten: als Navi31 opgebouwd zou zijn uit RDNA2 dual CU's en Shader Engines, te weten Navi23 = 2 Shader Engines en 16 dual CU's

Echter is Navi 23 2 Shader Engines, met 8 WGP's (Dual CU) en 16 CU's

dan zou Navi31 bestaan uit 6x dat, dus 12 Shader Engines en 96 dual CU's, oude stijl.

Hmm, nee, waarom? Omdat het aantal SIMD's per "CU" verdubbelt? Dat zijn enkel ALU's (en registers), niet de rest. Als je niet zou "weten" (in de zin dat dat in die post van angstronomics staat) dat het 8 WGP per SE, met 6 SE voor Navi 31 is, zou je alsnog niet zo door moeten rekenen. Jij verdubbelt namelijk niet alleen de hele WGP's (wat dus al niet helemaal klopt), je verdubbelt op die manier ook primitives/RB's/L1$, dus je verdubbelt méér dan hetgeen er "bevestigd" is.

Wat er namelijk staat is dat je van zoiets:



Naar zoiets gaat:


Ik weet het, prachtig werk, dank u, dank u.

En daarbuiten (in de rest van de SE) niets anders.

De CU's kloppen wel, de SE's niet, maar daar ging het niet om. Het ging om 6x het oppervlakte vermenigvuldigen van een deel van Navi23 voor de GCD. Vandaar.

Die 6 klopt wel, echter moet je dat dus gewoon voor 1 SE doen en niet 2

Sterker nog, als de nieuwe WGP's daadwerkelijk even groot zijn op dezelfde node, krimpt de SE perfect, want het is onwaarschijnlijk dat ze aan de RB's en dergelijke iets gaan veranderen (wellicht de L1$ iets groter, maar ROP's/primitives waarschijnlijk niet). Wat betekent dat de huidige SE in Navi 23 dus nóg beter werkt als vergelijkend materiaal.

sunsmountain schreef op zaterdag 13 augustus 2022 @ 19:50:
Waarvoor zou een 192 KB Vector Register L0 cache nuttig zijn?

Klein detail: ze hebben het over de register files (die hangen rechtstreeks aan de ALU's), niet de L0 vector cache. Dat laatste is slechts 32 KB per WGP. AMD heeft nogal wat data structuren

Op zich als de SIMD van 4 naar 8 gaan voor een dual CU, heb je het al over 8x128 = 1024 KB L0 register cache ipv de huidige 4x128 KB. Zou de extra 64 KB bijvoorbeeld nuttig zijn voor ray tracing berekeningen?

Betekent vooral dat er meer data kan blijven "hangen" in de registers voor opeenvolgende ops. Daarnaast worden nu 2 VGPR's naast elkaar gebruikt als 1 64-bit register, hoewel dat voor graphics niet echt boeiend is.

[DaniëlWW2]

sunsmountain schreef op zaterdag 13 augustus 2022 @ 19:50:
[...]

Waarvoor zou een 192 KB Vector Register L0 cache nuttig zijn? Op zich als de SIMD van 4 naar 8 gaan voor een dual CU, heb je het al over 8x128 = 1024 KB L0 register cache ipv de huidige 4x128 KB. Zou de extra 64 KB bijvoorbeeld nuttig zijn voor ray tracing berekeningen?

Ten eerste is dit per SIMD32. Er is geen SIMD van 4 naar 8. Het zou van 4x naar 8x SIMD32 per WGP gaan. Vergeet CU ook gewoon, dat lijkt nu echt compleet achterhaald te gaan worden.

Tweede is dat het dit is.


Dat is een SIMD specifiek register waaruit de SIMD data kan trekken die nodig is voor nieuwe berekeningen. De reden waarom je dit zou vergroten is omdat naarmate een GPU groter word, je op een gegeven moment last krijgt van wachttijden omdat een berekening een stukje data mist. Dit is een van de redenen waarom grotere GPU's nooit lineair meesschalen. Dat AMD dit nu lijkt aan te pakken voor hun grotere chips, zegt ook wel iets over het oog voor detail en optimalisatie per SKU die er lijkt te komen. En ja, dit zou zeker een impact moeten hebben voor RT, juist voor RT.

RT is nu per definitie hybride. Je pakt een volledig gerenderd object en je laat er in feite nu boxes op los. Dit zijn Bounding Volume Hierarchies. Dit is een proces dat je een aantal keer herhaald totdat het object afdoende is ingedeeld. Vervolgens laat je het absoluut minimale aantal rays los op elke box. Die "bouncen" vervolgens op het object en dan heb je een ray die je kan tracen, RT dus. Vervolgens moet je het beeld ook denoisen omdat het er anders verschrikkelijk uitziet omdat je met geen mogelijkheid afdoende rays kan casten met huidige hardware. Dit is zeer data intensief.

Het is eigenlijk dit:

Juist omdat voor AMD het logisch is om aan te nemen dat ze RT blijven doen met hun ALU's en een alternatief renderpad in hun TMU's, gaat die extra cache hier ook helpen. Immers wil AMD eigenlijk geen fixed function hardware hebben die extra ruimte inneemt en proberen ze hun spul zo veelzijdig mogelijk te maken.

Een ander is trouwens dat RDNA3 ook WMMA instructies gaat ondersteunen. Mijn persoonlijke vermoeden is dat ze hiervoor de "trans units" gaan opwaarderen en hiermee ook denoising gaan doen.
Zie: https://videocardz.com/ne...itecture-amds-tensor-core

---

Onder de streep (pun intended ) denk ik dat AMD zeker ook hun RT performance niet zal negeren.

[sunsmountain]

Werelds schreef op zaterdag 13 augustus 2022 @ 20:50:
[...]

Je had het over 192 CU's, wat met 48 WGP's op 4 CU per WGP uit zou komen


[...]

Echter is Navi 23 2 Shader Engines, met 8 WGP's (Dual CU) en 16 CU's

Je bent in de war met Navi24 , Navi23 heeft 16 WGP / dual CU en 32 CU in totaal:
https://www.techpowerup.com/gpu-specs/amd-navi-23.g926

Werelds schreef op zaterdag 13 augustus 2022 @ 20:50:
Hmm, nee, waarom? Omdat het aantal SIMD's per "CU" verdubbelt?

Nee, omdat ik het oppervlak weet van een bestaande 2SE en 16WGP/32 CU. Daarom doe ik dat x6.

Werelds schreef op zaterdag 13 augustus 2022 @ 20:50:
Dat zijn enkel ALU's (en registers), niet de rest. Als je niet zou "weten" (in de zin dat dat in die post van angstronomics staat) dat het 8 WGP per SE, met 6 SE voor Navi 31 is, zou je alsnog niet zo door moeten rekenen. Jij verdubbelt namelijk niet alleen de hele WGP's (wat dus al niet helemaal klopt), je verdubbelt op die manier ook primitives/RB's/L1$, dus je verdubbelt méér dan hetgeen er "bevestigd" is.

Nou, dat verklaart dan ook waarom er zoveel ruimte te vinden is om zaken weg te snijden door AMD


Ik weet het, prachtig werk, dank u, dank u.

Werelds schreef op zaterdag 13 augustus 2022 @ 20:50:

Klein detail: ze hebben het over de register files (die hangen rechtstreeks aan de ALU's), niet de L0 vector cache. Dat laatste is slechts 32 KB per WGP. AMD heeft nogal wat data structuren

Ah ja, klopt, cache != register. En dan ook nog twee voor scalars.

Werelds schreef op zaterdag 13 augustus 2022 @ 20:50:

Betekent vooral dat er meer data kan blijven "hangen" in de registers voor opeenvolgende ops. Daarnaast worden nu 2 VGPR's naast elkaar gebruikt als 1 64-bit register, hoewel dat voor graphics niet echt boeiend is.

Thanks, maar gaan ze dan ook hun dispatchers verdubbelen, zodat ze meer ops achter elkaar kunnen doen? Of willen ze gewoon nuttige occupancy (nog verder) verhogen?