PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: Hardware- und Nachrichten-Links des 8. Dezember 2020


Leonidas
2020-12-09, 09:21:25
Link zur News:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-8-dezember-2020

Denniss
2020-12-09, 11:19:56
Sony und M$ saugen wohl den GDDR6-Markt leer

Leonidas
2020-12-09, 12:57:56
An Punkt hab ich noch gar nicht gedacht, stimmt aber. Starker Bedarfsanstieg in kurzer Zeit, daneben sicherlich auch Schwierigkeiten, die Fertigung in diesen Zeiten schnell auszuweiten.

basix
2020-12-09, 14:16:53
Die 18.3x18.3mm könnten ganz gut passen, wenn man sich den N21 Die Shot anschaut. Der Chip ist in etwa gleich breit aber halt einiges kürzer. Ich tippe ausserdem auf 48 oder 64 MByte Infinity Cache mit Tendenz auf ersteres.

Gast
2020-12-09, 16:04:12
Der Chip ist in etwa gleich breit aber halt einiges kürzer. Ich tippe ausserdem auf 48 oder 64 MByte Infinity Cache mit Tendenz auf ersteres.

Sicher nicht, unter 64MB wird es sinnlos, wobei mich auch nicht gänzlich überraschen würde wenn der Infinity Cache bei 128MB bleiben würde.

Leonidas
2020-12-09, 16:13:18
Angesichts der Chipgröße wäre das nicht undenkbar.

basix
2020-12-09, 17:28:52
Sicher nicht, unter 64MB wird es sinnlos, wobei mich auch nicht gänzlich überraschen würde wenn der Infinity Cache bei 128MB bleiben würde.

Da bin ich auf deine Erklärung gespannt, wieso es sinnlos ist und wie 128MB neben allem anderen Zeugs in 334mm2 passen ;)

Gast
2020-12-09, 18:48:16
Navi 22 (Mobile)

NV22 TBD:
– 146 W TGP

Womit wollen die das Teil in einem Notebook kühlen? Mit Trockeneis?

Gast
2020-12-09, 20:22:24
Womit wollen die das Teil in einem Notebook kühlen? Mit Trockeneis?

Die top Notebook GPUs haben heute schon 180W

Iscaran
2020-12-09, 20:44:00
Da bin ich auf deine Erklärung gespannt, wieso es sinnlos ist und wie 128MB neben allem anderen Zeugs in 334mm2 passen ;)

Das würde sogar ziemlich gut passen mit 334 mm^2 und 40 CUs.

Ziemlich perfekt sogar :-). Allerdings wäre es schon seltsam, soviel Transistoren für so ein kleines Chipchen zu verbraten, das davon vermutlich gar nicht so stark profitieren kann.

Gast
2020-12-09, 22:27:53
Da bin ich auf deine Erklärung gespannt, wieso es sinnlos ist und wie 128MB neben allem anderen Zeugs in 334mm2 passen ;)


https://www.pcgameshardware.de/Radeon-RX-6800-XT-Grafikkarte-276951/Tests/Benchmark-Release-Review-vs-RTX-3080-1361423/galerie/3457096/

Wie man sieht ist 64MB die absolut unterste Grenze an welcher der Infinity Cache überhaupt noch sinnvoll ist, wobei man zumindest unter 4k damit stark leiden würde. Auch wenn die entstehenden Karten wohl kaum wirklich für 4k gedacht sind ist trotzdem fraglich ob man sich diese Schmach wirklich antun will.
Alles darunter kann man zu 100% ausschließen.

Wobei ich 96MB auch für die wahrscheinlichste Auflösung halte, da man mit 50% der Hardware 75% des Speicherinterfaces aufbietet, sollte ein maßvoller Verlust der Effizienz des Infinity Caches sich nicht wesentlich auf die Performance auswirken.

Warum ich sogar 128MB nicht ganz ausschließen würde? Energieeffizienz, mehr Cache heißt mehr Energieeffizienz, und wenn man gerade auf dem Notebook Markt wieder Fuß fassen will kann man jedes bisschen an Effizienz brauchen. Vor allem da es ein Markt ist in dem man die OEMs überzeugen muss man echte Vorteile gegenüber der Konkurrenz bieten.

Bisher ist RDNA2 "nur" ungefähr gleich Effizient bei gleichem Betriebspunkt, was natürlich wenn man sieht wo man mit RDNA1 gestanden ist immer noch eine riesen Leistung von AMD ist. Gleich gut ist aber eben nicht besser.

Und was die 128MB noch wahrscheinlicher macht sind eben jene 334mm².

128MB brauchen ca. 6,5 Mrd. Transistoren, ausgehend von den 26,8Mrd Transistoren bleiben ca. 20Mrd. für den Rest (ein bisschen Redundanz gibt es im Cache bestimmt, vor allem da es keine Resteverwertung mit deaktiviertem Cache gibt)

Wenn wir jetzt eine Milchmädchenrechnung anstellen und davon ausgehen dass der Infinity Cache gleich bleibt, und der Rest halbiert wird landen wir bei ca. 20/2 + 7 = 17Mrd. Transistoren, also ca. 60%.

Und siehe da, wenn wir davon ausgehen dass alle Transistoren gleich viel Fläche benötigen würden (was natürlich nicht stimmt), landen wir bei 310mm².

Passt ziemlich gut für so eine einfache Mildmädchenrechnung oder?
Jetzt können wir noch ungefähr den Fehler unserer Rechnung abschätzen. Einerseits wird das Speicherinterface nur um 25% verkleinert, anstatt halbiert, zusätzlich sind Videoprozessor, PCIe Interface und ähnliches vermutlich unverändert. Das verursacht, dass unsere Rechnung "zu klein" wird, aber wir haben ja immerhin noch 24mm² übrig.

Andererseits ist der Infinity Cache aber vermutlich das was die höchste Transistordichte aufweist, was unsere Rechnung wieder zu groß werden lässt.
Wir haben also mehr als die 24mm² übrig für den "Rest".

Klingt jetzt nicht unbedingt unwahrscheinlich.


Wir können aber auch mal einfach einen DIE Shot nehmen, mit eingezeichnetem Blockdiagramm und anfangen Pixel zu zählen.
https://www.computerbase.de/forum/attachments/923-block-diagram-jpg.998285/

Und mit unseren gezählten Pixeln können wir dann ein paar Berechnungen vornehmen:

[img]https://i.imgur.com/w0YfI6O.png[/quote]

Und hier sehen wir, dass alles unter 96MB komplett unrealistisch ist, wenn wir annehmen dass die 334mm² stimmen, und die 128M zumindest nicht ausgeschlossen sind.

basix
2020-12-10, 00:44:46
Ui, da hat sich aber wer Mühe gemacht. Respekt :up:

Ich sehe in deiner Rechnung aber leider folgende Fehlerquellen:

Cache, und somit der IF$, hat eine deutlich höhere Transistordichte als der Rest des Chips. Das lässt sich nur schlecht auf den ganze Chip übertragen
AMD gibt für 32 MByte exakt 27mm2 an (sie RDNA2 Slidedeck 1x Slide weiter, welche du verlinkt hast). 128 MByte entsprechen also eher 108mm2 und nicht 82mm2. Das ist die wahrscheinlich grösste Fehlerquelle deiner Rechnung
Was ist das für ein "Rest" in deiner Rechnung? Ist das der Zwischenbereich zwischen den angemalten Blöcken?
Unwahrscheinlich, dass L2 und Frontend halbiert werden können. Der L2 hängt an der Anzahl 32b Speichercontroller, welche 75% von N21 beträgt.
Die Rechnung mit den übrigbleibenden 24mm2 könnte knapp aufgehen, auch wenn ich den Weg dahin etwas umständlich finde ;)

N22 ist für mich auch eher eine 1440p Karte, da reichen auch 48 MByte für eine anständige Hitrate. Vor allem bei 66-75% der Bandbreite (14 oder 16 GT/s GDDR6) und einer Halbierung der CUs. Somit ist N22 relativ gesehen weniger stark als N21 beim Speicherinterface beschnitten. 64 MByte sind sicher möglich (habe ich auch geschrieben) aber mehr halte ich für ziemlich unwahrscheinlich. Wir können ja wetten :deal:

Gast
2020-12-10, 10:00:05
Cache, und somit der IF$, hat eine deutlich höhere Transistordichte als der Rest des Chips. Das lässt sich nur schlecht auf den ganze Chip übertragen


Richtig, und weil Cache eben dichter gepackt ist spielt das zugunsten unserer Rechnung für mehr Cache. Eine Reduktion an Cachetransistoren bringt viel weniger zusätzliche Fläche als eine Reduktion der restlichen Transistoren.


AMD gibt für 32 MByte exakt 27mm2 an (sie RDNA2 Slidedeck 1x Slide weiter, welche du verlinkt hast). 128 MByte entsprechen also eher 108mm2 und nicht 82mm2. Das ist die wahrscheinlich grösste Fehlerquelle deiner Rechnung


32MB von Zen2 entsprechen laut der Folie 27mm². Das muss einerseits nicht 1:1 auf RDNA2 zutreffen, und andererseits sieht man am Highlighting im Zen2 Die shot dass hier nicht nur die Speicherzellen mit gezählt werden sondern auch teile des IF, der kreuz und quer durch den Cache verläuft.
In meiner Rechnung werden nur die Speicherzellen berücksichtigt.


Was ist das für ein "Rest" in deiner Rechnung? Ist das der Zwischenbereich zwischen den angemalten Blöcken?

Dead Silicon und alles andere was nicht zuordenbar ist.
Ich halte es eigentlich sehr unwahrscheinlich, dass dieser Rest bei Navi22 größer als bei Navi 21 sein kann, also kommen eigentlich nur die 128MB und 96MB Varianten in Frage, wobei die 128er zugegebenermaßen etwas knapp kalkuliert ist.


Unwahrscheinlich, dass L2 und Frontend halbiert werden können. Der L2 hängt an der Anzahl 32b Speichercontroller, welche 75% von N21 beträgt.


Laut Blockdiagramm nicht, und es macht auch keinen Sinn, da ja noch der L3 zwischen dem "Kern" und dem Speichercontroller liegt.
Wenn ein Cache abhängig von der Breite des Speichercontroller ist dann immer nur der Last Level Cache, und der ist bei RDNA2 eben der L3.
Da der L2 an den Shader Engines hängt und diese halbiert werden macht es absolut Sinn diesen auch zu halbieren.
Eher unsicher bin ich mir da beim restlichen Frontend wobei auch hier eine Reduktion wohl sicher ist die Frage ist nur wie viel.



N22 ist für mich auch eher eine 1440p Karte, da reichen auch 48 MByte für eine anständige Hitrate. Vor allem bei 66-75% der Bandbreite (14 oder 16 GT/s GDDR6) und einer Halbierung der CUs. Somit ist N22 relativ gesehen weniger stark als N21 beim Speicherinterface beschnitten. 64 MByte sind sicher möglich (habe ich auch geschrieben) aber mehr halte ich für ziemlich unwahrscheinlich. Wir können ja wetten :deal:


Wie gesagt, 48MB halte ich für absolut unmöglich, dafür ist der Chip viel zu groß. Ab 64MB sind zumindest denkbar.

Was am DIE shot von Navi 21 auch auffällt. Während die Geometrie der meisten Blöcke ja relativ fix vorgegeben ist, scheint diese beim L3 Cache ziemlich frei "formbar" zu sein. Man kann also offenbar überall wo sonst nix vernünftiges mehr reinpasst "einfach" Cache reinstopfen.

So und zum Schluss noch mal das Bild ordentlich eingebunden weil ich vorher zu blöd war:

https://i.imgur.com/w0YfI6O.png

Leonidas
2020-12-10, 13:12:06
Um das mal richtig zu lesen, bedeutet dies:

Navi 21 hat bei 128MB IF-Cache abzüglich bekannter Chipteile einen Rest von 79,5mm²

Navi 22 hätte bei 128 MB IF-Cache einen Rest von 38,8mm² und bei 96 MB IF-Cache einen Rest von 60,0mm². Die Rechnungen mit 48/64 MB IF-Cache verbieten sich, weil mehr Rest als bei Navi 21 übrig bleibt.

Die Frage ist nun: Was ist im Rest bzw. was für eine Skalierungs-Abschätzung kann man hier erbringen? Hohe Skalierung, mittlere Skalierung oder schlechte Skalierung mit der Anzahl der CUs?

Gast
2020-12-10, 18:13:25
Die Frage ist nun: Was ist im Rest bzw. was für eine Skalierungs-Abschätzung kann man hier erbringen? Hohe Skalierung, mittlere Skalierung oder schlechte Skalierung mit der Anzahl der CUs?

Erstmal eine Korrektur, Photoshop hat mich leider ausgetrickst, weshalb in meinen ersten Messungen die Ergebnisse zum IF signifikant zu klein ausgefallen sind.
Das Ergebnis ist, dass die Werte zum Dead Silicon für alle Varianten deutlich geringer sind.
https://i.imgur.com/VMzIPk9.png

Zusätzlich habe ich die Messungen zum IF genauer unterteilt in Parts die für den L3 und Parts die für die restlichen Blöcke zuständig sind und damit die Skalierungswerte für den IF verbessert, mit dem Ergebnis dass die Skalierung nun stärker mit dem verbauten L3 korreliert.

Bei dem Rest handelt es sich hauptsächlich um Dead Silicon, also im Wahrsten sinne des Wortes "nichts", weil man dort keine ganzen Funktionsblöcke mehr unterbringen konnte.

Wie viel davon übrig bleibt ist nicht ganz leicht abzuschätzen, im Zweifelsfall würde ich sagen, das Verhältnis sollte ungefähr gleich bleiben.
Dann müssten wir für Nav22 bei 38mm² landen. Wobei ich durchaus eine Chance sehe, dass sich dieser Wert bedeutend verringert. Der größte Teil vom Dead Silicon ist ja um die Infinity-Links die bei Navi22 sicherlich nicht vorhanden sind. Diesen Platz könnte man also mit L3 "füllen".

96MB bleiben also weiterhin die wahrscheinlichste Lösung, 128MB wird etwas unwahrscheinlicher aber noch nicht ganz ausgeschlossen.

Die Frage ist wie das physische Layout aussehen wird. Wir haben einige Blöcke deren Layout mehr oder weniger feststeht, z.B. die Shader-Engines und die ganzen PHY Interfaces, und dann noch einige die man offenbar mehr oder weniger frei "verlegen" kann, darunter der IF und der L3.

Iscaran
2020-12-10, 22:07:21
Also mit den alten Werten aus dem Speku-Thread käme man auf:
97.80 mm^2 für 40 CUs
48.96 mm^2 für 192 Bit SI
37.72 mm^2 für Frontend
10.85 mm^2 für GPU Core
86.61 mm^2 für 128 MB InfCache (0.6766 mm^2 pro MB)

Summe: 328.6 mm^2

mit 96 MB Cache sinds nur 306.9 mm^2

DA aber mit obigen Rechnungen Navi21 auch zu "klein" ausfällt (489.4 mm^2) = +6.2564% (gegenüber den echten 520 mm^2).
=> Skaliere ich also die obigen Chipgrößen noch mit 1.062564 ergeben sich:
128 MB Cache: 349.2 mm^2
96 MB Cache: 326.2 mm^2

Letzteres erscheint mir plausibler zu sein und ist auch näher an den kolportierten 332 mm^2 dran.

=> Navi 22 hat 96 MB Cache.

Gast
2020-12-11, 13:24:26
Also mit den alten Werten aus dem Speku-Thread käme man auf:
97.80 mm^2 für 40 CUs
48.96 mm^2 für 192 Bit SI
37.72 mm^2 für Frontend
10.85 mm^2 für GPU Core
86.61 mm^2 für 128 MB InfCache (0.6766 mm^2 pro MB)

Summe: 328.6 mm^2

mit 96 MB Cache sinds nur 306.9 mm^2

DA aber mit obigen Rechnungen Navi21 auch zu "klein" ausfällt (489.4 mm^2) = +6.2564% (gegenüber den echten 520 mm^2).
=> Skaliere ich also die obigen Chipgrößen noch mit 1.062564 ergeben sich:
128 MB Cache: 349.2 mm^2
96 MB Cache: 326.2 mm^2

Letzteres erscheint mir plausibler zu sein und ist auch näher an den kolportierten 332 mm^2 dran.

=> Navi 22 hat 96 MB Cache.

Und mit 128MB Cache und 128bit SI auf ca 335mm^2

Iscaran
2020-12-12, 16:47:43
Und mit 128MB Cache und 128bit SI auf ca 335mm^2

Die Reduktion des SI von 192 bit auf 128 Bit spart nur ca 16 mm^2 ein

mit 128 MB Cache und 128 bit SI und 1.06% korrekturfaktor käme ich auf 331.8 mm^2

Aber wir wissen doch schon ziemlich sicher aus den Treiberleaks dass es ein 192 bit SI wird ? Das ist eigentlich AFAIK 99% sicher.

Gast
2020-12-12, 17:15:57
Die Reduktion des SI von 192 bit auf 128 Bit spart nur ca 16 mm^2 ein

Das darf man nicht unterschätzen die Speichercontroller kann man eben nicht beliebig positionieren, und je nach physischer Struktur die DIEs könnte es da schon zu deutlich größeren Unterschieden kommen, wenn man durch das größere Interface bestimmte DIE-Fläche einfach für nichts mehr anderes verwenden kann.