M-spec schreef op zondag 30 oktober 2022 @ 12:50:
Ga je bij de verhouding tussen generaties zelf uit van hoeveelheid transistoren en 4K-prestaties of andere factoren zoals FPS per Watt? Is kan ook niet snel ergens een soort IPC vergelijk vinden. Zou wel interessant zijn als men de GPU's op een zelfde kloksnelheid tegen elkaar test.
Niet zozeer het aantal transistors an sich, wel het aantal ALU's en wat er theoretisch uit zou moeten komen op een gegeven kloksnelheid (FLOPS). En als vergelijkingsmateriaal dan TPU's cijfers voor average FPS gebruiken. Het is eerder iets als FPS per TFLOP ofzo.
Nu heb ik over dat laatste sowieso al vaak gezegd dat Nvidia's cijfers 100% onzin zijn. De 40 TF die ze op geven voor een 3090 Ti zit er theoretisch wel in, maar door de manier waarop Ampère werkt ga je dat er nooit uit krijgen, zelfs niet met volledig synthetische workloads. Zodra je ook maar één integer OP hebt, verlies je meteen ergens 16 FP32 ops. Dat betekent geen branching, oppassen met moves, enzovoort.
Als je bij Pascal begint, had GP102 32 "CUDA cores" per partitie; 4 partities per SM, dus 128 in totaal per SM. Aanhalingstekens omdat de term "CUDA core" ambigu is. Wat dat precies betekent is door de jaren heen veranderd en dit is dan ook de enige keer dat ik de term gebruik omdat Pascal's ALU's nog iets van INT konden doen, waar de "CUDA cores" in latere GPU's enkel FP32 (en soms 2xFP16) kunnen doen. En pre-Maxwell waren ze ook weer anders.
Enfin, met Turing hebben ze in de SM's wat dingen veranderd. Waar GP102 1 scheduler en 2 dispatch units per partitie had (en ze dus 2 instructies per clock aan de ALU's én SFU's én LD/ST units konden uitdelen -
per partitie), had TU102 slechts 1 scheduler en 1 dispatch unit. Verder zakten ze nu naar 16 pure FP32 ALU's, met daarnaast 16 pure INT32 ALU's, 2 Tensor Cores, en half zo veel LD/ST en SFU. De denkwijze daarachter was dat ze voor elke 100 FP32 ops gemiddeld 36 INT32 ops zagen, dus door dat te splitsen wilden ze ~36% meer FP32 throughput realiseren. In de praktijk kwam dat er niet helemaal uit, maar wel redelijk. Op 2160p is een 2080 Ti ~45% sneller dan een 1080 Ti, terwijl de te verwachten sprong op basis van theoretische FP32 throughput zo'n ~20% is. 25 procentpunten meer is dus best aardig. Het grote punt is echter dat TU102 met 64 FP32 ALU's per SM niet onderdeed voor GP102's 128 ALU's per SM. In totaal heeft TU102 wel 128 ALU's per SM, maar ze zijn 50/50 gesplitst tussen FP32 en INT32.
Met Ampère hebben ze weer 64 (16 per partitie) FP32 ALU's toegevoegd, maar cruciaal is dat die in hetzelfde blok als de INT32 ALU's zitten. Ze kunnen óf die INT32 ALU's aansturen, óf de extra FP32 ALU's. Een SM in GA10x heeft dus 192 ALU's in totaal, maar die kunnen niet allemaal aangestuurd worden. Gevolg is dat hoewel Nvidia claimt dat Ampère het dubbele aan FP32 uit kan voeren, gooit hun eigen opmerking bij TU102 dat er voor elke 100 FP32 ops ook ~36 INT32 ops zijn, ook roet in het eten. Die extra FP32 ALU's worden slechts een deel van de tijd aangestuurd. In de praktijk betekent dat dat een 3090 Ti op papier 40 TFLOPS zou moeten kunnen doen, waarmee hij net geen 3 keer zo snel is als TU102 met slechts 13,4 TFLOPS...maar als je dan gaat kijken presteert het ding op 2160p geen 200% beter, maar slechts 64%. En op lagere resoluties is dat enkel minder.
Op dezelfde manier kun je vergelijken bínnen een architectuur. Een 2080 Ti is op papier 34% sneller dan een 2080 en in de praktijk 27%. 7 procentpunt verlies dus, maar dat is niets vergeleken met wat Ampère verliest. Een 1080 Ti is op papier ~28% sneller dan een 1080 en in de praktijk zo'n 33%; 5 procentpunt winst dus, maar als je naar 1080p kijkt is het 27% uit 28% (1 procentpunt verlies) en op 1440p 30% uit 28% (2 procentpunt winst), dus dat is vrijwel zeker een bandbreedte probleem voor de kleinere 1080. Doe je datzelfde voor Ampère zie je echter dat zelfs op 2160p er al 17 procentpunt verlies is van een 3070 Ti naar een 3080 - en dat cijfer gaat omhoog hoe groter de GPU wordt. Dus niet alleen verliest Ampère ten opzichte van Turing, het verliest ook ten opzichte van zichzelf; de architectuur schaalt niet omhoog.
Het probleem bij Nvidia is dat enerzijds elke partitie voor minimaal een derde stil ligt op enig gegeven moment; want waar ik het nog niet over heb gehad is dat die ene scheduler + dispatch unit niet alleen de FP32 en INT32 aan moeten sturen...maar dus ook de LD/ST, SFU, de Tensor Core, texture units én RT ops naar de speciale scheduler daarvoor moeten sturen. Dus even los van het feit dat ze sowieso al niet alle ALU's aan kunnen sturen, moet de scheduler ook dusdanig veel units aan sturen dat ze daar ook cycles gaan verliezen. En met Ada is daar 0,0, nada, niks, noppes veranderd.
Als je diezelfde methodiek op RDNA 1 en 2 toe past zie je min of meer hetzelfde als bij Pascal en Turing. Binnen de architectuur schaalt het nagenoeg perfect en van RDNA1 naar RDNA2, met als enige verschil dat de "XL" chips boven hun kunnen presteren; de RX 5700 (non-XT) en RX 6800 (non-XT) presteren in verhouding iets beter dan je zou verwachten. Over het geheel gezien zit RDNA2 zo rond Turing qua prestaties, ze persen er beide ongeveer even veel frames per TFLOP uit.
Waar het allemaal op neer komt is dat Ampère en Ada een hoop transistors aan die 64 extra FP32 ALU's per SM spenderen, maar dat dat nauwelijks iets op levert omdat ze het niet aan kunnen sturen. Vervolgens hebben ze nóg een groot probleem in de zin dat hun cache latency dusdanig hoog is dat de SM's ook daardoor veel stil liggen. Pascal, Turing en RDNA zijn gewoon veel efficiënter als het aan komt op het daadwerkelijk gebruiken van de beschikbare ALU's.
Een 3090 Ti heeft op papier 40 TFLOPS uit z'n 10752 ALU's, in de praktijk komt daar ~24 uit (net iets meer dan de 6950 XT met z'n 5120 ALU's). Met andere woorden, als ze half zo veel ALU's (5376) beter aan konden sturen, zouden ze een hoop transistors bespaard hebben. AD102 is nog erger: die presteert ergens als een Turing/RDNA GPU met tussen de 35 en 40 TFLOPS. Op papier heeft dat ding met officiële specs 82,6 TFLOPS; in de praktijk ligt de kloksnelheid (ook weer zo'n bullshit cijfer van Nvidia

) hoger en is het eigenlijk zelfs 88 TFLOPS. Er komt gewoon ruim minder dan de helft uit.
AMD heeft ongeveer even veel transistors gebruikt voor Navi 21 als Nvidia voor GA102, maar het grote verschil is dat AMD's transistors voor een groot deel in de gigantische caches zitten. Die caches hoefden ze sowieso al niet groter te maken voor RDNA3 - maar volgens Angstronomics worden ze zelfs iets kleiner. Dus waar AD102 ~2,7x zo veel transistors als GA102 heeft, zal dat voor AMD vrijwel zeker niet het geval zijn, omdat bij AMD de helft van de RDNA2 die even groot blijft als voorheen (en gesplitst wordt in losse, kleinere dies). Sterker nog, AMD zou zelfs onder de 50 miljard kunnen blijven, maar ze zullen vast meer transistors spenderen aan RT en dergelijke.
RT is een ander verhaal, daar verliest Ada minder ten opzichte van Ampère (en schaalt die laatste binnen z'n eigen architectuur wél min of meer lineair), maar dat komt doordat de RT hardware nog steeds bij lange na niet toereikend is. Dat gezegd hebbende, schaalt Ada ook daar niet 100%. 52% meer RT cores op 35% hogere kloksnelheid zou tot een verdubbeling in prestaties moeten leiden, maar dat doet het ook niet - zelfs niet op 2160p. Dat is uiteindelijk wel gunstig voor AMD, omdat het betekent dat ze daar minder in hoeven te lopen
En doordat zo veel van AD102 stil ligt, valt het verbruik ook mee; als ze iets zouden vinden waarmee ze de GPU beter bezig kunnen houden, blijft dat ding van z'n leven niet op de 350W hangen die hij nu in de meeste games gebruikt, die 450W wordt dan volledig benut. Dat zie je dan ook in Cyberpunk met RT, daar trekt dat ding gewoon alles wat hij mag trekken.
Edit: klein dingetje wat ik over AD102 had willen vermelden maar vergeten ben, maar wel heel erg onder de "brute force" methodiek valt. De grotere L2 cache is precies dat: groter. Niet sneller, enkel groter. En dat lost dus geen moer op, behalve dan iets minder druk op de geheugen controllers...maar dat was toch al geen probleem.