sunsmountain schreef op vrijdag 17 november 2023 @ 22:39:
- 580: 65,7 FPS door 2304 ALU bij 1340 MHz
- 5600 XT: 102,5 FPS door 2304 ALU bij 1560 MHz
56% meer FPS
16% door kloksnelheid
34% door architectuur
(1,56 delen door 1,16 geeft 1,34, je mag % niet van elkaar aftrekken en zeggen 40%)
Excuus, had procent
punt moeten zeggen

- 580: 65,7 FPS door 2304 ALU bij 1340 MHz
- 6600 XT: 133,8 FPS door 2048 ALU bij 2589 MHz
104% meer FPS
72% door kloksnelheid
19% door architectuur
(2,04 delen door 1,72 geeft 1,19)
Ok geen 0%, maar dit (19% dus) is wat ik bedoelde met ~0%. Ik had alleen de frequenties door elkaar gedeeld in m'n hoofd, zonder het verschil in CU units te verrekenen voor de throughput.
Maar dan kom je bij m'n andere punt, dat de 6600 XT dat nog steeds met een kleiner stroombudget doet maar wel richting het dubbele aan kloksnelheid gaat - en uiteraard RT heeft. TDP's van de twee RDNA GPU's is 160W, Polaris is 185W; de 5600 XT piekt gemeten op 175W, de 6600 XT op 185W en de 580 deed dat op zo'n 200-210W. Iets van die winst komt uit het gebruik van 4 GDDR6 chips in plaats van 8xGDDR5, dat zal rond de 12W zijn.
Zoals ik al zei, RDNA2 had een geheel andere focus

Als je de percentages netjes deelt, kom je op 19-34% voor de architectuur van RDNA1/2 tov GCN5. Dat stelt me toch een beetje teleur t.o.v. de "2xSIMD32 in plaats van 4xSIMD16" x2 lineair belofte. Kloksnelheid maakt daarentegen meer van haar lineair belofte waar.
[...]
De SIMD in RDNA moet dan wel 2x zo snel gevuld en geleegd worden als in GCN om die productiviteit bij te houden, is dat het geval? En voor oude games, worden threads dan per 16 gegroepeerd? Dan zou RDNA geen verschil maken.
Nee, zo werkt dat helaas niet.
Ik wilde er niet te diep op in gaan (en zal dat nu ook proberen te vermijden; er is veel lees-/kijkmateriaal hierover dus ik ga het alsnog extreem versimpelen!), maar het zit een beetje aan beide kanten: devs en drivers, want de één groepeert dingen en de ander probeert die groepen te optimaliseren. GCN werkte in de werkelijkheid met wave64, dus één wave kostte 4 kloktikken om af te werken op een SIMD16 (ik had het over 32 in 2 tikken om het simpel te houden, maar dat bestond helemaal niet met GCN

). Echter deden ze ook min of meer 4 waves tegelijk. Het voordeel van die aanpak was dat wanneer er veel verschillende instructies waren, dat weinig impact had. Vergeet niet waar SIMD voor staat: Single Instruction, Multiple Data. Dat betekent dat veel verschillende instructies betekent dat je veel moet wisselen; en als al die instructies niet "perfect" zijn (dus allemaal 32 stukjes data) heb je ALU's stil liggen. Met de kleinere SIMD's wilde AMD dat af vangen en dat werkte deels, vooral in het begin.
Probleem is echter dat die 32 de sweet spot blijkt te zijn
Die optimalisaties is ook waarom RDNA3 waarschijnlijk nog een stuk performance op de plank heeft liggen, omdat de compiler (in de driver) niet genoeg kansen voor dual-issue weet te vinden. Maar devs kunnen daar ook specifiek voor optimaliseren...maar beide gevallen zijn best ingewikkeld
En ja, RDNA2+ in z'n algemeen is heel erg gericht op data aanvoer, dus die ALU's worden goed gevoerd. RDNA1 was de grote architectuur wijziging, RDNA2 was o.a. gericht op betere bezetting.
Ik ben wat meer van de benaderingen, jij wat meer van de precieze aansturing, maar ik zeg niet dat theoretische throughput = praktische game performance. Ik probeer game performance wel te begrijpen op basis van de eigenschappen van kaarten. Volgens jou mag je bijvoorbeeld geen 32 CU zeggen voor een 6600XT maar moet het precies 16 dual CU zijn. Ik ben wat rekkelijker en vind 32 CU prima om de 6600XT in stukjes te hakken en die (CU) stukjes (AMDs eigen benaming) te vergelijken met de stukjes van andere architecturen.
Even los van dat verhaal, kun je een CU van RDNA simpelweg niet 1:1 vergelijken met een CU van GCN, of een CU (eender welke) met een SM - want ze zitten allemaal heel anders in elkaar
Als AMD en Nvidia over 3 jaar besluiten dat een CU/SM voortaan uit een enkele SIMD64 bestaat met daarnaast 4 RT units omdat dat beter blijkt te werken voor RT, zal dat voor raster werk juist minder uitpakken. En dan zou je een GPU met 80 CU/SM wel met iets van de huidige generatie kunnen vergelijken, maar dat gaat dan niet werken.
Nog wat voorbeelden uit die grafiek:
- GP106 (GTX 1060), 10 SM's, 1280 ALU's op 1708 MHz - 71% van de FP32 throughput, maar hij haalt er hetzelfde uit.
- Vega 56: 56 CU's, 71% meer FP32, komt maar 54% uit.
- 2070: 36 SM's, 21% meer FP32, 75% sneller.
- 3060: 28 SM's, 106% meer FP32, "slechts" 82% sneller ondanks "meer" ALU's met 128 per SM
Op basis van CU's/SM's én ALU's zouden de 2070 en de RX 580 gelijkwaardig moeten zijn, klopt uiteraard geen drol van want daar wordt geen rekening gehouden met het feit dat Turing ook 64 onafhankelijke INT32 cores per SM heeft, in tegenstelling tot alle andere (vandaar de winst over Pascal; GP106 presteert 32% bovenverwacht, TU106 en TU116 rond de 45%). Anderzijds heeft GA104 op papier wel "128" FP32 ALU's per SM en zou hij dus volledig gehakt moeten maken van de rest (behalve Vega56), in de praktijk moet de helft daarvan ook INT32 voor hun rekening nemen dus vandaar dat hij zo dicht op Turing zit. Op basis van CU's zou Vega 56 ook weer gehakt moeten maken van al het andere, behalve GA104.
Daarnaast is, zoals ik zei, niet elke generatie gericht op meer prestaties. Bij RDNA2 was dat helemaal het doel niet, ze moesten daar hogere kloksnelheden halen om met RT om te kunnen gaan. Dat er dan toch nog iets van winst uit kwam is een klein gelukje.
En puur als oefening: probeer jouw aanpak eens op Intel toe te passen?

Niet alleen inhoud en aansturing, ook de bottlenecks. En binnen een groep van videokaarten van dezelfde architectuur, probeer ik toch een lineair begrip te krijgen van hoeveel beter maakt "meer motortjes" de krachtigere videokaart? Of hoeveel meer cache, VRAM, TMUs, etc.
Met name ook om toekomstige performance beter te voorspellen. Maar in dit geval om de tweedehandsjes beter te begrijpen.
Maar dat is het probleem juist: GPU's zijn niet zo simpel. Er is geen enkel lineair verband, tenzij je architectuur niet/nauwelijks verandert. Ampère en Ada kun je gerust naast elkaar zetten, dat is gewoon dezelfde architectuur. En dan mag Nvidia wel claimen dat de RT cores van Gen Y twee keer zo snel zijn als Gen X, ze kunnen ze duidelijk ook niet snel genoeg van data voorzien dus dat heeft dan 0,0 effect. Net zoals AMD's dual issue vooralsnog niet effectiever is dan Nvidia's mixed type ALU's. Maar verder dan zulke gevallen kun je vaak niet vergelijken. Niet binnen één vendor, maar al helemaal niet tussen verschillende vendors.
Daarnaast is de workload ook belangrijk. RDNA3 is bijvoorbeeld sneller in RT dan RDNA2 (10-20% afhankelijk van het spel; de ene RT workload is de andere niet) met even veel RA's, terwijl er op raster gebied nauwelijks winst te vinden is.
Om één van je andere voorbeelden te nemen, meer cache zegt ook niets op zichzelf, want ondanks de gigantische cache bump van Ada, helpt ze dat niet veel. Ja, latency is lager, maar dat lost hun problemen met bezetting niet op, dat is namelijk een scheduling probleem. Bij AMD daarentegen zie je dat de sprong van 32 MB naar 80 MB IC meer uit de aanwezige ALU's weet te halen, hun ALU's zijn dus vooral data-starved.