XanderDrake schreef op maandag 28 december 2020 @ 17:33:
Bij Pascal waren het 128 per cluster of SM (de 1080Ti had 3584 shaders over 28 clusters als ik het goed heb) bij Turing waren het er 64 per SM, ondanks dat deze shaders per stuk veel sneller zijn dan die van Pascal. Dit heeft iets met fp32 te maken geloof ik, maar ik zit er waarschijnlijk naast en daar kan iemand van de AMD Discussie Club me vanalles over kan vertellen

Bij Ampere is dit weer 128 als ik Techpowerup mag geloven, en Lovelace heeft hetzelfde maar dan gewoon meer SMs. Beetje jammer, niet efficienter maar gewoon grotere die's, dus duurder over het algemeen.
Niet helemaal. Eerste deel klopt: Pascal heeft 128xFP32 per SM, Turing heeft er 64. Dat heeft echter niets te maken met hoe snel ze zijn, maar juist met de manier waarop Nvidia ze aan wil sturen. Er zijn in Turing ook fors meer SM's; elke SM bevat dan wel minder FP32 units, maar wat er voor de rest de SM zit is ook anders. Het heeft meer te maken met de logische verdeling tussen RT, Tensor en FP32. Ze wilden gewoon 64 FP32 units per RT core hebben
Ampère heeft er nog steeds 64 per SM - pure FP32 ALU's welteverstaan. Wat ik hierboven bewust niet heb vermeld, is dat elke SM in Turing en Pascal ook een evenredig aantal INT32 ALU's heeft. En daar zit het verschil in bij Ampère: nog steeds hetzelfde, echter zijn het nu geen pure INT32 ALU's, dat zijn ALU's die óf INT32 kunnen doen, of FP32.
GA102-300 (3090) heeft dus helemaal geen 10496 shaders zoals Nvidia beweert. Het zijn er 5248, met daarnaast nog eens 5248 units die een deel van de tijd óók FP32 kunnen doen, maar het grootste deel van de tijd zich gewoon gedragen als de pure INT32 in Pascal en Turing.
Samengevat:
- GP102-350 (1080 Ti): 3584 FP32 + 3584 INT32
- TU102-300 (2080 Ti): 4352 FP32 + 4352 INT32
- GA102-300 (3090): 5248 FP32 + 5248 FP32/INT32
Men zou ergens IPC voor GPU's moeten bij houden. Zo veel FPS per SM op 1000mhz ofzo.
Even los van de bullshit term "IPC", zou je dat niet per SM moeten doen
Een SM is enkel een logisch element voor de aansturing, dat is geen maatstaaf om mee te rekenen. Je zou dan gewoon het aantal teraflops moeten normaliseren. Een vaste kloksnelheid forceren heb je wel juist, want teraflops zijn gewoon het aantal shaders maal de kloksnelheid, maal 2 (die ALU's werken op zowel rise als fall van een kloktik). Genormaliseerd op 1500 MHz geven GP102-350 en TU102-300 respectievelijk 10,75 en 13,05 FP32 TF. GA102-300 heeft sowieso 15,74 FP32 TF en dan
in theorie nog eens 15,74 FP32 TF uit die mixed units. Echter zullen die units het grootste deel van de tijd gewoon INT32 werk moeten doen, waardoor je in de praktijk zelfs in het gunstigste geval slechts 20-40% van de tijd iets extra's aan FP32 units hebt.
Dat zie je ook allemaal terug in de reviews van TPU; waar TU102 ~21% meer FP32 units heeft dan GP102, komt dat er ook gewoon uit in de benchmarks. Bijna exact zelfs, op 1080p is het ook daadwerkelijk 21% meer. Op hogere resoluties gaan dingen als bandbreedte ook een rol spelen, dus dan verschuift de balans. Waar GA102 volgens Nvidia's onzin maar liefst ~141% meer "CUDA Cores" heeft (en het in werkelijkheid ~20,6% is), zie je in benchmarks dat het dat laatste is dat naar voren komt. Op 1080p is een 3090 19,5% sneller dan een 2080 Ti. Pas op hogere resoluties komt er meer van die extra rekenkracht vrij, maar bij lange na niet die 141%. Eerder een derde daarvan, zo'n 45%. Een deel daarvan zal komen doordat de INT32/FP32 verhouding iets verschuift, maar ook een deel komt simpelweg uit bandbreedte.
Het probleem met teraflops is echter dat dat een cijfer is dat afhankelijk is van de kloksnelheid. En die is tegenwoordig niet constant, dus je kunt uit reviews geen "FPS per TF" of iets dergelijks halen, omdat de TF constant variëert.
En dan als laatste, voordat ik klaar ben met m'n muur (

), er is niet zoiets als "IPC". Voor CPU's slaat het al nergens op (wat voor instructie? FMA? AVX-512? AES?), maar voor GPU's is het al helemaal bullshit. Het meeste werk dat GPU's doen is letterlijk twee decimale cijfers optellen, aftrekken, vermenigvuldigen of delen. Dat is wat zo'n unit kan doen. Niet meer, niet minder. Erger nog, de meeste units in een GPU kunnen dat enkel doen voor een specifiek type cijfer: een floating point of een integer. En dan wordt het nog erger, want in sommige gevallen maakt het aantal bits waar dat cijfer uit bestaat ook nog iets uit; als jij vooral 16-bits floating point rekenwerk hebt, kun je beter een AMD GPU hebben, want AMD's units zijn flexibeler en kunnen twee FP16 ops per kloktik uitvoeren.
Er is simpelweg geen "IPC" die omhoog kan gaan in een GPU, althans niet voor het gros van het rekenwerk. Voor de simpele rekeneenheden gaat dat gewoon niet op, want die doen bijna niets. Het enige waar je iets van "IPC" zou kunnen uitvogelen, zijn in de fixed-function stukjes hardware: geometry, textures en ja, ray tracing. Die units werken op meerdere inputs, produceren meerdere outputs en hebben meerdere cycles nodig om hun werk te doen. Wat je wél kan meten is de effectiviteit van de driver(s) en/of scheduler(s). Die is bij AMD fors omhoog gegaan, waardoor de teraflops van RDNA2 ineens wél enigszins gebruikt kunnen worden als maatstaaf vergeleken met Nvidia.
Lovelace, zoals die geruchten het brengen, lijkt niets meer dan Ampère te zijn, maar dan op een nieuw procedé. Ze maken het ding gewoon weer meer dan 600mm^2 groot om zo een performance sprong te krijgen. Zelfde als de afgelopen paar generaties dus.