Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: Hardware- und Nachrichten-Links des 10. November 2021
Leonidas
2021-11-11, 07:25:33
Link zur News:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-10-november-2021
"Die seitens AMD zugrundeliegende Rechnung geht dabei von einem Stromverbrauchs-Vorteil zwischen 7nm- und 5nm-Fertigung von –50% aus, womit angesichts des (früheren) Performance-Ziels von Navi 31 (2,5fach gegenüber Navi 21) und dem Basiswert des Verbrauchs von Navi 21 (300W) dann ein hochgerechneter Stromverbrauch von 375 Watt für Navi 31 herauskommt"
Naja, vielleicht hat man die 50% bei Navi 33 im Vergleich zu Navi 21. Bei Navi 31 würde ich nicht davon ausgehen, dass man nur 375W verbrauchen wird. Die Verbrauchsvergleiche laufen meist zwischen einer eher ineffizienten Karte der Vorgänger-Gen und der effizientesten Karte der neuen Gen. Bei Polaris zu RDNA1 war es glaube ich 590 gegen 5600.
Die 50% sind also eher der Maximalwert, den nicht alle Karten erreichen.
Gast Ritis
2021-11-11, 08:48:45
Die CUs werden nicht abgeschafft, das ist der falsche Ausdruck.
Die CUs wurden als Dual-CUs in WGP umbenannt. Dabei war der Schritt von GCN CU auf Dual CU von RDNA viel grösser, als dort statt 4x16 SIMD auf 2x32 SIMD umgebaut wurde. Die 4x16 wollten eine 64er Wavefront sehen, die 2x32 nehmen auch eine bzw. zwei 32er Wavefront, sind also viel flexibler.
RDNA3 wird nach alten Begrifflichkeiten Quad-CUs haben. Das Wort Workgroup soll doch nur betonen, dass es eine Gruppe von Prozessoren bzw. Compute Units sind, die den Shared Cache haben. Es geht um die Cache-Hierarchien damit die "Laien" es leichter verstehen.
Es bleibt dabei bei 32er Wavefronts, d.h. man hat innerhalb des WGP (vermutlich) 4x grösseren Local Data Share als GCN. Solange die 4 CUs als 32er SIMD mit teils gleichen Daten über die 4 Wavefronts arbeiten wird das massiv weniger Speicherzugriffe erlauben, das war doch letztlich auch der Trick bei sparsamen RDNA1.
Mit höherer Dichte in der Chipfertigung wäre später mal Hexa- oder Octa-CU möglich und ist der erwartete nächste Schritt. Möglich dass der shared Cache dann nicht im gleichem Mass mitwachsen muss.
Die Zusatzfrage beim WGP ist wie viele der Einheiten einer ursprünglichen CU Schritt für Schritt je RDNA-Gen ebenso geshared werden können. Es wird wohl auch der Instruction und Scalar Cache ab einer Gen geshared werden, auch wäre von Vorteil wenn alle Load/Store Einheiten und Texture Units unhabhängig von jeweiligen SIMD-Einheiten im WGP-Scheduler angesprochen werden können.
Darüber muss AMD aber nicht schwadronieren, weill es v.a. im HW-Scheduler und Treiber Auswirkungen hat, den LDS muss man aber für Performanceoptimierung im Engine-Code bzw. der Anwendung berücksichtigen. Der Rest sollte dann mehr oder weniger automatisch profitieren, sobald Wavefronts für den LDS Cache in der Grösse optimiert gruppiert wurden.
https://fuse.wikichip.org/news/3331/radeon-rx-5700-navi-and-the-rdna-architecture/2/
GerryB
2021-11-11, 10:00:30
Will denn AMD überhaupt mit RDNA3 schon die Performancekrone?
Anhand der Liefersituation, könnte man doppelt soviel Grakas vermutlich gar net so ohne Weiteres stemmen.(x)
Von Daher hoffe ich, das AMD wieder mehr auf Effizienz statt Fps schaut, und in aller Ruhe das Multichipdesign ausprobiert.
(evtl. sogar mal 3d-Cache mit RDNA3=sparsamer, oder auch beim RDNA2-Refresh?)
(x) nach m.E. wirds wohl erst so ca. 2025 mit 3nm so richtig wieder Chips im Überfluss geben, wenn die ganzen neuen FAB`s fertig sind
amdfanuwe
2021-11-11, 11:30:42
Will denn AMD überhaupt mit RDNA3 schon die Performancekrone?
Anhand der Liefersituation, könnte man doppelt soviel Grakas vermutlich gar net so ohne Weiteres stemmen.(x)
Deshalb baut man ja teure leistungsfähige Karten. Da werden nicht so viele gekauft, man hat den höchsten Gewinn pro Chip und kann sich auf die Fahne schreiben die besten zu sein.
----------
Zu Navi 31. Letztendlich wird die TDP dadurch bestimmt, was man noch sinnvoll wegkühlen kann ohne mit Ohrenstöpseln am Rechner sitzen zu müssen.
Navi 33 und 32 werden sicherlich nahe der Kotzgrenze betrieben.
Dürften dann 150-200W für Navi 33 und 275-300W für Navi 32 sein.
Da die letzten paar Prozent Leistung überproportional viel Energie verbrauchen, dürfte Navi 33 eher am sweet Spot getaktet werden. Senkt den Energieverbrauch dann auf ~400W.
Könnte die Effizienteste Karte werden.
Gast Ritis
2021-11-11, 11:45:33
(x) nach m.E. wirds wohl erst so ca. 2025 mit 3nm so richtig wieder Chips im Überfluss geben, wenn die ganzen neuen FAB`s fertig sind
Nicht die Fabs sind das Hauptproblem. Es soll wohl die Verfügbarkeit von Substrat sein.
Macht auch Sinn, weil das alle Fertiger gleichermassen betrifft und nicht nur einzelne Fabs, also ungeachtet des Herstellers und einzelner Prozesse. Alle Halbleiter sind relativ zu vor Covid Mangelware, nicht nur AMDs GPUs. Die Autohersteller müssen das gerade bitter verarbeiten, wo AMD und Co. nicht offensichtlich weniger Silicon als in den Jahren zuvor in den Markt abgeben, nur halt der Nachfrage nicht hinterherkommen. PKWs sind im Bedarf/Stückzahlen jetzt nicht plötzlich angestiegen aber wegen fehlender Halbleiter nicht in üblichen Mengen produzierbar.
amdfanuwe
2021-11-11, 14:04:45
PKWs sind im Bedarf/Stückzahlen jetzt nicht plötzlich angestiegen aber wegen fehlender Halbleiter nicht in üblichen Mengen produzierbar.
Nur hatten die Hersteller mit fallender Nachfrage wegen Corona gerechnet und hatten ihre Halbleiter-Bestellungen runtergeschraubt.
Lehdro
2021-11-11, 14:07:25
Hat der 12900F wirklich mehr Boost als der 12900 nonF? Das wäre ja neu...
Die Cache-Größen skalieren seltsam.
Booby
2021-11-11, 23:41:19
Die Cache-Größen skalieren seltsam.
Nicht wirklich:
Big Core 1,25MB Cache
Little Core 0,5MB Cache
Leonidas
2021-11-12, 04:03:59
Die CUs werden nicht abgeschafft, das ist der falsche Ausdruck.
Das habe einige Leute, die sich schon mit RDAN3 auskennen, komplett anders gesagt. Dort hieß es: Keinerlei CU mehr zu sehen, wird auch nicht mehr erwähnt.
Muß natürlich nicht stimmen, ich wollte nur auf diese konträre Aussage hinweisen.
Hat der 12900F wirklich mehr Boost als der 12900 nonF? Das wäre ja neu...
Wurde exakt so vermeldet. Ist wahrscheinlich ein Fehler, aber ich weiss derzeit nicht in welche Richtung.
Gast Ritis
2021-11-12, 10:43:20
Das habe einige Leute, die sich schon mit RDAN3 auskennen, komplett anders gesagt. Dort hieß es: Keinerlei CU mehr zu sehen, wird auch nicht mehr erwähnt.
Muß natürlich nicht stimmen, ich wollte nur auf diese konträre Aussage hinweisen.
Das sind dann vermutlich Leute die sich nicht wirklich RDNA als Evolution aus GCN heraus beschreiben und allenfalls RDNA3 mit GCN vergleichen ohne die beiden Zwischenschritte zu sehen.
Im Whitepaper zu RDNA ist das eindeutig dargelegt, wie aus den CUs von GCN Dual CUs von RDNA wurden. WGP wurde später synonym eingeführt. Es ist demnach keine Abschaffung sondern eine schrittweise Fortentwicklung - keine Ablösung im eigentlichen Wortsinn.
https://www.amd.com/system/files/documents/rdna-whitepaper.pdf
Wie ich schon geschrieben habe, Schritt für Schritt können einzelne Elemente der CUs im WGP wie schon der Local Data Share zunehmend zusammengefasst werden. AMD belbit da bedeckt.
Erst wenn keinerlei Elemente neben den Shader Coress der SIMD Einheiten noch nach CU-Organisation getrennt sind würde ich davon sprechen, dass das Erbe der GCN-CUs nicht mehr sichtbar ist. Ich würde dann aber auch annehmen, dass AMD das in den Whitepapern zum entsprechenden RDNAx deutlich macht. Nicht ausgeschlossen, dass RDNA3 das bereits schafft.
Der erste WGP war aber gleichzeitig auch ein Dual-CU. Der Übergang bleibt retrospektiv mindestens über 3 Generationen fliessend ohne klar abgegrenzt werden zu können.
Damit man besser versteht was eigentlich passiert bleibt die die Analogie zu Dual oder Quad-CU aber immer geeignet.
Ich finde es wichtig dass der allgemeine Leser nicht glaubt es wäre ein revolutionäre Verwerfen alter Konzepte, es ist vielmehr eine sehr langfristige Entwicklung. Einzelne Schritte können sich schon mal von Gen zu Gen aus vielerlei Gründen verschieben oder neu interpretiert werden (Prim-Shader oder HBCC von Vega).
Leonidas
2021-11-12, 11:05:14
Danke für die erhellenden Hinweise. Da waren sich einige andere wohl zu sehr sicher.
danarcho
2021-11-12, 11:06:45
Die CUs werden nicht abgeschafft, das ist der falsche Ausdruck.
Ja, das hat mich auch stutzig gemacht. Vor allem wurden sie nicht abgeschafft. Im CU-mode hat RDNA immernoch die doppelte LDS-Bandbreite (shared memory). Lediglich sehr große Workgroups sowie welche, die sehr viel shared memory brauchen, performen im WGP-mode besser. Ist aber Sache des Treibers.
Die CUs wurden als Dual-CUs in WGP umbenannt. Dabei war der Schritt von GCN CU auf Dual CU von RDNA viel grösser, als dort statt 4x16 SIMD auf 2x32 SIMD umgebaut wurde. Die 4x16 wollten eine 64er Wavefront sehen, die 2x32 nehmen auch eine bzw. zwei 32er Wavefront, sind also viel flexibler.
Kleine Korrektur: Eine Wavefront läuft auf je einer SIMD-Unit. Bei GCN also 4*(bis zu 10) wavefronts auf einer CU, bei RDNA sind es 2*(bis zu 20) wavefronts je CU bzw 4*(bis zu 20) je WGP.
Zum Verständnis: Eine Workgroup muss auf einer CU (im CU-mode) bzw auf einer WGP ausgeführt werden. Wenn also die Workgroup sehr groß ist oder sehr viel shared memory braucht, dann kann die situation entstehen, dass je CU nur eine Workgroup passt, aber auf eine WGP würden 3 passen.
Zu RDNA3 kann ich mich nicht äußern.
Gast Ritis
2021-11-13, 09:54:00
Kleine Korrektur: Eine Wavefront läuft auf je einer SIMD-Unit. Bei GCN also 4*(bis zu 10) wavefronts auf einer CU, bei RDNA sind es 2*(bis zu 20) wavefronts je CU bzw 4*(bis zu 20) je WGP.
Ja mei, wenn man Whitepaper zitiert müsste man schon wissen was drin steht:
For the GCN architecture, the shader compiler creates wavefronts that contain 64 work-items. When every work-item in a wavefront is executing the same instruction, this organization is highly efficient. Each GCN compute unit (CU) includes four SIMD units that consist of 16 ALUs; each SIMD executes a full wavefront instruction over four clock cycles. The main challenge then becomes maintaining enough active wavefronts to saturate the four SIMD units in a CU
Hast natürlich recht. :) Jede der 4 SIMD16 in GCN braucht eine Wave64 für 4 Takte. Die Effizienz ist nur bei Aulastung mit gleicher Instruktion gegeben und man wartet immer 4 Takte auf das Ergebnis. Bei RDNA kann der Shader halb so grosse Waves machen und das Ergebnis liegt nach einem Takt vor. Dafür mussten die Register aufgebohrt werden.
Nicht wirklich:
Big Core 1,25MB Cache
Little Core 0,5MB Cache
Korrekt. Und weiter?
Demnach müsste 8+4 26MB L3 und 8+8 28MB L3 haben. Eingetragen sind aber 25 bzw. 30.
Ich würde . taggen, weiss aber nicht wie das hier im Forum funktioniert. Mit @Leonidas jedenfalls nicht.
Demnach müsste 8+4 26MB L3 und 8+8 28MB L3 haben. Eingetragen sind aber 25 bzw. 30.
Anandtech Review lesen, da wird aufgeschlüsselt, dass der L3 wohl etwas anders als erwartet aufgebaut ist.
Und beim L2 passt es genau, 8x 1,25 + 2.
Anandtech Review lesen, da wird aufgeschlüsselt, dass der L3 wohl etwas anders als erwartet aufgebaut ist.
Und beim L2 passt es genau, 8x 1,25 + 2.
Beim L2 habe ich auch nichts gesagt.
Wirklich klar wird nicht, warum der L3 so ist, wie er ist. Selbst wenn er unabhängig von der Zahl der aktiven P- & E-Kerne ist und daher anders skalieren kann, ist das noch keine Erklärung für die krummen Zahlen.
Muss ich wohl so hinnehmen.
Nachtrag: Habe mir jetzt mal Bild von AL angeschaut. Sieht nach 10 Blöcken a 3MB aus. Auf 25/20 kommt man durch Deaktivierung von je 512/1024 pro Block. Der kleine AL mag komplett anders sein. Warum 10 und 3, bleibt mir Rätsel, aber egal.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.