:strip_icc():strip_exif()/u/94045/crop66c1b4250e8a2_cropped.jpg?f=community)
En naast AMD ook voor Intel kan werken
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
:strip_icc():strip_exif()/u/19522/crop6124d729ee8a5_cropped.jpg?f=community)
Dit zit volledig in het spel en niet in de drivers, dus werkt dit ook op Intel, aangenomen dat Intel zijn kaarten hier eindelijk eens gaat uitbrengen EN met goede drivers.:
[...]
En naast AMD ook voor Intel kan werken
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
Moderator General Chat
Dyslectic history cynic
/u/324913/crop56a24cce05cd3_cropped.png?f=community)
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
Moderator General Chat
Dyslectic history cynic
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
:strip_icc():strip_exif()/u/218864/crop5db0c8ff43fff_cropped.jpeg?f=community)
Wat betreft die 3 GHz, die hoeven ze maar op 1 chip te halen en het gerucht is al correct. Dat lukt ze vast op Navi34 en Navi35 (6nm refreshes van Navi22 en Navi23). Of het ze ook lukt voor Navi33 moet ik nog zien, ik zou het knap vinden. Voor Navi30 (dat 2x Navi32 ding), 31 en 32 verwacht ik van niet.
Wat betreft RT capaciteiten is het leerzaam om te kijken naar de huidige generatie RDNA2 en Ampere.
https://www.techspot.com/...idia-ampere-vs-amd-rdna2/
Nvidia heeft bepaalde tweaks uitgehaald voor de Ray tracing cores en Tensor Cores in Ampere:
- Tensor cores gehalveerd maar 2x zo sterk:
- Ray tracing cores nu onafhankelijk van CUDA cores:
Ondertussen, voor AMD's RDNA2:
- Texture processors kunnen niet èn textures èn ray-primitive intersections tegelijkertijd doen.
Die "rearchitected compute units" that would "enhance ray tracing capabilities" in RDNA3 zou inderdaad kunnen betekenen dat de Texture Filter Units onafhankelijk zullen gaan werken van de Ray Accelerators.
Wat het echter niet betekent, is dat AMD Tensor cores gaat toevoegen:
https://www.tomshardware....terview-amd-sam-naffziger
En softwarematig zullen ze hun SIMD32 units capabeler willen maken met WMMA instructies. Ik vermoed dat die niet van RDNA3 afhankelijk zullen zijn.
Wat voor de RDNA3 "rearchitected compute units" ook zeker relevant is: 4 SIMD32 units per CU ipv 2
According to Linux drivers, it appears that Compute Units still exist, and WGPs are still DualCUs. The big change is going back to 4x SIMD per CU like GCN, but now with RDNA's 32 ALU design. pic.twitter.com/hAzGs9M9E6
— Kepler (@Kepler_L2) 30 april 2022
:fill(white):strip_exif()/f/image/VwO87K70QIboBikH5WvILbs9.png?f=user_large)
kleine muisjes hebben grote wensjes: Beschuit Met Gestampte Mensjes
/u/400/defember100.png?f=community)
PC Specs
Asus ROG Strix B650E-E | AMD 9800X3D |TR Phantom Spirit 120 SE | G-Skill 32GB DDR5 6000C30 M-die | 4090 FE | 3840*1600p 160Hz | Corsair RM1000x Shift
Dit is leuk maar euh, ik speel momenteel Tiny Tina's Wonderland op mijn Steam Deck (dus RDNA2.0) en ik wilde dolgraag FSR2.0 gebruiken. Nou dat is een groot Ghosting festijn
. Snel-bewegende karakters zijn allemaal smeary, en in zo'n spel is dat nagenoeg alle karakters... Ik heb het heel snel weer uitgezet.Is dat een brakke implementatie van FSR2.0 of is er iets anders aan de hand?
Hephaestus: Xeon 2680 v2 - 64GB ECC Quad - WD Blue 3D 1TB
Virtualis: Ryzen 3700X - 16GB DDR4 - Gigabyte 1080 Ti OC - Sandisk 2TB - Valve Index
Agon:Valve Steam Deck 64GB
Non scholae sed vitae discimus Seneca
:strip_exif()/u/211274/bestabstractwallpapers5.gif?f=community)
Combinatie van een slechte implementatie en het feit dat FSR 2.0 (en DLSS) het moeilijker heeft/hebben in third person spellen. Edit: Oh ik dacht dat het een third person spel was:
[...]
Dit is leuk maar euh, ik speel momenteel Tiny Tina's Wonderland op mijn Steam Deck (dus RDNA2.0) en ik wilde dolgraag FSR2.0 gebruiken. Nou dat is een groot Ghosting festijn
Is dat een brakke implementatie van FSR2.0 of is er iets anders aan de hand?
.Zie de God of War review van DigitalFoundry.
[ Voor 3% gewijzigd door Sp3ci3s8472 op 01-07-2022 20:15 ]
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
Tiny Tina is een First person shooter. En uit jou bovenstaande filmpje haal ik juist ándere problemen met FSR 2.0, zoals problemen met snelle bewegingen en wazigheid van vacht of haren.:
Combinatie van een slechte implementatie en het feit dat FSR 2.0 (en DLSS) het moeilijker heeft/hebben in third person spellen. Edit: Oh ik dacht dat het een third person spel was
Zie de God of War review van DigitalFoundry.
[YouTube: God of War PC: AMD FSR 2.0 vs Nvidia DLSS Image/ Motion Quality Face-Off]
Mijn conclusie is dat FSR 2.0 in Deathloop is leuk maar in andere games is het minder goed. FSR 2.0 != DLSS 2.3.x. DLSS is nog beter, momenteel.
Hephaestus: Xeon 2680 v2 - 64GB ECC Quad - WD Blue 3D 1TB
Virtualis: Ryzen 3700X - 16GB DDR4 - Gigabyte 1080 Ti OC - Sandisk 2TB - Valve Index
Agon:Valve Steam Deck 64GB
Non scholae sed vitae discimus Seneca
Moderator General Chat
Dyslectic history cynic
Grappig dat je dit zegt. Want AMD heeft al een SIMD based GPU met FP + INT capabele ALU's die ook async compute kunnen doen, sinds GCN1 in 2012. Het duurde maar 6,5 jaar voordat Nvidia ook reageerde en de oplossing van Nvidia is verre van elegant.
Nvidia heeft hun oude 32 FP ALU clusters uit Maxwell en Pascal, simpelweg omgevormd in 2 x 16 ALU clusters en een cluster INT only gemaakt. Dat deden ze omdat elke keer als er een INT wave32 tussen veel frequentere de FP waves zaten, ze clock cycles verloren terwijl de ALU's moesten switchen naar de andere berekening. In feite berekende het cluster van ALU's dan even niks. Dat ging niet meer omdat games steeds meer compute begonnen te gebruiken. Hierom presteerde een willekeurige Turing GPU, zeg RTX2080 met 2944 FP ALU's, vaak vergelijkbaar met een Pascal GPU zoals de GTX1080Ti met 3584 FP ALU's. Pascal liep simpelweg tegen haar limieten aan. En inmiddels vermoed ik dat met moderne games, de Turing GPU inmiddels de Pascal tegenhanger makkelijk verslaat.
Met Ampere hebben ze die INT pipeline weer dual use gemaakt zoals het eigenlijk ook met Maxwell/Pascal was en is het probleem van context switching weer terug. Ze halen alleen wel wat snelheid uit een dedicated FP pipeline die niet meer verstoord word. Het is totaal niet revolutionair of geweldig. Het is een simpele en weinig verfijnde oplossing voor een zwakte die al in Maxwell zat. Want sinds Maxwell uit 2014 heeft Nvidia weinig fundamenteels meer gedaan in hun graphics pipeline.
Ik zeg dit bewust wat gechargeerd. Want de laatste weken volg ik het wel, maar de hoeveelheid onzin die verteld word is bedroevend. Ik kan vrijwel niks meer serieus nemen. We beginnen met leesvoer. Dit is hoe GCN werkte. https://www.anandtech.com...-architects-for-compute/4
Het was een wave van maximaal 64 threads opbouwen, deze vervolgens in vier stukken delen en uitgeven aan een set van 16 ALU's per clock cycle. Je was dus vijf clock cycles bezig voor het berekenen van een wave64 omdat het telkens een stuk van maximaal 16 was en de vijfde cyclus was voor het berekenen van de vierde set van 16. Het voordeel was dat je INT en FP kon combineren in een wave64. Het nadeel was dat je nooit meer dan 25% van de ALU's iets deden tijdens een clock cycle.
Toen AMD eindelijk weer een beetje geld had voor iets nieuws, waarschijnlijk van Sony en MS, gingen ze meteen los met RDNA. Weg met vier cycle issue en naar een uniforme een cycle issue met twee units die elk wave32 deden. Dat is ook werkelijk het enige dat ze van Nvidia (Maxwell) hebben overgenomen. De rest hoeven ze niet over te nemen omdat ze dit beter voor elkaar hebben dan Nvidia. Case in point: 2560 ALU RX5700XT vs. 2560 FP + 2560 INT ALU RTX2070S = nauwelijks verschil in prestaties. Circa een verdubbeling in occupency voor AMD.
En Ampere komt ook niet in de buurt van wat RDNA1 al deed qua occupency percentages. Dat is ook overduidelijk. RDNA2 is zeer vergelijkbaar met RDNA1 maar dan groter en efficiënter. En ja hoor, de 5120 ALU's van Navi 21 doen het behoorlijk tegen de 10496 ALU's van de RTX3090. Nvidia haalt iets van 20 a 30% uit hun FP + INT/FP en AMD haalt het uit clock speeds. Punt staat alleen dat AMD nog steeds richting het dubbele aan occupency haalt. En met RDNA2 heeft AMD dat voordeel gebruik voor L3 cache en betere efficiëntie.
Ik bedacht met net dat ik dit twee maanden geleden ook al had gezegd.
DaniëlWW2 in "CJ's AMD Radeon Info & Nieuwsdiscussietopic - Deel 144"
RDNA3 gaat ook niet om CU indeling. Het gaat primair om hoeveel ALU's de chips hebben. Het idee zou zijn dat AMD hun WGP, een cluster van twee CU's, naar vier CU's gaat uitbreiden. Dat is al een oud idee dat jaren geleden al in patenten voorbij is gekomen. Daaraan verbonden is ook het idee van de "SuperSIMD" die VLIW2 zou combineren met SIMD. En als ze dat doen en het werkt ook goed, tja dan gaat het helemaal leuk worden.
Maar ook zonder geld voor iedereen die dit een beetje begrijpt, dat Nvidia met iets radicaal anders en beters moet komen dan "Ampere refresh" als AMD met een 12288 ALU Navi 31 komt. Doen ze dat niet, tja dan heeft Nvidia een enorme sprong in clock speeds nodig en/of andere zaken die hun occupency fors omhoog gooien. Want anders is dit een win voor AMD. Nu heeft Nvidia die enorme L2 cache, maar ik betwijfel of dat afdoende is. En daar komen de constante geruchten over de bezopen TDP waarden van Nvidia vandaan.
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
Mooie samenvatting met superieure AMD oplossing ondertoon (occupancy, perf/Watt), ik ben ook team rood. Maar wees nou eens eerlijk over performance::
[...]
Grappig dat je dit zegt. Want AMD heeft al een SIMD based GPU met FP + INT capabele ALU's die ook async compute kunnen doen, sinds GCN1 in 2012. Het duurde maar 6,5 jaar voordat Nvidia ook reageerde en de oplossing van Nvidia is verre van elegant.
Nvidia heeft hun oude 32 FP ALU clusters uit Maxwell en Pascal, simpelweg omgevormd in 2 x 16 ALU clusters en een cluster INT only gemaakt. Dat deden ze omdat elke keer als er een INT wave32 tussen veel frequentere de FP waves zaten, ze clock cycles verloren terwijl de ALU's moesten switchen naar de andere berekening. In feite berekende het cluster van ALU's dan even niks. Dat ging niet meer omdat games steeds meer compute begonnen te gebruiken. Hierom presteerde een willekeurige Turing GPU, zeg RTX2080 met 2944 FP ALU's, vaak vergelijkbaar met een Pascal GPU zoals de GTX1080Ti met 3584 FP ALU's. Pascal liep simpelweg tegen haar limieten aan. En inmiddels vermoed ik dat met moderne games, de Turing GPU inmiddels de Pascal tegenhanger makkelijk verslaat.
Met Ampere hebben ze die INT pipeline weer dual use gemaakt zoals het eigenlijk ook met Maxwell/Pascal was en is het probleem van context switching weer terug. Ze halen alleen wel wat snelheid uit een dedicated FP pipeline die niet meer verstoord word. Het is totaal niet revolutionair of geweldig. Het is een simpele en weinig verfijnde oplossing voor een zwakte die al in Maxwell zat. Want sinds Maxwell uit 2014 heeft Nvidia weinig fundamenteels meer gedaan in hun graphics pipeline.
Ik zeg dit bewust wat gechargeerd. Want de laatste weken volg ik het wel, maar de hoeveelheid onzin die verteld word is bedroevend. Ik kan vrijwel niks meer serieus nemen. We beginnen met leesvoer. Dit is hoe GCN werkte. https://www.anandtech.com...-architects-for-compute/4
Het was een wave van maximaal 64 threads opbouwen, deze vervolgens in vier stukken delen en uitgeven aan een set van 16 ALU's per clock cycle. Je was dus vijf clock cycles bezig voor het berekenen van een wave64 omdat het telkens een stuk van maximaal 16 was en de vijfde cyclus was voor het berekenen van de vierde set van 16. Het voordeel was dat je INT en FP kon combineren in een wave64. Het nadeel was dat je nooit meer dan 25% van de ALU's iets deden tijdens een clock cycle.
Toen AMD eindelijk weer een beetje geld had voor iets nieuws, waarschijnlijk van Sony en MS, gingen ze meteen los met RDNA. Weg met vier cycle issue en naar een uniforme een cycle issue met twee units die elk wave32 deden. Dat is ook werkelijk het enige dat ze van Nvidia (Maxwell) hebben overgenomen. De rest hoeven ze niet over te nemen omdat ze dit beter voor elkaar hebben dan Nvidia. Case in point: 2560 ALU RX5700XT vs. 2560 FP + 2560 INT ALU RTX2070S = nauwelijks verschil in prestaties. Circa een verdubbeling in occupency voor AMD.
[Afbeelding]
En Ampere komt ook niet in de buurt van wat RDNA1 al deed qua occupency percentages. Dat is ook overduidelijk. RDNA2 is eigenlijk RDNA1 maar dan groter en efficiënter. En ja hoor, de 5120 ALU's van Navi 21 doen het behoorlijk tegen de 10496 ALU's van de RTX3090. Nvidia haalt iets van 20 a 30% uit hun FP + INT/FP en AMD haalt het uit clock speeds. Punt staat alleen dat AMD bijna het dubbele aan occupency haalt. En met RDNA2 heeft AMD dat voordeel gebruik voor L3 cache en betere efficiëntie.
Ik bedacht met net dat ik dit twee maanden geleden ook al had gezegd.
DaniëlWW2 in "CJ's AMD Radeon Info & Nieuwsdiscussietopic - Deel 144"
RDNA3 gaat ook niet om CU indeling. Het gaat primair om hoeveel ALU's de chips hebben. Het idee zou zijn dat AMD hun WGP, een cluster van twee CU's, naar vier CU's gaat uitbreiden. Dat is al een oud idee dat jaren geleden al in patenten voorbij is gekomen. Daaraan verbonden is ook het idee van de "SuperSIMD" die VLIW2 zou combineren met SIMD. En als ze dat doen en het werkt ook goed, tja dan gaat het helemaal leuk worden.
Maar ook zonder geld voor iedereen die dit een beetje begrijpt, dat Nvidia met iets radicaal anders en beters moet komen dan "Ampere refresh" als AMD met een 12288 ALU Navi 31 komt. Doen ze dat niet, tja dan heeft Nvidia een enorme sprong in clock speeds nodig en/of andere zaken die hun occupency fors omhoog gooien. Want anders is dit een win voor AMD. Nu heeft Nvidia die enorme L2 cache, maar ik betwijfel of dat afdoende is. En daar komen de constante geruchten over de bezopen TDP waarden van Nvidia vandaan.
- Hoeveel FP32 en INT32 kan AMD nu in RDNA2, per CU, per cycle?
- Hoeveel FP32 en INT32 kan Nvidia nu in Ampere, per SM, per cycle?
Wat is je verwachting precies van RDNA3 en Lovelace? 12288 ALU zoals de geruchten? Is het straks niet 192x256 ALU ipv x128 ALU per CU? Ik denk 256. Geen 4xCU, nog steeds 2xCU per WGP, maar 4 SIMD ipv 2 SIMD (zoals in de Linux drivers van AMD al terug te vinden is nu op dit moment). Op basis van:
According to Linux drivers, it appears that Compute Units still exist, and WGPs are still DualCUs. The big change is going back to 4x SIMD per CU like GCN, but now with RDNA's 32 ALU design. pic.twitter.com/hAzGs9M9E6
— Kepler (@Kepler_L2) 30 april 2022
Dan hebben we het voor Navi 31 toch echt over 24576 ALU.
Team groen. Klokspeed om occupancy omhoog te gooien? Wat dacht je van de enorme sprong in L2 cache en GDDR6X snelheid nog steeds vergeleken met GDDR6, toch een doorslag in 4k?
Gooit Lovelace er "even" 64 FP32 bij, heb je het over 144 SM x 192 ALU/SM, met het grote verschil dat Nvidia's SM's tegelijkertijd 128 FP32 + tot 64 INT32 er doorheen duwen, terwijl AMD's CU's elegant 128 FP32 of INT32 lopen te doen (of mix). Met optimale occupancy. Ja leuk, maar 128 is minder dan 192. Op basis van:
OK, I did some corrections. Is it really that simple? pic.twitter.com/j7QUIY98lG
— kopite7kimi (@kopite7kimi) 13 mei 2022
Dan hebben we het over 27648 ALU voor AD102, wat nog steeds een hoger getal is dan 24576 ALU van Navi31.
Ok, maar behalve ALU's, laten we kijken naar klokfrequentie. De node sprongen zijn niet meer spectactulair, maar toch. Vergeet even power efficiency, nobody cares voor de extreme high end.
https://en.wikichip.org/wiki/5_nm_lithography_process#N5
Laten we een graphics compute chiplet (2xNavi23) ruim 2400 MHz geven. Kom ik op:
alles (boost clock)
Navi21 = 2250 MHz
Navi22/23 = 2600 MHz
2xNavi23 ~ 2400 MHz
alles (boost clock), 250MHz straf per chiplet.
Navi30 ~ 2000 MHz
Navi31 ~ 2250 MHz
Navi32 ~ 2500 MHz
Navi33 (double Navi23): 2400*1,15 ~ 2760 MHz
Navi34 = Navi22 refresh. Can hit ~3000 MHz.
Navi35 = Navi23 refresh. Can hit ~3000 MHz.
15% tot dusver RDNA3.
Maar dan team groen.
Samsung 8nm -> TSMC N4:
Assume (no source/MLID): TSMC 7nm is 15% more speed at 15% less power than Samsung 8nm.
https://en.wikichip.org/wiki/5_nm_lithography_process#N5
https://pr.tsmc.com/english/news/2874
Kom ik op:
GA102 = 1860 MHz (boost clock)
alles (boost clock), 250 MHz straf voor 12 GPC ipv 7 GPC.
AD102 ~ 2500 MHz
AD103 (GA102): 1860*1,15*1,15*1,11 ~ 2730 MHz
AD104 (GA104): can hit ~3000 MHz.
AD106/107: can hit ~3000 MHz.
Dit heb ik geschat vóórdat kopite7kimi dit bevestigde in geruchten (2520 MHz boost clock): 5nm of 4nm is gewoon snel qua logica en klokfrequentie, voor beide partijen.
In combinatie, ALU's + klokfrequentie: wie gaat er winnen? Ik ben niet zo zeker meer van RDNA3. Een beetje, "disappointed", begrijp ik nu wel van kopite7kimi.
TL:DR;
AD102 ~2500 MHz + 27648 ALU
Navi31 ~2250 MHz + 24576 ALU
kleine muisjes hebben grote wensjes: Beschuit Met Gestampte Mensjes
/u/286895/icon1.png?f=community)
Ze zeggen d'r nooit bij "or a 25% improvement in performance for a 15% increase in power.
Heeft geen speciale krachten en is daar erg boos over.
Moderator General Chat
Dyslectic history cynic
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
/u/226258/tweakersavatar.png?f=community){kind=avatar}
We zullen het wel zien
Heb de thread wel gevolgd, maar ik heb een zeker virusje opgelopen tijdens een werktrip naar Londen vorige week, dus ik ben niet 100% momenteel
Ik zal wel even hierop reageren:
Volgens mij is dat niet juist. Ik zou de whitepaper er bij moeten nemen, maar volgens mij kan AMD elke SIMD32 apart schakelen; per CU zijn er 2 SIMD32's en per DCU dus 4 stuks. Per DCU delen de 4 SIMD32's ook hun L0$ waardoor AMD binnen 1 cycle (nogmaals, ik zou de whitepaper op na moeten slaan) kan schakelen. Zelfs al zouden ze per CU moeten schakelen, dan kan AMD dat nu per 64 ALU's waar Nvidia dat per 128 moet doen, want Nvidia moet wél een hele SM schakelen. Ze kunnen dat absoluut niet per partitie (niet geheel ontoevallig ook 4 per SM, met 16xFP32 + 16xFP32/INT32 per partitie
), enige gedeelde tussen de partities is de L1$.Als Nvidia 16 FP32 ALU's aan elke partitie toe zou voegen zou dat niets oplossen als ze ook niet hun hele frontend en geheugen model op de schop gooien. Beide (AMD + Nvidia) geven al jaren aan dat warp32/wave32 de sweet spot is; 64 breed wordt nooit gevuld en 16 is meestal te smal. Met 16 extra FP32 units zou elke partitie dus in theorie maximaal 48 breed worden, wat daar niet bij past.
Er is bij mijn weten nog niets "gelekt" aan de Nvidia kant over enige revolutie in hun frontend, H100 had ook niets nieuws op dat gebied (althans niet dat ik me kan herinneren). En volgens mij is dat ook waar dat "gerucht" vandaan komt: want H100 heeft nu wel 16xINT32 + 32xFP32 in een SM, waar A100 16+16 had. Maar dat zijn ook pure FP32 en INT32 ALU's. Als Nvidia er 4x16 FP32 bij stopt, geloof ik niet dat ze ook het mixed INT32/FP32 datapad behouden; want dat datapad bestaat niet uit échte mixed ALU's, het zijn gewoon 16xINT32 en 16xFP32 units waarvan slechts één reeks aangestuurd kan worden. Het is logischer dat ze dat gewoon weer splitsen, maar dan moet hun aansturing alsnog verbeterd worden.
Ik ben verder gestopt met het in de gaten houden van de "lekkers", want er komt écht te veel onzin uit. Een tijd terug zou 3 GHz "easy" zijn, zou Nvidia minimaal 100 TF doen, enzovoort. Ik wacht wel gewoon af.
Omdat dat niet op die manier werkt, dat is niet voorpslebaar:
[...]
Ze zeggen d'r nooit bij "or a 25% improvement in performance for a 15% increase in power.
Die "15% improvement" betekent 15% hogere kloksnelheid bij dezelfde spanning. Dus van bijvoorbeeld 1000 MHz op 1000 mV naar 1150 op diezelfde 1000 mV. 25% meer kloksnelheid (1250) kan echter best ineens 1100 mV (+10%) vereisen. Maar dat gaat uiteindelijk op minimaal 20% meer stroomverbruik neerkomen, omdat de relatie tussen spanning en frequentie kwadratisch is. Daarom zie je dat met overklokken het verbruik dramatisch omhoog kan schieten met slechts een paar millivolt meer - of omgekeerd, waarom undervolten zo goed kan werken.
Het is minimaal zo veel omdat het bovenstaande enkel het dynamische verbruik van de chip is; dat wil zeggen, het verbruik puur voor het schakelen van de gates. Daarnaast heb je nog te maken met een statische belasting, verlies door kortsluiting, verlies door leakage en met pieken voor het schakelen tussen frequenties. Geen van die dingen is lineair, het zijn allemaal exponentiële functies die ook nog eens afhankelijk van het chip ontwerp kunnen zijn (zie Fermi; slecht fysiek ontwerp zorgde voor ondermaatse elektrische eigenschappen).
Daarom geeft TSMC altijd enkel de performance bij constant verbruik, of verbruik bij constante performance, omdat dan slechts één variabele verandert en het dus vrij voorspelbaar is. Wat ze eigenlijk zeggen is dat je bij dezelfde spanning als voorheen de klokfrequentie met X procent kunt verhogen, of bij dezelfde frequentie de spanning X procent kan verlagen als je fysieke ontwerp niet veranderd is. Ga je met meer dan dat klooien? YMMV.
Toch dank voor je antwoord, goed om een second opinion te krijgen.:
[...]
We zullen het wel zien
Heb de thread wel gevolgd, maar ik heb een zeker virusje opgelopen tijdens een werktrip naar Londen vorige week, dus ik ben niet 100% momenteel
Ik zal wel even hierop reageren:
[...]
Volgens mij is dat niet juist. Ik zou de whitepaper er bij moeten nemen, maar volgens mij kan AMD elke SIMD32 apart schakelen; per CU zijn er 2 SIMD32's en per DCU dus 4 stuks. Per DCU delen de 4 SIMD32's ook hun L0$ waardoor AMD binnen 1 cycle (nogmaals, ik zou de whitepaper op na moeten slaan) kan schakelen. Zelfs al zouden ze per CU moeten schakelen, dan kan AMD dat nu per 64 ALU's waar Nvidia dat per 128 moet doen, want Nvidia moet wél een hele SM schakelen. Ze kunnen dat absoluut niet per partitie (niet geheel ontoevallig ook 4 per SM, met 16xFP32 + 16xFP32/INT32 per partitie
Als Nvidia 16 FP32 ALU's aan elke partitie toe zou voegen zou dat niets oplossen als ze ook niet hun hele frontend en geheugen model op de schop gooien. Beide (AMD + Nvidia) geven al jaren aan dat warp32/wave32 de sweet spot is; 64 breed wordt nooit gevuld en 16 is meestal te smal. Met 16 extra FP32 units zou elke partitie dus in theorie maximaal 48 breed worden, wat daar niet bij past.
Er is bij mijn weten nog niets "gelekt" aan de Nvidia kant over enige revolutie in hun frontend, H100 had ook niets nieuws op dat gebied (althans niet dat ik me kan herinneren). En volgens mij is dat ook waar dat "gerucht" vandaan komt: want H100 heeft nu wel 16xINT32 + 32xFP32 in een SM, waar A100 16+16 had. Maar dat zijn ook pure FP32 en INT32 ALU's. Als Nvidia er 4x16 FP32 bij stopt, geloof ik niet dat ze ook het mixed INT32/FP32 datapad behouden; want dat datapad bestaat niet uit échte mixed ALU's, het zijn gewoon 16xINT32 en 16xFP32 units waarvan slechts één reeks aangestuurd kan worden. Het is logischer dat ze dat gewoon weer splitsen, maar dan moet hun aansturing alsnog verbeterd worden.
Ik ben verder gestopt met het in de gaten houden van de "lekkers", want er komt écht te veel onzin uit. Een tijd terug zou 3 GHz "easy" zijn, zou Nvidia minimaal 100 TF doen, enzovoort. Ik wacht wel gewoon af.
In de huidige Ampere (vs RDNA2) oplossing, switchen inderdaad alle subcores (je noemt ze partities) per workload naar INT32 of FP32, er is geen aansturing per subcore.
kopite7kimi geeft wel aan: 192kB L1 cache, wat dan zou passen bij de 48 breed x 4 = 192. Verder neem ik inderdaad aan dat Nvidia de frontend aansturing en het geheugenmodel aanpast, juist om die mixed INT32/FP32 shit te splitsen. Dan hoeven ze niet meer te switchen per SM of per subcore/partitie. De ALU's worden gevuld of niet, that's it.
Nvidia zelf lekt sowieso heel weinig. De vorige keer zag niemand de 10752 CUDA cores aankomen. Daarom wil ik er deze keer rekening mee houden.
Voor AMD RDNA3 zou een DCU dus gaan van 4 naar 8 SIMD's, met 256 kB L1 cache qua geheugen.
Is het - in de huidige architectuur - niet zonde om een SIMD te gebruiken als INT32 ALU? Is de aanpak van Nvidia niet slimmer?
DCU RDNA2: 4x SIMD = 4 ALU's flexibel
SM Ampere: 4x (1x FP32 + 1x FP32/INT32) = 8 ALU's gelijktijdig
De tijd zal het leren.
kleine muisjes hebben grote wensjes: Beschuit Met Gestampte Mensjes
Moderator General Chat
Dyslectic history cynic
Nog een keer dan.
Ik zie gewoon geen reden om vooralsnog aan te nemen dat er iets compleet anders gaat gebeuren met AD102 dan we nu al jaren zien van Nvidia. We weten dat het 144SM's is en 96MB aan L2 cache. Node is in de N5 klasse waarvan je eigenlijk al weet dat alleen de logic delen (dus rekeneenheden) nog flink kleiner zullen worden. Je kan dus meer ALU's kwijt per mm2, maar I/O, geheugencontrollers en zelfs SRAM gaat niet veel kleiner meer worden.
Dat wordt ook duidelijk als je de claims van TSMC zelf ziet. Die claimen een forse maximale dichtheidsverbetering van 1,84x voor logic, 1,2x voor I/O en 1,3x voor SRAM over N7. Dit zijn puur theoretische maxima die niet gehaald zullen worden in praktische chips, laat staan voor een high performance GPU.
https://en.wikichip.org/wiki/5_nm_lithography_process#TSMC
We hebben ook al een voorbeeld in GH100. Die chip is 814mm2 met 80 miljard transistoren. Dichtheid is dus 101,75mm2. Dat is een enorme chip met lage clock speeds en geen noemenswaardige grote hoeveelheid I/O. Een gaming GPU heeft die voordelen niet en blijft onherroepelijk dus onder de 100mm2 waarbij Navi 21 nu op 51,5mm2 zit. Een grove inschatting zal denk ik rond de 80 a 90mm2 zitten waarbij Nvidia zomaar lager kan zitten dan AMD omdat AMD het voordeel van chiplets in ieder geval heeft.
En daar is meteen probleem nummer een. 96MB aan L2 cache zal een fors oppervlakte innemen. Zeker als je ziet dat de 6MB op GA102 al niet een klein detail is. Het percentage van de chip dat besteed zal worden aan cache, zal toenemen. Dit terwijl andere zaken zoals de geheugencontrollers waarschijnlijk niet veel kleiner zullen worden.
En in die context kijk ik dus naar de steeds extremere waarden die worden verkondigd. We weten dat het 144SM's is voor AD102. Daaruit kan je herleiden dat het waarschijnlijk om 18432 ALU's gaat. Het is 70% meer dan GA102 en dat is al heel veel gevraagd. Immers zit GA102 op 45,1mm2. Tussen 70% meer ALU's en de extra cache zit je denk ik zo weer over de 600mm2. Waar moet Nvidia precies nog eens 9216 ALU's + alle caches + frontend en backend kwijt? GH100 zit al tegen de redicle limit aan en Nvidia vraagt de absolute hoofdprijs voor dergelijke chips
Hetzelfde geld voor Navi 31. 2,5x ALU's over Navi 21 is gigantisch en dit kan alleen als AMD de I/O + L3 afsplitst en op aparte chiplets plaatst. En omdat AMD zelf heeft gezegd dat ze chiplets gaan gebruiken, is het dus mogelijk om een dergelijke chip te creëren.
Immers is dit Navi 21. Heel wat van die chip is I/O en SRAM. Je moet 2,5x aan ALU's + front en backend erbij zien te krijgen en dat kan, als je de geheugencontrollers, (boven en onderin) de blocken L3 cache en de I/O rechts van chip haalt en op aparte chiplets plaatst en een die shrink hebt. Je kijkt alsnog waarschijnlijk naar 500mm2+, maar dit kan.
Ik zie gewoon geen reden om vooralsnog aan te nemen dat er iets compleet anders gaat gebeuren met AD102 dan we nu al jaren zien van Nvidia. We weten dat het 144SM's is en 96MB aan L2 cache. Node is in de N5 klasse waarvan je eigenlijk al weet dat alleen de logic delen (dus rekeneenheden) nog flink kleiner zullen worden. Je kan dus meer ALU's kwijt per mm2, maar I/O, geheugencontrollers en zelfs SRAM gaat niet veel kleiner meer worden.
Dat wordt ook duidelijk als je de claims van TSMC zelf ziet. Die claimen een forse maximale dichtheidsverbetering van 1,84x voor logic, 1,2x voor I/O en 1,3x voor SRAM over N7. Dit zijn puur theoretische maxima die niet gehaald zullen worden in praktische chips, laat staan voor een high performance GPU.
https://en.wikichip.org/wiki/5_nm_lithography_process#TSMC
We hebben ook al een voorbeeld in GH100. Die chip is 814mm2 met 80 miljard transistoren. Dichtheid is dus 101,75mm2. Dat is een enorme chip met lage clock speeds en geen noemenswaardige grote hoeveelheid I/O. Een gaming GPU heeft die voordelen niet en blijft onherroepelijk dus onder de 100mm2 waarbij Navi 21 nu op 51,5mm2 zit. Een grove inschatting zal denk ik rond de 80 a 90mm2 zitten waarbij Nvidia zomaar lager kan zitten dan AMD omdat AMD het voordeel van chiplets in ieder geval heeft.
En daar is meteen probleem nummer een. 96MB aan L2 cache zal een fors oppervlakte innemen. Zeker als je ziet dat de 6MB op GA102 al niet een klein detail is. Het percentage van de chip dat besteed zal worden aan cache, zal toenemen. Dit terwijl andere zaken zoals de geheugencontrollers waarschijnlijk niet veel kleiner zullen worden.
En in die context kijk ik dus naar de steeds extremere waarden die worden verkondigd. We weten dat het 144SM's is voor AD102. Daaruit kan je herleiden dat het waarschijnlijk om 18432 ALU's gaat. Het is 70% meer dan GA102 en dat is al heel veel gevraagd. Immers zit GA102 op 45,1mm2. Tussen 70% meer ALU's en de extra cache zit je denk ik zo weer over de 600mm2. Waar moet Nvidia precies nog eens 9216 ALU's + alle caches + frontend en backend kwijt? GH100 zit al tegen de redicle limit aan en Nvidia vraagt de absolute hoofdprijs voor dergelijke chips
Hetzelfde geld voor Navi 31. 2,5x ALU's over Navi 21 is gigantisch en dit kan alleen als AMD de I/O + L3 afsplitst en op aparte chiplets plaatst. En omdat AMD zelf heeft gezegd dat ze chiplets gaan gebruiken, is het dus mogelijk om een dergelijke chip te creëren.
Immers is dit Navi 21. Heel wat van die chip is I/O en SRAM. Je moet 2,5x aan ALU's + front en backend erbij zien te krijgen en dat kan, als je de geheugencontrollers, (boven en onderin) de blocken L3 cache en de I/O rechts van chip haalt en op aparte chiplets plaatst en een die shrink hebt. Je kijkt alsnog waarschijnlijk naar 500mm2+, maar dit kan.
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
Die reden is er wel:
OK, I did some corrections. Is it really that simple? pic.twitter.com/j7QUIY98lG
— kopite7kimi (@kopite7kimi) 13 mei 2022
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/f2uLH6vGSSHY4iMGqaXt76Bg.jpg?f=user_large)
80 a 90 M / mm² lijkt me al heel ruim. Dat is 2x de huidige density.
Ah, dit doet me denken aan mijn infinity cache berekeningen voor de geruchten Navi21, waar ik liet zien dat het kon. https://gathering.tweakers.net/forum/view_message/63825102
Tijd voor ronde 2!
Nee dat kan je niet. Je doet de aanname dat een GA102 SM hetzelfde als een AD102 SM is. En dat is waarschijnlijk niet het geval, vanwege de bovengenoemde tweet door kopite7kimi.
Als je kijkt naar de Navi21 die shot, dan zie je dat de 128 MB infinity cache bij lange na niet 32x zo groot is als de 4MB L2 waarvan je bijna zou vergeten dat Navi21 die heeft. Ik heb even pixels geteld:
- 4MB L2 = 12,44 mm2
- 128MB L3 = 70,01 mm2
Dat is maar 5,6x zo groot. In plaats van 32x. Dat is toevallig bijna de wortel van 32.
Zoals Locuza ons leert (en er met een factor 2 tot 4 naast zat):
The picture is just meant as a super rough compass.
— Locuza (@Locuza_) 12 september 2020
If Xbox Series X chip shot = 360.4mm²
Then 128MB based on 4MB Zen2 L3$ slices = 178.6mm²
128MB based on 2MB RDNA2 L2$ slices = 340.9mm²
Clock rate, bandwidth requirements and coherency management have a large impact on size. pic.twitter.com/KeFKXKiZR2
Clock rate, bandwidth requirements and coherency management have a large impact on size.
Dus dan is het niet zo rationeel om te denken dat voor AD102 de 96MB L2 cache, precies 16x zo groot is als de 6MB L2 cache van GA102. Stel dat Nvidia de 96 MB "L2 cache" tot een factor 4x kan beperken, de wortel van 16. Dan is er al genoeg ruimte voor die extra ALU's. Concreet uitgerekend voor je:
7GPC = 364 mm2 , GA102
12GPC *1,5 (50% er bij voor de ALU's) = 938 mm2 op Samsung 8nm, 469mm2 op TSMC 4nm.
3MB L2 cache = 47,33 mm2 , GA102
92MB "L2 cache" = 189,3 mm2 op Samsung 8nm, 94,65 mm2 op TSMC 4nm.
Bij elkaar 563,9 mm2. Ruimte zat dus.
Anders gezegd. Als Nvidia 300 m2 (50%) van hun AD102 gebruikt voor L2 cache, terwijl AMD nog niet eens 14% van het Navi21 oppervlak daar aan besteedt, zit er een steekje bij hen los.
Het merendeel van Navi21 is Shader Engines hoor (70,8%). Maar het helpt zeker om de minder goed schaalbare zaken op een I/O memory control die te zetten, zoals ze dat bij Epyc/Zen3 server chips ook gedaan hebben. Met tot wel 8 chiplets
Het enige waar ik nog over twijfel, is of de Navi3x graphics chiplet inclusief of exclusief infinity cache is. En of deze cache vertical stacked is of gewoon onderdeel van de graphics chiplet (2x Navi23) net als de 8-core CCD/CCX chiplet van Zen3.
kleine muisjes hebben grote wensjes: Beschuit Met Gestampte Mensjes
Ah sorry, dacht dat het een serieuze reactie was
Dat gaat 100% zeker weten niet gebeuren. De FP32 en/of INT32 units zullen geclusterd aangestuurd blijven, dat zal niet per aparte unit geschakeld kunnen worden. Dat kan niet in verband met hoe registers en dergelijke werken. Om dat te bewerkstelligen zouden beide (Nvidia en AMD) helemaal vanaf de grond af moeten ontwerpen en dat wordt dan ook dusdanig ingewikkeld dat de chips niet meer te behapstukken zijn (qua afmetingen). Je krijgt dan veel te veel data lines.
Je verwart hier wat termen. Een DCU in RDNA2 bestaat uit 2 CU's, elke CU uit 2 SIMD32's en elke SIMD32 uit 32 Vector ALU's (ik kom hier zometeen op terug). Een SM in Ampère is gepartitioneerd in 4 processing blocks (subcores), waarbij elk blok een datapad met 16 FP32 ALU's en een data pad met 16 FP32 + 16 INT32 ALU's heeft.
Een ALU is de kleinst mogelijke rekeneenheid binnen een chip. Dus het gaat niet om een cluster, maar om de eenheden ván een cluster. Er is ook de term "FPU", maar die wordt al heel lang niet meer gebruikt door zowel Nvidia als AMD. Laatste keer was volgens mij Fermi, waar een "CUDA Core" bestond uit zowel een FPU (FP32) als een ALU (INT32). Tegenwoordig betekent "CUDA Core" enkel de FP32 units. Één van de redenen waarom ik het vertik die term te gebruiken en vast houdt aan FP32/INT32/etc.
AMD kan dus per 32 van 128 units in een DCU schakelen (nogmaals, als ik me de whitepaper goed herinner), terwijl Nvidia dat enkel op SM niveau kan en op die manier dus 64 units tegelijkertijd moet schakelen. Anders gezegd: Nvidia heeft 2 opties (128xFP32 óf 64xFP32 + 64xINT32), AMD heeft er 5 (128+0, 96+32, 64+64, 32+96, 0+128). Dus nee, AMD's oplossing is slimmer.
En dat gaat verder dan enkel die partities. Want AMD's "units" (om het maar even zo breed mogelijk te houden) zijn veel flexibeler. De reden dat ik ze vaak nog steeds "SP" noem, is omdat AMD's units meerdere data types aan kunnen en zij ze zelf daarom een tijd lang SP noemden. Een RDNA2 unit kan zo'n beetje alle FP32 ops (inclusief FMA) per cycle uitvoeren, maar ook INT32 en INT24. Daar zijn geen aparte units voor zoals bij Nvidia. AMD heeft ook minder units dan Nvidia, juist omdat ze iets flexibeler zijn; maar dus ook iets complexer en groter. En ga je naar halve precisie (16 bits) gebruiken ze alsnog alle beschikbare 32 bits in een unit, door er gewoon 2 16-bit operands tegelijkertijd mee te verwerken (packed math heet dat). Dat werkt ook deels door naar 8 en 4 bits, waardoor AMD veel van die kleinere ops met 4 (8 bits) of zelfs 8 (4 bits) tegelijk kan uitvoeren. Zelfs in GCN 1.0 konden de SP's (ik weet niet of ze ze toen al Vector ALU noemden) al zowel FP als INT aan. Geen packed math zoals nu en volgens mij was INT ook niet full rate, maar ze hebben al heel lang geen aparte units.
Daarom klopt @Ludewig's opmerking dat AMD iets van Nvidia zou kopiëren ook geenszins. Sterker nog, dat wás juist andersom, want Nvidia heeft eigenlijk altijd units gehad die exact één data type konden verwerken...en that's it. Uitzonderingen daarop waren GP100 (maar niet de rest van de Pascal lineup!) en Turing, die FP32 units hadden die ook packed FP16 konden doen. Met Ampère is dat weer verleden tijd, maar ze kunnen wel nog 1xFP16 in een FP32 unit verwerken, waardoor de maximum FP16 snelheid 1:1 is. Maar nog steeds zijn INT32 en FP32 gescheiden, ook al laten sommige diagrammen "FP32/INT32" zien; in werkelijkheid zijn dat aparte units in een enkel datapad, waarbij het hele datapad ofwel FP32 doet, ofwel INT32.
Kanttekening hierbij is dat die tweet (en veel van kopite's andere tweets) geen "leaks" zijn. Die tweet (en genoeg andere) zijn kopite's eigen "ontwerpen". Dat is niet meer of minder dan zijn/haar eigen natte vinger aan het werk
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
Misschien is er nog steeds een uitbreiding van FP32 units mogelijk van Ampere naar Lovelace. Kom ik zo op terug.
Klopt, ik mag niet zomaar een SIMD aan een ALU gelijk stellen, de ene ALU is de andere niet. Ik heb de whitepaper niet in dat detail gelezen, ik baseer me vooral op de analyse van Techspot.
Dat verheldert wel, maar dat laatste klopt niet. Je vergelijkt een SM met een 2xCU.
RDNA2 1 CU (2 SIMD) =
64xFP32 òf 32xFP32+32xINT32 òf 64xINT32. (3 opties)
versus
Ampere 1 SM (4 subcores/partities) =
128xFP32 óf 64xFP32 + 64xINT32 (2 opties)
(waarbij de Nvidia SM's meestal in de 64+64 stand staan, en aardig wat INT32 verloren gaat, terwijl AMD qua performance per Watt beter gebruik maakt van de CU's)
bron:
https://www.techspot.com/...idia-ampere-vs-amd-rdna2/
Ja ik vraag me nog steeds af of dat voor INT32 berekeningen niet "zonde" is - die complexere en grotere units, maar de helft van Ampere's ALU's kan alleen FP32, terwijl de andere helft alleen òf FP32 òf INT32 kan. Het is niet alsof Ampere losse ALU's heeft die alleen INT32 kunnen.
Dan is de strategische vraag: Wat is efficiënter, een vector32 ALU die zowel FP32 als INT32 kan, of een kleinere ALU die minder kan, maar waar je er meer van kwijt kan? Het oude kwaliteit kwantiteit vraagstuk.
Ik vraag me dus af of qua performance, de ALU strategie van Nvidia superieur is. AMD's ALU's zijn flexibeler, maar groter, Nvidia ALU's zijn minder flexibel, maar talrijker.
Als Nvidia AMD zou hebben gekopieerd, dan hadden ze nu Ampere ALU's die èn FP32 èn INT32 tegelijkertijd kunnen. Maar dat is niet het geval. Ze hebben een andere strategie. Nvidia bombardeert FP32 tot CUDA puur voor marketing, maar ik ben het met je eens dat het een FP32 ALU blijft.
Mmm, ik zou kopite7kimi niet snel beschuldigen van natte vinger werk, maar hij/zij kan zeker eigen speculaties hebben. Het is duidelijk dat je een 4x subcore structuur van 1 SM niet zomaar even ombouwt, qua L1 geheugen data, en (frontend) aansturing. Maar er is wel degelijk een verbetering in de SM's mogelijk.:
Kanttekening hierbij is dat die tweet (en veel van kopite's andere tweets) geen "leaks" zijn. Die tweet (en genoeg andere) zijn kopite's eigen "ontwerpen". Dat is niet meer of minder dan zijn/haar eigen natte vinger aan het werk
Wat dacht je van dit:
RDNA3 1 CU (4 SIMD) =
128+0, 96+32, 64+64, 32+96, 0+128 (5 opties)
versus
Lovelace 1 SM (4 krachtigere subcores/partities) =
192xFP32 óf 128xFP32 + 64xINT32 (2 opties)
Nvidia maakt dan voor 1 SM het FP32 pad letterlijk 2x zo sterk, de aansturing blijft verder hetzelfde. En ik vermoed dat 128+64 sterker is dan 96+32, het verschil is dat AMD dit keer meer CU's zal bieden dan Nvidia aan SM's. Kloksnelheid zal het verschil maken, en we weten niet wat we daarbij kunnen verwachten van een MCM ontwerp.
kleine muisjes hebben grote wensjes: Beschuit Met Gestampte Mensjes
Whitepapers hebben daar niet veel mee te maken. Noemt Techspot een SIMD32 een ALU? Dat lijkt me sterk, dat zou een hele grove fout zijn. En als puntje bij paaltje komt, is een subcore in een SM min of meer hetzelfde als een SIMD32, in de zin dat je er één instructie aan geeft (Single Instruction) voor maximaal 32 inputs (Multiple Data).
Ik vergelijk de DCU's met SM's omdat de DCU hetgeen is dat door de frontend gevoed moet worden. Ze zijn per twee gekoppeld aan een enkele instructie cache. Heb je de diagrammen van Nvidia en AMD wel eens bekeken? Elke Shader Engine in RDNA2 bestaat uit 10 DCU's, niet 20 CU's
Er is een reden dat ze dingen in zulke groepen afbeelden. Dat is omdat ze op die manier aangedreven worden.
Dat laatste is dus wel zo. Binnen een partitie zijn er twee datapaden. Aan de ene kant zijn het 16 pure FP32 units, aan de andere kant is het een set van 16 pure FP32 units én een set van 16 pure INT32 units. Dat is niet één set van 16 "FP32+INT32" units.
Je moet het zo zien: AMD heeft waarschijnlijk iets meer gates nodig voor hun units dan Nvidia voor hun FP32 of INT32 units. In totaal zitten de gates voor de hele FP+INT oplossing bij AMD echter korter op elkaar omdat ze in één logische unit horen en slechts één keer input vereisen, terwijl Nvidia beide units van input moet voorzien. Het is dus een compromis tussen iets meer ruimte per unit, tegenover meer ruimte tússen de units.
Geen van beide is "efficiënter" of "sneller", hangt er van af hoe ze aangestuurd worden. Dat zie je wel in Ampère.
In beide gevallen heb je te maken met clusters van X ALU's, die samen één instructie op meerdere stukjes data verwerken. Als jij 100 van Nvidia's units naast 100 units van AMD zet, ze op dezelfde manier van data voorziet, ze op dezelfde kloksnelheid laat tikken, dan ga jij 0,0 verschil zien.
Dat verschil zit niet in de ALU's, het zit in de logische organisatie van alles om de units heen.
Ga voor de gein eens door kopite's tweets heen. Zeker 50% zijn eigen verzinsels die niet "gelekt" zijn, maar pogingen om hetgeen ze denken gehoord te hebben logisch te maken. De cijfers én verhoudingen daartussen zijn de afgelopen 3-4 maanden tig keer veranderd. Met andere woorden: er zit maar heel weinig tussen dat daadwerkelijk "gelekt" is.
Kan allemaal, maar de aantallen maken allemaal geen donder uit. Als Nvidia met hun huidige frontend en memory layout binnen één SM een datapad met 128 FP32 units en een datapad met 64+64 doet, gaat dat alsnog niet geweldig schalen. Die FP32 units in het tweede datapad liggen dan nog steeds 70% van de tijd stil. Het feit dat er dan alsnog 128 over zouden zijn helpt ook niet veel met het verwerken van de 64 warps. De warps zijn toch maar 32 threads "groot". Dat zou hoogstwaarschijnlijk zelfs voor mínder occupancy per SM zorgen.
Ik zou dan eerder denken aan meer partities per SM. 6 partities, elk met dezelfde twee datapaden als nu: 16xFP32 in pad 1, 16+16 in het andere. Dan krijg je 96 FP32 + (96 FP32 / 96 INT32). Of misschien zelfs 3 paden: 16xFP32, 16xFP32 en 16xINT32 - maar dat vereist ook een behoorlijke aanpassing. 32 + (16+16) in de huidige layout is gewoon onlogisch. Ze gaan nooit zo veel FP32 aan het werk houden in elke partitie. Alles is geoptimaliseerd voor 32 breed.
Ja ik heb de diagrammen zeker bekeken, en vind je vergelijking nog steeds oneerlijk. 6900XT heeft 80 CU's, 3080 Ti heeft 80 SM's. 6700 XT 40 CU's, 3060 Ti 38 SM's. Dan ga je toch niet 2 CU's met 1 SM vergelijken?:
Ik vergelijk de DCU's met SM's omdat de DCU hetgeen is dat door de frontend gevoed moet worden. Ze zijn per twee gekoppeld aan een enkele instructie cache. Heb je de diagrammen van Nvidia en AMD wel eens bekeken? Elke Shader Engine in RDNA2 bestaat uit 10 DCU's, niet 20 CU's
Er is een reden dat ze dingen in zulke groepen afbeelden. Dat is omdat ze op die manier aangedreven worden.
Als je vanuit de aansturing wilt vergelijken, vergelijk dan 2 CU's met 2 losse SM's. Dan krijg je:
===
RDNA2 the dual CU (2x2 = 4 SIMD) =
1x
4x L0 128 kB Vector Register File
4x L0 32 kB instruction cache (4-way set-associative)
1x L1 128 kB cache (data / texture / shared memory) shared per DCU
FP32+INT32 = 0, 32, 64, 92 or 128 FP32 + 0, 32, 64, 92 or 128 INT32
128+0, 96+32, 64+64, 32+96, 0+128 (5 opties)
===
Ampere 2 x SM (4 partities) =
2x
4x L0 64 kB Register File
4x L0 16 kB instruction cache, dedicated
1x L1 128 kB cache (data / texture / shared memory) per SM
FP32+INT32 = 128, 192 or 256 FP32 + 0, 64 or 128 INT32
2x128+0, 128+0 en 64+64, 2x 64+64 (3 opties)
"256+0, 192+64, 128+128"
AMD heeft meer gates nodig voor hun 4x SIMD32 units (dual CU) dan Nvidia, maar Nvidia heeft meer L1 cache nodig om hun talrijkere maar kleinere 8x 16 FP32 en 8x 16 FP32/INT32 units (2 SM) te vullen (zelfde L0 register cache totaal, 512 kB).
edit: Tegelijkertijd heeft Nvidia er per subcore/partitie 1 Tensor core bij gedaan (4 per SM, 8 per 2 SM), en AMD heeft per SIMD ook 1 Ray Accelerators (2 per CU, 4 per dual CU) die werkt op de Texture Filter & Mapping Unites.
Ampere kan meer operaties per cycle dan RDNA2, maar alleen als de data er is. Als de data opgehaald moet worden, heeft Ampere er duidelijk meer moeite mee:
https://wccftech.com/amd-...-ampere-gpu-architecture/
maar dat gaan ze met Lovelace natuurlijk verbeteren (92 MB "L2 cache").
En dat van dezelfde manier data voorzien is niet het geval. Ze volgen duidelijk een andere strategie:
- Ampere: groter aantal beperktere ALU's (kwantiteit), elk met eigen cache, meer cache nodig om te vullen
- RDNA2: kleiner aantal sterkere ALU's (kwaliteit), met meer gedeelde cache, makkelijker om te vullen
6 partities met de huidige 2 paden, of 4 partities met 3 paden klinken allebei goed, maar ik verwacht dan voor Lovelace 3 paden met een FP32 er bij (geen splitsing van INT32, dat zou een stap terug richting Turing zijn):
16xFP32, 16xFP32 en 16x(FP32 / INT32).
De L0 instructie cache gaat dan van 64 kB -> 92 kB per partitie, en ik vermoed 192 kB L1 shared cache geheugen voor de 4 partities. De huidige L1 shared cache in Ampere is voor graphics workload stiekem beperkt tot:
64 KB L1 data / texture cache,
48 KB Shared Memory, and
16 KB reserved for various graphics pipeline operations.
dat zou dan worden:
128 KB L1 data / texture cache,
48 KB Shared Memory, and
16 KB reserved for various graphics pipeline operations.
waarbij de L1 data / texture cache alleen voor FP32 gebruikt kan worden. Dus max 33% INT32 in Lovelace (nu nog 50% INT32 in Ampere)
Deze verhouding FP32 : INT32 sluit beter aan bij games:
Lovelace, per 1 SM:
192+0, 128+64 (2 opties)
per 2 SM:
"384+0, 320+64, 256+128" (3 opties)
RDNA3, per 1 CU:
128+0, 96+32, 64+64, 32+96, 0+128 (5 opties)
per dual 2 CU:
256+0, 224+32, 192+64, 160+92, 128+128, 96+160, 64+192, 32+224, 0+256 (9 opties)
^^ ik denk alsnog dat Nvidia een betere strategie volgt voor games. Wat heb je aan al die flexibiliteit als je performance wilt?
kleine muisjes hebben grote wensjes: Beschuit Met Gestampte Mensjes
Waarom niet? Waarom wil je per se een SM gelijk trekken aan een CU?
- L0 (instructies): per partitie bij Nvidia, gehele DCU bij AMD (grotendeels, vector L0 is per CU)
- L1 (data): per SM bij Nvidia, afwezig bij AMD op dat niveau (dat is gedeeld per array, omdat AMD geen L1 per (D)CU nodig heeft)
- Registers: per partitie bij Nvidia, per SIMD32 bij AMD
- Wavefront/warp schedulers: per partitie bij Nvidia, per SIMD32 bij AMD
- LD/ST: per partitie bij Nvidia, per SIMD32 bij AMD
Er is niets "oneerlijk" aan een DCU gelijk trekken aan een SM, dat is nu eenmaal het niveau waarop de waves/warps binnenkomen en verwerkt worden. Je kunt niet 1 DCU met 2 SM's vergelijken, want 2 SM's kunnen in verschillende GPC's zitten, wat betekent dat ze aan geheel verschillende warps werken.
Een warp gaat door een enkele SM heen, een wave32 door een enkele DCU. Zo simpel is het gewoon.
Een belangrijk detail is overigens ook wel dat Nvidia 2 cycles nodig heeft voor een warp, terwijl AMD met RDNA slechts 1 cycle nodig heeft voor een wave (zowel een warp als wave bestaan uit 32 "threads"). GCN had waves van 64 en ze hadden daar 4 cycles voor nodig.
Je focust veel te veel op het proberen gelijk te trekken van de cijfertjes, maar zo werkt dat niet.
Uh, waar haal je 64 SIMD32 units vandaan?
Navi 21 heeft 40 DCU's/WGP's, wat 80 CU's maakt, wat 160 SIMD32 maakt. Doel je hiermee op de 64 ALU's binnen een CU?
Die latency komt doordat Nvidia vaker data naar "beneden" moet trekken (dus van L2 naar L1); een grotere L2 zal wel helpen, maar het zal ook geen wonderen verrichten. Het zal vooral met roundtrips naar VRAM schelen.
De hoeveelheid "L3" (IC) die AMD heeft is ook bedoeld om de druk van/naar VRAM te verminderen. Daaronder heeft AMD echter véél minder cache dan Nvidia, maar ze hoeven ook niet zo vaak data te verplaatsen. AMD heeft slechts 128 KB aan L1 per SE (10 DCU's of 20 CU's). Met andere woorden: 10 KB voor elke 128 ALU's en slechts 0,5 MB totaal. Cruciaal is echter dat de RB's (depth/stencil/alpha) óók aan die L1 hangen en dus het gros van de tijd niet naar L2 hoeven te grijpen.
Nvidia daarentegen heeft 128 KB per SM aan L1. Een volledige GA102 heeft dus maar liefst 10,5 MB aan L1 én 5 MB aan L2 (4 voor AMD). Alles wat echter in L1 zit is echter lokaal voor die SM, wat betekent dat alles wat de andere units moeten doen uit de gedeelde L2 moet komen. Met andere woorden: die L2 wordt heel veel gebruikt. Als die groter wordt, wordt die niet sneller. De roundtrip time (latency dus) blijft hetzelfde. Het zal enkel wat druk richting het geheugen weg nemen.
Dat is ook wat ik bedoel met Nvidia's aansturing en aanvoer: ze moeten per partitie instructies uitdelen (waar AMD dat per DCU doet en het verder binnen die DCU verder verdelen) en moeten constant data tussen L1 en L2 schuiven, omdat de meeste units anders niet aan de data komen. Als je een GPC met een SE vergelijkt, zul je zien dat AMD eigenlijk alleen buiten die SE hoeft te gaan op het moment dat de data nog helemaal niet geladen is; als de ene DCU iets gedaan heeft, kan een andere DCU of een RB ofzo er mee verder. Dat kan Nvidia niet. Een SM doet z'n werk en dan móet het eerst naar L2, voordat een andere SM of wat dan ook er mee verder kan.
Dat was dan ook een hypothetisch voorbeeld om te illustreren dat de ALU's niet het grote verschil zijn
Vind je?
Zet een 6900 XT eens naast een 3080 Ti. AMD heeft "slechts" 5120 ALU's voor zowel FP32 als INT32, waar een 3080 Ti 5120 FP32 gegarandeerd heeft en dan nog eens 5120 ALU's voor FP32 óf INT32 waar mogelijk. Nvidia heeft daar ook zo'n 15-20% meer sap (~350W vs ~300W*) voor nodig, ondanks de lagere kloksnelheden. RT en tensor hoef je niet eens in beschouwing, aangezien dat in de meeste games geen factor is (en zeker niet voor de tests waar men naar verbruik kijkt). Dat is puur voor "ouderwetse" graphics.
En dan draaien hun GPU's ook nog eens fors (vergeleken met AMD
) sneller dan geadverteerd; een 6900 XT zal tegen de 2,3 GHz aanhikken (tegenover 2250 geadverteerde boost, pakweg 2% meer), terwijl een 3080 Ti eerder tegen de 1800 aan hikt (tegenover 1665 geadverteerd, makkelijk 8% meer). In de praktijk doet een 6900 XT in games dus zo'n 23,6 tera-ops/s, wat dan het totaal is voor FP32 en INT32 gecombineerd. Een 3080 Ti op 1800 zou in theorie 18,4 TFLOPS doen, met daarnaast nóg eens 18,4 tera-ops/s voor FP32 en INT32 gecombineerd. Neem je 30% van die 18,4 dan mag je er 5,5 bij tellen en zou je dus op 23,9 TFLOPS en daarnaast nog eens 12,9 TIOPS uit komen.Lijkt mij dat AMD juist de betere strategie heeft, ze hebben duidelijk veel minder moeite met alles aan het werk te houden. Nvidia heeft daar nú al moeite mee, met meer units wordt dat niet makkelijker. Daarnaast kan AMD makkelijker spelen met hun verhoudingen, omdat een DCU vrij zelfstandig is en enkel de SE L1 nodig heeft van buitenaf. En elke SE is ook vrij zelfstandig, hoeft enkel via de L2 naar buiten toe. Binnen een SM heeft Nvidia het al lastig doordat de instructie caches per partitie werken, laat staan daarbuiten waar er nauwelijks iets gedeeld wordt.
* zonder geheugen:
- Formule voor verbruik van GDDR is (J per bit) * (bps / 2) * 32
- 3080 Ti = GDDR6X = 7,25 pJ/bit = (7,25 * 10^-12) * (19 * 10^9 / 2) * 32 = 2,204 W per chip; 26,5W totaal
- 6900 XT = GDDR6 = 7,50 pJ/bit = (7,25 * 10^-12) * (19 * 10^9 / 2) * 32 = 1,92 W per chip; 30,7W totaal
Kom je uit op respectievelijk rond ~323,5W en ~269,3W. En dat is een verschil van 20% voor enkel de chip.
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
Moderator General Chat
Dyslectic history cynic
Paar kleine dingetjes weer.
-Er zijn vier GFX11 ID's gevonden in Linux patches.
-Er lijkt een nieuwe display engine te zijn waarbij een chip, waarschijnlijk de APU Phoenix Point, een iets andere versie heeft. Ook lijkt deze Infinity cache te missen.
-Nog steeds geen "Navi 34" te bekennen. Ik denk dat er gewoon echt geen lager middensegment meer gaat zijn. Misschien rebranden ze Navi 23 hiervoor omdat die chip behoorlijk efficiënt is, maar dat is mijn eigen speculatie.
https://videocardz.com/ne...ix-point-apu-gets-dcn-3-1
-Er zijn vier GFX11 ID's gevonden in Linux patches.
-Er lijkt een nieuwe display engine te zijn waarbij een chip, waarschijnlijk de APU Phoenix Point, een iets andere versie heeft. Ook lijkt deze Infinity cache te missen.
-Nog steeds geen "Navi 34" te bekennen. Ik denk dat er gewoon echt geen lager middensegment meer gaat zijn. Misschien rebranden ze Navi 23 hiervoor omdat die chip behoorlijk efficiënt is, maar dat is mijn eigen speculatie.
https://videocardz.com/ne...ix-point-apu-gets-dcn-3-1
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
Moderator General Chat
Dyslectic history cynic
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
Moderator General Chat
Dyslectic history cynic
Zo te zien is AMD een beetje op de interview toer.
Nog eentje met wat details over hoe het er intern aan toe gaat met de focus op efficiëntie.
-RDNA2 haalde inderdaad veel uit imput van het CPU team als het om efficiëntie ging.
-Het vraagstuk bij efficiëntie is echt het benodigde voltage.
-Die clock speeds hebben ze zo verhoogd omdat ze systematisch door het ontwerp zijn gegaan en hun logic hebben aangepast voor hogere frequenties zonder het voltage te hoeven te verhogen.
-Smart Power Management kan blijkbaar detecteren of de game hoge frequenties nodig heeft of tegen een geheugenbottleneck gaat aanlopen en kan hierop anticiperen voor efficiëntiedoeleinden.
-Ook lijken ze bewust hun ontwerpen te analyseren rond de vraag of een logic gate wel aan hoeft te staan.
-Ze analyseren Nvidia hun ontwerpen ook uitgebreid en proberen uiteraard beter te zijn.
-Koduri krijgt eigenlijk ook een diplomatieke veeg uit de pan. Hij wordt beschreven als een visionair en software guy die veel daarvoor deed, maar eigenlijk ook iemand met weinig ervaring voor hardware of interesse in efficiëntie.
-De L3 cache arrays op RDNA2 zijn blijkbaar identiek als die gebruikt worden voor de Zen CPU's.
-Wederom 50% perf/watt voor RDNA3 zoals we al weten. Een deel hiervan is chiplets.
-Bij AMD zeggen ze dat Nvidia nu niet naar chiplets gaat, maar uiteindelijk wel zal moeten. Mij is niet helemaal duidelijk of ze doelen op Hopper of ook Lovelace bedoelen.
https://venturebeat.com/2...ergy-efficient-computing/
Nog eentje met wat details over hoe het er intern aan toe gaat met de focus op efficiëntie.
-RDNA2 haalde inderdaad veel uit imput van het CPU team als het om efficiëntie ging.
-Het vraagstuk bij efficiëntie is echt het benodigde voltage.
-Die clock speeds hebben ze zo verhoogd omdat ze systematisch door het ontwerp zijn gegaan en hun logic hebben aangepast voor hogere frequenties zonder het voltage te hoeven te verhogen.
-Smart Power Management kan blijkbaar detecteren of de game hoge frequenties nodig heeft of tegen een geheugenbottleneck gaat aanlopen en kan hierop anticiperen voor efficiëntiedoeleinden.
-Ook lijken ze bewust hun ontwerpen te analyseren rond de vraag of een logic gate wel aan hoeft te staan.
-Ze analyseren Nvidia hun ontwerpen ook uitgebreid en proberen uiteraard beter te zijn.
-Koduri krijgt eigenlijk ook een diplomatieke veeg uit de pan. Hij wordt beschreven als een visionair en software guy die veel daarvoor deed, maar eigenlijk ook iemand met weinig ervaring voor hardware of interesse in efficiëntie.
-De L3 cache arrays op RDNA2 zijn blijkbaar identiek als die gebruikt worden voor de Zen CPU's.
-Wederom 50% perf/watt voor RDNA3 zoals we al weten. Een deel hiervan is chiplets.
-Bij AMD zeggen ze dat Nvidia nu niet naar chiplets gaat, maar uiteindelijk wel zal moeten. Mij is niet helemaal duidelijk of ze doelen op Hopper of ook Lovelace bedoelen.
https://venturebeat.com/2...ergy-efficient-computing/
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
Koduri heb ik altijd een beetje het Kojima gevoel bij:
Zo te zien is AMD een beetje op de interview toer.
Nog eentje met wat details over hoe het er intern aan toe gaat met de focus op efficiëntie.
-RDNA2 haalde inderdaad veel uit imput van het CPU team als het om efficiëntie ging.
-Het vraagstuk bij efficiëntie is echt het benodigde voltage.
-Die clock speeds hebben ze zo verhoogd omdat ze systematisch door het ontwerp zijn gegaan en hun logic hebben aangepast voor hogere frequenties zonder het voltage te hoeven te verhogen.
-Smart Power Management kan blijkbaar detecteren of de game hoge frequenties nodig heeft of tegen een geheugenbottleneck gaat aanlopen en kan hierop anticiperen voor efficiëntiedoeleinden.
-Ook lijken ze bewust hun ontwerpen te analyseren rond de vraag of een logic gate wel aan hoeft te staan.
-Ze analyseren Nvidia hun ontwerpen ook uitgebreid en proberen uiteraard beter te zijn.
-Koduri krijgt eigenlijk ook een diplomatieke veeg uit de pan. Hij wordt beschreven als een visionair en software guy die veel daarvoor deed, maar eigenlijk ook iemand met weinig ervaring voor hardware of interesse in efficiëntie.
-De L3 cache arrays op RDNA2 zijn blijkbaar identiek als die gebruikt worden voor de Zen CPU's.
-Wederom 50% perf/watt voor RDNA3 zoals we al weten. Een deel hiervan is chiplets.
-Bij AMD zeggen ze dat Nvidia nu niet naar chiplets gaat, maar uiteindelijk wel zal moeten. Mij is niet helemaal duidelijk of ze doelen op Hopper of ook Lovelace bedoelen.
https://venturebeat.com/2...ergy-efficient-computing/
. Misschien beter nog John Romero; die had een John Carmack nodig voor de diepe technische kennis (John Romero was overigens zeker niet dom).Ik vermoed dat die cache meer die-size in neemt dan bijvoorbeeld een gpu met een wijdere geheugenbus. Het is wel erg efficient omdat je de data dichtbij houdt.
Moderator General Chat
Dyslectic history cynic
Ik denk dat Koduri ook wel ondergewaardeerd is. De man heeft jarenlang een grote rol gespeeld bij veel geweldige ATi videokaarten en ook een rol bij hoe goed AMD drivers nu zijn. Al die features die AMD nu ook eindelijk introduceert, nou die afdeling is door hem opgebouwd.:
[...]
Koduri heb ik altijd een beetje het Kojima gevoel bij
Koduri lijkt alleen ook wel iemand te zijn die een directe ondergeschikte nodig heeft die dagelijkse zaken afhandelt en Koduri een beetje scherp houdt. Eigenlijk was hij misschien beter op zijn plaats geweest als hoofd Radeon software + drivers en David Wang nu bij de hardware. Want die softwareafdeling die met geweldige dingen zoals Freesync of Chill kwam, heeft nu ook de hardware.
Oh dat doet het zeker. Je kan het ook zien. (onderaan)
DaniëlWW2 in "CJ's AMD Radeon Info & Nieuwsdiscussietopic - Deel 144"
Maar het scheelt waarschijnlijk wel enkele tientallen watts en verhoogt de occupency en daarom doet AMD het. Laatste zoals ik in 2020 al zei, vermoed ik ook dat ze dit deden vanwege RT. Op deze manier is data terughalen voor BvH checks ook veel makkelijker. Laatste is dat ik me toen ook al besefte dat dit een opmars was voor een chiplet based GPU en dat lijkt te gebeuren.
Want mijn vermoeden is steeds meer dat ze de L3 cache + geheugencontrollers van RDNA2 gaan afsplitsen, dit combineren met een aangepaste display engine zoals duidelijk word uit die linux patches en op een aparte N7 klasse chiplets gaan plaatsen en combineren met een RDNA3 GPU met alle logic circuits. Dat is het meest logische vanuit verschillende benaderpunten. En het zou ze ook in staat stellen om werkelijk 2,5x Navi 21 te doen, dus 12288 ALU's. Immers alles wat niet meer goed mee schaalt met N5, produceren ze niet meer op N5.
Ik besef me ook dat dit een "eens in vele generaties" kan gaan worden, misschien zelfs alla G80. Want de combinatie van flinke logic verbetering met N5 + "geheugenchiplets" + enorme centrale GPU chiplet zal het transistorbudget zo gigantisch doen toenemen dat ze iets bijzonders kunnen doen. Uiteindelijk is het namelijk ook een vraag van meer transistoren in een GPU krijgen en AMD lijkt alles te doen om dit ook te maximaliseren.
[ Voor 49% gewijzigd door DaniëlWW2 op 11-07-2022 18:56 ]
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
Je bedoelt met Navi 34 de 6nm refresh van Navi 22?:
Paar kleine dingetjes weer.
-Er zijn vier GFX11 ID's gevonden in Linux patches.
-Er lijkt een nieuwe display engine te zijn waarbij een chip, waarschijnlijk de APU Phoenix Point, een iets andere versie heeft. Ook lijkt deze Infinity cache te missen.
-Nog steeds geen "Navi 34" te bekennen. Ik denk dat er gewoon echt geen lager middensegment meer gaat zijn. Misschien rebranden ze Navi 23 hiervoor omdat die chip behoorlijk efficiënt is, maar dat is mijn eigen speculatie.
https://videocardz.com/ne...ix-point-apu-gets-dcn-3-1
https://videocardz.com/ne...efreshed-6nm-navi-2x-gpus
Navi 35 zou dan de Navi 23 refresh zijn. Lager dan 32 CU moet je het met APU's doen.
kleine muisjes hebben grote wensjes: Beschuit Met Gestampte Mensjes
/u/46804/crop5f989efcbb253.png?f=community)
Een interview met Sam Naffziger. Hij heeft het onder andere over de uitdaging van het hoge stroomverbruik van GPU's.
AMD: Addressing the challenge of energy-efficient computing
/f/image/ob79oy1o0XfQFdLhR9N5I8ps.png?f=fotoalbum_large)
AMD: Addressing the challenge of energy-efficient computing
:fill(white):strip_exif()/f/image/ob79oy1o0XfQFdLhR9N5I8ps.png?f=user_large)
Moderator General Chat
Dyslectic history cynic
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
:strip_icc():strip_exif()/u/109168/crop5c6ad3dc9bc0f_cropped.jpeg?f=community)
Ik wil ze niet gelijk trekken - ze zijn en blijven verschillend - maar ik wil ze wel vergelijken op plus- en minpunten. Net zoals het Techspot artikel doet: vergelijk 1 CU met 1 SM. Ga geen appels met peren vergelijken, ook al worden ze verschillend aangestuurd. Laten we kijken naar het transistor budget en het totale plaatje van de GPU, om eerlijk 1 CU met 1 SM te vergelijken (ik kom straks met transistor per SM/CU en transistor per ALU berekeningen), in plaats van alleen inzoomen op de aansturing.
Ik vind je aansturing perspectief wel interessant en leerzaam, maar die 40 dual CU's in een 6900XT moeten het alsnog praktisch opnemen tegen de 80 SM's van een 3080 Ti.
Wat ik probeer te begrijpen is dit: Hoe dragen de verschillende onderdelen van de units, bij aan de game performance? Als je dat begrijpt, kun je beter voorspellen waar de zwakke punten zitten, die AMD en Nvidia waarschijnlijk graag willen verbeteren. Dankzij onze discussie heb ik daar nu een beter beeld van.
Ik ben niet op zoek naar wetenschappelijke uitspraken over 1 CU of 1 SM, ik probeer hier game performance in te schatten, en welke factoren daar wel/niet aan bijdragen. Ook als de designs van een CU en SM inhoudelijk verschillend zijn, dan kun je alsnog uitspraken doen over hun capaciteiten, en ze vergelijken. Waar zijn ze goed in, waar zijn ze slecht in?
Inhoudelijk zie ik trouwens ook veel overeenkomsten:
- L0 Register cache: bij allebei 256 kB in totaal (SM: 4x64kB. CU: 2x128kB)
- L1 shared data cache: 128 kB per SM, elke dual CU heeft 128 kB local data share
- Allebei registers. Partities de subunits bij Nvidia, SIMD32 de subunits bij AMD. Allebei subunits.
- Wavefront/warp schedulers: allebei de architecturen verdelen voor game performance de wavefronts en warps over alle dual CU's en SM's. Niet slechts 1.
- Ik beperk me tot FP32 en INT32, een typische game workload. LD/ST instructies beschouw ik niet.
Je mag het niet oneerlijk vinden, ik mag het wel oneerlijk vinden. Daar komen we niet uit, is een waarde oordeel. Je kunt heel goed 1 DCU met 2 SM's vergelijken. In het totaal plaatje werken 40 DCU's aan verschillende warps èn werken 80 SM's aan verschillende warps
Als je 80 warps stuurt naar 80 SM's die er 2 cycles over doen, dan heb je het toch over dezelfde 80 warps die je naar 40 DCU's stuurt die er 1 cycle over doen, maar dan 2x? Even aangenomen dat alle warps binnen die 1 of 2 cycles afgerond kunnen worden (is niet zo, maar goed).
Ik probeer een SM en CU niet gelijk te trekken: ze zijn verschillend. Ik probeer de voor- en nadelen van RDNA2/Ampere te vergelijken.
Typefout, dus ik kan je verdere vragen hierover helaas niet beantwoorden. Ik dacht waarschijnlijk 2x32 = 64 SIMD ipv 2 SIMD32.:
Uh, waar haal je 64 SIMD32 units vandaan?
Dat is dus duidelijk een minpunt van de Ampere architectuur, het Techspot artikel bevestigt dat ook. Maar zelfs in de "slechtste" 4x 16 FP32 + 16 INT32 modus per SM, doet Ampere nog steeds de INT32 gelijktijdig. Bij RDNA2 plegen die roofbouw op de FP32 operaties.
Point taken, maar toch presteert Ampere vergelijkbaar, per SM of per CU, in de vergelijking met RDNA2. Op 4k verslaat Ampere duidelijk RDNA2:
https://www.techpowerup.c...-founders-edition/28.html
Qua performance per Watt, zit Nvidia maximaal 15% lager: https://www.techpowerup.c...-founders-edition/35.html , maar let op: de 3060 Ti geeft betere performance per Watt dan een 6700 XT. Zo inefficient zijn Nvidia's ontwerpen niet, wat die Sam Naffziger ook bevestigt:
https://venturebeat.com/2...ergy-efficient-computing/
Bedenk ook dat GA102 groter is dan Navi21 en daardoor meer stroom verbruikt (meer oppervlak, meer stroom nodig).
Weet ik niet. Ik zie 2x zoveel ALU's bij Nvidia. Ze moeten die lagere kloksnelheid en slechte cache benadering toch ergens mee compenseren.:
Dat was dan ook een hypothetisch voorbeeld om te illustreren dat de ALU's niet het grote verschil zijn
Ik geef zeker toe dat AMD een slimmere strategie lijkt te voeren, maar uiteindelijk telt performance. Als Nvidia met een paar slimme ingrepen hun zwakke punten kan verminderen, zou hun monolitische design deze generatie nog steeds kunnen winnen.:
Vind je?
Zet een 6900 XT eens naast een 3080 Ti. AMD heeft "slechts" 5120 ALU's voor zowel FP32 als INT32, waar een 3080 Ti 5120 FP32 gegarandeerd heeft en dan nog eens 5120 ALU's voor FP32 óf INT32 waar mogelijk. Nvidia heeft daar ook zo'n 15-20% meer sap (~350W vs ~300W*) voor nodig, ondanks de lagere kloksnelheden. RT en tensor hoef je niet eens in beschouwing, aangezien dat in de meeste games geen factor is (en zeker niet voor de tests waar men naar verbruik kijkt). Dat is puur voor "ouderwetse" graphics.
En dan draaien hun GPU's ook nog eens fors (vergeleken met AMD
Lijkt mij dat AMD juist de betere strategie heeft, ze hebben duidelijk veel minder moeite met alles aan het werk te houden. Nvidia heeft daar nú al moeite mee, met meer units wordt dat niet makkelijker. Daarnaast kan AMD makkelijker spelen met hun verhoudingen, omdat een DCU vrij zelfstandig is en enkel de SE L1 nodig heeft van buitenaf. En elke SE is ook vrij zelfstandig, hoeft enkel via de L2 naar buiten toe. Binnen een SM heeft Nvidia het al lastig doordat de instructie caches per partitie werken, laat staan daarbuiten waar er nauwelijks iets gedeeld wordt.
In de vergelijking van TFLOPs, geeft Techspot aan:
- 36% of the instructions processed by a GPU involved INT32 routines
Als je uitgaat van 1800 en 2300 MHz en de 23,6 TFLOPs van Navi21, dan moet GA102 iets van 30,2 totale TFLOPs en TIOPs (ik combineer ze even tot TOPs) halen (als er verder geen bottlenecks zijn om game performance te vergelijken). Van de totale 36,8 TOPs zal er beste 6,6 TOPs verloren gaan, dankzij latency, lagere occupancy, etc.
Dan de goeie ouwe transistors, wat kost 1 SM en wat kost 1 CU? Hoeveel transistors kost een ALU bij beide?
GA102, 7 GPC, 84 SM: 363 mm2 , density 45,1 Mtr/mm2 => 194,9 Mtr/SM
Navi21, 4 SE, 80 CU: 215 mm2 , density 51,5 Mtr/mm2 => 138,36 Mtr/CU
1 SM heeft 4x(16 FP32 ALU + 16 FP32/INT32 ALU) = 128 ALU's
1 CU heeft 2x(32 FP32/INT32 ALU) = 64 ALU's
Ampere: 1,52 Mtr per ALU
RDNA2: 2,16 Mtr per ALU
Je zou de AMD ingenieurs transistor-gulzig per ALU kunnen noemen
, maar performance per Watt kan de doorslag geven voor de high end omdat er grenzen zijn aan TDP.Nvidia heeft ruimte over voor L2 cache èn extra ALU's.
AMD zal ALU's meer dan moeten verdubbelen om gelijk te komen, dat gaan ze niet per CU doen met evenveel CU als SM. Zij zullen het moeten hebben van het chiplet design, om meer dan 144 SM te hebben aan CU. En dat is ook het plan met Navi31: 3x64 = 192 CU. Wat is echter de latency of kloksnelheid prijs om 3 chiplets met elkaar te laten praten, snel genoeg?
Qua kloksnelheid, Nvidia gaat een stuk meer terrein winnen vanuit Samsung 8nm naar TSMC 4nm, dan AMD van TSMC 7nm naar 5nm.
Dit gevecht wordt nog steeds spannend.
kleine muisjes hebben grote wensjes: Beschuit Met Gestampte Mensjes
Moderator General Chat
Dyslectic history cynic
AMD lijkt weer een oepsie te hebben gedaan. De beste bron van informatie dus.
Uit weer linux patches is te herleiden dat Navi 31 inderdaad bestaat uit een GCD en zes MCM chips.
Daaruit kan je meteen herleiden dat we een 192 of 384bit bus hebben. Het is dus 384 want high end. Kijk je dus naar 12GB of 24GB aan VRAM.
Ook impliceert het waarschijnlijk 192 of 384MB aan L3 cache.
https://videocardz.com/ne...e-384-bit-wide-memory-bus
En dan ga ik eens in mijn hoofd na wie hier allemaal al een tijdje geleden mee kwamen aanzetten. Tja zo krijg ik ook wel meer vertrouwen in dat het inderdaad 12288 ALU's voor Navi 31 gaat worden. Die waarde past perfect in een verdeling met zes shader engines alsmede met het idee van een aangepaste WGP en CU.
Dus voor de mensen die de 2x tussen RDNA1 en RDNA2 al indrukwekkend vonden, tja ik ben bang dat je nog niks hebt gezien. Dit ding is hard op weg om werkelijk over de 2x te gaan.
Oh en deze is ook wel grappig. Hallo single issue wave64. Ik denk dat we kunnen concluderen dat er ook iets gaat veranderen aan de CU structuur.
Nee, RDNA1/2 kunnen dit niet. Die hebben twee cycles nodig om een wave64 af te handelen omdat die een dergelijke wave opsplitsten in twee wave32 een in sequentie uitvoeren op een SIMD32.
Uit weer linux patches is te herleiden dat Navi 31 inderdaad bestaat uit een GCD en zes MCM chips.
Daaruit kan je meteen herleiden dat we een 192 of 384bit bus hebben. Het is dus 384 want high end. Kijk je dus naar 12GB of 24GB aan VRAM.
Ook impliceert het waarschijnlijk 192 of 384MB aan L3 cache.
https://videocardz.com/ne...e-384-bit-wide-memory-bus
En dan ga ik eens in mijn hoofd na wie hier allemaal al een tijdje geleden mee kwamen aanzetten. Tja zo krijg ik ook wel meer vertrouwen in dat het inderdaad 12288 ALU's voor Navi 31 gaat worden. Die waarde past perfect in een verdeling met zes shader engines alsmede met het idee van een aangepaste WGP en CU.
Dus voor de mensen die de 2x tussen RDNA1 en RDNA2 al indrukwekkend vonden, tja ik ben bang dat je nog niks hebt gezien. Dit ding is hard op weg om werkelijk over de 2x te gaan.
Oh en deze is ook wel grappig. Hallo single issue wave64. Ik denk dat we kunnen concluderen dat er ook iets gaat veranderen aan de CU structuur.
— Kepler (@Kepler_L2) 6 juli 2022
Nee, RDNA1/2 kunnen dit niet. Die hebben twee cycles nodig om een wave64 af te handelen omdat die een dergelijke wave opsplitsten in twee wave32 een in sequentie uitvoeren op een SIMD32.
[ Voor 8% gewijzigd door DaniëlWW2 op 13-07-2022 19:05 ]
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
:strip_icc():strip_exif()/u/92491/crop64a1593f33a7b_cropped.jpg?f=community)
Moderator General Chat
Dyslectic history cynic
Dat dit heel erg duur kan gaan worden, had ik je maanden geleden al kunnen vertellen. Sterker nog, volgens mij heb ik dat zelfs gedaan.
Maar compleet rampzalig is het ook niet. Ergens denk ik dat die centrale GCD in het 400mm a 500mm2 bereik kan blijven. Immers schaalt logic wel, de rest niet echt meer. Ook weet ik nog steeds niet of ze een interposer nodig gaan hebben of ze niet alsnog wegkomen met alleen een substraat net zoals met Zen 2/3/4. Ik vermoed dat een interposer niet nodig gaat zijn omdat het om verbindingen gaat die niet erg latency gevoelig zullen zijn. Immers is L3 cache of VRAM binnen RDNA niet iets dat constant aangesproken moet worden om de verschillende shader array's aan het werk te houden.
Dit in tegenstelling tot Nvidia waar hun GPU's waarschijnlijk veel afhankelijker zijn van de centrale L2 cache toegang. Voor mij is dat eigenlijk een van de voornaamste redenen dat ik al langer vermoed dat er geen MCM ontwerp gaat komen voor Lovelace. En omdat Nvidia niet de voordelen van chiplets kan gebruiken, zie ik ze daar makkelijk over de 600mm2 gaan.
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
@DaniëlWW2 ik had volgens mij met de 6900Xt gezegd dat ie 1200€ ongeveer ging kosten, zat er toen een paar honderd € naast maar na een paar maand was het wel zo ver en zelfs duurder. Ben eens benieuwd hoeveel ik er nu naast gaan zitten.
en zelfs duurder. Ben eens benieuwd hoeveel ik er nu naast gaan zitten.
Al wat ik aanraak werk niet meer zoals het hoort. Damic houd niet van zijn verjaardag
Moderator General Chat
Dyslectic history cynic
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
Uiteraard, maar dat wisten we al, maar dan alsnog, je koopt die kaart liever voor $1499 of $1999 zelfs als Enthousiast dan dat je een $1499 MSRP kaart moet kopen voor $2999 omdat crypto toevallig booming is, wat gebeurde met de RTX 3090 bijvoorbeeld. Voor Halo kaarten is zeker een markt, maar ook die kopers geven vaak liever niet teveel uit (want dat kunnen ze weer aan andere goodies besteden
). Gelukkig viel de 6900XT mee omdat deze bij AMD.com vrij goed verkrijgbaar was, vaak zelfs een relatief goede deal, omdat de 6800XT altijd binnen 10 seconden weg was en dus eigenlijk niet bestond. Ook de enige reden waarom ik nu een 'Halo' kaart in mijn PC heb trouwens.
Bij de launch kan de euro zo maar 70 dollarcent waard zijn, dus maak je borst maar nat 
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Het punt is juist dat je niet "eerlijk" aan het vergelijken bent als je de aantallen tussen CU's en SM's gelijk probeert te trekken. Je kunt een partitie in een SM niet los van de andere partities bekijken; die partitie kan niet autonoom draaien. Als die partitie in mixed-mode draait, draaien de andere 3 partities dat ook. Omgekeerd kun je een CU niet los bekijken, omdat die z'n instructies met de andere CU in de DCU deelt. Je kunt (van "buitenaf" of "bovenaf") geen instructies naar een enkele CU sturen. Je hebt er altijd twee "bezet"; zelfs als de scheduler binnen de DCU alles op 1 CU zou gooien, is de andere bezet omdat er geen instructies voor beschikbaar zijn.
Dat is juist waardoor game performance bepaald wordt. AMD gooit 80 wave32's naar een DCU, Nvidia gooit 64 warps naar een SM. Die workloads worden vervolgens binnen de gehele SM of gehele DCU verwerkt. In een ideale wereld is dat 4x20 voor AMD en 4x16 voor Nvidia, in de praktijk komt dat over het algemeen niet helemaal uit door afhankelijkheden tussen threads.
Registers != L0 instructie cache.
Een DCU heeft slechts 32 KB aan L0 instructie cache voor de 2 CU's / 4 SIMD32's; het is 16 KB per partitie bij Nvidia.
Daarnaast kun je ook niet zomaar zeggen dat ze beide 256 KB aan (vector) registers hebben, want de manier waarop dat verdeeld is doet er ook toe. Sowieso is het volgens mij niet 2x128 voor een CU, als ik het me goed herinner heeft een SIMD32 wel toegang tot 128 KB, maar is dat juist gedeeld (en coherent!) binnen een CU. Coherence met de andere CU in die DCU is niet gegarandeerd. Bij Nvidia is er niets coherent tussen de partities. Niet alleen de verdeling doet er toe, ook de manier waarop het "aangesloten" is. Ik kom hier zometeen op terug.
L1 != local data share. Heel andere dingen. AMD's LDS is bedoeld voor synchronisatie tussen workloads en wat texture operaties. AMD's DCU's hebben zoals ik al zei ook gewoon toegang tot een "echte" L1$.
Dat is niet helemaal juist, zoals ik hierboven al aan gaf, echter geef je hier precies aan wat ik de hele tijd zeg: je kunt een enkele CU niet aansturen zonder de andere CU in een DCU ook aan te sturen, evenmin als je een enkele partitie van een SM kunt aansturen zonder de andere 3 partities ook te "bezetten".
Een DCU heeft 4 wave controllers (1 per SIMD32), goed voor maximaal 80 waves, een SM heeft 4 warp schedulers (1 per partitie), goed voor maximaal 64 warps. Cruciaal hierbij is dat de 4 wave controllers aan een enkele, gedeelde L0$ hangen en dus niet onafhankelijk van elkaar aangedreven kunnen worden. Wederom: je kunt een CU niet aan het werk zetten zonder de ander ook aan het werk te zetten. Bij Nvidia is het minder duidelijk hóe ze tegenwoordig alles precies naar de warp schedulers krijgen (daar hebben ze sinds Fermi niets meer over gezegd), maar we weten wel dat je evenmin een partitie aan het werk kan krijgen zonder de rest van de SM ook te "bezetten".
Om het dus vanuit de "top" schedulers te bekijken (Nvidia's GigaThread Engine en AMD's Command Processor): je kunt 80 SM's aansturen, of 40 DCU's. Bínnen die groepen nemen de "lokale" schedulers het over.
Sorry, maar dat is onzin. Juist games hebben veel load/store activiteit. En juist dat is waar AMD's cache layout heel veel data verplaatsing vermijdt. Wederom, cache zal ik zo even op terug komen.
Wederom geef je precies aan wat ik ook de hele tijd zeg: 1 warp of wave32 wordt door respectievelijk 1 SM of 1 DCU afgehandeld. Een SM of een DCU is de kleinst mogelijk aanstuurbare groep vanuit de "top" scheduler gezien. Dat dat betekent dat AMD over "slechts" 40 groepen beschikt doet er verder niet toe, want die groepen werken anders dan die van Nvidia, wat je ook aan geeft.
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.
Wellicht belangrijker is echter dat als je achter elkaar 128xFP32, 64+64 en weer 128xFP32 (allemaal netjes verdeeld over 4 verschillende warps/waves voor perfecte bezetting) zou hebben dat dat voor Nvidia in theorie een ideale bezetting is. Echter zitten er dan tijd tussen de ops omdat de SM moet schakelen tussen FP32 en INT32 mode; dat is niet "gratis" voor ze. AMD daarentegen heeft daar schijt aan en gooit ze gewoon in 3 cycles door de hele DCU heen. Zij doen de ene cycle gewoon FP32 en de cycle erna INT32, dat maakt niets uit (data cycles even negerend
). Jouw voorbeeld hierboven zou dus waarschijnlijk sneller op AMD zijn omdat het schakelen hen niets kost.Het wordt nog erger als je 3 warps/waves met enkel 32xFP32 en 1 warp/wave met 32xINT32 hebt. AMD kan dat er in principe in één keer doorheen knallen. Een SIMD32 voor die 32 INT ops en de andere 3 aan FP32. No problemo. Nvidia moet dat sowieso in twee keer doen, 64+32 en dan nog eens 32. Dat is dus iets wat de scheduler zal proberen te vermijden door die INT warp naar een andere SM te gooien, maar dat kan niet altijd.
Er zijn voor beide verdelingen van warps/waves die de ander veel sneller zou kunnen doen, met name bij warps/waves die kleiner dan 32 zijn. AMD heeft echter wel meer flexibiliteit in de zin dat zij in theorie binnen een DCU in principe 1 SIMD constant aan INT zouden kunnen laten werken en dus slechts per 32 units hoeven te plannen. Nvidia moet dat meteen per 64 doen, wat het lastiger maakt én een groter risico van lage bezetting heeft. Je moet het zo zien, Nvidia moet al in een heel vroeg stadium zorgen dat ze integer werk zo veel mogelijk concentreren zodat zo min mogelijk SM's hoeven te gaan schakelen. Tegelijkertijd moeten ze ook wel genoeg FP "mee sturen" om de pure FP32 ALU's ook een beetje aan het werk te houden. AMD haalt intussen z'n schouders op en verdeelt alles gewoon zoveel mogelijk in groepen van gelijke grootte, wat daar precies in zit doet er pas toe als ze willen optimaliseren voor throughput (packed FP16 etc). Maar als alles 32 bits is? Nergens zorgen over.
Ah, maar ook dat is vrij logisch, wederom aan de hand van de memory layout
In Nvidia's geval heb je per SM een L1 die aan de L2 hangt, die op zijn beurt gedeeld wordt door de hele chip. Met GA104 heb je dus véél minder druk op de L2, simpelweg omdat er minder SM's zijn. En dat is één van de meest sap-vretende dingen in een CPU of GPU: data verplaatsen. Ik weet uit m'n hoofd niet hoe veel cache lines er overal lopen, maar het zal waarschijnlijk genoeg voor een hele warp zijn, dus minstens 128 bytes per L1.
In AMD's geval gaat dat anders. Daar hangen slechts 10 DCU's aan een stukje L1 (ook weer genoeg voor een hele wave in één keer), minder dan een kwart van het aantal SM's aan de L2. En de L1 hangt op zijn beurt weer aan de L2, wat betekent dat er slechts 4 L1 caches aan de L2 hangen.
Waar het grote verschil zit is in hoe váák die L2 caches aangesproken moeten worden. Een partitie in een SM vraagt data op uit de L1 en als dat daar nog niet aanwezig is moet het meteen naar de L2. Een partitie in een andere SM moet precies hetzelfde doen als die dezelfde data nodig heeft. Je zou dus zomaar 84 SM's kunnen hebben die exact dezelfde data uit de L2 opvragen. Voor GA104 zakt dat meteen naar 48, wat duidelijk scheelt.
AMD daarentegen deelt sowieso al binnen een CU, vervolgens binnen een DCU, dan weer binnen een array en pas dan moet de L2 er aan te pas komen. In het ergste geval krijgt de L2 dus van 4 kanten een verzoek om dezelfde data in Navi 21. Of van 2 kanten in Navi 22.
Dus hoewel een SM niet per definitie minder efficiënt is dan een DCU, is de manier waarop alles samen hangt dat wel. Bij AMD blijft de data veel vaker "dichtbij" voor de units die er iets mee moeten. Of om het wellicht iets meer naar de fysieke chips te trekken, bij Nvidia moet er veel vaker "stroom" helemaal van L2 naar een register voor een ALU dan bij AMD. Daarom zie je bij Nvidia ook zo'n extreme schommelingen in het verbruik, terwijl het bij AMD relatief voorspelbaar is. Het schaalt ook allemaal vrij voorspelbaar, terwijl GA104 duidelijk veel efficiënter is dan GA102.
Oh, absoluut, het kán wel. Maar dat is juist wat ik de hele tijd al zeg: die "slimme ingrepen" zijn behoorlijk radicaal. Er zou er sowieso een L2 binnen een GPC moeten komen zodat SM's data kunnen delen, en de huidige L2 zou een L3 moeten worden, om zowel de druk op L3 te verlagen alsmede minder cycles kwijt te raken aan het verkrijgen van data. En eigenlijk zou er per GPC ook een scheduler moeten komen, want alles in één klap over 84 SM's verdelen is gewoon lastig; in het ergste geval hebben ze 5376 warps te verdelen, waarbij ze constant rekening moeten houden met welke SM met welk data type bezig is en welke data wellicht al in de L1 van een SM aanwezig is. Binnen een SM moet je de mixed datapaden onafhankelijk aan kunnen sturen om de bezetting te verbeteren en er voor zorgen dat je geen cycles kwijt raakt aan het schakelen tussen de twee modes en er het liefst elke cycle gewoon een warp doorheen kan gooien. Maar dan moet ook de scheduler op z'n kop, want die moet ook overweg kunnen met workloads ontworpen voor alles t/m Ampère. En de driver ook, aangezien die veel werk verzet met het splitsen.
Dat is allemaal heel ingrijpend, maar dat is wel wat AMD met RDNA heeft gedaan ten opzichte van GCN. Hoewel ze veel van dezelfde termen gebruiken, is RDNA duidelijk van de grond af herontworpen. Alles in RDNA is er op gericht om elke cycle alle delen van de GPU aan het werk te houden. Alle caches hebben genoeg lines om per cycle een hele waves in één klap van data te voorzien. De schedulers kunnen elke cycle een instructie uitdelen. De ALU's kunnen elke cycle een op tot 32-bit uitvoeren; met minder bits meer ops.
Dat is ook wat ik bedoel wanneer ik zeg dat de ALU's of zelfs Nvidia's SM's an sich het probleem niet zijn. Het is alles er omheen. Kan dat anders? Zeker. Maar tot op heden wijst helemaal niets er op dat er een geheel nieuwe architectuur aan zit te komen.
Wat het enkel tragischer maakt, want AMD heeft op die manier dus 23,6 "TOPs", 78% van wat Nvidia heeft (of Nvidia heeft 28% meer als je het om draait), maar er vrijwel even veel performance uit perst. Nvidia gooit met GA102 veel performance weg. De 3080 is nog redelijk, maar de SKU's daarboven zijn gewoon onzinnig. Meer ALU's gaat dat niet oplossen, ongeacht of dat in meer SM's is of meer ALU's per SM.
Helaas is dit niet zo eenvoudig (ik ga er van uit dat je de oppervlaktes gebaseerd hebt op een percentage van het totaal van de chip, kijkend naar de die shots (~41% voor AMD, ~57% voor Nvidia)? Transistor dichtheid is niet constant in een hele chip. Cache (SRAM) heeft een heel andere dichtheid dan een rekeneenheid (TSMC kan SRAM op N7 bijvoorbeeld op meer dan 200Mt/mm² doen); maar zelfs dan zijn RT cores, Tensor cores, ROP's (enzovoort) niet gelijkwaardig.
Het zal daarom ook niet uit komen op miljoenen per ALU, want in die miljoenen van jou zitten dus ook al die andere dingen verwerkt; een ALU zelf is vele malen kleiner dan dat. Ik ga niet eens een poging wagen, we zullen er nooit bij in de buurt komen.
Waarom heeft Nvidia ruimte over en AMD niet, ik volg dat totaal niet? AMD kan op dit moment juist makkelijk twee shader engines toevoegen en dus 50% meer ALU's in dezelfde ruimte als Nvidia persen als ze de IC houden zoals hij is op 128 MB. En zelfs als ze die verhogen naar 160 MB (+32; Navi 22 XT heeft -32 voor 50% van de shader engines
) is dat slechts een kwart meer van de ruimte die IC nu in neemt. Juist met jouw berekening zou 50% meer logica slechts ~107,5mm² kosten Dat is echter ook wat het lastig maakt in te schatten waar de transistors nu zitten, laat staan waar het naartoe gaat met N5. Zoals ik hierboven zei is SRAM over het algemeen heel compact, waardoor Navi 21's transistor dichtheid dus hoger lijkt dan het is, want IC neemt ook aardig wat ruimte in op de hele chip. Als Nvidia dus een berg L2 toe zou voegen, hebben we ook geen enkel idee waar hun chips naar toe gaan qua afmetingen.
Ook dat is weer zoiets dat zo vaak geroepen wordt, maar helemaal zo makkelijk niet is
Ten eerste is dat volgens de gerichten "4N", wat dan een naam is voor "N5 for Nvidia". Dat zal geen hogere dichtheid of iets dergelijks omvatten, maar tweaks voor Nvidia's ontwerpen qua doel dichtheden. Net zoals "12FFN" dat was. TSMC's "N4" is een daadwerkelijke verbetering, maar dat is dus N4, niet 4N
Daarnaast is kloksnelheid extreem afhankelijk van chip ontwerp. We kunnen helemaal niets zeggen over wat Nvidia wel of niet kan gaan halen op N5/4N (of wat ze nu op N7 zouden kunnen halen tegenover Samsung's 8N), want AMD heeft RDNA heel specifiek ontworpen om hoge kloksnelheden te halen.
Wat bedoel je met "de rest"? Want uitgerekend SRAM (cache) schaalt doorgaans wél goed en daar heeft RDNA aardig wat van
De sprong wordt voor SRAM wel steeds kleiner juist omdat dat al zo bizar compact is, is dat wat je bedoelt?
Moderator General Chat
Dyslectic history cynic
TSMC is het niet met je eens.:
Wat bedoel je met "de rest"? Want uitgerekend SRAM (cache) schaalt doorgaans wél goed en daar heeft RDNA aardig wat van
De sprong wordt voor SRAM wel steeds kleiner juist omdat dat al zo bizar compact is, is dat wat je bedoelt?
Voor N5 vanaf N7 claimen ze zelf:
Logic = 1,84x
SRAM = 1,3x
I/O = 1,2x
DaniëlWW2 in "CJ's AMD Radeon Info & Nieuwsdiscussietopic - Deel 144"
In de praktijk zal het nog minder zijn omdat we beiden weten dat de opgegeven waarden van de fabrikant, altijd beste scenario zijn. Er is denk ik een heel goede reden waarom ze bij AMD waarschijnlijk nu naar chiplets gaan met RDNA3 en al die L3 cache gaan afsplitsen en op N6 produceren. Het hele punt is juist dat nu bij N5, de rek er ook een beetje eruit is voor de kleinere SRAM cellen en alleen logic nog over is.
Ik besefte het me in 2020 eigenlijk al toen ik Navi 21 zag. Het hele ontwerp schreeuwde toen al afsplitsen samen met de I/O naar aparte chiplets. Zeker omdat toen al duidelijk was hoe duur N5 is per wafer en dat de voordelen beperkt zijn voor steeds grotere delen van een chip.
Tweede is dat dus blijkt dat RDNA2, dezelfde L3 cache array zit als in Zen 2/3. Direct van Zen 2 overgenomen dus. En het zou eens tijd worden dat AMD dergelijke stappen ging nemen. ATi is immers in 2006 overgenomen en na al die jaren mag er wel eens wat succesvolle synergie ontstaan.
DaniëlWW2 in "CJ's AMD Radeon Info & Nieuwsdiscussietopic - Deel 144"
En voor mij gaat er dan ook een andere gedachte op. Ik denk dat AMD eigenlijk weinig tot niks gaat veranderen aan hun geheugencontrollers voor RDNA3. Navi 33 zou monolithisch op N6 zijn en daar porten ze het vanuit RDNA2. Navi 31/32 gebruiken ze hoogstwaarschijnlijk dezelfde MCM chips. Vervolgens hebben ze de L3 cache array allang ontwikkeld en hebben ze nog een functie voor, Raphael-X. Ik denk dat ze daar ook N6 zullen gebruiken voor de 3D V-cache.
AMD moet ergens ook wel omdat zoveel bleeding edge chips van verschillende fabrikanten, nu naar TSMC N5 gaan. Als je dan leidend bent in heterogene halfgeleidertechnologie en je zit krap qua wafers en RDNA3 is waarschijnlijk ook nog eens minder winstgevend dan de andere N5 producten van AMD, tja dan gaat elke mm2 denk ik tellen.
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
Ah zo bedoel je. Ja, met de stap naar N5 krimpt SRAM in verhouding minder dan voorheen (een cel is nu op N7 27nm²; op 10 was dat nog 42 en op 16/12 maar liefst 74!).:
TSMC is het niet met je eens.
Voor N5 vanaf N7 claimen ze zelf:
Logic = 1,84x
SRAM = 1,3x
I/O = 1,2x
DaniëlWW2 in "CJ's AMD Radeon Info & Nieuwsdiscussietopic - Deel 144"
In de praktijk zal het nog minder zijn omdat we beiden weten dat de opgegeven waarden van de fabrikant, altijd beste scenario zijn. Er is denk ik een heel goede reden waarom ze bij AMD waarschijnlijk nu naar chiplets gaan met RDNA3 en al die L3 cache gaan afsplitsen en op N6 produceren. Het hele punt is juist dat nu bij N5, de rek er ook een beetje eruit is voor de kleinere SRAM cellen en alleen logic nog over is.
Díe verhouding is echter wél relatief haalbaar, omdat SRAM min of meer een standaard gegeven is. Voor logic zijn die cijfers zelden haalbaar omdat dat enkel theorie is en ten koste gaat van overige eigenschappen (spanning, frequentie, leakage, enzovoort), terwijl dat voor SRAM cellen er niet écht toe doet.
Eenvoudigste te zien in SoC's met relatief veel cache, zoals Apple's A serie. Tussen A12/A13 (N7) en A11 (N10) is de dichtheid met pakweg 75% omhoog gegaan; TSMC's claim was ~60% volgens mij, dus dat is boven verwachting. A14 (N5) zit zo'n 55% hoger dan A13, minder dan die 84%...maar dat is omdat er nauwelijks iets veranderd is qua caches ten opzichte van 12/13, terwijl die op hun beurt juist een hele berg aan cache (system cache noemde Apple dat) toe voegden, maar liefst 16 MB (en volgens mij werd de L1 ook groter). In een chip van rond de 90mm². A14 heeft dat allemaal behouden en vooral bergen logica toegevoegd, met name in de "Neural Engine".
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
PC Specs
Asus ROG Strix B650E-E | AMD 9800X3D |TR Phantom Spirit 120 SE | G-Skill 32GB DDR5 6000C30 M-die | 4090 FE | 3840*1600p 160Hz | Corsair RM1000x Shift
/u/233413/crop574768220d598_cropped.png?f=community)
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
Moderator General Chat
Dyslectic history cynic
Sampling. Misschien krijgt de "RX7900XT" dit nog net, al dan niet met een refresh, maar de meeste denk ik niet. Ik denk dat de meeste RDNA3 SKU's met 18Gbps komen.:
Dit zou op de komende generatie kunnen zitten
Samsung Launches Industry's First 24Gbps GDDR6 Memory
En nu is het 21nm2 volgens TSMC. Dus iets van 22% kleiner.
Ik kijk misschien te snel, maar ik heb nu ook niet iets van dat A14 of M1 nu zo indrukwekkend lijken qua cache formaat of percentage van de chips die uit cache bestaan. Als je een bak met cache met een klein beetje logic wil, dan moet je bij Zen 2/3 zijn. Ik denk dat Zen 4 een beter ijkpunt zal zijn.
Voor RDNA3 zie ik eigenlijk ook niet in hoe ze afdoende L3 cache gaan implementeren voor het verwachte toename aan formaat en de nu wel bevestigde 384bit bus. Ik denk dat het echt afgesplitst zal zijn omdat het anders waarschijnlijk niet gaat passen en de logica van zes MCM chiplets compleet verloren gaat. Het werkt ook in RDNA om L3 cache af te splitsen omdat het tussen VRAM en de pipelines zit. Het is geen onderdeel van een pipeline of zoals de centrale L2 cache van Nvidia, waarbij de latency penalty onacceptabel zou zijn.
L0, L1 en L2 zullen wel op de GCD chiplet zitten. Kan niet anders tenzij AMD wel heel, veel veel rare dingen gaat doen met RDNA3. Daar gaan we denk ik de meer geringe voordelen van N5 SRAM wel zien, maar het zal denk ik een relatief klein deel van de hele chip zijn.
Dan nog de afgelopen generatie en prijzen. Er is natuurlijk wel meer veranderd. We zaten in een periode waarbij mensen min of meer thuis opgesloten zaten en hun extra besteedbaar inkomen niet gemakkelijk konden uitgeven. In dat kader kan je nog rechtvaardigen om een paar honderd euro extra uit te geven aan een videokaart.
Inmiddels is de wereld veranderd. We hebben te maken met enorme inflatie die echt niet meer gaat verdwijnen. We kunnen weer naar buiten, de nieuwe nodes zijn duur en veel handelsnetwerken zijn zwaar verstoord. Een dreigend wereldwijd olietekort maakt het nog erger. Ook lijkt zeker Nvidia, een gigantische inventaris te hebben aan oude RTX30 serie chips. Aan de ene kant gaan de productiekosten dus omhoog, maar aan de andere kant gaat de financiële draagkracht van de gemiddelde consument waarschijnlijk omlaag. Het gaat denk ik nog interessant worden hoe dat precies gaat uitvallen. Navi 31/AD102 schrijf ik echt af als "betaalbaar", maar ik weet niet wat er met Navi 32/33 en AD103/104 gaat gebeuren. Want zeker voor 33 en 104 is er denk ik wel een negatieve prijsdruk met de oude kaarten alsmede afnemende financiële draagkracht van consumenten.
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
:strip_icc():strip_exif()/u/91627/crop6479f5b3c63ee_cropped.jpg?f=community)
R7 5800X3D // Dark Rock rock 4 // MSI B450 Tomahawk Max // 32Gb Corsair Vengeance // BeQuiet Pure Base 500FX // MSI RTX3080 Suprim X
PC Specs
Asus ROG Strix B650E-E | AMD 9800X3D |TR Phantom Spirit 120 SE | G-Skill 32GB DDR5 6000C30 M-die | 4090 FE | 3840*1600p 160Hz | Corsair RM1000x Shift
Moderator General Chat
Dyslectic history cynic
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
M1 weet ik zo uit m'n hoofd niet, maar ik vermoed dat daar vooral de GPU veel ruimte in neemt.
A14 daarentegen is pakweg 88mm² groot (11,8 miljard transistors), met 16 MB system cache, en 8 + 4 MB L2$ voor de BIG.little cores respectievelijk. A13 had precies even veel cache, 8,5 miljard transistors op 98,5mm². Bizar veel voor zo'n kleine chip en qua verhouding zal het niet ver van AMD vandaan zitten
Hier is een die shot van Anandtech voor de A13:
Het is uiteraard een heel package, wat de vergelijking wat lastig maakt, maar de 3,3 miljard transistors die A14 meer heeft zijn volledig in logica gaan zitten (met name de NPU). Als het SRAM beneden verwachting zou schalen, hadden ze die 55% hogere dichtheid niet eens gehaald.
Moderator General Chat
Dyslectic history cynic
Yup.
Ik weet niet zo zeker of het direct vertaald. Dit is Zen 3 en het is uiteindelijk wel een x86-64 CPU.A14 daarentegen is pakweg 88mm² groot (11,8 miljard transistors), met 16 MB system cache, en 8 + 4 MB L2$ voor de BIG.little cores respectievelijk. A13 had precies even veel cache, 8,5 miljard transistors op 98,5mm². Bizar veel voor zo'n kleine chip en qua verhouding zal het niet ver van AMD vandaan zitten
Hier is een die shot van Anandtech voor de A13:
[Afbeelding]
Het is uiteraard een heel package, wat de vergelijking wat lastig maakt, maar de 3,3 miljard transistors die A14 meer heeft zijn volledig in logica gaan zitten (met name de NPU). Als het SRAM beneden verwachting zou schalen, hadden ze die 55% hogere dichtheid niet eens gehaald.
De complexiteit voor de Zen 3 L3 cache lijkt een flink stuk hoger te liggen dan wat je kan opmaken uit Apple hun ontwerpen. Dit is dan een 84mm2 chip met 32MB aan L3 cache. Ik zie eigenlijk niet hoe je dit met iets meer dan 20% kleiner wordende cache, echt enorme winsten gaat zien. Daarom wil ik Zen 4 zien om in te kunnen schatten wat ze echt hebben bereikt.
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
Dat is wel enkel een CCD, geen I/O en dergelijke. Als je dat bij Apple weg rekent zul je op ongeveer de helft uit komen...wat betekent dat ze grofweg even veel cache hebben
Of het complexer is weet ik niet, Apple's die shots zijn verrassend lastig uit te pluizen.
Het is en blijft inderdaad lastig -vooral met verschillende chips-, maar het gaat om de verhoudingen. Die 1,84 voor logica is wat maximaal haalbaar is, echter is logica sowieso al geen doorlopend vlak aan transistors. Dat zijn allemaal kleine clustertjes aan transistors, waar ruimte tussen moet zitten en die ruimte schaalt niet altijd lekker mee. SRAM daarentegen is juist wel een relatief constant doorlopend vlak aan transistors.Ik zie eigenlijk niet hoe je dit met iets meer dan 20% kleiner wordende cache, echt enorme winsten gaat zien. Daarom wil ik Zen 4 zien om in te kunnen schatten wat ze echt hebben bereikt.
Als je dus een chip hebt waar je qua oppervlakte bijvoorbeeld 30% SRAM hebt en 50% logica (met 20% voor andere zooi) is de kans best groot dat je even veel (of zelfs meer) transistors in het SRAM hebt zitten als in de logica. Ik vermoed dat Navi 21 bijvoorbeeld meer transistors kwijt is aan SRAM dan aan logica, ook al neemt dat laatste technisch gezien meer oppervlakte in. Die oppervlakte omvat echter ook flink wat loze ruimte en heel erg fluctuerende dichtheden. En vergeet ook niet dat zelfs binnen die logica, ook SRAM zit.
Was daar straks ook aan't denken,: "zal wel op de 7950XT komen, of Navi4":
Dit zou op de komende generatie kunnen zitten
Samsung Launches Industry's First 24Gbps GDDR6 Memory
Al wat ik aanraak werk niet meer zoals het hoort. Damic houd niet van zijn verjaardag
PC Specs
Asus ROG Strix B650E-E | AMD 9800X3D |TR Phantom Spirit 120 SE | G-Skill 32GB DDR5 6000C30 M-die | 4090 FE | 3840*1600p 160Hz | Corsair RM1000x Shift
When a man finds a conclusion agreeable, he accepts it without argument, but when he finds it disagreeable, he will bring against it all the forces of logic and reason
Moderator General Chat
Dyslectic history cynic
M1 is circa 120mm2 met een big/little CPU opzet, GPU, I/O, "neural engine" en die cache.:
[...]
Dat is wel enkel een CCD, geen I/O en dergelijke. Als je dat bij Apple weg rekent zul je op ongeveer de helft uit komen...wat betekent dat ze grofweg even veel cache hebben
Of het complexer is weet ik niet, Apple's die shots zijn verrassend lastig uit te pluizen.
Het is denk ik wel duidelijk dat op de M1, de L3 cache veel kleiner is dan op Zen 3. Ik vermoed dat het verschil veel te groot is voor een directe vergelijking. Komt bij dat Apple waarschijnlijk een eigen invulling van de high density library gebruikt en AMD eentje van de high performance library. Immers jaagt AMD vrij comfortabel 3x of meer door hun chip dan Apple met de M1.
Ook kwam ik dit tegen:
https://www.eetasia.com/t...-distinct-circuit-blocks/
Ja 180 graden omgedraaid maar iets duidelijker wat nu wat is:
-Linksboven is de GPU
-Links is de CPU met de big cores en cache ertussen
-In het midden zitten de little cores, meer cache en de neural processor
-De rest is voornamelijk specifieke Apple logic om taken niet te draaien op de CPU maar op gespecialiseerde hardware
Bij AMD vermoed ik ook dat de bedrading voor de L3 cache, behoorlijk wat extra verbindingen heeft om latency zo uniform te houden tussen de cores. Ook zal AMD beduidend meer read/write cycles doorvoeren omdat ze nu eenmaal hogere clock speeds hebben. Dat is vervolgens meer hitte waardoor je al snel iets meer dichtheid moet opofferen voor je gewenste clock speeds.
Onder de streep is de vergelijking denk ik echt te lastig om iets te zeggen, al helemaal voor RDNA3. Want L3 cache van RDNA2 kwam van Zen 2/3, maar L0/L1/L2 denk ik niet. Immers compleet andere inzet.
Het kan heel goed dat RDNA2 een hogere SRAM dichtheid heeft. Maar ik zou dat van de andere kant benaderen. Want wat ze met RDNA2 hebben gedaan qua clock speeds is behoorlijk ondergewaardeerd. Het moet namelijk enorm veel optimalisatie zijn geweest in logic om dit te doen. In dat interview dat ik linkte gingen ze hier ook op in hoeveel moeite dat eigenlijk koste. Want RDNA2 lijkt vanaf de grond opgebouwd te zijn met de vraag of een gate wel moet switchen en zo nee, dan moet die ook uit blijven. Zo hou je het powerbudget in toom en kan je die clock speeds halen zonder dat je oververhitting krijgt. Dat monitoren ze ook met sensoren op de chip.
En dan zou RDNA3 ook nog eens door de 3GHz barrière gaan. Ik ga niet eens pretenderen het helemaal te begrijpen, maar ik denk dat ik wel afdoende begrijp om in te zien dat dit helemaal niet zo makkelijk is als "we verhogen de clock speeds even". En die houding komt mij de laatste tijd ook te vaak voorbij aan de Nvidia kant dat ze wel even 1000MHz erbij gaan clocken omdat ze naar TSMC N5 gaan en/of omdat AMD ook hoger clockt.
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
Oh, ik had het over de A14. M1 is een hele rare chip. Het werkt duidelijk wel
AMD heeft bij hun floorplan inderdaad na gedacht over de datapaden. De L1 zit namelijk tussen de DCU's en ... het command centre? in
En dan tussen command centre en IF zit de L2. Vanuit een shader engine lijkt er dus een heel strak pad naar L1, L2 en L3 te zijn, daar zitten geen obstructies in.
Het ging mij vooral om het aantal transistors dat er in verhouding tot logica in gaat zitten. Bij beide is de verhouding cache tot logica grofweg gelijk (I/O even helemaal negerend) en bij beide vermoed ik dat er meer transistors in SRAM dan in logica zitten. Weten doen we het uiteraard nooit, tenzij we bij die bedrijven of TSMC gaan werkenOnder de streep is de vergelijking denk ik echt te lastig om iets te zeggen, al helemaal voor RDNA3. Want L3 cache van RDNA2 kwam van Zen 2/3, maar L0/L1/L2 denk ik niet. Immers compleet andere inzet.
Dat gaf ik eerder ook al aan ja. RDNA (zowel 1 als 2) zijn 100% gebouwd op zo veel mogelijk cycles te draaien en per cycle zo veel mogelijk werk te verzetten met zo min mogelijk data te verplaatsen. Het is namelijk dat laatste dat veel sap nodig heeft.
Dat zeg ik al jaren. Ik wacht nog steeds op die magische super simpele stap waar Nvidia eventjes naar N7 over gaat stappen met Ampère en zomaar 25% meer performance krijgt met minder verbruik
Moderator General Chat
Dyslectic history cynic
Dit zou het zijn.:
[...]
Oh, ik had het over de A14. M1 is een hele rare chip. Het werkt duidelijk wel
[...]
AMD heeft bij hun floorplan inderdaad na gedacht over de datapaden. De L1 zit namelijk tussen de DCU's en ... het command centre? in
En dan tussen command centre en IF zit de L2. Vanuit een shader engine lijkt er dus een heel strak pad naar L1, L2 en L3 te zijn, daar zitten geen obstructies in.
Ga nou maar lezen.[...]
Het ging mij vooral om het aantal transistors dat er in verhouding tot logica in gaat zitten. Bij beide is de verhouding cache tot logica grofweg gelijk (I/O even helemaal negerend) en bij beide vermoed ik dat er meer transistors in SRAM dan in logica zitten. Weten doen we het uiteraard nooit, tenzij we bij die bedrijven of TSMC gaan werken
[...]
Dat gaf ik eerder ook al aan ja. RDNA (zowel 1 als 2) zijn 100% gebouwd op zo veel mogelijk cycles te draaien en per cycle zo veel mogelijk werk te verzetten met zo min mogelijk data te verplaatsen. Het is namelijk dat laatste dat veel sap nodig heeft.
Want ze haalde het er echt pas met RDNA2 eruit. RDNA1 blijft denk ik vooral een proof of concept. Echt veel meer clock speed dan Vega 20 haalde ze er namelijk niet eruit. En ik zou niet durven te pretenderen dat Vega nu een bijzonder efficiëntie of goed clockende architectuur was.
Het is denk ik ook geen toeval dat ze in een jaar al met RDNA2 kwamen waarbij ze de efficiëntie behoorlijk hadden verbeterd, L3 cache introduceerde en er RT erin hadden weten te proppen.
https://venturebeat.com/2...ergy-efficient-computing/
En voor de korte samenvatting.
DaniëlWW2 in "CJ's AMD Radeon Info & Nieuwsdiscussietopic - Deel 144"
En als je dan klaar bent, dan mag je ook naar Arc gaan kijken met Tom Petersen.
DaniëlWW2 in "Intel Nieuwsdiscussietopic - Deel 2"
Het kan op zich, maar dan moet Nvidia echt heel wat veranderen denk ik zo. Zowel onder de kap qua logic als qua architectuur. En die indicaties zien we gewoon niet. Ze kunnen best door de 2GHz barrière gaan, maar dat hele "oh het is 2,8GHz want node of Nvidia is beter" is mij echt te makkelijk.[...]
Dat zeg ik al jaren. Ik wacht nog steeds op die magische super simpele stap waar Nvidia eventjes naar N7 over gaat stappen met Ampère en zomaar 25% meer performance krijgt met minder verbruik
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
Weet ik, daarom zei ik het ook. Ik wist alleen niet hoe ik het centrum (waar de command processor, ACE's etc. zitten)...dat noem ik vanaf nu command centre:
Dit zou het zijn.
Dat valt wel mee hoor, Navi 10 XT hield zonder problemen de 1900 vast. En de XTX bins zaten tegen de 2 GHz aan. Dat is best behoorlijk voor zo'n kleine chip, want kleinere chips klokken niet per se beter. Wat AMD met N22/N23 doet is best apart, kijk maar eens naar oudere chips op andere procedé's. Kleinere chips (of meer gecastreerde chips) klokken niet per se beter, omdat ze niet meer in balans zijn en de spanning fluctueert, waardoor ze hogere kloksnelheden niet vast kunnen houden.Ga nou maar lezen.
Want ze haalde het er echt pas met RDNA2 eruit. RDNA1 blijft denk ik vooral een proof of concept. Echt veel meer clock speed dan Vega 20 haalde ze er namelijk niet eruit. En ik zou niet durven te pretenderen dat Vega nu een bijzonder efficiëntie of goed clockende architectuur was.
Dan nog is 1900-2000 voor Navi 10 behoorlijk netjes. Verder wel met je eens dat het min of meer een PoC was, maar dat is ook niet zo heel gek. Dat is bijna het oude AMD dat doet wat het moet doen - nieuwe node, nieuwe architectuur, dus niet meteen voor 600mm² gaan
RDNA1 draaide om het testen van de pipelines en "voelen" hoe N7 ging. Indeling en werken van DCU's, de gedeelde L1 tussen DCU clusters, de verschillende schedulers. Dat is het "zo veel mogelijk werk per cycle met zo min mogelijk data" gedeelte van de vergelijking
Zal iets voor het weekend worden vrees ik. Neem aan dat ze geen echt leesvoer beschikbaar hebben gesteld en we het enkel met Petersen moeten doen? De beste man is helaas daadwerkelijk goed met de technische kant...maar hij is even goed met de marketing bullshit. Daarom was hij zo lang het gezicht van NvidiaEn als je dan klaar bent, dan mag je ook naar Arc gaan kijken met Tom Petersen.
DaniëlWW2 in "Intel Nieuwsdiscussietopic - Deel 2"
Moderator General Chat
Dyslectic history cynic
Gewoon scheduler because buck het.:
[...]
Weet ik, daarom zei ik het ook. Ik wist alleen niet hoe ik het centrum (waar de command processor, ACE's etc. zitten)...dat noem ik vanaf nu command centre
Eigenlijk is het Graphics Command Prosessor waaronder dan de Geometry Processor en de ACE's vallen, maar dat ga ik niet elke keer uittypen.
Ik heb nog RX5700XT dus clock speeds weet ik erg goed.Dat valt wel mee hoor, Navi 10 XT hield zonder problemen de 1900 vast. En de XTX bins zaten tegen de 2 GHz aan. Dat is best behoorlijk voor zo'n kleine chip, want kleinere chips klokken niet per se beter. Wat AMD met N22/N23 doet is best apart, kijk maar eens naar oudere chips op andere procedé's. Kleinere chips (of meer gecastreerde chips) klokken niet per se beter, omdat ze niet meer in balans zijn en de spanning fluctueert, waardoor ze hogere kloksnelheden niet vast kunnen houden.
Dan nog is 1900-2000 voor Navi 10 behoorlijk netjes. Verder wel met je eens dat het min of meer een PoC was, maar dat is ook niet zo heel gek. Dat is bijna het oude AMD dat doet wat het moet doen - nieuwe node, nieuwe architectuur, dus niet meteen voor 600mm² gaan
RDNA1 draaide om het testen van de pipelines en "voelen" hoe N7 ging. Indeling en werken van DCU's, de gedeelde L1 tussen DCU clusters, de verschillende schedulers. Dat is het "zo veel mogelijk werk per cycle met zo min mogelijk data" gedeelte van de vergelijking
Maar Vega 20 ging ook al over de 1800MHz zo 1800-1900MHz deed Nvidia ook al met Pascal. Dat Navi 22/23 zo over de 2500MHz gaan, dat is veel indrukwekkender. Overigens vind ik 22 echt een complete flop van een chip die vrijwel geen meerwaarde heeft over 23, maar dat is een andere discussie.
Ryan Shrout zat er ook bij. Dat lijkt me afdoende antwoord.[...]
Zal iets voor het weekend worden vrees ik. Neem aan dat ze geen echt leesvoer beschikbaar hebben gesteld en we het enkel met Petersen moeten doen? De beste man is helaas daadwerkelijk goed met de technische kant...maar hij is even goed met de marketing bullshit. Daarom was hij zo lang het gezicht van Nvidia
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
Nee, de GCP en de ACE's hebben aparte functies, althans in RDNA! Net als jij had ik ook in m'n hoofd dat het van GCP -> ACE ging, maar blijkbaar niet (meer) in RDNA, ik moet er eigenlijk eens keer een GCN whitepaper bij pakken om te kijken of dat altijd al zo was. Eerstgenoemde handelt pixel + vertex shaders af en fixed-function hardware (dus o.a. geometry, RT), de ACE's handelen compute shaders af.:
Gewoon scheduler because buck het.
Eigenlijk is het Graphics Command Prosessor waaronder dan de Geometry Processor en de ACE's vallen, maar dat ga ik niet elke keer uittypen.
Goed, dan zal het in elk geval wel vermakelijk zijn, maar details zullen nog steeds summier zijn vermoed ik?Ryan Shrout zat er ook bij. Dat lijkt me afdoende antwoord.
Moderator General Chat
Dyslectic history cynic
Ik weet dat de ACE's en Geometry Prosessor respectievelijk INT en FP doen en eigen workloads creëren. Maar volgens mij is de Graphics Command Processor de eerste stap in de keten. Daar komen de render opdrachten immers binnen. Vervolgens gaat FP naar de Geometry Processor en INT naar een van de ACE units. Hoe het daarna precies gaat is mij ook niet helemaal duidelijk. Het lijkt erop dat de Geometry Processor en ACE units zelf wave32 verzenden naar de DCU's.
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/CghYNCgc6mrWlkW5oCvRo6ab.jpg?f=user_large)
Nee, hij zat alleen achterin en ze lieten hem twee seconden zien. Dan weet je al genoeg.[...]
Goed, dan zal het in elk geval wel vermakelijk zijn, maar details zullen nog steeds summier zijn vermoed ik?
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
Nee, lees de laatste paragraaf maar. Gaat niet om FP vs INT, het gaat om het type workload, die in beide gevallen uit meerdere datatypen kunnen bestaan. Dat zeg je zelf hier eigenlijk ook; het render werk komt bij de GCP binnen, compute komt bij de ACE's binnen.
Hoe ze tussen die twee coördineren zodat ze elkaar niet in de weg zitten, of waarom er meerdere ACE's zijn (en ze zo klein zijn!) is een andere reden waarom ik GCN whitepapers er weer eens bij moet pakken
BoeNee, hij zat alleen achterin en ze lieten hem twee seconden zien. Dan weet je al genoeg.
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.
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.
Richt je feedback tot Techspot, ik heb alleen naar de plaatjes gekeken:
Het kan best dat dat in de whitepapers niet helemaal precies dezelfde L1 cache is. We benadrukken wederom verschillende zaken.
Ja en zelfs als je perfect vanuit de aansturing vergelijkt, kan je nog steeds niks zeggen over de performance zonder dat je de workload weet. Ik vind het gewoon makkelijker om te kijken naar de uitvoer capaciteiten, in de aanname dat GPU's altijd zullen proberen de aansturing en bezetting zo goed mogelijk te doen. En inderdaad tijdens een GPU leven zie je de drivers dit aspect verbeteren. Maar wat niet verandert? De uitvoer capaciteit.
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?
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.
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.
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. 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.:
Wellicht belangrijker is echter dat als je achter elkaar 128xFP32, 64+64 en weer 128xFP32 (allemaal netjes verdeeld over 4 verschillende warps/waves voor perfecte bezetting) zou hebben dat dat voor Nvidia in theorie een ideale bezetting is. Echter zitten er dan tijd tussen de ops omdat de SM moet schakelen tussen FP32 en INT32 mode; dat is niet "gratis" voor ze. AMD daarentegen heeft daar schijt aan en gooit ze gewoon in 3 cycles door de hele DCU heen. Zij doen de ene cycle gewoon FP32 en de cycle erna INT32, dat maakt niets uit (data cycles even negerend
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.
Leerzaam, en ik ben het met je eens. Toch grappig dat ondanks de minder flexibele oplossing, Ampere met dat wat meer "fixed function ALU's" goed mee kan komen qua performance.
Niet efficiënte performance is nog steeds performance. Het klopt wel dat RDNA beter schaalt, maar zo is die architectuur dan ook ontworpen.:
Ah, maar ook dat is vrij logisch, wederom aan de hand van de memory layout
In Nvidia's geval heb je per SM een L1 die aan de L2 hangt, die op zijn beurt gedeeld wordt door de hele chip. Met GA104 heb je dus véél minder druk op de L2, simpelweg omdat er minder SM's zijn. En dat is één van de meest sap-vretende dingen in een CPU of GPU: data verplaatsen. Ik weet uit m'n hoofd niet hoe veel cache lines er overal lopen, maar het zal waarschijnlijk genoeg voor een hele warp zijn, dus minstens 128 bytes per L1.
In AMD's geval gaat dat anders. Daar hangen slechts 10 DCU's aan een stukje L1 (ook weer genoeg voor een hele wave in één keer), minder dan een kwart van het aantal SM's aan de L2. En de L1 hangt op zijn beurt weer aan de L2, wat betekent dat er slechts 4 L1 caches aan de L2 hangen.
Waar het grote verschil zit is in hoe váák die L2 caches aangesproken moeten worden. Een partitie in een SM vraagt data op uit de L1 en als dat daar nog niet aanwezig is moet het meteen naar de L2. Een partitie in een andere SM moet precies hetzelfde doen als die dezelfde data nodig heeft. Je zou dus zomaar 84 SM's kunnen hebben die exact dezelfde data uit de L2 opvragen. Voor GA104 zakt dat meteen naar 48, wat duidelijk scheelt.
AMD daarentegen deelt sowieso al binnen een CU, vervolgens binnen een DCU, dan weer binnen een array en pas dan moet de L2 er aan te pas komen. In het ergste geval krijgt de L2 dus van 4 kanten een verzoek om dezelfde data in Navi 21. Of van 2 kanten in Navi 22.
Dus hoewel een SM niet per definitie minder efficiënt is dan een DCU, is de manier waarop alles samen hangt dat wel. Bij AMD blijft de data veel vaker "dichtbij" voor de units die er iets mee moeten. Of om het wellicht iets meer naar de fysieke chips te trekken, bij Nvidia moet er veel vaker "stroom" helemaal van L2 naar een register voor een ALU dan bij AMD. Daarom zie je bij Nvidia ook zo'n extreme schommelingen in het verbruik, terwijl het bij AMD relatief voorspelbaar is. Het schaalt ook allemaal vrij voorspelbaar, terwijl GA104 duidelijk veel efficiënter is dan GA102.
Goed om te horen dat het kàn en ik vermoed dat de Nvidia ingenieurs in de richting denken wat je hier beschrijft.
Tot nu toe hebben de afgelopen Nvidia generaties telkens een wijziging in de SM structuur laten zien. Vaak tot verrassing van de leakers. Juist door het toevoegen van de grote hoeveelheid L2/L3 cache, is wijziging in de cache structuur van SM's ook waarschijnlijker geworden. Ik zou in ieder geval niet aannemen dat Lovelace precies dezelfde SM structuur heeft als Ampere, maar dat is helaas wel wat veel leakers aannemen... om bijvoorbeeld ALU's te berekenen.
Het is beter om het bij SM's / CU's te houden in plaats van uitspraken te doen over RDNA3 of Lovelace ALU's.
Ik hoor 's wereld kleinste viooltje, maar Ampere is niet zielig. Ook niet schaalbaar qua efficiënt SM's aan het werk houden, maar ik zou Nvidia ingenieurs niet onderschatten voor Lovelace.
Die getallen zijn inclusief L0 en L1 cache ja, wat het aantal transistors per ALU of cache vertroebelt.
Ampere: 1,52 Mtr per ALU (inclusief L0 en L1)
RDNA2: 2,16 Mtr per ALU (inclusief L0 en L1)
Nog steeds is het aannemelijk dat de SIMD32 meer transistors nodig hebben om zowel FP32 en INT32 te kunnen doen, in vergelijking met de losse FP32 INT32 logic units van Nvidia. Omdat Nvidia 2x zoveel ALU's in hun SM gepropt heeft vergeleken met een CU, komt het gemiddelde budget van transistors per ALU natuurlijk lager uit.
Ik denk meer ruimte bij Nvidia, omdat de node jump hoger is, en omdat ze per ALU minder transistors nodig hadden. Maar waarschijnlijk gaan ze met Lovelace cache toevoegen, waardoor de transistors per ALU (inclusief L0, L1) verder omhoog gaan. Uiteindelijk kunnen we er niks uit afleiden of voorspellen, helaas.:
Waarom heeft Nvidia ruimte over en AMD niet, ik volg dat totaal niet? AMD kan op dit moment juist makkelijk twee shader engines toevoegen en dus 50% meer ALU's in dezelfde ruimte als Nvidia persen als ze de IC houden zoals hij is op 128 MB. En zelfs als ze die verhogen naar 160 MB (+32; Navi 22 XT heeft -32 voor 50% van de shader engines
Dat is echter ook wat het lastig maakt in te schatten waar de transistors nu zitten, laat staan waar het naartoe gaat met N5. Zoals ik hierboven zei is SRAM over het algemeen heel compact, waardoor Navi 21's transistor dichtheid dus hoger lijkt dan het is, want IC neemt ook aardig wat ruimte in op de hele chip. Als Nvidia dus een berg L2 toe zou voegen, hebben we ook geen enkel idee waar hun chips naar toe gaan qua afmetingen.
Ik zei 4nm:
Ook dat is weer zoiets dat zo vaak geroepen wordt, maar helemaal zo makkelijk niet is
Ten eerste is dat volgens de gerichten "4N", wat dan een naam is voor "N5 for Nvidia". Dat zal geen hogere dichtheid of iets dergelijks omvatten, maar tweaks voor Nvidia's ontwerpen qua doel dichtheden. Net zoals "12FFN" dat was. TSMC's "N4" is een daadwerkelijke verbetering, maar dat is dus N4, niet 4N
Daarnaast is kloksnelheid extreem afhankelijk van chip ontwerp. We kunnen helemaal niets zeggen over wat Nvidia wel of niet kan gaan halen op N5/4N (of wat ze nu op N7 zouden kunnen halen tegenover Samsung's 8N), want AMD heeft RDNA heel specifiek ontworpen om hoge kloksnelheden te halen.
wat het al jaren niet meer is. De EUV golflengte die er in gaat is nog steeds ~28 nm.Ik denk dat AMD RDNA ontworpen heeft om een goede bezetting te houden bij meer CU's, oftewel schaalbaar qua occupancy en performance per watt.
Klokfrequentie is afhankelijk van hoe lang de (kritieke) datapaden zijn, bijvoorbeeld hoeveel CU's je in een SE stouwt.
https://venturebeat.com/2...ergy-efficient-computing/
kleine muisjes hebben grote wensjes: Beschuit Met Gestampte Mensjes
Waardoor maak je je zo'n zorgen om L3 cache? Als ik de Navi21 chip L3 cache oppervlakte zo zie, dan is dat 42,4 mm2 voor 64 MB. Van 7nm naar 6nm wordt dat 35,7 mm2, niet echt veel.:
Ik kijk misschien te snel, maar ik heb nu ook niet iets van dat A14 of M1 nu zo indrukwekkend lijken qua cache formaat of percentage van de chips die uit cache bestaan. Als je een bak met cache met een klein beetje logic wil, dan moet je bij Zen 2/3 zijn. Ik denk dat Zen 4 een beter ijkpunt zal zijn.
Voor RDNA3 zie ik eigenlijk ook niet in hoe ze afdoende L3 cache gaan implementeren voor het verwachte toename aan formaat en de nu wel bevestigde 384bit bus. Ik denk dat het echt afgesplitst zal zijn omdat het anders waarschijnlijk niet gaat passen en de logica van zes MCM chiplets compleet verloren gaat. Het werkt ook in RDNA om L3 cache af te splitsen omdat het tussen VRAM en de pipelines zit. Het is geen onderdeel van een pipeline of zoals de centrale L2 cache van Nvidia, waarbij de latency penalty onacceptabel zou zijn.
L0, L1 en L2 zullen wel op de GCD chiplet zitten. Kan niet anders tenzij AMD wel heel, veel veel rare dingen gaat doen met RDNA3. Daar gaan we denk ik de meer geringe voordelen van N5 SRAM wel zien, maar het zal denk ik een relatief klein deel van de hele chip zijn.
384 MB is dan 214,3 mm2 verdeeld over 6 chips. Ik twijfel aan aparte MCD chiplets van maar 35,7 mm2, dat lijkt me een enorm gepriegel, is dat wel praktisch voor de machines? Waar zou je de 32-bit PHY elementen zetten, op de MCD (van 6nm), of een centrale memory I/O die (zoals by Milan Epyc, van 12 nm)?
kleine muisjes hebben grote wensjes: Beschuit Met Gestampte Mensjes
Moderator General Chat
Dyslectic history cynic
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
Moderator General Chat
Dyslectic history cynic
En dat is dus selectief quoten.
Voor RDNA3 zie ik eigenlijk ook niet in hoe ze afdoende L3 cache gaan implementeren voor het verwachte toename aan formaat en de nu wel bevestigde 384bit bus. Ik denk dat het echt afgesplitst zal zijn omdat het anders waarschijnlijk niet gaat passen en de logica van zes MCM chiplets compleet verloren gaat. Het werkt ook in RDNA om L3 cache af te splitsen omdat het tussen VRAM en de pipelines zit. Het is geen onderdeel van een pipeline of zoals de centrale L2 cache van Nvidia, waarbij de latency penalty onacceptabel zou zijn.
L0, L1 en L2 zullen wel op de GCD chiplet zitten. Kan niet anders tenzij AMD wel heel, veel veel rare dingen gaat doen met RDNA3. Daar gaan we denk ik de meer geringe voordelen van N5 SRAM wel zien, maar het zal denk ik een relatief klein deel van de hele chip zijn.
N6 is dan ook niks meer dan EUV machines gebruiken voor dezelfde PDK als N7. TSMC claimt weliswaar een 18% verbetering in logic density, maar ik vermoed dat het weinig gebruikt zal worden. N6 lijkt interessanter te zijn omdat de EUV machines waarschijnlijk ingezet worden om een paar lagen aan metaal die met N7 met quad pattering DUV worden gedaan, nu in een keer met een EUV machine te doen. Zo haal je het beste uit beide werelden want EUV zou juist de complexe delen van een chip, beter moeten doen dan DUV. Dit terwijl DUV uiteraard sneller is en beter toepasbaar voor de minder complexe lagen metaal van een chip. Het is een productieoptimalisatie die de prijs van de chips alsmede de productietijd iets zal drukken. Want als dat niet gebeurd, dan zou AMD bijvoorbeeld niet voor Rembrandt naar N6 zijn gegaan of dat nu niet ook van plan zijn voor RDNA MCM chiplets.
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
Moderator General Chat
Dyslectic history cynic
Omdat RDNA een fundamenteel andere architectuur is die zo ongeveer letterlijk als enige overbruggende feature met Nvidia, het gebruik van SIMD32 deelt. Voor de rest is het compleet anders.
Tweede is omdat L2 cache een zeer belangrijke rol speelt in RDNA Shader Engines hun mogelijkheid om data terug te halen naar de rekeneenheden. In L2 zit in principe data waarvan de GPU weet dat die over een paar clock cycles nodig gaat zijn voor een nieuwe berekening. Als je dat in L3 laat zitten of VRAM, dan ben je te laat en krijg je een stall met een videokaart met zulke hoge clock speeds. Nog een reden waarom zomaar de clock speed verhogen geen magisch middel is. Je moet je rekeneenheden ook kunnen voorzien van data en dat wordt alleen maar moeilijker.
Het hele punt van L2<-L3<-VRAM in RDNA2 is om relevante data waarvan de GPU weet dat die misschien nodig zijn, dichtbij de rekeneenheden te houden. Omdat AMD nog steeds geen RDNA2 whitepaper heeft vrijgegeven is dit wat speculatie. Maar mijn vermoeden is dat de GPU data die potentieel relevant kan zijn, in L3 cache opslaat, data die relevant gaat zijn in L2 cache opslaat en als het direct nodig is, dan gaat het naar L1 zodat het klaarstaat voor gebruik. L1 is immers Shader Array level cache binnen RDNA.
In RDNA2 is de verbinding tussen L1 en L2 al tweemaal zo breed als tussen L2 en L3. Latency staat daar nog eens los van en voor zover ik weet is dat niet publiekelijk. En ik vermoed met reden want dit is een van de zaken die RDNA2 zo efficiënt heeft gemaakt. Ik heb het al vaker gezegd en @Werelds ook. RDNA is vanaf de grond af ontworpen voor ocupency, occupency en nog eens ocupency. Daarnaast komen de clock speeds om er heel veel perf/watt eruit te halen. Die twee samen vormen een synergie. En die clock speeds haal je alleen maar op een zinvolle wijze als je alles aan die GPU optimaliseert ervoor. Dat is RDNA2.
Navi 21 heeft al 128MB. Ga gerust uit van minstens het dubbele voor Navi 31. Ja dus.
En het is nog steeds sneller om iets alvast uit VRAM te halen en op een aparte chiplet op te slaan met L3 cache dan te moeten wachten totdat het eindelijk uit VRAM komt en dan direct naar L2 te halen. Zeker als die data vervolgens toch niet nodig blijkt te zijn. L2 cache is door haar natuur als zeer snel en dichtbij de rekeneenheden voor latency gevoeligheid, maar dat impliceert ook dat het relatief klein blijft omdat een grote L2 cache ook grotere complexiteit qua opslag en verplaatsing van data met zich meebrengt. En latency is letterlijk de tijdsduur om data van punt een naar twee te brengen. Een grotere cache heeft gewoon langere bedrading en doet er langer over.
Dit is ook onder iedereens radar gevlogen.
AMD kwam even vertellen waarom hun drivers beter zijn.
Verder hebben ze dus ook een kleine verbetering aan RSR doorgevoerd en natuurlijk hebben ze flink wat werk verzet voor hun DX11 drivers.
https://community.amd.com...e/ba-p/530424?sf258519940
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
Als je te laat bent als je L2 naar aparte chiplets beweegt, dan zou dat ook al vrij snel gelden voor L3.
128MB is 85 mm2. 384MB is 255 mm2. Maar verdeeld over 6 chiplets? Is het maar 42,5 mm2. Zonder schaling door de node. Doe je de L3 gewoon op N5? Dan is het nog maar 28 mm2 er bij...
Zeker, props voor AMD drivers, "age like fine wine".:
Dit is ook onder iedereens radar gevlogen.
AMD kwam even vertellen waarom hun drivers beter zijn.
[Afbeelding]
Verder hebben ze dus ook een kleine verbetering aan RSR doorgevoerd en natuurlijk hebben ze flink wat werk verzet voor hun DX11 drivers.
https://community.amd.com...e/ba-p/530424?sf258519940
kleine muisjes hebben grote wensjes: Beschuit Met Gestampte Mensjes
Moderator General Chat
Dyslectic history cynic
Never argue with an idiot. He will drag you down to his own level and beat you with experience.
Ik denk dat de L3 ook bij de GPU chiplet blijft net als de L2. L2 is al een tussenpunt, de snelheden tussen L1 L2 en L3 moeten goed blijven. De snelheden tussen L3's onderling kunnen (als gecombineerde L3 voor de moeder chiplet) misschien wat lager, maar het zal lastig worden om latency te verbergen voor Navi31/Navi32.
Die ook heel goed op een centrale I/O memory controller die kunnen:
(Milan Epyc)
samen met andere elementen die niet goed schalen op N5:
- Digital Logic for PCIe & display control
- Video Core Next 4.0
- xGMI infinity link
- infinity fabric + connects to infinity fabric of GPU chiplets
- naast de genoemde 32-bit GDDR6 PHY memory controllers, volgens mij aan de buitenkant van de I/O die.
kleine muisjes hebben grote wensjes: Beschuit Met Gestampte Mensjes