Navi 1X (7nm, RDNA1, 2019) & Navi 2X (7nm, RDNA2, 2020)

[Digidi]

Mit Navi hat man vermutlich in einer ähnlichen Größenordnung Kontrolllogik, Caches etc. Immerhin kommt man oft auf Auslastungsbereiche, die vergleichbar ist. Jetzt muss vor allem Perf/W gesteigert werden, damit man mehr Ausführungseinheiten verbaut werden können ohne dass die tdp explodiert. Und auch RT. Auf beides scheint sich rdna2 zu konzentrieren.

Hat man bei Navi nicht sogar die Kontrolllogik zurückgefahren? Es sind doch nun weniger AWS und HWS Einheiten verbaut?

Ich glaube auch Vega hatte schon gute Kontrollogiken nur wurden die halt nur bei Forza Horizon oder Doom benutzt.

[robbitop]

Schau dir an wie viele Transistoren N10 hat und wie viele CUs ubd vergleiche das mal mit den Vorgängergenerationen.
Damit meine ich jetzt nicht ACE etc sondern CU interne Kontrolllogik.

Ist ja bei Volta/Turing auch so.

[gmb]

@gmb

Du behauptest "later this year" heißt Ende des Jahres. Das ist schlicht falsch und gelogen. Da kannst du noch so oft schreiben, dass AMD es auf late bzw. end of this year klarifiziert hat.


Marketing ist dir schon ein Begriff? Bei dem Wortlaut war mir sofort klar, dass man das nicht wortwörtlich nehmen kann, sondern das man erfahrungsgemäß von einem Termin gegen Ende des Jahres ausgehen kann, sonst hätte das AMD ganz anders kommuniziert und nicht so wischiwaschi mäßig mit later this year. Die Pressemitteilung hat mich voll bestätigt, also wo ist jetzt dein Problem? Du hast den Mund wieder einmal zu voll genommen und wurdest eines besseren belehrt. Alles was dir nicht in dem Kram passt ist erlogen, wir wissen es.

[Unicous]

Wie oft willst du noch deine Unkenntnis der englischen Sprache zur Schau stellen?:confused:

Es gibt zig Beispiele wo ein Hersteller zum Beispiel zur CES ein Produkt ankündigt und dann zum Launch sagt "later this year". Das bedeutet dann meist in der zweiten Jahreshälfte oder eben auch manchmal spätes zweites Quartal. Das liegt u.a. an SEC-Regularien die eingehalten werden müssen.

Nur weil AMD hier nicht von Anfang deutlich gesagt hat, dass der Launch erst Ende des Jahres stattfindet gibt dir nicht das Recht die englische Sprache für dich umzudeuten. :facepalm:

[BlacKi]

Nur weil AMD hier nicht von Anfang deutlich gesagt hat, dass der Launch erst Ende des Jahres stattfindet gibt dir nicht das Recht die englische Sprache für dich umzudeuten. :facepalm:
NICHT Q2 eher q3/4. passt das dir eher?

aber spielt das denn die rolle?

[aufkrawall]

Later this year heißt übersetzt meistens nichts anderes als nicht innerhalb dieses Quartals.
Wo ist das zu entnehmen?
Hier z.B. ist es mindestens ein Quartal später:
https://www.theverge.com/2020/2/28/21156037/gdc-2020-canceled-coronavirus-gaming-event-san-francisco
Wo findet sich ein Beispiel, bei dem der Zeitraum innerhalb des gleichen Quartals gemeint ist?

[Unicous]

Wo findet sich ein Beispiel, bei dem der Zeitraum innerhalb des gleichen Quartals gemeint ist?
:confused:

Du zitierst meinen Post und stellst dann diese Frage?

nicht innerhalb dieses Quartals


The GDC organizers say they “fully intend to host a GDC event later in the summer,”

[aufkrawall]

Ist trotzdem nicht im selben Quartal und kann auch das übernächste bedeuten.
Du darfst gerne 1-2 weitere Beispiele beisteuern.

[Unicous]

Ich habe irgendwie keine Worte mehr? Willst du mich absichtlich falsch verstehen?

[Felixxz2]

Also ich muss hier Unicous leider ganz klar recht geben: im Englischen heißt „later this year“ einfach nur ziemlich wertneutral „später als heute“. Das kann in einem Monat sein oder eben auch im Dezember. Es heißt aber explizit NICHT „am Ende des Jahres“, so wie einige das hier verstehen.

In diesem Fall wird das Datum natürlich schon ein wenig weiter in der Zulunft liegen als sagen wir, April. Zum Beispiel August oder September. Sonst hötte man es natürlich auch schon deutlicher präzisieren können. Allerdings ist, wie schon gesagt, die Übersetzung zu „am Ende des Jahres“ leider falsch und von AMD auch hier nicht gemeint.
Gebts einfach mal mal google ein 😉

[Leonidas]

Schau dir an wie viele Transistoren N10 hat und wie viele CUs ubd vergleiche das mal mit den Vorgängergenerationen. .


Exakt. Siehe hier:

.|Jahr|Gen.|Shader-Einheiten & Interface|Vollausbau-Lösung|Transistoren pro Shader-Einheit
AMD R1000/Tahiti|2011|GCN1|2048 SE @ 384 Bit GDDR5|Radeon HD 7970|2,10 Mio. Transistoren pro Shader-Einheit
AMD Pitcairn|2012|GCN1|1280 SE @ 256 Bit GDDR5|Radeon HD 7870|2,19 Mio. Transistoren pro Shader-Einheit
AMD Hawaii|2013|GCN2|2816 SE @ 512 Bit GDDR5|Radeon R9 290X|2,20 Mio. Transistoren pro Shader-Einheit
AMD Tonga|2014|GCN3|2048 SE @ 256 Bit GDDR5|Radeon R9 380X|2,44 Mio. Transistoren pro Shader-Einheit
AMD Polaris|2016|GCN4|2304 SE @ 256 Bit GDDR5|Radeon RX 480|2,47 Mio. Transistoren pro Shader-Einheit
AMD Vega 10|2017|GCN5|4096 SE @ 2048 Bit HBM2|Radeon RX Vega 64|3,05 Mio. Transistoren pro Shader-Einheit
AMD Navi 10|2019|RDNA1|2560 SE @ 256 Bit GDDR6|Radeon RX 5700 XT|4,02 Mio. Transistoren pro Shader-Einheit
nVidia TU116|2019|Turing|1536 SE @ 192 Bit GDDR6|GeForce GTX 1660 Ti|4,30 Mio. Transistoren pro Shader-Einheit
nVidia GP104|2017|Pascal|2560 SE @ 256 Bit GDDR5X|GeForce GTX 1080|2,81 Mio. Transistoren pro Shader-Einheit

[fondness]

https://i.imgur.com/FkG2Bx5h.jpg

Für mich die beeindruckenste Aussage des gesamten FADs. 50% mehr Perf/Watt im selben Prozess war nicht unbedingt zu erwarten, noch dazu wo auch noch Raytracing und andere Features dazu kommen. Sie vergleichen das auch 1 zu 1 mit Navi, wo auch 50% mehr Perf/Watt vs. Vega angegeben wurde (in der Realität war das eher mehr - allerdings auch 7nm vs. 14nm).

Damit hätte man es in nur zwei Generationen uU geschafft, den fast uneinholbar erscheinenden Rückstand auf Nvidia aufzuholen. Schon beeindruckend was Lisa Su aus AMD gemacht hat; in einer Situation, wo kaum Geld und Ressourcen zur Verfügung standen. Die Chips die heute und in nächster Zeit gelauncht werden hatten natürlich eine lange Vorlaufzeit. Zeigt wieder mal wie wichtig der CEO ist und warum man dort so viel verdient.

[basix]

@basix

Seit wann bitte ist die Behauptung kleine die size= kleiner Endundenpreis bitte belegt?:freak:


Die Auflistung höhere Marge vs. günstiger für Endkunden ist auch eher als XOR zu verstehen ;) Aber sobald Konkurrenz ins Spiel kommt (namentlich Nvidia), bleibt mehr Spielraum für Preisanpassungen. Das könnte uns schon zugute kommen.


Deine anderen Aussagen sind weder allgemeingültig noch besonders aussagekräftig. Dass es ein die size bzw. Masken-Limit gibt hat physikalische bzw. verfahrenstechnische Gründe. Große Dies sind meist sogar besser bzw. nötig für die Performance, siehe die dark silicon Problematik.

Performance / Area wird aufgrund der immer teurer werdenden Prozesse sogar immer wichtiger. Ansonsten erleben wir eben genau das: Steigende Preise. Und mit HiNA (High Numeric Aperture, 3nm und beyond) wird die maximale Chipgrösse sogar auf 400mm2 limiert sein (Reticle Limit).


Dass man die Kunden mit kleinen dies abzocken kann und während man geringe Kosten hat, zeigt unter anderem Apple in gewisser Hinsicht auch zeitweise Intel, wenn sie ihren Prozess in den Begriff bekommen und ihre Fabs richtig auslasten.

AMD hat kleine dies und ihre Marge steigt immer weiter, die Endkundenpreise stagnieren eher.:wink:

Bei AMD muss ich ein wenig widersprechen. Nvidia und Intel haben eine wie hohe Marge? >60%? AMD hat gerade mal 45%. Ausserdem sind CPUs bei Perf/$ aufgrund AMD noch nie so günstig gewesen. Einzig bei den GPUs sind die Preise so hoch wie nie und zudem auf diesem Niveau stagnierend. Deswegen: Wenn man die Performance / Area maximiert, kann das zu positiven Effekten für die Endkundenpreise führen. So lange sich die Firmen in ihrer Komfortzone bewegen was Marge anbelangt, ist auch Spielraum für günstigere Preise.

[Ghost1nTh3GPU]

Für mich die beeindruckenste Aussage des gesamten FADs. 50% mehr Perf/Watt im selben Prozess war nicht unbedingt zu erwarten, noch dazu wo auch noch Raytracing und andere Features dazu kommen. Sie vergleichen das noch dazu 1 zu 1 mit Navi, wo auch 50% mehr Perf/Watt vs. Vega angegeben wurde (in der Realität war das eher mehr - allerdings auch 7nm vs. 14nm).
Den Transistoreinsatz sollte man aber auch nicht vernachlässigen (Verdopplung von PolarisX0 zu Navi10) und das wird wohl bei Navi2X auch einer der Bausteine für die 50% sein. Aber natürlich wird 7nm mittelfristig günstiger pro Wafer.


Damit hätte man es in nur zwei Generationen uU geschafft, den fast uneinholbar erscheinenden Rückstand auf Nvidia aufzuholen. Schon beeindruckend was Lisa Su aus AMD gemacht hat. Zeigt wieder mal wie wichtig der CEO ist und warum man dort so viel verdient.
Lisa und Jensen sollte vielleicht mal Intel einen ihrer Verwandten (https://www.reddit.com/r/nvidia/comments/8pdxo7/nvidias_ceo_jensens_niece_is_lisa_su_ceo_of_amd/)empfehlen. ;D

[y33H@]

Durch das geringere Reticle wird je nach Design ggf Mask-Stitching bei HiNA EUV eingesetzt wie heute schon bei Interposern, habe mich aber damit nicht weiter beschäftigt.

[robbitop]

Wobei der Transistoreinsatz auch sinnvoll ist. Auch GPUs leiden an ihrer Skalierbarkeit (bzw dessen abnehmenden Grenzertrags). Ansonsten hätte man plump Polaris CUs oder Maxwell SMs skaliert. Denn Perf/Transistor sind die super gemessen an dem was wir heute haben. Aber die Skalierbarkeit geht irgendwann den Bach runter. Also muss der praktische Durchsatz pro Ausführungseinheit hoch, ohne dass die TDP explodiert. Und das kostet neben mehr Features auch Transistoren.
Mehr Takt (längere Pipeline), mehr Reuse (mehr Cache und besseres Prefetching), mehr IPC (feinere Granularität, bessere Zusammenfassung von Instruktionen, mehr Kontrolllogik).

Auch diese Maßnahmen werden überproportional teuer, da jeder Zugewinn auch schnell in unschöne Bereiche des abnehmenden Grenzertrags wandert.

[AffenJack]

Bei AMD muss ich ein wenig widersprechen. Nvidia und Intel haben eine wie hohe Marge? >60%? AMD hat gerade mal 45%. Ausserdem sind CPUs bei Perf/$ aufgrund AMD noch nie so günstig gewesen. Einzig bei den GPUs sind die Preise so hoch wie nie und zudem auf diesem Niveau stagnierend. Deswegen: Wenn man die Performance / Area maximiert, kann das zu positiven Effekten für die Endkundenpreise führen. So lange sich die Firmen in ihrer Komfortzone bewegen was Marge anbelangt, ist auch Spielraum für günstigere Preise.

Der Unterschied liegt aber nicht daran, dass AMD ihre CPUs so günstig anbietet, sondern am Verhältnis Umsatz mit niedriger Marge (Konsolen) bis mittlerer Marge (Consumer) zu Umsatz mit hoher Marge (Server). Intel und Nvidia sind deutlich Serverlastiger als AMD. Bei Consumercpus und GPUs dürften die Margenunterschiede recht klein sein. Es würde mich nichtmal wundern, wenn AMD mittlerweile bei CPUs bessere Margen als Intel hat, da die kleinen Dies günstig zu produzieren sind. Günstiger Produktionspreis bringt den Kunden nur was, wenn die Hersteller Marge für Preiskampf opfern wollen. Wie man schön an Turing vs Navi sieht, ist dies nicht der Fall und beide Hersteller ziehen Marge vor.

[robbitop]

Naja alles ab TU104 hat garantiert auch im Consumerbereich bessere margen. Man schaue sich das P/L an. Überall da wo es kein Wettbewerb gibt kann man eben einsammeln. Völlig normal. Zeigt aber auch, dass Wettbewerb wichtig ist.

[AffenJack]

Naja alles ab TU104 hat garantiert auch im Consumerbereich bessere margen. Man schaue sich das P/L an. Überall da wo es kein Wettbewerb gibt kann man eben einsammeln. Völlig normal. Zeigt aber auch, dass Wettbewerb wichtig ist.

Natürlich, mir gehts eher um die Bereich mit Konkurrenzprodukten. Würde mich wundern, wenn Navi10 vs TU106 oder Navi 14 vs TU116 sich viel nehmen.

[robbitop]

Natürlich, mir gehts eher um die Bereich mit Konkurrenzprodukten. Würde mich wundern, wenn Navi10 vs TU106 oder Navi 14 vs TU116 sich viel nehmen.

Da würde ich dir zustimmen. Dank Navi braucht man diese Runde kein größeres, teureres SI und wesentlich mehr Transistoren pro Perf. Zu Pascal vs Polaris und Vega war das deutlich drastischer. Auch bei Maxwell und Kepler. Da konnte NV Produkte verkaufen, die günstiger in der Herstellung waren. Dank effizienterer Designs.
Wenn AMD es schaffen sollte in jedem Marktsegment der GPUs so kompetativ zu sein wie aktuell bei den CPUs steht uns Endkunden endlich mal wieder eine gute Zeit bevor. (mehr Wettbewerb bringt mehr Performanceentwicklung und besseres PL)

[reaperrr]

Schau dir an wie viele Transistoren N10 hat und wie viele CUs ubd vergleiche das mal mit den Vorgängergenerationen.
Damit meine ich jetzt nicht ACE etc sondern CU interne Kontrolllogik.

Ist ja bei Volta/Turing auch so.
Nur dass das bei Navi den kleineren Teil des Transistoranstiegs ausmacht.

Exakt. Siehe hier:

.|Jahr|Gen.|Shader-Einheiten & Interface|Vollausbau-Lösung|Transistoren pro Shader-Einheit
AMD R1000/Tahiti|2011|GCN1|2048 SE @ 384 Bit GDDR5|Radeon HD 7970|2,10 Mio. Transistoren pro Shader-Einheit
AMD Pitcairn|2012|GCN1|1280 SE @ 256 Bit GDDR5|Radeon HD 7870|2,19 Mio. Transistoren pro Shader-Einheit
AMD Hawaii|2013|GCN2|2816 SE @ 512 Bit GDDR5|Radeon R9 290X|2,20 Mio. Transistoren pro Shader-Einheit
AMD Tonga|2014|GCN3|2048 SE @ 256 Bit GDDR5|Radeon R9 380X|2,44 Mio. Transistoren pro Shader-Einheit
AMD Polaris|2016|GCN4|2304 SE @ 256 Bit GDDR5|Radeon RX 480|2,47 Mio. Transistoren pro Shader-Einheit
AMD Vega 10|2017|GCN5|4096 SE @ 2048 Bit HBM2|Radeon RX Vega 64|3,05 Mio. Transistoren pro Shader-Einheit
AMD Navi 10|2019|RDNA1|2560 SE @ 256 Bit GDDR6|Radeon RX 5700 XT|4,02 Mio. Transistoren pro Shader-Einheit
nVidia TU116|2019|Turing|1536 SE @ 192 Bit GDDR6|GeForce GTX 1660 Ti|4,30 Mio. Transistoren pro Shader-Einheit
nVidia GP104|2017|Pascal|2560 SE @ 256 Bit GDDR5X|GeForce GTX 1080|2,81 Mio. Transistoren pro Shader-Einheit

Diese Vergleiche haben einen ganz fetten Haken:
Diese zusätzlichen Transistoren stecken mehrheitlich NICHT in den CUs/WGPs.

Ein Navi-WGP (2 CUs nach alter Rechnung) ist nur ~4,05mm² groß, selbst eine einzelne Vega10-CU in 14nm ist größer (~4,15mm²), und 2 Vega20-CUs in 7nm sind nur unwesentlich kleiner (2x ~1,9mm² = ~3,8mm²).

Von den 251mm² von Navi10 werden nur ~81mm² durch die CUs/WGPs belegt, also nicht mal ein Drittel der GPU.

Was bei Navi massiv fetter geworden ist, ist das Gesamtpaket aus Frontend, Backend (inkl. Memory-Controller) und Uncore (VCN, Displaycontroller etc.). An den WGPs liegt's nicht, die sind - auch prozess-normalisiert - nach wie vor (deutlich) kleiner als Turing-SMs und somit für sich betrachtet sogar deutlich besser in Sachen Perf/mm². Das wird dann bloß u.a. durch fettere Memory-Controller und ROPs (https://twitter.com/GPUsAreMagic/status/1227635008636178432) wieder kaputt gemacht.

[robbitop]

@reaperrr
Danke für den Beitrag. Sehr aufschlussreich. :up:

[aufkrawall]

Ich habe irgendwie keine Worte mehr?
Und das als selbsternannter Sprach-Sheriff! :eek:

Also ich muss hier Unicous leider ganz klar recht geben: im Englischen heißt „later this year“ einfach nur ziemlich wertneutral „später als heute“. Das kann in einem Monat sein oder eben auch im Dezember. Es heißt aber explizit NICHT „am Ende des Jahres“, so wie einige das hier verstehen.

Wer sind denn "einige"?
Wenn man auf gmb bei so etwas eingeht, hat das den Anspruch einer "Diskussion" zwischen Automatix und Verleihnix...

[Screemer]

Und das als selbsternannter Sprach-Sheriff! :eek:

Was ist denn an "nicht innerhalb dieses Quartals" falsch zu verstehen? Kann ein beliebiges Quartal des selben Jahres ab dem aktuellen sein.

[aufkrawall]

I bims doof, der Wein hatte das Wort "nicht" weggeclipt. :redface:

[Screemer]

:ugly: alles klar. Passiert.:up:

[Unicous]

I bims doof, der Wein hatte das Wort "nicht" weggeclipt. :redface:

Na endlich.

[fondness]

Ein Navi-WGP (2 CUs nach alter Rechnung) ist nur ~4,05mm² groß, selbst eine einzelne Vega10-CU in 14nm ist größer (~4,15mm²), und 2 Vega20-CUs in 7nm sind nur unwesentlich kleiner (2x ~1,9mm² = ~3,8mm²).


Naja, Vega20 hat 1:2 DP.

[boxleitnerb]

Spekulation statt Kleinkriegen & Korinthenkackerei? Werdet doch bitte erwachsen. Danke.

[reaperrr]

Naja, Vega20 hat 1:2 DP.
Ich weiß, so groß ist der Unterschied aber nicht, und an den Flächenverhältnissen von Navi10 ändert es auch nichts.

[robbitop]

Also V10 passt da schon besser. Da hat N10 schon 1/3 draufgelegt - ist jetzt auch nicht ohne,

[Leonidas]

@reaperrr
Danke für den Beitrag. Sehr aufschlussreich. :up:


Schließe mich an. Wobei ich meine Ausführung nicht zwingend darauf verstehen wollte, das unbedingt in den CUs mehr Transistoren liegen. Das gesamte Design hat einfach mehr Transistoren, das ganze habe ich schlicht relativ zur Anzahl der Shader-Einheiten angegeben. Die richtige Bemessungsgrenze wäre eher gewesen: Pro taktnormierter Rechenleistung.

[SKYNET]

so, da big navi ja 50% effektiver sein soll, kann man evtl. jetzt sogar von 96CUs ausgehen, und nicht nur 80CUs...

werfe mal was in den raum:
96CUs
24GB HBM2 1.2TB/s
3x RT leistung einer RTX Titan
250W

[Screemer]

verdammt. was soll man dazu nur sagen :ugly:

mach mal langsam mit dem hypetrain. nicht dass das wieder so ausartet wie mit fury damals.

[[MK2]Mythos]

Na, da gehen die Fan-wars sicher gleich in die zweite Runde...
:popcorn:

[BlacKi]

no comment

aber post, gespeichert^^

[Der_Korken]

werfe mal was in den raum:
96CUs 64CUs @2Ghz, +5-10% IPC
24GB HBM2 1.2TB/s 12GB GDDR6 768GB/s
3x1,5x RT leistung einer RTX Titan
250W280W

ftfy :D

[robbitop]

Ich tippe auf 80CUs. Ggf leicht gesteigerter Takt und Effizienz inkl RT. :)

[Der_Korken]

Da AMD auch von höherem Takt und höherer IPC gesprochen hat, würde es mich nicht wundern, wenn es gar nicht so viele CUs werden. 2Ghz und +10%IPC wären auch schon +20% Leistung pro CU. Davon dann 60% mehr ist auch fast eine Verdopplung gegenüber N10. Da würde man eher mit weniger als 505mm² auskommen.

[robbitop]

Der Gegner für RDNA2 ist nicht Turing sondern dessen Nachfolger. Sandbagging wird AMD nichts nützen. Beim Topdog würde ich von mehr als 64 CUs ausgehen.

[gedi]

Da AMD ja eine 4k -Performance ohne Abstriche angibt, dann bedeutet das für mich, auch mit RT.

Performancewise sollten dann im Schnitt unabhängig der API 2080Ti-Performance + 30% rauskommen, mit RT sollte sie aber min. doppelt so schnell sein. Ich denke 16GB GDDR6 sind wohl sicher, 96CUs möglich, aber eher unwahrscheinlich, takten wird das Ding im Boost bis zu 2G und verbrauchen nahe 300W - AMD-typisch halt.

[HOT]

Selten war es so schwer was sinnvolles zu spekulieren... Ich hab ja die Chiplets noch nicht abgeschrieben, obwohl das regemäßig plattgebügelt wird.

[robbitop]

Ohne einen Durchbruch bei Interfaces nur schwierig mögwenn es transparent zur Anwendung sein soll. Bandbreiten und Latenzbedarf ist nunmal ganz anders als bei cpus. Entsprechend muss der Energiebedarf pro bit aus dem Chip in den Nachbarchip massiv runter.

[bbott]

Die 50% bessere Effizenz könnten doch neben der Fertigung Verbesserung, auch durch die Nutzung des hbm2 Speichers wie bei Fiji mit eingerechnet sein?!

[robbitop]

Man darf gespannt sein. Bis dato war HBM für Consumerkarten immer etwas teuer. Kann dann schnell zum Margenfresser werden. IMO bleibt HBM mittelfristig bei Profi/HPC HW.

[unl34shed]

Ohne einen Durchbruch bei Interfaces nur schwierig mögwenn es transparent zur Anwendung sein soll. Bandbreiten und Latenzbedarf ist nunmal ganz anders als bei cpus. Entsprechend muss der Energiebedarf pro bit aus dem Chip in den Nachbarchip massiv runter.

Gibt es eigentlich belastbare Zahlen, wie viel Daten normalerweise zwischen den einzelnen Compute Engines ausgetauscht werden? Reine Speicherzugriffe könnte man mit lokalem Speicher/Cache teilweise abfangen.

[robbitop]

Ich habe da leider auch nichts. Ich würde allerdings schätzen, dass man da schon im einstelligen TB/s Bereich liegen könnte.

[maximus_hertus]

Ist der Polaris Launch schon so weit her? Die 50% sind erstmal eine Zahl von AMD. Bei CPUs wäre das vielleicht ein verlässlicher Wert, bei GPUs aber eher unwahrscheinlich.

Am Ende ist es ein theoretischer Wert, der bei den finalen Konfigurationen der Karten keine Bedeutung hat und man landet irgendwo bei 20-30%.

Nach der Turing-Enttäuschung muss nV erstmal liefern.

[HOT]

Ohne einen Durchbruch bei Interfaces nur schwierig mögwenn es transparent zur Anwendung sein soll. Bandbreiten und Latenzbedarf ist nunmal ganz anders als bei cpus. Entsprechend muss der Energiebedarf pro bit aus dem Chip in den Nachbarchip massiv runter.
Tjo, bis Zen2 wurde das auch für Prozessoren für utopisch gehalten. Und da ging es. Mit einem Interposer könnte es bei GPUs ähnlich realisierbar sein.

[robbitop]

Tjo, bis Zen2 wurde das auch für Prozessoren für utopisch gehalten. Und da ging es. Mit einem Interposer könnte es bei GPUs ähnlich realisierbar sein.

Warum wurde das für utopisch gehalten? Macht IBM mit ihren Power CPUs seit Jahrzehnten. Wie gesagt ist die Bandbreitenanforderung um Größenordnungen geringer.

Auch Clarkdale war 2009 schon ähnlich. CPU Cores im 32 nm Chiplet und I/O und GPU im günstigeren 45 nm Chiplet auf dem gleichen Träger. Ein weiteres CPU Chiplet wäre jetzt auch keine schwarze Magie gewesen.

[Der_Korken]

Der Gegner für RDNA2 ist nicht Turing sondern dessen Nachfolger. Sandbagging wird AMD nichts nützen. Beim Topdog würde ich von mehr als 64 CUs ausgehen.

Naja, was heißt Sandbagging. Ein kleinerer Chip ist auch billiger. Der wird dann gegen die 3070Ti/3080 positioniert und die 3080Ti bleibt wieder ohne Gegenspieler. Für Margen und Stückzahlen ist das gut genug.

[robbitop]

Naja, was heißt Sandbagging. Ein kleinerer Chip ist auch billiger. Der wird dann gegen die 3070Ti/3080 positioniert und die 3080Ti bleibt wieder ohne Gegenspieler. Für Margen und Stückzahlen ist das gut genug.

Die 3080 wird vermutlich ein gutes Stück schneller als die 2080ti. Die 2080 war eine Ausnahme weil RT dazu kom, die fetten Volta SMs und es keinen Shrink gab.
Da wird man schon Gas geben müssen IMO.

[Der_Korken]

Wie gesagt: 60% mehr CUs, 10% mehr Takt, 10% mehr IPC ~ 90% mehr Leistung als 5700XT = ~25% mehr Leistung als 2080Ti. Da muss Nvidia auch erstmal hinkommen, ohne dass denen die Chipgröße um die Ohren fliegt. AMD dürfte eher auf margeträchtige Chips als auf die Leistungskrone aus sein.

[robbitop]

Möglich. Mal sehen, wie es kommt. Ich bleibe bei 80 CUs für den topdog. Wird in jedem Fall spannend.

[Berniyh]

Die 50% bessere Effizenz könnten doch neben der Fertigung Verbesserung, auch durch die Nutzung des hbm2 Speichers wie bei Fiji mit eingerechnet sein?!
Ich muss zugeben, dass ich ein großer Fan von HBM2 bin und tatsächlich auch mehr für die Karte zahlen würde, wenn sie mit HBM2 kommt (da sparsamer, bleibt also mehr für die GPU über).

Aber an der Stelle muss man schon bedenken, dass es für AMD ein gewisses Risiko ist so einen Chip mit HBM2 zu designen.
Wie schon erwähnt wurde ist die potentielle Marge für so eine Karte geringer und damit steigt eben das Risiko das AMD eingeht.
Wenn die Karte 1000€ oder mehr kostet ist das nicht so schlimm, aber es ist schwierig mit 2-3 Jahren Vorlaut die Karte auf dem Level zu positionieren (insbesondere, wenn man nicht so genau weiß was Nvidia umsetzen wird).

Bei unter 1000€ dürfte dann aber der finanzielle Einfluss von HBM2 schon signifikant werden und entsprechend eben unwahrscheinlicher.
Irgendwie kann ich mir nicht vorstellen, dass AMD Big Navi bei über 1000€ positionieren wird. Eher so VII Gefilde, also ca. 700€.
Mit 60-80 CUs und 384 Bit GDDR6 Speicherinterface.

Wenn Leo mit seiner Theorie von Navi23 als "Nvidia Killer" Recht behält, dann dürfte das eben dann die Karte mit HBM2 (und noch mehr CUs) sein.
Ich glaube da aber nicht so wirklich dran, schätze eher, dass Big Navi mit max. 80 CUs schon der angebliche Nvidia Killer ist und der Begriff letztendlich Nonsens ist.

Will sagen, dass ich nur einen RDNA2 Chip (Navi21 oder Navi23) im High-End Segment erwarte. Denke der andere wird eher Low-End bis Mittelklasse abdecken.
Und den Dritten würde ich wieder in irgendeinem Custom-Projekt erwarten statt in Consumerprodukten.

[gedi]

Navi 23 dürfte bereits RDNA3 sein

[Linmoum]

Ist der Polaris Launch schon so weit her? Die 50% sind erstmal eine Zahl von AMD. Bei CPUs wäre das vielleicht ein verlässlicher Wert, bei GPUs aber eher unwahrscheinlich.

Am Ende ist es ein theoretischer Wert, der bei den finalen Konfigurationen der Karten keine Bedeutung hat und man landet irgendwo bei 20-30%.
Sie hatten bei RDNA schon damals +50% ggü. GCN (Vega) genannt. Die Realität hatte gezeigt, dass diese von AMD eigens genannte Perf/Watt-Steigerung sogar konservativ und es tatsächlich mehr war. CB hatte von Vega64 auf 5700XT damals zum Launch z.B.
+63%.

https://www.computerbase.de/2019-07/radeon-rx-5700-xt-test/3/#abschnitt_die_energieeffizienz_als_performance_pro_watt

Ich sehe daher erstmal keinen Grund dafür, warum AMD jetzt plötzlich übertreiben sollte.

[Pirx]

Wir werden es ja dann in ~10 Monaten sehen *gähn*

[Piefkee]

Navi 23 dürfte bereits RDNA3 sein

Nope auf der FAD Folie steht klar RDNA3 Navi 3x

[Berniyh]

Navi 23 dürfte bereits RDNA3 sein
Wahrscheinlicher dürfte sein, dass eine Ziege ein Kreuzworträtsel löst.

(Zitat Pispers)

[gedi]

Wahrscheinlicher dürfte sein, dass eine Ziege ein Kreuzworträtsel löst.

(Zitat Pispers)

Man gebe dem ungeborenem einen Namen ...

[Iscaran]

Tjo, bis Zen2 wurde das auch für Prozessoren für utopisch gehalten. Und da ging es. Mit einem Interposer könnte es bei GPUs ähnlich realisierbar sein.

Stimmt. Vielleicht wäre die Lösung ja auch 4x sehr kleine, aber sehr "effiziente" GPU Dies mit einem Interposer und RAM-Connect etc. zu verbinden.

Wenn ich dazu noch das hier lese von
Ein Navi-WGP (2 CUs nach alter Rechnung) ist nur ~4,05mm² groß, selbst eine einzelne Vega10-CU in 14nm ist größer (~4,15mm²), und 2 Vega20-CUs in 7nm sind nur unwesentlich kleiner (2x ~1,9mm² = ~3,8mm²).

Von den 251mm² von Navi10 werden nur ~81mm² durch die CUs/WGPs belegt, also nicht mal ein Drittel der GPU.


Mal grob überschlagen könnte so ein Navi 2x ein sehr stark auf Vebrauchsoptimierung getrimmter Navi10 Weiterentwicklung sein (=> RDNA2) mit 24 CUs.
Sehen wir mal der komplette Navi 14 mit 22 CUs inkl. ALLER noch so benötigen Dinge ist nur 158 mm^2 groß. Mit Reaperrrs zahlen wären also die CU's selbst hier 22*4.05 mm^2 = 89.1 mm^2

Nehmen wir mal also 24 Stück sind wir bei 97.2 mm^2

Diese CUs x4 = 96 CUs aber als 4 "getrennte GPU-Chiplets" = 4x100mm^2.

Dazu dann eben noch eine gewisse Kontroll-Logik etc.

Kommt man ggf. mit vielleicht 500 mm^2 aus.

Allein schon durch die Umorganisation und Takt/Verbrauchsoptimierung hat man so extrem viel Spielraum und kann diese kleinen Chiplets evtl. daher viel stärker Takten bzw. eben auch bei Bedarf sehr stark Strom sparen, da die GPU sozusagen 1, 2, 3 oder 4 aktivieren kann je nach dem wie die Last ausfällt.

4x24 CUs + angepasste Logik, etc. und noch 50-100 mm^2 für RT-Einheiten (wobei ich mir da noch unschlüssig bin ob AMD hier nicht den Weg von "Software" bzw. Hybrid RT stärker verfolgt mit mehr "allgemeiner" Nutzbaren Recheneinheiten. Summe also 505 mm^2. Halte ich für durchaus machbar, vor allem wenn man an solche Dinge hier bzgl. RT denkt:

https://www.cryengine.com/news/view/ray-tracing-for-everyone-neon-noir-benchmark-tool-released#
Zum Hybrid RT hat AMD ja auch 2019 erst Patente angemeldet:
https://www.tweaktown.com/news/66455/amds-new-patent-explains-hybrid-ray-tracing-approach/index.html

[unl34shed]

Ich habe da leider auch nichts. Ich würde allerdings schätzen, dass man da schon im einstelligen TB/s Bereich liegen könnte.

Habe da was gefunden: https://www.amd.com/system/files/documents/rdna-whitepaper.pdf
Die Cache Bandbreiten in Navi10 und Vega10 auf Seite21. Breiter müsste so ein Interconnect wohl auch nicht sein.
L0 Bandwidth TB/s 9.76
L1 Bandwidth TB/s 3.90
L2 Bandwidth TB/s 1.95

Mit Compute Engine meine ich alles was hinter einem L1 liegt, also im Fall von Navi10 10CUs. Die haben bei Navi "nur" 256B/Clk * ~1,9GHz = ~485GB/s. Ich nehme an, dass die Bandbreite hauptsächlich für Speicherzugriffe genutzt wird und der eigneltiche Datenaustausch zwischen den CEs (oder Shader Engines hab beides gelesen) recht gering ist.

Frontend, Display- und Memorycontroller in einem I/O Die plus CU-Dies darum Verteilen. 20CUs pro Chiplet, sollte eine angenehme Größe ergeben, dazu den L1 pro Chiplet aufbohren (256kB -> 2MB).

Wenn ich von den Zahlen von Navi ausgehe, würde ich so einem Chiplet wäre ich mir nicht sicher, ob man wirklich 1TB/s braucht. Würde es auf 2/3 reduzieren mit dem HBM2 Verbrauch (~0,75pJ/b) als Referenz, wären das nur ca. 4W pro Chiplet. (https://www.techdesignforums.com/practice/technique/choosing-between-ddr4-and-hbm-in-memory-intensive-applications/)
Das ganze auf 4Chiplets/80CUs begrenzt und 2xHBM2E(820GB/s) könnten vielleicht sogar reichen.

Ok ist natürlich eine Milchmädchenrechnung. :biggrin:

https://static.techspot.com/articles-info/1874/images/2019-07-31-image-3.png
https://www.techdesignforums.com/practice/files/2018/01/CS12154_Figure-3.jpg

[Der_Korken]

Das Problem an den Chiplets ist, dass man das Frontend und den L2$ irgendwo hin tun muss. Da die GPU-Teile im Wesentlichen an einer Sache rechnen und Daten austauschen, ist es hier im Gegensatz zu CPUs vermutlich schmerzhafter, wenn es keinen shared LLC bzw. er nur shared über 1/2 oder 1/4 der GPU ist. Also braucht man einen ziemlich fetten IO-Die, der neben dem IO auch noch den LLC und das ganze Frontend beinhaltet, d.h. der muss auch in 7nm gefertigt werden. Ist der Chiplet-Ansatz dann noch ein großer Vorteil?

Die Modularität ist auch so eine Sache. Der 3800X und der 3950X unterscheiden sich durch die Anzahl der Chiplets, aber der Speicherdurchsatz ist bei beiden gleich. Bei GPUs wäre das totaler Käse wenn z.B. die 80CU-GPU genauso viel Speicherbandbreite hat wie die 40CU-GPU und auch genauso viel teuren Speicher verbaut hat. Also würde man für die 40CU-GPU nicht das gesamte Memory-Interface bestücken - was aber auch wieder Verschwendung von Chipfläche ist, wenn der Großteil an IO-Dies dann das halbe Memory-Interface deaktiviert hat.

[basix]

Bei Gaming GPUs werden Chiplets vermutlich noch etwas länger auf sich warten lassen. Bis und mit der ersten 5nm Generation erwarte ich keine. Bei HPC Chips wird das aber vermutlich spätestens mit CDNA2 kommen (X3D wie am FAD gezeigt). Sobald man einen Interposer aufgrund HBM benötigt, ist der Grundaufwand eh schon gelegt. Ausserdem ist dein Punkt bezüglich Frontend und LLC-Cache weniger kritisch und HPC-Chips besitzen recht viel I/O, welches man in den (aktiven) Interposer verfrachten kann. Zudem gibt es im HPC Bereich nicht allzu viele SKUs, womit unnötiger "Verschnitt" nicht so oft auftreten sollte.

AMD hat X3D ja auch als Kombination von 2.5D als auch 3D Stacking und Chiplets angekündigt. Irgendwann wird man auch im Gaming Bereich auf HBM umschwenken müssen. Dann würden 1x Chiplet + 1x HBM Stack Module gut Sinn machen, welche wie bei den CPUs aus mehreren Modulen eine grosse GPU bilden. 40CU mit 4-8 GByte HBM3 @ 3.2 GT/s @ ca. 75W ergäbe ein noch relativ günstiges Konstrukt und ein sehr variables Portfolio. Skalierbar von Mobile bis High-End und Workstation, genau wie bei Zen. Bei Bedarf könnten auch 6-8 Module zusammengesteckt werden, wenn die Konkurrenzsituation oder eine Anwendung das verlangt. Die 40CU wären natürlich in 5nm und knapp 100mm2 gross und das meiste I/O liegt im Interposer. Ein Navi 14 + GDDR6 ist vermutlich ähnlich teuer in der Herstellung wie diese 100 + 50mm2 + Interposer + HBM.

Was man aber dennoch braucht: Ein I/O Die mit PCIe, Display Controller etc. weil diese Komponenten benötigt man nur 1x pro Grafikkarte. Dieser Chip wäre vielleicht 50mm2 in 7nm. Man würde dieses "Crossfire" Konstrukt aber definitiv neu erfinden müssen, damit das gut funktioniert.

[mksn7]

Ich glaube ein Design mit IO-Die braucht mehr Bandbreite zwischen den Chips. Zwischen IO-Die und Chiplets braucht es auf jeden Fall die gleiche Bandbreite wie die gesamte Bandbreite.


Im Fall ohne IO-Die, so wie bei Zen 1, hat man dann eine NUMA Situation. Hier und da lässt sich vielleicht mit der Lokalität was tricksen, so dass ein Chiplet eher auf den eigenen Speicher zugreift (Texturen auch mal duplizieren), aber im Allgemeinen muss man von random accesses ausgehen. Dann liest jedes Chiplet die Hälfte seiner Daten aus dem eigenen Speicher, die andere Hälfte vom anderen Speicher. Die Verbindung zwischen den Chips muss also in beide Richtungen jeweils halb so schnell sein wie die Speicherbandbreite eines Chiplets, also insgesamt so breit wie eins der Speicherinterfaces. Nachdem das Speicherinteface der Chiplets nur halb so breit wär wie das des IO-Dies, braucht es nur halb so viel Bandbreite zwischen Chips.

Bei GPUs ist der L2 Cache sowieso eng an die Speichercontroller gekoppelt. Jeder L2 slice cached genau das was zu dem dazugehörigen Speichercontroller gehört. Dadurch ist die Kohörenz einfach, weil die Daten nur in einem Cache liegen können. Dafür gehen remote L2 cache hits aber jedes Mal über den Bus zwischen den Chips. Die Speicherbandbreite für den remote L2 wäre dann halt nicht so toll.

In jedem Fall ist eine Verbindung zwischen zwei Chips im mehrere 100 GB/s wahrscheinlich recht Energiehungrig. Soll ja bei Epyc schon viel ausmachen, und da sind die Bandbreiten nicht so hoch.

Für HPC kommen Chiplet konstrukte sicher früher, weil es da einfacher ist auf Lokalität zu achten. Im einfachsten Fall so wie die K80, die sich als zwei GPUs ausgibt. HPC Codes sind eher auch mal für MultiGPU ausgelegt, da ist das einfacher.

[HOT]

Es wird sicherlich kein Produkt aus gleichen Chips, das halte ich für absurd, weil schreiend ineffizient. Wenn man sowas macht, braucht man den Interposer als Verbindung zwischen den einzelnen Einheiten, meinetwegen dem Frontend und mehreren Backends. Ob dann der Speicher und/oder andere I/O-Bereiche besser am Frontend oder am Backend sitzt ist dann ne Effizienzsache. Mit IF hätten die eh einen einzigen Adressraum, egal, wo der Speicher sitzt.
AMD setzt ja seit Vega IF für die intrachip-Kommunikation ein, jetzt würde man eben die Kommunikation ebenfalls über IF laufen lassen, nur eben über einen Interposer und nicht mehr auf dem monolithischen Design. Man könnte also sowas wie Zen2 machen, einen Frontend-Chip und meinetwegen 2-4 Backends. Da man sowieso Interposer verwendet, wird man gleichzeitig natürlich HBM verbauen. Die höheren Latenzen müsste man mit besseren Caches abfedern selbstverständlich, wo es nötig ist, denn viele Rechenoperationen auf dem Grafikchip sind die Latenzen ziemlich egal AFAIK. Das muss also nur für die kritischen gelten.

Die Vorteile einer solchen Lösung wären jedenfalls Wahnsinn. Man könnte 20 CU-Designs in 7nm machen und davon 4 an ein Frontend basteln. Die Chipkosten werden dadurch sicherlich mal eben halbiert. Hinzu käme noch, dass man später einfach in 5nm ein weiteres Backend mit 32CUs anbieten könnte, das die gleichen Ausmaße hat wie die 7nm-Backends und man so von 80 auf 128 CUs im Handstreich käme, nur durch neue Chiplets. Die Kartenhersteller müssten nicht mal neue PCBs machen, mehr Speicher kann AMD einfach über HBM realisieren, wenn nötig. Man könnte ein komplettes Portfolio von Mainsteam bis Enthusiast mit 2 unterschiedlichen Chiplets abdecken und einem kleinen bzw. großen Package und das später ganz simpel nach oben hin ergänzen mit nem neuen Chiplet. Das ist der feuchte Traum eines jeden Betriebswirtschaftlers.
Als I-Tüpfelchen kann man noch verschiedene Turbostufen für verschiedene Chiplets verwenden und das beste Chiplet am meisten nutzen.

[Iscaran]

Ah als Nachtrag zu meiner Raytracing von AMD wird anders implementiert sein These hier hab ich endlich die Beiträge gefunden die ich gesucht habe.

Die LocalRay-Technik, auf der CES im Januar von Bakalash und AdShir vorgestellt:
https://wccftech.com/localray-promises-cross-platform-raytracing-even-for-smartphones/

Laut Beyond3d hat AdShir auch schon einen Vertrag mit einem der NextGen Konsolenhersteller:
https://forum.beyond3d.com/threads/adshirs-localray-mobile-friendly-realtime-raytracing-solution-spawn.61541/


They said they have a contract with at least a console platform holder.


Laut diesem Interview haben sie sogar "multiple deals":https://venturebeat.com/2020/01/07/adshirs-localray-software-enables-real-time-ray-tracing-on-2-watt-smartphones/

Für eine derartige Implementation von Raytracing bräuchte man dann gar nicht so arg spezialisierte Hardware, man bräuchte vor allem eine gute Kontrolllogik um die "LocalRays" zu generieren und das ganze am besten maximal parallelisiert.

Ein weiterer Vorteil evtl. diese "Chiplet" GPU Ansatzes ? Man könnte die zentrale LocalRay-Einheit als "Controller" auffassen und diese verteilt die Arbeit dann z.B. Bildsegmentweise (z.b linkes oberes Bildviertel, rechtes unteres Bildviertel usw.) an die CU-Chiplets. Dort kann dann maximal parallel die Raytracisierung stattfinden.

[Berniyh]

Raytracisierung
Autsch … :freak:

[Unicous]

Warum nicht einfach Strahlenzeichnen?:freak:

[Berniyh]

trace bedeutet eher folgen oder verfolgen.
Strahlenverfolgung quasi.

Das oben tut halt weh, weil es echt eine komische Form von Denglisch ist.
Raytraycing ist schon ein substantiviertes Verb. Daraus dann wieder ein Verb und auch wieder ein substantiviertes Verb zu machen und das dann auch noch in einer denglischen Version ist halt schon eine Form von Mindfuck. xD

[Unicous]

Es war ein Witz. trace kann auch (nach)zeichnen heißen.:wink:

[gravitationsfeld]

Tut es hier aber nicht.

[Unicous]

Vielen Dank, Captain Obvious.:eek:

[gedi]

Wird AMDs RT überhaupt Kompatibel zu NV-RTX sein? Wenn nein, könnte dies ein Grund für die vielen Absagen an GeForce Now bedeuten. Denn was auf der Konsole läuft..,

[Unicous]

Was hat das eine mit dem anderen zu tun? Warum muss AMD mit Nvidia kompatibel sein?:confused:

AMD ist kompatibel mit DXR, Nvidia auch. Das ist der common ground auf dem man sich bewegen sollte.

Dass fast alle von Geforce Now abspringen hat monetäre Gründe. Die Publisher wollen doppelt kassieren. Nvidia macht nicht mit. Außerdem haben die eh ihre eigenen Streaming-Angebote in Entwicklung.

Leider wird Geforce Now so nicht überleben können und dies mal ist nicht einmal Nvidia mit ihrem Geschäftsgebahren wirklich selbst daran schuld sondern die Gier der Publisher.:freak:

[SKYNET]

Was hat das eine mit dem anderen zu tun? Warum muss AMD mit Nvidia kompatibel sein?:confused:

AMD ist kompatibel mit DXR, Nvidia auch. Das ist der common ground auf dem man sich bewegen sollte.

Dass fast alle von Geforce Now abspringen hat monetäre Gründe. Die Publisher wollen doppelt kassieren. Nvidia macht nicht mit. Außerdem haben die eh ihre eigenen Streaming-Angebote in Entwicklung.

Leider wird Geforce Now so nicht überleben können und dies mal ist nicht einmal Nvidia mit ihrem Geschäftsgebahren wirklich selbst daran schuld sondern die Gier der Publisher.:freak:

Was aber total dämlich ist, kannst die games ja eh nzr zocken wenn du sie schon gekauft hast...

[Unicous]

Was ist daran dämlich den Kunden zweimal löhnen zu lassen?:freak:

https://i.kym-cdn.com/photos/images/newsfeed/001/490/511/148.jpg

[robbitop]

So wie die Vorposter schreiben: es gibt Schnittstellen, die funktionieren müssen. Was die HW und der Treiber tun ist für uns egal.
So ist es ja auch beim Rest der Implementierung von 3D Rendering, Texturfilterung, Shading etc. RT ist in der Hinsicht nicht anders. DXR und Vulkan RT werden angesprochen.

[Berniyh]

AMD ist kompatibel mit DXR, Nvidia auch. Das ist der common ground auf dem man sich bewegen sollte.
Ich bezweifle, dass die PS5 DXR unterstützen wird.

[Unicous]

Wen interessieren Konsolen?:confused: Die machen doch eh ihr eigenes Ding.

Was Sony nutzt ist doch völlig Wurscht. Sie könnten sogar Vulkan nutzen, was gar keine so unkluge Idee ist.:uponder:

Wenn erfolgreiche Spiele geported werden (wie z.B. Horizon Zero Dawn aktuell) wird man schon Mittel und Wege haben, RT zu implementieren.

MS hat den Vorteil, dass sie ihr Windows Ökosystem pushen, aber Sony hat den Vorteil, des größeren mind share.

CDPR konnte sogar Witcher auf die Switch portieren, oder Bethesda Doom.

Wenn sich der Aufwand lohnt gibt es Mittel und Wege.

[basix]

Ich bezweifle, dass die PS5 DXR unterstützen wird.

Aber die HW wird vermutlich nahe dran sein.

[Berniyh]

Wen interessieren Konsolen?:confused: Die machen doch eh ihr eigenes Ding.
Die Entwickler aber nicht (wenn sie nicht müssen).
Was Sony nutzt ist doch völlig Wurscht. Sie könnten sogar Vulkan nutzen, was gar keine so unkluge Idee ist.:uponder:
Würde ich auch als sinnvoll ansehen, zumal schon so einige Engines Vulkan unterstützen.
Aber Sony wäre ja nicht Sony, wenn … ihr wisst schon worauf das hinaus läuft. :rolleyes:

Ich persönlich schätze aber eh, dass Raytracing auch in 1-2 Jahren noch kaum mehr als ein Showcase sein wird.
Mir ist das Thema auch viel zu sehr gehyped für den (optischen) Vorteil den es bringt.
Aber die HW wird vermutlich nahe dran sein.
Naja, prinzipiell dürfte DXR auch auf einer Vega oder Polaris zum Laufen zu bekommen sein.

Was man so liest wird sich die HW bei AMD aber von Nvidia (zumindest in der RTX 20xx Form) doch deutlich unterscheiden.
Inwieweit es da Überschneidungen geben wird muss man abwarten.

[Unicous]

Die Entwickler kotzen doch fast immer wenn es um eine neue Konsolengeneration geht und deren Dokumentation, die API und die Limitierungen. Am Ende schaffen sie es dann doch.:wink:

Ich persönlich sehe RT in der derzeitigen Form auch nicht als den Heilsbringer. Aber wir werden sehen wie sich das in den nächsten zwei, drei Jahren entwickelt.
Die ganze Debatte erinnert mich an die Tessellation-Kontroverse über die Jahre. Nvidia hat ihre Chips aufgepumpt und am Ende hatte man einen tesselierten Betonblock den man bewundern durfte.:wink:


Was ich bislang so lese zu RT@Konsolen/RDNA2 sind konstruierte Gerüchte, dass AMD nur eine Sparflammen RT-Variante bringen soll, weil natürlich niemand an Nvidia herankommt und sie deswegen tricksen müssen um RT performant realisieren zu können.:rolleyes:

Ich glaube es hatte etwas mit einer Firma oder einem Patent zu tun, dass RT in cheap berechnet und sie haben eine Verbindung zu AMD oder den Konsolen gezogen.

[Berniyh]

Meint ihr AMD könnte bei RDNA2 für die verschiedenen Chips unterschiedliche Nodes verwenden?
Mal angenommen Navi21 ist High-End und Navi23 ist Mid-Range, dann also Navi21 in N7+ (also EUV), aber Navi23 in N7P (als DUV)?
Wäre durchaus denkbar wenn N7+ noch arg teuer ist und die Kapazitäten etwas knapp?

Bei Zen3 kann ich mir das hingegen nicht vorstellen, da reichen so wenig Wafer um praktisch alles an notwendigen Chiplets abzudecken.

[robbitop]

Konsolen supporten wieder ihre eigenen APIs.

[gravitationsfeld]

Also ich will definitiv kein Vulkan fuer die Playstation. Optional vielleicht, aber die meisten wuerden eh die native API benutzen.

[basix]

Meint ihr AMD könnte bei RDNA2 für die verschiedenen Chips unterschiedliche Nodes verwenden?
Mal angenommen Navi21 ist High-End und Navi23 ist Mid-Range, dann also Navi21 in N7+ (also EUV), aber Navi23 in N7P (als DUV)?
Wäre durchaus denkbar wenn N7+ noch arg teuer ist und die Kapazitäten etwas knapp?

Bei Zen3 kann ich mir das hingegen nicht vorstellen, da reichen so wenig Wafer um praktisch alles an notwendigen Chiplets abzudecken.

Zen wird vermutlich immer den latest and greatest Node verwenden. Bei den GPUs denke ich, wird die jeweilige RDNAx Stufe keinen Prozessrefresh erhalten. Das Design und der Prozess sind Co-Engineered. Wenn du innerhalb der Familie unterschiedliche Prozesse hast, wird das viel aufwändiger, da man andere Designrules etc. anwenden muss.

Deswegen:

RDNA = 7nm
RDNA2 = 7nm "enhanced"
RDNA3 = "advanced node"


RDNA2 wird vermutlich Top to Bottom inkl. APUs ausgerollt werden (mit Zen 3). Was aber passieren könnte: GPUs der Vorgängergeneration ergänzen den Produktstack hier und da. Evtl. ähnlich wie es momentan bei Zen 2 vs. Zen/Zen+ läuft.

[horn 12]

https://www.youtube.com/watch?time_continue=122&v=B9hLFeh-gEI&feature=emb_logo

Wirklich Beeindruckend, und auf RDNA 2 soll dies laufen, also min.. XBOX mit den 12 Tflops

[crux2005]

https://www.youtube.com/watch?time_continue=122&v=B9hLFeh-gEI&feature=emb_logo

Wirklich Beeindruckend, und auf RDNA 2 soll dies laufen, also min.. XBOX mit den 12 Tflops

Wie bitte?

Es läuft auf einem:
R.O.G Laptop, DX11, non-rtx GPU 1080MaxQ

und sehe nur Reflexionen für die er DXR benutzt.

[TheGood]

Die Entwickler kotzen doch fast immer wenn es um eine neue Konsolengeneration geht und deren Dokumentation, die API und die Limitierungen. Am Ende schaffen sie es dann doch.:wink:

Ich persönlich sehe RT in der derzeitigen Form auch nicht als den Heilsbringer. Aber wir werden sehen wie sich das in den nächsten zwei, drei Jahren entwickelt.
Die ganze Debatte erinnert mich an die Tessellation-Kontroverse über die Jahre. Nvidia hat ihre Chips aufgepumpt und am Ende hatte man einen tesselierten Betonblock den man bewundern durfte.:wink:


Was ich bislang so lese zu RT@Konsolen/RDNA2 sind konstruierte Gerüchte, dass AMD nur eine Sparflammen RT-Variante bringen soll, weil natürlich niemand an Nvidia herankommt und sie deswegen tricksen müssen um RT performant realisieren zu können.:rolleyes:

Ich glaube es hatte etwas mit einer Firma oder einem Patent zu tun, dass RT in cheap berechnet und sie haben eine Verbindung zu AMD oder den Konsolen gezogen.

Die einzig relevante Frage ist doch, ob AMD alle Raytracing Use Cases untersrtützt oder nur z.b. die Schattenberechnung usw. Ich glaube am Ende wird es sich darauf reduzieren.
GGf. machen sie auch was völlig neues, denn die DXR Api von Microsoft anpassen zulassen, wenn ich auch den Unterbau für deren Konsole mache ist ja wohl easy. Dann allerdings weiss Nvidia jetzt schon bescheid wie die Implementierung aussehen wird.
Vielleicht sind sie deshalb vielleicht "nur" auf dem 8nm prozess von Samsung.

[JVC]

´...Dann allerdings weiss Nvidia jetzt schon bescheid wie die Implementierung aussehen wird.
Vielleicht sind sie deshalb vielleicht "nur" auf dem 8nm prozess von Samsung.
Soviel ich weis ist es ein 10nm+++...
Und zu Samsung sind sie vermutlich wegen einem guten Deal = mehr Gewinn für NV...
(man munkelt auch das AMD bei TSMC zu gut den Fuß in der Tür hat und einfach zu wenig Platz daneben für NV ist)

Das ist eventuell die Chance für AMDs "Big-Navi" vielleicht doch noch ganz vorne mit zu spielen.
(vielleicht wusste auch AMD, das NV "nur" auf "10nm" geht ?)

M.f.G. JVC

[robbitop]

Die einzig relevante Frage ist doch, ob AMD alle Raytracing Use Cases untersrtützt oder nur z.b. die Schattenberechnung usw. Ich glaube am Ende wird es sich darauf reduzieren.
GGf. machen sie auch was völlig neues, denn die DXR Api von Microsoft anpassen zulassen, wenn ich auch den Unterbau für deren Konsole mache ist ja wohl easy. Dann allerdings weiss Nvidia jetzt schon bescheid wie die Implementierung aussehen wird.
Vielleicht sind sie deshalb vielleicht "nur" auf dem 8nm prozess von Samsung.

Wofür RT genutzt wird, entscheidet der Entwickler selbst. Je nach Content oder Performance Budget. Die Funktionsweise von RT ist mWn gleich.
Und wenns dafür eine Schnittstelle gibt, für die es einen Treiber und eine HW gibt, dann ist auch eine HW Beschleunigung dafür da. Entsprechend kann der Entwickler dann diese so nutzen, wie es ihm beliebt.

Das ist völlig analog dazu ob du Pixelshader für Schattem, Beleuchtung, Reflektion oder Bumpmapping nutzt. Oder zu allem. In den frühen 2000ern als programmierbare Pixelshader gerade in der ersten Generation waren, musste man sich das aus Performancegründen auch noch genau überlegen. Aber man hätte es auch für alles einsetzen können... :)

[pixeljetstream]

Wofür RT genutzt wird, entscheidet der Entwickler selbst. ...
+1

Das neue an DXR 1.1 ist, dass jeder shader typ "einfache" Strahltests durchführen kann. Damit kann man es für einfache Dinge leichter überall nutzen, und für komplexere Situationen eigene Shading Systeme entwickeln. Am PC ist letzteres nicht ganz so einfach weil es nicht so viele Möglichkeiten gibt standardisiert das shader setup/scheduling von der GPU als Entwickler zu beeinflussen (die Hardware in beiden Lagern kann es aber seit Ewigkeiten), auf Konsolen ist dies durch den direkten Zugriff aber gegeben, weswegen ich davon ausgehe dass man das hier vermehrt machen wird.
Sobald sich dann ein gewisses Schema ergibt und ein Druck entsteht, wird imo PC nachziehen, iOS Metal hat solche features schon, und NV hat das auch unter Vulkan zum Teil experimentell veröffentlicht. CUDA bzw. OpenCL 2 haben auch paar Techniken die sowas erlauben, wobei nicht direkt in dem Maße wie es für games/real-time nötig wäre.

[TheGood]

+1

Das neue an DXR 1.1 ist, dass jeder shader typ "einfache" Strahltests durchführen kann. Damit kann man es für einfache Dinge leichter überall nutzen, und für komplexere Situationen eigene Shading Systeme entwickeln. Am PC ist letzteres nicht ganz so einfach weil es nicht so viele Möglichkeiten gibt standardisiert das shader setup/scheduling von der GPU als Entwickler zu beeinflussen (die Hardware in beiden Lagern kann es aber seit Ewigkeiten), auf Konsolen ist dies durch den direkten Zugriff aber gegeben, weswegen ich davon ausgehe dass man das hier vermehrt machen wird.
Sobald sich dann ein gewisses Schema ergibt und ein Druck entsteht, wird imo PC nachziehen, iOS Metal hat solche features schon, und NV hat das auch unter Vulkan zum Teil experimentell veröffentlicht. CUDA bzw. OpenCL 2 haben auch paar Techniken die sowas erlauben, wobei nicht direkt in dem Maße wie es für games/real-time nötig wäre.

Das bringt alles nichts, wenn die HARdware es nicht schnell genug unterstützt. GGf. ist es ja so, dass nicht alle Use Cases vollständig in HArdware unterstützt werden und damit ist auch klar, welche Effekte wann wie eingesetzt wird. ICh vermute aber mal dass meine Annahme da schon grundlegen falsch ist ;) Ihr könnt mich da ja gerne korrigieren.

[aufkrawall]

Wäre allerdings nicht das erste Mal, wenn AMD mit kleiner Chipfläche sehr viel untergebracht bekommt.

[gedi]

Wäre allerdings nicht das erste Mal, wenn AMD mit kleiner Chipfläche sehr viel untergebracht bekommt.

Japp, alles gut. Ich dachte ich hätte schon dümmeres gelesen, aber nein, du schießt ihn mal wieder ab, den Vogel 😊

[Piefkee]

https://www.chiphell.com/thread-2199812-1-1.html

RDNA2 und Zen 3 Release im Oktober 2020
Übersetzt „verlässliche Quelle“

[BoMbY]

Ja, nicht unmöglich. Aber wenn überhaupt ist das jetzt ehh nur ein vorläufiger Termin.

[Unicous]

Ist halt in dem Sinne verwirrend, da AMD explizit "end of year" sagte und Q3 nicht end of year ist.

Zudem wird hier behauptet, dass Nvidia auf AMD wartet und erst im Q4 neue Consumer GPUs veröffentlichen wird.

https://www.ptt.cc/bbs/PC_Shopping/M.1584077954.A.606.html

Navi22 wird auch erwähnt, Google Translate macht daraus zwar fast nur Müll, aber zumindest das mit Nvidia ist relativ eindeutig.

[Piefkee]

Ist halt in dem Sinne verwirrend, da AMD explizit "end of year" sagte und Q3 nicht end of year ist.

Zudem wird hier behauptet, dass Nvidia auf AMD wartet und erst im Q4 neue Consumer GPUs veröffentlichen wird.

https://www.ptt.cc/bbs/PC_Shopping/M.1584077954.A.606.html

Navi22 wird auch erwähnt, Google Translate macht daraus zwar fast nur Müll, aber zumindest das mit Nvidia ist relativ eindeutig.

Naja aber Oktober 2020 ist Q4 ;D

[crux2005]

So viel dazu das "late this year" nicht Q4 ist.

[TheGood]

So viel dazu das "late this year" nicht Q4 ist.
auch für die die es nicht kapieren wollen. ES hies übrigens "later this year"
Es heisst schlicht irgendwann/später in diesem Jahr. Es ist ein völlig unbestimmter Zeitpunkt. Theoretisch hätte das auch Q2 sein können...

[Benutzername]

auch für die die es nicht kapieren wollen. ES hies übrigens "later this year"
Es heisst schlicht irgendwann/später in diesem Jahr. Es ist ein völlig unbestimmter Zeitpunkt. Theoretisch hätte das auch Q2 sein können...

Oder Silvester. ;)

[SKYNET]

auch für die die es nicht kapieren wollen. ES hies übrigens "later this year"
Es heisst schlicht irgendwann/später in diesem Jahr. Es ist ein völlig unbestimmter Zeitpunkt. Theoretisch hätte das auch Q2 sein können...


wilde theorie: big navi ist schon fertig, und man wartet nur auf ampere :freak:

[tEd]

wilde theorie: big navi ist schon fertig, und man wartet nur auf ampere :freak:

..oder die treiber brauchen noch ein paar Monate :freak:

[JVC]

Oder die Virusprobleme sind schon inklusive...

M.f.G. JVC

[Digidi]

Die Präsentation war vor 1 Woche. Nach Stand heute kommt neue GPUs wohl erst mitte 2021. Corona sei Dank.

Zurzeit geht nichts mehr! Ganze Teams in verschiedenen Bereichen werden aus Vorsorge heimgeschickt. Ganze Lieferketten stehen still. Wer glaubt das dieses Jahr noch was kommt hat die Realität verkannt.

[Unicous]

Hast du auch schon Klopapier und Dosenravioli gebunkert?:ucrazy2:

[Digidi]

Hast du auch schon Klopapier und Dosenravioli gebunkert?:ucrazy2:

Nein aber ein Freund ist in der Welt ganz gut Vernetzt. Zurzeit haben viele Unternehmen Probleme Ressourcen zu bekommen. Wiederstände und Kondensatoren werden in China gebaut. Da läuft noch lange nicht alles Rund und auch die anderen Länder haben mit Covid-19 noch ganz schön zu kämpfen.

Ich gehe mal davon aus das wir noch nächste Woche den totalen Shut Down von Deutschland sehen und 1-2 Wochen später in den USA und in Afrika ist das Virus auch noch nicht angekommen.

[Unicous]

Und ein Freund eines Freundes sagte mir, dass Big Navi erst 2022 kommt weil der Lötstopplack ausgegangen ist.:eek:

[Digidi]

Na wirst schon sehen Unicous....

Wer jetzt noch glaubt Massen an Luxusgütern produzieren zu können, der hat den schuss nicht gehört. Dank Schlanker Produktion und Taylorismus sind Lieferkennt und Forschungsabteilungen mitlerweile extrem empfindlich wenn nur ein Sublieferant mal für nur ein paar Tagen zu macht.

[Berniyh]

Nein aber ein Freund ist in der Welt ganz gut Vernetzt. Zurzeit haben viele Unternehmen Probleme Ressourcen zu bekommen. Wiederstände und Kondensatoren werden in China gebaut. Da läuft noch lange nicht alles Rund und auch die anderen Länder haben mit Covid-19 noch ganz schön zu kämpfen.

Ich gehe mal davon aus das wir noch nächste Woche den totalen Shut Down von Deutschland sehen und 1-2 Wochen später in den USA und in Afrika ist das Virus auch noch nicht angekommen.
Das stimmt schon, aber ein halbes Jahr Verzögerung wird es dadurch nicht zwingend geben.
In China waren es jetzt ungefähr 1.5-2 Monate in denen nichts ging. Die werden aber bald wieder relativ normal arbeiten.
Mit max. einem Quartal zu rechnen ist also realistisch.

Natürlich hängt das aber auch davon ab wie schnell andere Länder ihren Teil der Krise bewältigen.

[Leonidas]

Ist halt in dem Sinne verwirrend, da AMD explizit "end of year" sagte und Q3 nicht end of year ist.


Können wir das für Zen 3 & Navi 2X noch einmal eindeutig nachstellen, was AMD da nun wirklich gesagt hat? "late year" oder "later this year"?

[Berniyh]

Selbst wenn es "later" war muss das nicht zwingend was heißen, bei so einem Vortrag verspricht man sich auch schnell mal, gerade bei so Kleinigkeiten.

Bei Zen waren es bislang immer grob 14 Monate zwischen zwei Releases.
07/2019 + 14 Monate ist 09/2020. Dann noch 1-2 Monate Corona oben drauf und man ist bei Oktober bis Dezember.
Abgesehen von dem Random Gelabor eines Users hier neulich gibt es einfach keine Anzeichen dafür, dass an der Stelle etwas signifikant früher passiert, oder?

[[MK2]Mythos]

Die Präsentation war vor 1 Woche. Nach Stand heute kommt neue GPUs wohl erst mitte 2021. Corona sei Dank.

Zurzeit geht nichts mehr! Ganze Teams in verschiedenen Bereichen werden aus Vorsorge heimgeschickt. Ganze Lieferketten stehen still. Wer glaubt das dieses Jahr noch was kommt hat die Realität verkannt.
Das würde ja bedeuten dass man jetzt schon die Karten produzieren würde, was allerdings unwahrscheinlich ist wenn sie für ca Oktober anvisiert sind. Insofern kann es zur Zeit gerade keine nennenswerte Verzögerung auf Grund von Materialknappheit geben.

[HOT]

Man wird auf so ner Veranstaltung grundsätzlich von "later this year" sprechen, um sich alle Optionen offen zu halten. Das war ja ne Finanzveranstaltung.

Nichtsdestotrotz ist klar, dass Zen3 eh im Oktober erscheint (meine Prognose war September) und es ist sinnvoll, RDNA2 da gleich mit zu launchen, so wie Navi eben bei Zen2 gelauncht wurde - es wäre auch bei den Enthusiasts alles aus einer Hand verfügbar. Und mMn wird Zen3 ja auch recht klar die Führung übernehmen ggü. Comet Lake, Rocket Lake ist ja nicht vor Mitte 2021 zu erwarten nach den ganzen Verschiebungen bei Intel.

[Palpatin]

und in Afrika ist das Virus auch noch nicht angekommen.
Was soll er den in Afrika auch groß anrichten, dort gibt es keine Risikogruppe.
Bevölkerung über 64 in Afrika 3% ....

[Brillus]

Was soll er den in Afrika auch groß anrichten, dort gibt es keine Risikogruppe.
Bevölkerung über 64 in Afrika 3% ....

Dafür aber massiver Mangel an Beatmunggeräten, sobald die Fehlen schiesst die Sterblichkeit hoch gesehen in China und in Italien. 15% brauchen Stazionäre Behandlung lass das mal wegen jünger nur 10% sein. Mich würde eine höhere Sterblichkeit als in Europa nichtmal wundern.

[JVC]

Was soll er den in Afrika auch groß anrichten, dort gibt es keine Risikogruppe.
Bevölkerung über 64 in Afrika 3% ....
Etwas sehr kurz gedacht...
Ich bin keine 50 und gehöre zur Risikogruppe (Asthma).

M.f.G. JVC

[Piefkee]

Xbox Series X Technical Date

https://news.xbox.com/en-us/2020/03/16/xbox-series-x-tech/amp/?__twitter_impression=true


Besonders interessant ist, dass das Netzteil nur 300Watt hat

[Troyan]

Ein bisschen was über Hardware-RT: https://youtu.be/qcY4nRHapmE?t=581

Ich weiß nicht, ob Digitalfoundry das richtig verstanden hat... Aber wenn die Hardware-Beschleunigung "nur" 13TFLOPs entspräche, wäre dies gerade mal 1/4 der RT Cores von nVidia.

[dildo4u]

Unwahrscheinlich Minecraft läuft flüssig und nutzt volles Path Tracing was vermutlich so teuer wie Quake RTX ist.

[Troyan]

1080p/60FPS + Skalierung auf 4K ist auch flüssig.

Laut Microsoft wird der Raytracing-Workload von der Abarbeitungszeit halbiert ("zusätzliche 13TFLOPs"). Laut nVidia reduzieren die RT Cores in Metro den RT-Workload um Faktor 10x:

When we enable the dedicated RT Cores on GeForce RTX GPUs, a substantial load is lifted from the shader cores, further improving performance. And when we examine just the ray tracing subset of the graphics workload, RTX 2080 is upwards of 10x faster.
https://www.nvidia.com/en-us/geforce/news/geforce-gtx-ray-tracing-coming-soon/

[dildo4u]

1080p60fps wäre 2080 Performance passt also.


https://www.golem.de/news/benchmarks-von-quake-2-rtx-spieglein-an-der-wand-im-raytracing-land-2001-145968.html

[Unicous]

Können wir das für Zen 3 & Navi 2X noch einmal eindeutig nachstellen, was AMD da nun wirklich gesagt hat? "late year" oder "later this year"?

Anfangs wurde "later this year" gesagt. Im Laufe der Präsentationen ist es dann auf "end of this year" und sogar "late this year" umgeschwungen. Milan shipped "late this year".

"end of this year" dürfte Q4 bedeuten, wurde iirc für Navi genannt, late this year deutet auf Dezember hin.

[dildo4u]

Warum beißt ihr euch an diesen Aussagen fest,dort war noch gar nicht das komplette Ausmaß des Virus absehbar wie es Heute aussieht weiß keiner.
Es sollte Heute z.b unabhängige Ryzen 4000 Notebooks Benches geben was ausfällt wegen dem Virus.

[Berniyh]

hm, interessant, dass die XBOX in N7P gefertigt wird.
Ob das dann auch für andere RDNA2 Chips gilt?

[Piefkee]

hm, interessant, dass die XBOX in N7P gefertigt wird.
Ob das dann auch für andere RDNA2 Chips gilt?

Quelle?
Ich seh nur 7nm enhanced. Kann 7P oder 7+ sein.

[Berniyh]

steht in der 3DC News. Keine Ahnung ob das stimmt, mehr hab ich bislang nicht gelesen.

[y33H@]

Wäre es N7+ EUV würde man sicherlich damit werben.

[SKYNET]

Was soll er den in Afrika auch groß anrichten, dort gibt es keine Risikogruppe.
Bevölkerung über 64 in Afrika 3% ....

dafür 4 von 5 unterernährt und somit nen mieses immunsystem, 1/5 hat HIV(dunkelziffer) ohne behandlung... und dann gibts da auch noch diverse andere krankheiten... corona in afrika dürfte wohl auf die einwohneranzahl gerechnet, die höchste todesrate haben.

[Piefkee]

Wäre es N7+ EUV würde man sicherlich damit werben.

Richtig. Da aber AMD selber im Finacial Day von 7nm Enhanced spricht, bin ich mir nicht wirklich sicher. Zen3 war früher 7nm+ und jetzt da TSMC selber nur noch von Enhanced spricht, keine Ahnung was das jetzt genau ist. Daher wäre ich erstmal vorsichtig ob das nun 7NP oder 7N+ ist. Sind beide laut TSMC Enhanced 7N.

[Berniyh]

Richtig. Da aber AMD selber im Finacial Day von 7nm Enhanced spricht, bin ich mir nicht wirklich sicher. Zen3 war früher 7nm+ und jetzt da TSMC selber nur noch von Enhanced spricht, keine Ahnung was das jetzt genau ist. Daher wäre ich erstmal vorsichtig ob das nun 7NP oder 7N+ ist. Sind beide laut TSMC Enhanced 7N.
Leo bezieht sich hier wohl auf (den von MS selbst verlinkten) Artikel von eurogamer.net:
https://www.eurogamer.net/articles/digitalfoundry-2020-inside-xbox-series-x-full-specs
Hier steht drin:
The processor is fabricated on an enhanced rendition of TSMC's 7nm process, which we understand rolls up a bunch of improvements to the technology, right up to but not including the new EUV-based 7nm+.
Das klingt so ein bisschen als hätten sie da die Info bekommen, dass EUV nicht verwendet wird, aber sicher kann man da natürlich auch nicht sein.
evtl. ist es auch nur Spekulation.

Würde aber ein bisschen zu AMDs Aussage passen, dass man im Einzelfall entscheidet welchen Prozess man nutzt.
evtl. gibt es einfach nicht genug EUV Kapazität um die Chips für AMD/MS zu fertigen.

[Iscaran]

N7P bzw. N7 Enhanced ist klar was anderes als N7+ bzw. N7 plus
https://en.wikichip.org/wiki/7_nm_lithography_process#N7P
"In 2019 TSMC introduced a 2nd-generation N7 process called N7 Performance-enhanced (N7P). N7P is an optimized version of TSMC N7 process. to that end, it remains a DUV-based process, keeping the same design rules and is fully IP-compatible with N7. N7P introduces FEOL and MOL optimizations which are said to translate to either 7% performance improvement at iso-power or up to 10% lower power at iso-speed. "

N7P (performance enhanced) ist eine optimierte Version von N7 und nutzt DUV-Technik.

"The N7+ node is TSMC's first process technology to adopt EUV lithography. It is unrelated to N7 nor N7P and is not IP-compatible with either, requiring re-implementation (new physical layout and validation)."

N7+ ist eine völlig neue Technik und nutzt EUV.

AMD selbst hatte bei den Folien zu Ryzen zwar dieses 7nm+ stehen. Meinte damit aber eben nur einen verbesserten 7nm Prozess. Und nicht das was TSMC neuerdings mit 7nm+ als EUV Technik eingeführt hat.

AMD hat dies selbst gegenüber Anand so bestätigt und deswegen die neueren Folien alle anders beschriftet.
https://www.anandtech.com/show/15589/amd-clarifies-comments-on-7nm-7nm-for-future-products-euv-not-specified

Daher würde ich mal davon ausgehen das das der N7P Prozess ist und entsprechend die XBOX in N7P gefertigt sein dürfte. Navi 1x (RDNA 1) wurde ja in N7 gemacht. Es wäre hier durchaus logisch RDNA2 in N7P zu bringen. Der XBox Chip dürfte der erste RDNA 2 Chip sein der rauskommt.

[Leonidas]

Das bedeutet auch, das zumindest für den XBSX-SoC der Flächenvorteil einer besseren Fertigung fehlt - den gibt es nur bei N7+. Dies macht die 360mm² mit 56 CU (!) samt 320 Bit Interface und 8C-Zen2-CPU um so beeindruckender.

Dies bedeutet aber auch, das RDNA2 vermutlich weiterhin in N7P kommt und es dort auch keinen Flächenvorteil gibt.

[Locuza]

[...]
Daher würde ich mal davon ausgehen das das der N7P Prozess ist und entsprechend die XBOX in N7P gefertigt sein dürfte. Navi 1x (RDNA 1) wurde ja in N7 gemacht. Es wäre hier durchaus logisch RDNA2 in N7P zu bringen. Der XBox Chip dürfte der erste RDNA 2 Chip sein der rauskommt.
Laut David Shor meinte AMD das Navi10 schon unter N7P hergestellt wird:
I suspect AMD confirmed verbally to you that they are using N7P for Navi1X/RDNA1 since they only mention 7nm in their ISSCC2020 slides?
Yes, it's also explicitly stated in the paper.
https://twitter.com/david_schor/status/1235731985475096576
https://fuse.wikichip.org/wp-content/uploads/2020/02/amd-5700-navi.png
https://fuse.wikichip.org/news/3331/radeon-rx-5700-navi-and-the-rdna-architecture/

N7 wurde vielleicht nur für Vega20 verwendet?

[Berniyh]

Dies bedeutet aber auch, das RDNA2 vermutlich weiterhin in N7P kommt und es dort auch keinen Flächenvorteil gibt.
hm, also wenn das der Fall wäre und vor allem – wie im Post oben dargestellt – Navi1x auch schon in N7P produziert wird, dann würde das die angeblichen 50% Effizienzvorteil von RDNA2 ja in einem übelst großem Sprung im Sinne von Architekturverbesserungen darstellen lassen.

Insofern kommt für mich doch schon die Frage (wieder) auf, ob nicht evtl. manche RDNA2 Chips in N7+ mit EUV gefertigt werden.

[robbitop]

@RDNA2
Ich tippe darauf (nachdem was aus dem DF Video zu sehen war) dass:
1.) nicht so viel mehr Transistoren / Flop benötigt werden (sonst würden kaum 56 CUs in den 360 sqmm Kern passen)
2.) die IPC nicht stark steigt (Gears 5 erzielte bei gleichen Settings etwa 2080 Niveau - ja unoptimiert - aber auf dem PC wird auch nicht sooo großartig optimiert - 10 TF vs 12 TF - das sieht jetzt im ersten Moment (wobei das noch keine gute Basis ist) noch nicht nach einer Steigerung aus
3.) Energieeffizienz steigt jedoch (>1800 MHz bei 56 CUs und die Kühlung für den Gesamt SoC sieht jetzt nicht extrem aus)
4.) Featureset wird absolut modern (VRS, Meshshading, RT Beschleunigung)

Insgesamt also sehr, sehr gut. Außerdem dürfte es wirklich schwierig sein, ausgehend von der bereits sehr hohen IPC von Navi und Turing da noch richtig was draufzulegen. Ggf. wird das dann so teuer, dass die Erhöhung der CU Anzahl sinnvoller war.

Bis auf Punkt 4 ist das natürlich wackelig - aber das gilt ja für nahezu alle Spekulationen. :)

[Iscaran]

Laut David Shor meinte AMD das Navi10 schon unter N7P hergestellt wird:

N7 wurde vielleicht nur für Vega20 verwendet?

Oh - das ist in der Tat interessant. Hätte gedacht Navi wäre N7.
Ja dann muss wohl nur Vega20 in N7 gewesen sein. Da aber TSMC explizit davon spricht das die N7 Prozesse quasi direkt für N7P verwendet werden können ist das durchaus plausibel, dass AMD hier direkt für Navi/RDNA 1 schon auf N7P gewechselt ist.


Dies bedeutet aber auch, das RDNA2 vermutlich weiterhin in N7P kommt und es dort auch keinen Flächenvorteil gibt.


In der Tat.


Navi1x auch schon in N7P produziert wird, dann würde das die angeblichen 50% Effizienzvorteil von RDNA2 ja in einem übelst großem Sprung im Sinne von Architekturverbesserungen darstellen lassen.


Ja - das hatte AMD ja auch angedeutet in der PK zum Release der neuen Notebook APUs, das man hier nochmal durchaus rein architekturiell einen großen Sprung erwarten sollte.

[HOT]

Wann ist N7P denn wohl in Massenproduktion gegangen? Muss ja dann vor April 2019 gewesen sein. N7+ ist erst im Oktober AFAIK in Massenproduktion gegangen. Der Kirin 990 5G (nicht Kirin 990! der ist N7P) wird ja erst seit recht kurzer Zeit verbaut mein ich.
N7 Enhanced kann dann ja nur N7+ oder N6 sein, N6 ist aber noch zu weit weg, also bleibt nur der aktuellste verfügbare Prozess und das ist N7+.


robbitop
Da kann ich voll mitgehen. Das wird mMn ziemlich ins Schwarze treffen.

[Sunrise]

hm, also wenn das der Fall wäre und vor allem – wie im Post oben dargestellt – Navi1x auch schon in N7P produziert wird, dann würde das die angeblichen 50% Effizienzvorteil von RDNA2 ja in einem übelst großem Sprung im Sinne von Architekturverbesserungen darstellen lassen.

Insofern kommt für mich doch schon die Frage (wieder) auf, ob nicht evtl. manche RDNA2 Chips in N7+ mit EUV gefertigt werden.
Wollte gerade exakt das Gleiche schreiben. Tja, dann hatte ich und andere AMD eben doch richtig beim Analyst Day verstanden. RDNA2 macht einen satten Architektur-Sprung nach vorne, und zwar aufgrund diverser Faktoren, die ja auch in den Folien genannt wurden. Man kann sich jetzt sicherlich weiter streiten, ob man gewisse Optimierungen (Logic Enhancements, bzw. Optimierungen beim physikalischen Routing, inkl. Power) der Architektur zuordnet, oder ob man das eher als RDNA1.5 verstehen sollte (siehe Pascal), aber das was AMD hier zusätzlich integriert und dieses Mal scheinbar wirklich hart am Limit der Prozesse arbeitet (Susanne Plummer sagte es ja, da wurde richtig Zeit investiert...) zusammen mit dem recht aggressiven Fahrplan, zusätzlich dann RT und die weiteren unterstützten Features...das beeindruckt dann doch wirklich enorm.

Wegen EUV:
Diese Unsicherheit war ja von Anfang an da. DUV war viel früher verfügbar und ist auch noch billiger, vor allem da EUV deutlich Output-limitierter ist. Das wird schon die gewichtige Rolle bei der Entscheidung gespielt haben. Bei richtig großen GPUs erwarte ich eher, dass sich EUV rechnet, da der Yield stark ansteigen sollte, und die höheren Kosten von den hohen Margen besser abgefangen werden können.

@RDNA2
Ich tippe darauf (nachdem was aus dem DF Video zu sehen war) dass:
1.) nicht so viel mehr Transistoren / Flop benötigt werden (sonst würden kaum 56 CUs in den 360 sqmm Kern passen)
2.) die IPC nicht stark steigt (Gears 5 erzielte bei gleichen Settings etwa 2080 Niveau - ja unoptimiert - aber auf dem PC wird auch nicht sooo großartig optimiert - 10 TF vs 12 TF - das sieht jetzt im ersten Moment (wobei das noch keine gute Basis ist) noch nicht nach einer Steigerung aus
3.) Energieeffizienz steigt jedoch (>1800 MHz bei 56 CUs und die Kühlung für den Gesamt SoC sieht jetzt nicht extrem aus)
4.) Featureset wird absolut modern (VRS, Meshshading, RT Beschleunigung)

Insgesamt also sehr, sehr gut. Außerdem dürfte es wirklich schwierig sein, ausgehend von der bereits sehr hohen IPC von Navi und Turing da noch richtig was draufzulegen. Ggf. wird das dann so teuer, dass die Erhöhung der CU Anzahl sinnvoller war.

Bis auf Punkt 4 ist das natürlich wackelig - aber das gilt ja für nahezu alle Spekulationen. :)
1) Das kann man anhand der Analyst Day GPU-Folien auch herleiten (Logic Enhancement -> reduce complexity), hier wurde auf der Basis von RDNA1 also viel Zeit aufgewendet und am Grundgerüst (Architektur) "optimiert".
2) Stark ist natürlich relativ, anhand der Folie auf Seite 10 (IPC) sieht man aber, dass AMD auch da angesetzt hat, mich würden 15% nicht überraschen.
3) Klar, darum ging es ja auch hauptsächlich (siehe Folien). Sowohl der maximale Takt als auch die benötigte Energie um den jeweiligen Takt zu erreichen scheint mehr oder weniger deutlich erhöht/reduziert worden zu sein.

[mboeller]

Das bedeutet auch, das zumindest für den XBSX-SoC der Flächenvorteil einer besseren Fertigung fehlt - den gibt es nur bei N7+. Dies macht die 360mm² mit 56 CU (!) samt 320 Bit Interface und 8C-Zen2-CPU um so beeindruckender.

Dies bedeutet aber auch, das RDNA2 vermutlich weiterhin in N7P kommt und es dort auch keinen Flächenvorteil gibt.

die RDNA2 GPUs kommen aber min. 6 Monate später.
EUV war für die XBoxX vielleicht nur noch nicht fertig.
Die Fertigungskapazitäten/Kosten für N7+ sind vielleicht auch nicht geeignet für eine Console.
SoC brauchen aufgrund der unterschiedlichen Systeme wahrscheinlich ein wenig länger für die Validierung als eine "einfache" GPU und der XBoX SoC wurde vielleicht schon früher in die Fertigung gegeben als wir denken (Frühjahr 2019 und nicht Sommer 2019)

[basix]

1) Das kann man anhand der Analyst Day GPU-Folien auch herleiten (Logic Enhancement -> reduce complexity), hier wurde auf der Basis von RDNA1 also viel Zeit aufgewendet und am Grundgerüst (Architektur) "optimiert".
2) Stark ist natürlich relativ, anhand der Folie auf Seite 10 (IPC) sieht man aber, dass AMD auch da angesetzt hat, mich würden 15% nicht überraschen.
3) Klar, darum ging es ja auch hauptsächlich (siehe Folien). Sowohl der maximale Takt als auch die benötigte Energie um den jeweiligen Takt zu erreichen scheint mehr oder weniger deutlich erhöht/reduziert worden zu sein.

So wie es aussieht scheint AMD sehr gute Fortschritte bei der Optimierung ihrer Designs zu machen. "Logic Enhancement" scheint mir hier zudem ein sich selbst verstärkender Hebel zu sein:

Weniger Transistoren = Höhere Effizienz
Baugruppen näher beieinander platzieren, optimierte Signalwege = Höhere Effizienz
Mehr Platz für Transistoren = Weitere Features und effizienzsteigernde Massnahmen wie IPC-Steigerung möglich
Weniger Transistoren und/oder Leistungsaufnahme = Günstigere Herstellungskosten des gesamten Produkts

[HOT]

die RDNA2 GPUs kommen aber min. 6 Monate später.
EUV war für die XBoxX vielleicht nur noch nicht fertig.
Die Fertigungskapazitäten/Kosten für N7+ sind vielleicht auch nicht geeignet für eine Console.
SoC brauchen aufgrund der unterschiedlichen Systeme wahrscheinlich ein wenig länger für die Validierung als eine "einfache" GPU und der XBoX SoC wurde vielleicht schon früher in die Fertigung gegeben als wir denken (Frühjahr 2019 und nicht Sommer 2019)

Es geht hier um Kosten. Für die Konsolenhersteller ist der billigste Weg mit N7P anzufangen und im nächsten Jahr dann zügig auf den günstigen EUV-Prozess N6 zu wechseln, denn N6 ist mit N7(P) kompatibel, man muss also den Chip nicht neu designen. N7+ muss wohl durch die Bank teurer, aber auch leistungsfähiger sein als N6.

Übrigens gilt die maximale Maskengröße von 429mm² erst ab N5, N7+ und N6 sind davon nicht betroffen (wär ja auch schön blöd, wenn der N6-Prozess zu N7 kompatibel ist).

[Berniyh]

Da aber TSMC explizit davon spricht das die N7 Prozesse quasi direkt für N7P verwendet werden können ist das durchaus plausibel, dass AMD hier direkt für Navi/RDNA 1 schon auf N7P gewechselt ist.
Es wäre ja auch denkbar, dass Navi 10 mit N7 gestartet ist und dann irgendwann auf N7P gewechselt wurde.

Bei richtig großen GPUs erwarte ich eher, dass sich EUV rechnet, da der Yield stark ansteigen sollte, und die höheren Kosten von den hohen Margen besser abgefangen werden können.
Ja, zudem spielen da die Kapazitäten keine so große Rolle, da Big Navi sicherlich nicht "Mainstream" wird.

[basix]

Übrigens gilt die maximale Maskengröße von 429mm² erst ab N5, N7+ und N6

N5 sollte noch bis >800mm2 reichen. Erst 3nm wird auf HiNA wechseln.

[HOT]

Ahso ok. Dann wird N5P für beide wohl der letzte Prozess für große monolithische Dies.

[basix]

Genau. Oder man wagt mit 5nm schon einen Testversuch mit Chiplets. Weil bei 3nm und beyond muss man Chiplets beherrschen, um am oberen Ende des Leistungssprektrums mitmischen zu können.

[Piefkee]

Ich habe mal versucht basiert auf der XBox Series X die GPU-Power zu extrahieren. Damit kann man dann etwas exapolieren bezüglich Big Navi...

[Unicous]

Die PSU soll 315 Watt in der Spitze können. Die NVMe soll 4 Watt ziehen, 60 Watt für die CPU ist meiner Meinung nach zu viel, andere Kompenenten ziehen vermutlich deutlich mehr als du angegeben hast, welcher Chipsatz?, du hast die "Effizienz" des Netzteils nicht mit einbezogen, sicherlich wieder um die 90%.

Laut diesem Post versorgt die PSU einmal mit 255 Watt und einmal mit 60 Watt. https://old.reddit.com/r/Amd/comments/fk2xe5/rdna2_in_the_xbox_series_x_is_probably_more/

Ich würde also deutlich konservativer herangehen und von sagen wir 180 Watt ausgehen. ( bei 90% Effizienz und für 50 Watt CPU)

AMDs TDP basiert ja nicht auf dem Basistakt von daher macht der Vergleich mit Matisse und Renoir wenig Sinn, zumal I/O und L3 ordentlich abgespeckt sind.

[basix]

315W wird die Konsole niemals ziehen. Die One X hat ein 245W Netzteil und zieht 170-180W. 75% Last der Nominalleistung sind typischerweise ein guter Richtwert. Macht bei 255W aus dem Reddit Beitrag ca. 190-200W. Abzüglich NT Verlusten landet man auf 180W. CPU, RAM und SSD kommen auf ca. 50-60W, ergibt 120-140W für die GPU. VRM Verluste habe ich noch vergessen. Und wenn wer denkt, das sei zu wenig: +50% Effizienzsteigerung RDNA2 vs. dem Vorgänger.

Big Navi sollte meiner Meinung nach bei 80CU und 1.8 GHz zwischen 250-270W für die ganze Karte landen.

[Unicous]

Nein, nicht jede XOX zieht nur 180W. Das ist ein Fehlglaube. Es sind manchmal über 200 Watt. Außerdem muss MS natürlich einen Buffer einbauen für Regionen die nicht in Mitteleuropa oder Nordamerika liegen.:wink:

Anekdotische Evidenz nach 5 Sekunden googlen:

Eventually I put in a warranty claim on my launch One X. While I suspected that my original console was functioning as intended, I had at least hoped I would get a console that was quieter. Well, my replacement console just as loud, although the fan speed seems to not be quite as variable. It also draws even more power. Playing Gears of War 4 drew about 10 W more on average compared to my original console during the same campaign section. Rise of the Tomb Raider was about 5 W more when running through the Geothermal Valley. Then there's Wolfenstein II: The New Colossus. For as great as the story is, this game is notoriously unoptimized. Running at 4K pulls a nearly constant 200 W on my replacement console. On the flip side is Forza Motorsport 7. I found it interesting, but not entirely surprising, that the best optimized Xbox game required the same 160 - 170W on the second console during my testing.

https://www.tested.com/tech/825498-xbox-one-x-and-hovis-method/

[Iscaran]

Ich habe mal versucht basiert auf der XBox Series X die GPU-Power zu extrahieren. Damit kann man dann etwas exapolieren bezüglich Big Navi...

Hmm, sehr gute Idee. Damit würde man für die 80 CUs ca 250 W erwarten.

Das wäre in meinen Augen auch so das Limit das AMD anvisieren würde. Ich glaube nicht, daß AMD hier auf 300 W geht.

Falls AMD aber doch Richtung 300 W Monster geht, wären ja auch 96 CUs (4x24 als Chiplets) immer noch denkbar.

Oder 96 CUs aber mit niedrigerem Gesamttakt um die TDP zu halten (250 W ?).

So oder so - Big Navi scheint diesmal wirklich ein großes Ding zu werden, damit kann man vielleicht wieder im Top-Segment mehr oder weniger dagegen halten.

[HOT]

Da würd ich noch HBM vs. GDDR mit einrechnen, als Option jedenfalls.

[basix]

Nein, nicht jede XOX zieht nur 180W. Das ist ein Fehlglaube. Es sind manchmal über 200 Watt. Außerdem muss MS natürlich einen Buffer einbauen für Regionen die nicht in Mitteleuropa oder Nordamerika liegen.:wink:

Anekdotische Evidenz nach 5 Sekunden googlen:


https://www.tested.com/tech/825498-xbox-one-x-and-hovis-method/

Nicht jede XOX, aber alle anderen Testseiten die ich in 2min googeln finde, geben 170-180W an. Was ist also richtig? 10x Reviews inkl. Messung der Stromaufnahme und zum Teil sogar mit zeitlichem Verlauf bei verschiedenen Spielen vs. dieses eine Review? Und hier ist es sogar nur 1x Spiel (Wolfenstein II: The New Colossus), andere ziehen laut dem Tester weniger ;)

Aber OK, der Spezialfall mit 1x Spiel ist repräsentativ für die XOX... "Cherry Picking" at its best ;)

[robbitop]

Wenn man etwas dimensioniert, dann muss man schon auch nach den Worst Cases schauen. Silizium streut nunmal (leackage). Und wir sprechen ja hier gerade mal von ~10% Streuung. Alles im Rahmen IMO.

[HOT]

Auch die CPU streut, da ja die Taktraten fest vorgegeben sind. Da wird man irgendwo zwischen 45 und 55W landen mMn.

[robbitop]

Ja - sehe ich auch so. Da muss man ja auch mit Volllast von 8x CPU Kernen (das werden die Spielentwickler schon mittelfristig ausquetschen) rechnen. Und das bei 3,6 GHz mit SMT. Und da es ein Massen SoC ist, gelten halt auch die schlechtesten Exemplare für die Dimensionierung. Zumal da sicher wie immer auch ein bisschen VCore Reserve drauf liegt. Ich würde da auch auf >50...60W tippen.
Das geht besser mit Selektion und weniger VCore Reserve und insbesondere ist man in heutigen Spielen eben auch noch keine Vollauslastung von 14 Threads gewöhnt.

[basix]

Wenn man etwas dimensioniert, dann muss man schon auch nach den Worst Cases schauen. Silizium streut nunmal (leackage). Und wir sprechen ja hier gerade mal von ~10% Streuung. Alles im Rahmen IMO.

Natürlich, das nennt man ja auch Engineering ;) Aber der typische Verbrauch wird eben etwas geringer sein. Und für eine dGPU (Big Navi war das Thema) kann man eher vom typischen Verbrauch ausgehen (SKUs, Binning und so). Ausserdem kann man via Boost Mechanismen noch was gewinnen, was bei einer Konsole komplett entfällt.

Ich bin relativ optimistisch, was 80CU @ 1.7-1.8 GHz @ 250W anbelangt. Und das ist eher so +70% als die +50% Effffizienzsteigerung, welche AMD geteasert hat.

[davidzo]

Es geht hier um Kosten. Für die Konsolenhersteller ist der billigste Weg mit N7P anzufangen und im nächsten Jahr dann zügig auf den günstigen EUV-Prozess N6 zu wechseln, denn N6 ist mit N7(P) kompatibel, man muss also den Chip nicht neu designen. N7+ muss wohl durch die Bank teurer, aber auch leistungsfähiger sein als N6.

Nicht unbedingt nur Kosten, sondern auch um Output. Für Apple mögen die gesamten EUV Kapazitäten von TSMC noch reichen, aber für einen Konsolen-Chip mit doppelt bis dreifacher Transistoranzahl wird es dann schon knapp. Vor allem gleichzeitig zu Apple.
Zudem sind die Kosten nicht so 2-dimensional wie man das denkt.

Bei N7P und N6 sind vor allem die Masken teuer, wegen multi patterning. Da ist N7+ mit EUV sicher viel günstiger. Wieviele Masken man braucht hängt aber auch davon ab auf wie vielen Scannern man diesen Chip parallel fertigt. Den Output bzw. die zum Launchzeitpunkt verfügbare Menge kann man letztendlich über zwei Parameter steuern:
1. Parallelität in der Fertigung
2. früher anfangen, also ein längerer Vorproduktionszeitraum.

Ich kann mir durchaus vorstellen dass sich entschieden hat lieber früher mit N7P anzufangen anstatt auf N6 oder freigewordenen EUV-Kapazitäten zu warten. Gerade weil die mobile-Abnehmer mittlerweile geschlossne von N7 und N7P zu EUV übergegangen sind gibt es jetzt sehr viel freie Waferkapazitäten in diesen Prozessen. Das bedeutet nicht nur dass man gar nicht soviele teure Masken braucht, sondenr hat auch den angenehmen Nebeneffekt des early Silicon. Außerdem hat AMD schon lange diverse Scanner für Testzwecke in N7 und N7P zur Verfügung gehabt und mit den Designtools sehr viel Erfahrung. Nach Vega20 (1st), Matisse+Navi (2nd)ist das schon die dritte Generation N7 (renoir+seriesX) für AMD.

Ich würde sogar so weit spekulieren dass AMD aus diesen Gründen auch CDNA und RDNA2 sowie Zen3 noch in DUV Verfahren fertigen wird, einfach weil man darin industrieweit am meisten Erfahrungen gesammelt hat.
- Bei der aktuellen Marktverteilung benötigt man für RDNA2 lange nicht den breiten Output wie etwa nvidia und kann mit relativ wenigen Maskensätzen den bedarf decken. Überkapazitäten kann man flexibel mit Zen3, arcturus oder an microsoft vergeben.

Im Zusammenhang ergibt das auch eine Theorie wieso nvidia auf Samsungs 10/8nm gegangen ist statt einen EUV Prozess oder TSMCs N7P-N6.
- EUV Kapazitäten sind durch die Mobile Abnehmer gebucht, zu knapp verfügbar und zu teuer.
- TSMCs N7, N7P und N6 wurde frühzeitig von AMD und Microsoft größtenteils ausgebucht. AMD ist mittlerweile des größte N7 Abnehmer mit den meisten Erfahrungen. Nvidia müsste diese erst aufbauen und mit AMD in einen Preiskampf um die Kapazitäten gehen, während Samsungs DUV Kapazitäten einfacher verfügbar sind.
- bei einer beinahe 80/20 Marktverteilung vs AMD im Consumer GPU-Markt, insbesondere bei den performanc und enthusiast-Chips, benötigt man wesentlich mehr Masken um parallel zu fertigen. Bei TSMCs N7P und N6 sind diese am teuersten.
- Da nvidia angedeutet hat bei "7nm" einen Großteil an TSMC zu vergeben kann es immer noch sein dass man z.B. einen GA100 in N7P fertigt, während die Consumerchips aber in 10/8nm von Samsung kommen. Da GA100 kein Volumenprodukt ist reichen da wenige Scanner und Maskensätze.

[BoMbY]

Vulkan RT wurde übrigens veröffentlicht (ich glaube wir hatten hier vor kurzem darüber geschrieben): https://www.khronos.org/news/press/khronos-group-releases-vulkan-ray-tracing

[JVC]

Ich find "Vulkan" sowieso geil :smile:

M.f.G. JVC

[Berniyh]

Ich find "Vulkan" sowieso geil :smile:
Naja, man muss mal schauen, ob sich Vulkan RT in der Form durchsetzt. Wird ja auch maßgeblich davon abhängen, ob AMD das gut unterstützt.

[JVC]

Naja, man muss mal schauen, ob sich Vulkan RT in der Form durchsetzt....

NV ist doch scheinbar eben mit aufgesprungen ;)
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12248874#post12248874

Auch das neue "HBCC" wird NV vermutlich "bald" unterstützen ... VRS? keine Ahnung aber ist auch noch so n "zukünftig mal wichtiges Ding" unter umständen...
NAJA. Zu mindestens den VRR Standard hat NV ja zum glück angenommen :smile:
Und den Rest genießen wie dann hoffentlich schon mit HDMI 2.1 Grafikkarten ;)

M.f.G. JVC

[Berniyh]

NV ist doch scheinbar eben mit aufgesprungen ;)
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12248874#post12248874
Versteh den Bezug zu meinem Post nicht.

[aufkrawall]

Er hat halt offenbar *keine Ahnung, wie sich offene Standards konstituieren, und sein Narrativ ist sowieso immer AMD gegen die Bösen (Thema egal).

[JVC]

... und sein Narrativ ist sowieso immer AMD gegen die Bösen.
:uup: Ich steh dazu ... verdammt wieso hab ich keine AMD Aktien :usad:
(Edit: *... 6h später das Post von der Aussage her um 180° drehen, nicht nett.
dabei traf ich gar keine konkrete Aussage... spekulieren/vermuten darf man hier ja)

M.f.G. JVC

[Blediator16]

NV ist bei Vulkan auf den RT Zug aufgesprungen. Der war jetzt wirklich gut ;D

[dildo4u]

Warum sollten sie es nicht Wolfenstein Youngblood nutzt es schon und nur NV hat DXR taugliche GPUs.

[Unicous]

36 CUs@2,23 GHz.:freak:

WTF is that?

Immerhin zeigt es, dass RDNA2 noch taktfreudiger ist. ;)

[Berniyh]

36 CUs@2,23 GHz.:freak:

WTF is that?

Immerhin zeigt es, dass RDNA2 noch taktfreudiger ist. ;)
ähm? worauf beziehst du dich?

[Unicous]

PS5 natürlich. :)

[unl34shed]

Die wichtigere Frage, kann man deren M2 SSDs im PC nutzen?

Sorry, falscher Thread

[basix]

2.2 GHz in einer Konsole. Krass. Bin gespannt was die Leistungsaufnahme ist und wie hoch die dGPUs gehen werden.

[mironicus]

Ja, dann haben wir vielleicht Big Navi mit 80 CU und 2,2 GHz dank 7 nm+ und das haut dann alles von NVidia weg. :D

[Unicous]

Daraus kann man schon ein wenig extrapolieren, wie sich RDNA verhalten wird, zumal die Sony GPU anscheinend etwas näher am Verhalten einer retail GPU ist als die GPU in der Series X.

Wenn AMD den Vergleich den sie von GCN über RDNA zu RDNA2 gleich geblieben ist, werden eine theoretische 40 CU Vega CU mit einer 40 CU RDNA GPU mit einer 40 CU RDNA2 GPU verglichen. Also dürfte ein nicht geringer Teil an der verbesserten Effizienz auch durch nochmals deutlich höheren Takt erreicht werden.

Ergo dürfte RDNA2, wie schon aus der "multi gigahertz" Aussage von der FAD-Präsentation zu vermuten war, solch eine theoretische 40 CU RDNA2 die 2 GHz deutlich knacken und sich auch den 2,2 GHz annähern.:uponder:


@mironicus

Ähm, ja...:freak:

[basix]

Ich habe mal mit der XBOXSX Die Size von 360mm2 rumgespielt. Wenn ich die Zen Cores abziehe usw. wären allenfalls sogar 100 CUs in den 505mm2 aus der Gerüchteküche machbar. Nicht dass das sinnvoll wäre bei nur 384bit SI, aber es wäre machbar.

Ich vermute also folgendes:
- 80CU Navi ist kleiner und somit günstiger, so ca. 420-430mm2
- 505mm2 sind für 128 CUs von Arcturus.

Beides wäre sehr beeindruckend, was Flächeneffizienz angeht.

[JVC]

Ach was freu ich mich auf ne HDMI 2.1 Graka :smile:

M.f.G. JVC

[y33H@]

Die erste GraKa mit HDMI 2.1 wird sicherlich ne Low-End-Geforce :P

[Unicous]

Pascal@HDMI 2.1. confirmed?:eek:

[JVC]

@y33H@
Low-End bei mir sicherlich nicht ...
Geforce ja wieso nicht, besser als gar keine Graka die liefert was man braucht :)

Wenn ich Auswahl habe, um so besser ;)

@Unicous
Ich weiß leider noch nix davon... Edit Äh ... Pascal :confused:
Ampere hat ihn hoffentlich...k.a.

M.f.G. JVC

[Berniyh]

Ich verewige das mal hier:
https://twitter.com/KOMACHI_ENSAKA/status/1240510815960088578

[HOT]

Ziemlich plausible Liste.

[HOT]

Die erste GraKa mit HDMI 2.1 wird sicherlich ne Low-End-Geforce :P
Der Turing-Refresh mit PCIe4 für Tigerlake? Jo würd ich auch sagen.

[Iscaran]

Die PS5 scheint ja eher zu zeigen was in einer Desktop Karte möglich ist.

Wenn ich die Info zusammen nehme + was oben diskutiert wurde, vor allem hinsichtlich Leistungsbedarf in Watt wage ich folgende Aussage:

Navi 2x: ~80CUs @>2GHz @250 W

Das müsste eine GPU mit >20 TFlops ergeben (SP).
Eine 2080 Ti hat ~13.5 TFlops SP wenn ich nicht irre, man könnte also schon von bis zu +50% relativ zu einer 2080 Ti ausgehen. Selbst wenn am Ende nur +30 oder +40% relativ zur 2080 Ti rauskommen sollten, das ist schon eine ganze Ecke höher und aufgrund der Konsolen-Fakten und Gerüchtelage meiner Meinung nach durchaus im Bereich des realisierbaren.

Das dürfte auch reichen um zumindest in einem Bereich mit Ampere zu liegen.

EDIT: Nochmal ein andere Überschlagrechnung gemacht, selbst mit nur 64 CUS und 2GHz Takt kann man ca >16 TFlops erwarten. Das wäre immer noch 2080 Ti +20%.
Damit könnte man vielleicht auf folgendes LineUp kommen
Navi 21 = 64 CU @2GHz @200 W ~2080 Ti + ~10-20% (16 TFlops)
=4x16 CUs im "Chiplet-Design ?
Navi 22 = 80 CU @2GHz @250 W ~2080 Ti + ~50% (20 TFlops)
=5x16 CUs Chiplets
Navi 23 = 96 CU @1.8 GHz @300 W ~2080 Ti ~+60% (22 TFlops)
=6x16 CUs Chiplets

[DK999]

Vor allem bliebe da auch die Frage, wie viel kleiner RDNA2 für den PC aus fällt, da ja Custom-Einheiten für Sony (die wir nicht kennen) nicht im Design enthalten sind.
Falls man auf ein HBM-SI wechselt, wäre hier sogar nochmal DIE-Fläche frei und der Speicherdurchsatz höher.
Ich glaube mit RDNA2 kommt auch ein ordentliches Brett und RDNA1 war nur eine Geld einspielende Feldstudie....

[Ravenhearth]

RDNA2-Grafikkarten: AMD spricht heute über Raytracing (https://www.pcgameshardware.de/Raytracing-Hardware-255905/News/RDNA2-Raytracing-1345876/)

[Brillus]

Die PS5 scheint ja eher zu zeigen was in einer Desktop Karte möglich ist.

Wenn ich die Info zusammen nehme + was oben diskutiert wurde, vor allem hinsichtlich Leistungsbedarf in Watt wage ich folgende Aussage:

Navi 2x: ~80CUs @>2GHz @250 W

Das müsste eine GPU mit >20 TFlops ergeben (SP).
Eine 2080 Ti hat ~13.5 TFlops SP wenn ich nicht irre, man könnte also schon von bis zu +50% relativ zu einer 2080 Ti ausgehen. Selbst wenn am Ende nur +30 oder +40% relativ zur 2080 Ti rauskommen sollten, das ist schon eine ganze Ecke höher und aufgrund der Konsolen-Fakten und Gerüchtelage meiner Meinung nach durchaus im Bereich des realisierbaren.

Das dürfte auch reichen um zumindest in einem Bereich mit Ampere zu liegen.

EDIT: Nochmal ein andere Überschlagrechnung gemacht, selbst mit nur 64 CUS und 2GHz Takt kann man ca >16 TFlops erwarten. Das wäre immer noch 2080 Ti +20%.
Damit könnte man vielleicht auf folgendes LineUp kommen
Navi 21 = 64 CU @2GHz @200 W ~2080 Ti + ~10-20% (16 TFlops)
=4x16 CUs im "Chiplet-Design ?
Navi 22 = 80 CU @2GHz @250 W ~2080 Ti + ~50% (20 TFlops)
=5x16 CUs Chiplets
Navi 23 = 96 CU @1.8 GHz @300 W ~2080 Ti ~+60% (22 TFlops)
=6x16 CUs Chiplets

Ich geh davon aus das einer von Navi 21,22,23 der chip fürs lowend ist.

[HOT]

N21 wird sicherlich mit 80 CUs das obere Ende. Danach dürfte N22 mit 60 CUs und N23 mit 40CUs kommen. LowEnd deckt N1x ja recht gut ab, darunter hat man immer noch Polaris 12 (31). Daran wird man mit N2x sehr sicher nichts ändern. MMn kommen in 21 in N6 noch weitere weitere RDNA2-Auskopplungen um auch die restlichen Polaris und N1x-Varianten zu ersetzen. RDNA3 (die letzte monolithische Generation) wird sicherlich mit HighEnd in N5P in 22/23 erst weiter gehen.

Nach den Leistungsdaten der Konsolen dürfte aber klar sein, dass wir es mit 20+TFLOPs zu tun bekommen mit 80CUs > 2GHz @ 400mm²+. Da sind die 7nm, aber holla. Das wäre dann 2,5x, 1,8x und 1,3x N10 von den Leistungsdaten her, wie es den Anschein macht. Dabei wird die Karte mit N21 sicherlich wieder in Richtung 300W tendieren.
NV mit ihren 8LPP-Produkten kommen da sogar eher in Schwierigkeiten mMn. Das ist AMDs Maxwell+Pascal+Turing in einem Schritt. Man scheint die Ampere-Generation ja auch generell verschoben zu haben, wenn man den Buschfunk interpretiert. Da dürfte sicher letztendlich weniger Salvage und mehr Speicher und TDP bei rumkommen. Konkurrenz belebt das Geschäft.
Und man stelle sich vor, man würde noch eine Enthusiasten-Variante in N5 nachschieben in 21 :freak: viel Spass damit.

[mboeller]

36 CUs@2,23 GHz.:freak:

WTF is that?

Immerhin zeigt es, dass RDNA2 noch taktfreudiger ist. ;)

N7+ ?

[y33H@]

Hat da jemand Beispiele für?

VK_EXT_post_depth_coverage

o This extension indicates support for shader modules that use the SPV_KHR_post_depth_coverage extension. Fragment shaders using the SPV extension can control whether the SampleMask built-in input variable reflects the coverage after the depth and stencil tests are applied. This extension is only supported on AMD RDNA hardware.

[Iscaran]

Uhhh aus dem PCGH link:
"Die RDNA2-Architektur, Herz der kommenden Gaming-Radeons, wird höher takten denn je und +50 Prozent Performance pro Watt und außerdem eine höhere IPC-Leistung (Performance per Clock) bringen."

Zusammen mit dem Leak der PS5 und XBOX passt das eigentlich ganz gut.
@Brillus: Ich glaube nicht daß AMD mit Navi 21, 22, 23 irgendwas an low-/mid end bringt.

Midrange bedient die 5000er Reihe ganz gut. Low-End die Polaris mittlerweile.
Klar wird man hier jeweils refreshes rausbringen und evtl. auf Polaris auch ganz verzichten - aber das werden andere Chipnummern werden bzw. die werden noch unter RDNA1 also Navi 1x laufen. Denn Raytracing etc., also das was RDNA2 mit sich bringt werden die midrange und lowcost chips nicht brauchen.

=> Navi21, 22, 23 sind 3 "große" Chips.
Alias in der Art wie 6800, 6900, 6950 XT, ergänzt werden diese durch Refresh 5700, 5600, 5500 Chips als 6700, 6600, 6500.

Oder wie auch immer die Namen aussehen werden.
Wenn die Chips wirklich so einen "Sprung" hinlegen vermute ich fast, daß man einen neuen Namen auflegt.

Z.B. Radeon "Endgame" Series oder RayDNA xyz series

[Iscaran]

@yeehaa: Du bist doch von PCGH oder ?
Ihr habt da ein Fehler (glaub ich):
"... in der Next-Gen-Playstation eine Custom-RDNA2-GPU mit 26 Compute Units @ 2,23 GHz (bis zu 10,28 TFLOPS)."

Das muss doch 36 CUs heissen ?

[y33H@]

Nein, ich bin bei Golem - war bis 2013 bei PCGH, das ist schon ne Weile her ^^

Aber ja ... sollten 36 CUs sein.

[Berniyh]

=> Navi21, 22, 23 sind 3 "große" Chips.
Das würde ich ins Reich der Träume verorten.

Bedenkt, dass auch bei Navi1x 3 Chips existieren (Navi10, 12 und 14), davon aber nur 2 ihren Weg in Produkte für Enduser gefunden haben (Navi10 und 14).

Zu glauben, dass AMD gleich 3 "große" Chips mit RDNA2 bringt ist auf der Basis ehrlich gesagt eher naiv.

Da Navi22 relativ spät in den Treibern aufgetaucht ist würde ich auch dazu tendieren, dass der Chip in keinem (wesentlichen) Produkt auftaucht.
evtl. wieder was Apple-spezifisches o.ä.

[Iscaran]

@Berniyh: In der PCI ID gibt es immer noch keinen Eintrag zu Navi12 - ich glaube ehrlich gesagt nicht, dass dieser Chip in irgendeiner Form wirklich existiert. Das ist wohl nur eine Ausgeburt von diversen Foren/Bloggern gewesen. Weil man gedacht hat die verschiedenen Varianten von Navi10 würden eigene Chips darstellen.
Tatsache ist daß es bislang nur Navi10 und Navi14 gibt:
https://pci-ids.ucw.cz/read/PC/1002
Navi 10 = 5xxx Serie (5600, 5700, 5700 XT)
Navi 14 = 5500 und 5500 Mobile

Andererseits ist bislang zu Navi 2x und vor allem auch zur Anzahl der "Chips" die diese Serie darstellt quasi nichts bekannt und alles nur hören-sagen.

Daher können es 1, 2, 3 Chips sein...
Aber basierend auf der aktuell spekulierten Performance Lage KANN ich mir mind. 2 Große Chips vorstellen.

Falls es wirklich 3 sind (21, 22, 23) kann einer natürlich auch ein exoten Ding (Apple etc.) sein.
Vielleicht sind die PCI IDs 21, 22 einfach XBOX, PS5 und 23 = Desktop GPU.

[Berniyh]

Navi12 hat die PCI IDs 7360 und 7362, das ist bekannt.

Und zu allen drei Navi1x und allen drei Navi2x gibt es Belege aus Treiberdateien.
Aber die erstellt AMD sicherlich nur aus Spaß an der Freude?

Ich will auch gar nicht bestreiten, dass es 3 Chip für Consumerprodukte werden können, aber man sollte das nicht als gegeben ansehen.
Insbesondere, da wir viel früher von Navi21 und Navi23 wussten als von Navi22.

[Digidi]

Weiss man denn schon wie das Frontend der Xbox aussieht?
4 oder 6 Raserengines?

[Unicous]

Auf Grund dieses Schnipsels geht Komachi davon aus, dass bei Van Gogh (Renoir Nachfolger) aus 8 Vega CUs 8 RDNA(2) CUs bzw- WGPs werden:

https://pbs.twimg.com/media/ETYloJ3WsAEHpqM.png
https://twitter.com/_rogame/status/1240224503709536258



https://twitter.com/KOMACHI_ENSAKA/status/1240265060309581824

Das hatte ich ja auch angenommen und es liegt auch auf der Hand. Die RDNA CUs sind nicht allzu groß, der Renoir Die ist für das Gebotene ( echter SoC+8C+8CUs) relativ klein und man bleibt trotzdem noch deutlich unter 200mm².

[basix]

8 RDNA2 CUs habe ich auch vermutet. Klar, ist etwas grösser als Vega, so ca. +1/3 aber das macht nicht so viel aus bei <25mm2 für die 8 CUs in Renoir. Mit 7nm+ wird der Renoir Nachfolger vermutlich sogar weniger Fläche benötigen.

8 RDNA2 CUs könnten ausserdem ca. 2x so schnell sein wie die Vega CUs. Das reicht locker als Generationensprung.

[Unicous]

Mit 2x so schnell wäre ich etwas vorsichtig, da die die CUs schon ziemlich hoch takten aber 50-60% dürften auf jeden Fall drin sein.

[Iscaran]

Navi12 hat die PCI IDs 7360 und 7362, das ist bekannt.


Ich finde dazu nur die uralten Gerüchte vom Herbst 2019 - die ich mittlerweile als obsolet betrachte. Navi12 war damals in Diskussion als 5700 XT, aber offiziell ist 5700 XT immer noch Navi10 in der PCI ID.
Navi 12 scheint es nirgends als Produkt zu geben. Das war also eventuell einfach nur eine "hausinterne" Bezeichnung für Navi10 v2 alias 5600 XT oder eben 5700 XT (weil die erste nicht released wurde).
https://www.pcgameshardware.de/AMD-Radeon-Grafikkarte-255597/News/Navi-12-taucht-in-Linux-Treiber-auf-1332661/

EDIT: In der PCI ID Repository sind jedenfalls noch keine derartigen Devices gelistet - das dürften also bislang wirklich nur "Test"namen sein.


Und zu allen drei Navi1x und allen drei Navi2x gibt es Belege aus Treiberdateien.
Aber die erstellt AMD sicherlich nur aus Spaß an der Freude?


Nein sicher nicht - aber das muss noch nicht heissen dass das auch ein finales Produkt ist ;).


Ich will auch gar nicht bestreiten, dass es 3 Chip für Consumerprodukte werden können, aber man sollte das nicht als gegeben ansehen.
Insbesondere, da wir viel früher von Navi21 und Navi23 wussten als von Navi22.

Stimmt. Und bezogen auf dei Navi12 alias Navi10 (v2?) Möglichkeit könnte ähnliches auch für Navi21, 22, 23 gelten. Und das was wir bekommen ist Navi20 (V3) alias "23". Alles andere waren nur interne Testnummern bzw. soweit in die Öffentlichkeit wie man es gebraucht hat um die neuen Features (Raytracing z.B.) in Treiber zu implementieren, zu testen usw.

[Berniyh]

Ich finde dazu nur die uralten Gerüchte vom Herbst 2019 - die ich mittlerweile als obsolet betrachte. Navi12 war damals in Diskussion als 5700 XT, aber offiziell ist 5700 XT immer noch Navi10 in der PCI ID.
Navi 12 scheint es nirgends als Produkt zu geben. Das war also eventuell einfach nur eine "hausinterne" Bezeichnung für Navi10 v2 alias 5600 XT oder eben 5700 XT (weil die erste nicht released wurde).
Ne sorry, da liegst du definitiv falsch.
Die aktuell wahrscheinlichste Theorie ist, dass es sich bei Navi12 um eine HBM2 Variante von Navi10 handelt, da bei Navi12 Hinweise auf ein HBM2 gefunden wurden (Anfang 2020 iirc).
Aber tatsächlich lässt auch Komachi immer wieder durchklingen, dass er die Sache um Navi12 sehr frustrierend findet, weil es ziemlich schwer fällt das Teil einzuordnen und man einfach nicht weiß was das soll.
Ähnlich wie auch bei diesen LITE Versionen.

Solche Dinge passieren halt, wenn man – wie er und wie auch ich – gerne mal im Treiber herum stöbert um Hinweise auf zukünftige Produkte zu finden.
(so bin ich damals auch auf Navi22 gestoßen, der vorher noch nicht bekannt war)
EDIT: In der PCI ID Repository sind jedenfalls noch keine derartigen Devices gelistet - das dürften also bislang wirklich nur "Test"namen sein.
Kommt aus dem Linux Kernel, daher sind die PCI IDs als ziemlich gesichert zu betrachten, wenn auch nicht vollständig. Meistens kommen im Laufe der Zeit noch welche dazu.
Nein sicher nicht - aber das muss noch nicht heissen dass das auch ein finales Produkt ist ;).
Ja eben, meine Reden. ;)

Vega12 war auch mal geplant und wurde dann gecancelt. Navi12 findet man auch nirgends zu kaufen.
Irgendwie würde sich Navi22 da ganz gut einreihen. xD

[basix]

Mit 2x so schnell wäre ich etwas vorsichtig, da die die CUs schon ziemlich hoch takten aber 50-60% dürften auf jeden Fall drin sein.

Ja, der Takt müsste relativ hoch sein. Je nach dem wie viel IPC RDNA2 oben drauf legt +30-40% Takt. RDNA2 soll laut AMD aber 2.2x so energieeffizient wie Vega sein und die PS5 soll mit 2.2 GHz takten. Es ist also nicht unmöglich. +50% erwarte ich, auf +100% hoffe ich.

[Iscaran]

meine Theorie zu Navi12 wäre die folgende:

Das sind die Refresh Chips der aktuellen 5000er Reihe im RDNA2 "Design" also die Mid-Range/Low Cost varianten

passend dazu PCI ID
7360 = 5700er Refresh
7362 = 5600/5500er Refresh

Ja hab nach etwas googlen die paar indizien auch gefunden. Es geistert immer noch rum, vor allem aber als Treiber-Testballon:
https://cgit.freedesktop.org/~agd5f/linux/commit/drivers/gpu/drm/amd?h=amd-staging-drm-next&id=57d4f3b7fd65b56f98b62817f27c461142c0bc2a
https://www.ozlabs.org/~akpm/mmotm/broken-out/linux-next.patch
https://lists.freedesktop.org/archives/amd-gfx/2019-September/040077.html

[robbitop]

Auf Grund dieses Schnipsels geht Komachi davon aus, dass bei Van Gogh (Renoir Nachfolger) aus 8 Vega CUs 8 RDNA(2) CUs bzw- WGPs werden:

https://pbs.twimg.com/media/ETYloJ3WsAEHpqM.png
https://twitter.com/_rogame/status/1240224503709536258



https://twitter.com/KOMACHI_ENSAKA/status/1240265060309581824

Das hatte ich ja auch angenommen und es liegt auch auf der Hand. Die RDNA CUs sind nicht allzu groß, der Renoir Die ist für das Gebotene ( echter SoC+8C+8CUs) relativ klein und man bleibt trotzdem noch deutlich unter 200mm².
Wäre sinnvoll mMn. Denn die erhöhte Performance aus Takt und IPC ist schonmal relativ gesund. Riesen Sprünge in Bezug auf Bandbreite sind zu Zen 3 nicht zu erwarten - entsprechend tut man sich keinen großen Gefallen, mehr CUs zu verbauen, als man versorgen kann. :)

[Unicous]

@basix

Ich gehe nicht davon aus, dass VGH mobile so viel an Takt zulegt, ich würde schätzen, dass die 2GHz eine sinnvolle Schwelle sind. Deutlich darüber würde man den gewonnen Effizienzsprung fast nur in Leistung umsetzen und das müssen sie gar nicht (und lässt unter Umständen wenig Spielraum für einen Refresh). Tiger Lake sieht nicht danach aus als würde es eine Gefahr darstellen. ;)

Desktop könnte eine andere Geschichte sein, aber auch dort wird Renoir sicherlich einen höheren Takt fahren.

@robbitop

Mit RDNA müsste ja auch eine Vergrößerung des Caches einhergehen, von daher ist eine höhere Bandbreite nicht unbedingt vonnöten. Aber es gibt natürlich noch die sehr geringe Möglichkeit, dass auch LPDDR5 unterstützt wird. ;)
RDNA(2) dürfte auch generell deutlich bandbreiteneffizienter sein.
Irgendwann muss aber mal eine Lösung á la Wide I/O her. Leider scheint es darum ja sehr still geworden zu sein. :(

[basix]

Tiger Lake soll gerade bei der GPU stark zulegen.

+30-40% laut dieser Meldung: https://www.hardwareluxx.de/index.php/news/hardware/prozessoren/52402-tiger-lake-u-mit-integrierter-xe-gpu-zeigt-sich-bei-2-7-ghz.html

+100% laut dieser Meldung: https://www.pcgamesn.com/intel/tiger-lake-vs-ice-lake-gen12-xe-gpu

AMD will sich hier sicher nicht die Blösse geben und Intel einen Leistungsvorsprung bei Grafik überlassen ;)

[robbitop]

Ausgehend von Renoir wird man die Bandbreite nicht erhöhen. RDNA brachte +15% IPC und sicherlich +10% Takt. Mal schauen was RDNA2 drauflegen wird. Wenn man jetzt nochmal konservative +10% als Mischung aus Takt und IPC dazu packt, sind das ~40% Performance. RDNA2 kann ggü Vega sicherlich auch einiges an Bandbreiteneffizienz herausholen - aber es gibt sicherlich Grenzen. Deshalb denke ich, dass 8 CUs gut zur gleichen Bandbreite passen. :)

Geht man von 1800 MHz als sustained für die GPU aus, sind das 33 GB/s pro TFLOP bei LPDDR4X. Das ist schon relativ knapp. 5700XT liegt bei ~50. Nur die 1070ti liegt als dGPU so weit unten. Dessen Bandbreiteneffizienz sollte man mit RDNA2 allerdings erreichen.

@basix
Intel hat aber auch nur LPDDR4X und ist genauso bandbreitenbegrenzt. Entsprechend dürften sie bei ähnlicher Bandbreiteneffizienz vor gleichem Performance-Ceiling stehen. Wobei ich doch davon ausgehe, dass AMD mit RDNA2 vor Intel in dieser Metrik liegen dürfte.

[Iscaran]

Hat da jemand Beispiele für?

VK_EXT_post_depth_coverage

o This extension indicates support for shader modules that use the SPV_KHR_post_depth_coverage extension. Fragment shaders using the SPV extension can control whether the SampleMask built-in input variable reflects the coverage after the depth and stencil tests are applied. This extension is only supported on AMD RDNA hardware.

Ich denke das ist ein Feature das man für performantes Raytracing in Kombination mit Rasterizing braucht. Man muss einfach alle Pixel wegfiltern die keine Oberfläche darstellen um die Performance des RayCastings bzw. Ray nachverfolgens zu maximieren.

Bei MSAA wurde das damals eingesetzt bzw. entwickelt um die MSAA Performance zu erhöhen. Ähnliches wird wohl für RT benötigt.
Ist eine Art Filter der nur nach im Endbild "sichtbaren" Pixeln sucht um entsprechende Bearbeitungsschritte für die nichtsichtbaren Pixel zu vermeiden.

siehe auch:
http://developer.download.nvidia.com/assets/events/GDC15/GEFORCE/Maxwell_Archictecture_GDC15.pdf
https://developer.nvidia.com/sites/default/files/akamai/opengl/specs/GL_EXT_post_depth_coverage.txt
http://htmlpreview.github.io/?https://github.com/KhronosGroup/SPIRV-Registry/blob/master/extensions/KHR/SPV_KHR_post_depth_coverage.html

[Unicous]

@basix

Worauf willst du hinaus? Allein der Umstieg auf RDNA(2) wird das mehr als ausgleichen.:wink:

Bei Renoir gibt sich AMD auch nur mit 10% mehr bei Timespy (im Vergleich zu ICL) zufrieden.:freak:


edit:
Ich habe übrigens etwas zu Wide IO gefunden, aber die Innovation wird wohl wieder im Smartphone-Sektor erfolgen:

Liao described a next-generation of the 910 using a 3D stack of SRAM cache as well as HBM main memory. A version for smartphones will use a custom Wide-IO DRAM 3D bonded on to an apps processor.https://www.eetimes.com/huawei-paints-broad-ai-canvas/

[Berniyh]

meine Theorie zu Navi12 wäre die folgende:

Das sind die Refresh Chips der aktuellen 5000er Reihe im RDNA2 "Design" also die Mid-Range/Low Cost varianten

passend dazu PCI ID
7360 = 5700er Refresh
7362 = 5600/5500er Refresh

Ja hab nach etwas googlen die paar indizien auch gefunden. Es geistert immer noch rum, vor allem aber als Treiber-Testballon:
https://cgit.freedesktop.org/~agd5f/linux/commit/drivers/gpu/drm/amd?h=amd-staging-drm-next&id=57d4f3b7fd65b56f98b62817f27c461142c0bc2a
https://www.ozlabs.org/~akpm/mmotm/broken-out/linux-next.patch
https://lists.freedesktop.org/archives/amd-gfx/2019-September/040077.html
Wie gesagt, es gibt starke Hinweise darauf, dass Navi12 ein HBM2 Speicherinterface hat, daher kann man das als Refresh von Navi10/14 wohl ausschließen.

[Locuza]

meine Theorie zu Navi12 wäre die folgende:

Das sind die Refresh Chips der aktuellen 5000er Reihe im RDNA2 "Design" also die Mid-Range/Low Cost varianten

passend dazu PCI ID
7360 = 5700er Refresh
7362 = 5600/5500er Refresh

Ja hab nach etwas googlen die paar indizien auch gefunden. Es geistert immer noch rum, vor allem aber als Treiber-Testballon:
https://cgit.freedesktop.org/~agd5f/linux/commit/drivers/gpu/drm/amd?h=amd-staging-drm-next&id=57d4f3b7fd65b56f98b62817f27c461142c0bc2a
https://www.ozlabs.org/~akpm/mmotm/broken-out/linux-next.patch
https://lists.freedesktop.org/archives/amd-gfx/2019-September/040077.html
Steige ein in die Welt der Erleuchtung: ;)
https://www.reddit.com/r/Amd/comments/ef0zjq/navi12_arcturus_renoir_gpu_firmware_info_shader/

Es gibt eine navi12_gpu_info.bin Datei in ROCm3.0, Navi12 ist darüber hinaus schon ewig als Compiler-Target GFX1011 zu finden.
https://www.phoronix.com/scan.php?page=news_item&px=GFX1011-GFX1012-AMDGPU-LLVM

Wie bei Navi14 unterstützt man dot-instructions für vierfachen bzw. achtfachen INT8-/INT4-Durchsatz.
https://llvm.org/docs/AMDGPU/AMDGPUAsmGFX1011.html

Microsoft hat das auch für die Xbox Series X offiziell bestätigt.
Navi10 ist der einzige RDNA-Ableger bisher, dem solche Instruktionen fehlen.
Bzw. als Bild:
https://pbs.twimg.com/media/EQsiOD0XkAAJUqN?format=jpg&name=medium

Ansonsten fällt die prinzipielle Konfiguration im Vergleich zu Navi10 identisch aus, 40 CUs, 64 ROPs etc.
Ein markanter Unterschied ist, dass Navi12 ein 2048-Bit HBM2-Interface besitzt.
For Navi12 dram_channel_width_bytes is 16, i.e., 128 bits per channel, while for Navi10 it's 2, i.e., 16 bits per channel. num_chans is 16 for both, resulting in a total dram width of 2048 bits for Navi12 (and 256 bits for Navi10). This is another hint towards HBM.

Als einer der ersten RDNA GPUs und mit dem GFX-Level 1011 ist das auch höchstwahrscheinlich ein weiterer und vermutlich der letzte RDNA1-Ableger.

Tiger Lake soll gerade bei der GPU stark zulegen.

+30-40% laut dieser Meldung: https://www.hardwareluxx.de/index.php/news/hardware/prozessoren/52402-tiger-lake-u-mit-integrierter-xe-gpu-zeigt-sich-bei-2-7-ghz.html

+100% laut dieser Meldung: https://www.pcgamesn.com/intel/tiger-lake-vs-ice-lake-gen12-xe-gpu

AMD will sich hier sicher nicht die Blösse geben und Intel einen Leistungsvorsprung bei Grafik überlassen ;)
Da wird Intel wohl der iGPU-King werden, bis Van Gogh auftaucht.
Ich denke AMD wird es in Zukunft nicht so leicht haben.
Bei Tiger-Lake hat man immerhin noch das Glück, dass der Chip als Quadcore etwas limitiert ist, was die Marktsegmente angeht, ansonsten scheint Intel stark aufgestellt zu sein.

[basix]

@Unicous:
Bei +100% Performance von Tiger Lage wären +40-50% mit RDNA2 eben nicht mehr genug für die Performance Krone. Und 3DMark war nie repräsentativ für iGPUs, weil die Bandbreitenanforderung minimal ist. Nicht dass ich +100% von Tiger Lage erwarte, aber man weiss ja nie.

@robbitop:
RDNA brachte sogar +28% IPC: https://www.computerbase.de/2019-07/radeon-rx-5700-xt-test/4/#abschnitt_amd_navi_vs_nvidia_pascal

[robbitop]

IIRC hat DF im Schnitt 15% gemessen. :)

[Unicous]

Was für 100% Performance?:confused:

Der Artikel spekuliert auf Grund einer Spekulation auf Grund einer Behauptung eines Intel Mitarbeiters der bei Tekken das Ziel von 30 fps auf 60 fps gesetzt hat.:freak:

Und das ist auch von mir Spekulation, denn ich weiß nicht ob das ordentlich von Google Translate übersetzt wurde. So wie ich PCGamesN kenne, haben sie das aus irgendeinem Forum geklaut und dann einen Artikel daraus gebastelt ohne das vorher ordentlich übersetzen zu lassen. :rolleyes:

Bislang sieht es nicht so aus, als könnte Tiger Lake einer hypothetischen Van Gogh APU mit RDNA2 gefährlich werden, zumindest was die GPU anbelangt.

[basix]

Ich gehe auch nicht davon aus. Klar aber ist, das Intel mit Tiger Lake Ambitionen hat. Und für AMD wird es vermutlich kein so leichter Sieg wie auch schon, ausser RDNA2 legt ordentlich eine Schippe drauf.

Aber lassen wir mal das Thema und warten konkretere Infos ab.

PS:
Konkurrenz belebt das Geschäft ;)

[Unicous]

Oh, ich sage nicht, dass Tiger Lake kein Performancesprung im Vergleich zu ihren vorherigen "Ambitionen" ist. Aber ich bin ein wenig gmb-geschädigt, der in sämtlichen Threads davon spricht wie Intel mit Tiger Lake AMD zur endgültigen Aufgabe zwingen wird obwohl die Chips weder veröffentlicht wurden noch in einem Vakuum existieren.:wink:

Intel muss dafür Diefläche opfern, genauso wie AMD das auch muss und wir werden sehen wie sich das auswirkt. Zumal hier ja ein 8-Kerner mit einem 4-Kerner verglichen wird. Dazu wissen wir nicht ob die getesteten Chips alle auf 15W ausgelegt sind oder sich auch 25W genehmigen können. Darüber hinaus streuen die Benchmarkergebnisse ordentlich.

Ich würde daher noch ein paar Monate warten... unter Umständen sogar bis 2021.:wink:

[Iscaran]

Steige ein in die Welt der Erleuchtung: ;)
https://www.reddit.com/r/Amd/comments/ef0zjq/navi12_arcturus_renoir_gpu_firmware_info_shader/

Es gibt eine navi12_gpu_info.bin Datei in ROCm3.0, Navi12 ist darüber hinaus schon ewig als Compiler-Target GFX1011 zu finden.
https://www.phoronix.com/scan.php?page=news_item&px=GFX1011-GFX1012-AMDGPU-LLVM

Wie bei Navi14 unterstützt man dot-instructions für vierfachen bzw. achtfachen INT8-/INT4-Durchsatz.
https://llvm.org/docs/AMDGPU/AMDGPUAsmGFX1011.html

Microsoft hat das auch für die Xbox Series X offiziell bestätigt.
Navi10 ist der einzige RDNA-Ableger bisher, dem solche Instruktionen fehlen.


Ansonsten fällt die prinzipielle Konfiguration im Vergleich zu Navi10 identisch aus, 40 CUs, 64 ROPs etc.
Ein markanter Unterschied ist, dass Navi12 ein 2048-Bit HBM2-Interface besitzt.

Als einer der ersten RDNA GPUs und mit dem GFX-Level 1011 ist das auch höchstwahrscheinlich ein weiterer und vermutlich der letzte RDNA1-Ableger.


Hey Danke - das sind ja großartige News :-). Dann ist Navi12 die CDNA Version von Navi10 (Compute-DNA) sowas wie der Vorläufer (?) von Arcturus (von dem man munkelt das es die CDNA version von RDNA2 ist, sozusagen CDNA2).

[Locuza]

Hey Danke - das sind ja großartige News :-). Dann ist Navi12 die CDNA Version von Navi10 (Compute-DNA) sowas wie der Vorläufer (?) von Arcturus (von dem man munkelt das es die CDNA version von RDNA2 ist, sozusagen CDNA2).
Also Navi12 ist ganz simpel nur ein weiterer RDNA1-Ableger.
Navi10, Navi12 und Navi14 verwenden die gleiche Mikroarchitektur, es gibt soweit ich sehe nur einen relevanten Feature-Unterschied und das ist die Unterstützung vom hohem INT8/INT4-Durchsatz bei Navi12 und Navi14.
Navi14 wird aktuell als RX5500 Series im Gaming-Bereich verkauft.
https://b2c-images.idg.zone/4230989_620x310_r.jpg

Arcturus ist vermutlich CDNA1 und basiert auf der GCN5/Vega-Mikroarchitektur.
RDNA ist eine völlig andere Mikroarchitektur bzw. Basis.
MI200 (vielleicht schon CDNA2?) basiert weiterhin auf GCN5/Vega, also für ein paar Jahre stellen RDNA und CDNA stark unterschiedliche Mikroarchitekturen dar.
Ob das AMD später etwas zusammenführen wird?
Das habe ich z.B. für CDNA2 oder CDNA3 erwartet, also eine marktspezifische Computeableitung auf Basis von RDNA und nicht GCN5, aber mal sehen wie sich das entwickelt.
CDNA2 scheint wie schon erwähnt nach wie vor auf GCN5 zu basieren.

[Berniyh]

Hey Danke - das sind ja großartige News :-). Dann ist Navi12 die CDNA Version von Navi10 (Compute-DNA) sowas wie der Vorläufer (?) von Arcturus (von dem man munkelt das es die CDNA version von RDNA2 ist, sozusagen CDNA2).
Ne, wenn dann eher was in Richtung Workstation, aber im Gegensatz zu Navi10 (da gibt es Pro Varianten für Workstation) hat man bei Navi12 auch hierzu noch nix gehört.

Es ist und bleibt halt ein Mysterium. Ich schätze mal, dass die Dinger wirklich nur an ausgewählte Kunden verkauft werden, wie damals die Vega12 auch.

[fondness]

Also Navi12 ist ganz simpel nur ein weiterer RDNA1-Ableger.
Navi10, Navi12 und Navi14 verwenden die gleiche Mikroarchitektur, es gibt soweit ich sehe nur einen relevanten Feature-Unterschied und das ist die Unterstützung vom hohem INT8/INT4-Durchsatz bei Navi12 und Navi14.
Navi14 wird aktuell als RX5500 Series im Gaming-Bereich verkauft.
https://b2c-images.idg.zone/4230989_620x310_r.jpg

Arcturus ist vermutlich CDNA1 und basiert auf der GCN5/Vega-Mikroarchitektur.
RDNA ist eine völlig andere Mikroarchitektur bzw. Basis.
MI200 (vielleicht schon CDNA2?) basiert weiterhin auf GCN5/Vega, also für ein paar Jahre stellen RDNA und CDNA stark unterschiedliche Mikroarchitekturen dar.
Ob das AMD später etwas zusammenführen wird?
Das habe ich z.B. für CDNA2 oder CDNA3 erwartet, also eine marktspezifische Computeableitung auf Basis von RDNA und nicht GCN5, aber mal sehen wie sich das entwickelt.
CDNA2 scheint wie schon erwähnt nach wie vor auf GCN5 zu basieren.

Warum sollte man das zusammen führen? Man macht die Trennung ja nicht aus Spaß. Gcn ist die wesentlich effizientere Compute Architektur, rdna die effizientere gaming Architektur. MI200 ist imo ebenfalls arcturus, das sollte locker möglich sein mit 8k alus.

[Unicous]

Die Namen sind eh Schall und Rauch.

Arcturus wird sicherlich auch nicht einfach nur "Vega" sein sondern wird entsprechende Anpassungen haben.

Effizient ist GCN auch nicht. Performant, ja, teilweise. Aber es ist eben ein Hybrid der zu viele Kompromisse machen muss/te.

Ich glaube auch nicht, dass CDNA lediglich ein verbessertes GCN optimiert auf Compute ist. Da wird genug aus der RDNA-Entwicklung miteinfließen, zudem kommt ja auch noch die Abstimmung mit der Zen-Architektur und die Weiterentwicklung des Infinity-Fabric.

AMD hat jetzt wieder die Ressourcen und das finanzielle Standbein sich auszustrecken und mehr "Risiken" einzugehen. Ich wette den Schritt wollten sie schon vor langer Zeit gehen, es fehlten aber die Ressourcen.

[Naitsabes]

Ich habe jetzt nicht die Roadmaps vor Augen - in welche Richtung gehen die APUs? RDNA oder CDNA?
Letzteres würde ich bei APUs deutlich sinniger finden.


edit.
Bitte löschen oder verschieben, falls das zu sehr OT ist.

[Der_Korken]

Ich habe jetzt nicht die Roadmaps vor Augen - in welche Richtung gehen die APUs? RDNA oder CDNA?
Letzteres würde ich bei APUs deutlich sinniger finden.

Warum letzteres? Eine Consumer-APU wird nicht für Computing verwendet, weil die Leistung viel zu gering ist. Insofern wird dort natürlich RDNA verwendet.

[Locuza]

Warum sollte man das zusammen führen? Man macht die Trennung ja nicht aus Spaß. Gcn ist die wesentlich effizientere Compute Architektur, rdna die effizientere gaming Architektur. MI200 ist imo ebenfalls arcturus, das sollte locker möglich sein mit 8k alus.
Weil RDNA im Kern einige Eigenschaften besitzt, die auch im Compute/HPC-Bereich für eine höhere Leistung und Effizienz sorgen (können).
- RDNA kann Instruction-Level-Parallelism ausnutzen
- Unterstützt sowohl Wave32, als auch Wave64
- Jeden Takt werden neue Waves für die Compute Units initialisiert und es gibt doppelt soviele Wave-Scheduler pro CU.
- Register-Pressure ist ein wenig geringer
- Zwei CUs können gemeinsam an einer Workgroup arbeiten
- I$/K$ versorgt nur noch insgesamt 128 ALUs, nicht 256 bzw. 192.
- Und noch vieles mehr, 128B Cache-Lines, weniger Memory-Request zum füllen der Maschine, mehr Scalar-Units, usw.

Rein vom Design könnte der L1$ pro Shader-Array auch eine Bereicherung sein, damit würde man die Verdrahtung clustern und es würde die Skalierung mit hunderten von CUs vereinfachen, wenn die nicht alle zum L2$ verbunden werden müssen.

Sieht man vom Transistorenbudget/Flächenverbrauch ab, ist RDNA pro CU deutlich besser bei Compute aufgestellt, als GCN.

Natürlich geht es aber um gute Werte bei der PPA, Performance, Power and Area.
Wenn GCN je nach Code 10-30% langsamer ist, aber pro CU eben auch 40% kleiner, dann ist es schon einleuchtend, wieso man lieber das Design verwendet, wenn im Compute/HPC-Bereich der Workload im oberen Bereich der Auslastung bei GCN spielt, im Vergleich zum typischen Spielcode.
Aber es stellt sich bei mir die Frage, ob es nicht doch eine gute Idee wäre auf Basis von RDNA eine Compute-Mikroarchitektur aufzubauen, anstatt von GCN?
Man könnte schließlich RDNA an einigen Stellen abspecken oder größere Änderungen vornehmen, ohne das man wirklich Aufwand für zwei unterschiedliche Mikroarchitekturen betreiben muss.
Aktuell muss sich AMD um zwei sehr unterschiedliche Ausführungsmodelle kümmern und Software für stark unterschiedliche Architekturen optimieren, man könnte versuchen das deutlich näher zusammen zu bringen und dennoch, je nach Zielmarkt, die Prozessoren stark anzupassen.

MI200 hat Komachi iirc als GFX909 identifiziert, Arcturus ist GFX908.

[Digidi]

Lol Primitive shaders alive:
https://youtu.be/ph8LyNIT9sg?t=1772

[Daredevil]

Das war also alles ein geheimer Plan und AMD zündet mit den PS dann die Rakete für Vega und der VII? :D

[robbitop]

Weil RDNA im Kern einige Eigenschaften besitzt, die auch im Compute/HPC-Bereich für eine höhere Leistung und Effizienz sorgen (können).
- RDNA kann Instruction-Level-Parallelism ausnutzen
- Unterstützt sowohl Wave32, als auch Wave64
- Jeden Takt werden neue Waves für die Compute Units initialisiert und es gibt doppelt soviele Wave-Scheduler pro CU.
- Register-Pressure ist ein wenig geringer
- Zwei CUs können gemeinsam an einer Workgroup arbeiten
- I$/K$ versorgt nur noch insgesamt 128 ALUs, nicht 256 bzw. 192.
- Und noch vieles mehr, 128B Cache-Lines, weniger Memory-Request zum füllen der Maschine, mehr Scalar-Units, usw.

Rein vom Design könnte der L1$ pro Shader-Array auch eine Bereicherung sein, damit würde man die Verdrahtung clustern und es würde die Skalierung mit hunderten von CUs vereinfachen, wenn die nicht alle zum L2$ verbunden werden müssen.

Sieht man vom Transistorenbudget/Flächenverbrauch ab, ist RDNA pro CU deutlich besser bei Compute aufgestellt, als GCN.

Natürlich geht es aber um gute Werte bei der PPA, Performance, Power and Area.
Wenn GCN je nach Code 10-30% langsamer ist, aber pro CU eben auch 40% kleiner, dann ist es schon einleuchtend, wieso man lieber das Design verwendet, wenn im Compute/HPC-Bereich der Workload im oberen Bereich der Auslastung bei GCN spielt, im Vergleich zum typischen Spielcode.
Aber es stellt sich bei mir die Frage, ob es nicht doch eine gute Idee wäre auf Basis von RDNA eine Compute-Mikroarchitektur aufzubauen, anstatt von GCN?
Man könnte schließlich RDNA an einigen Stellen abspecken oder größere Änderungen vornehmen, ohne das man wirklich Aufwand für zwei unterschiedliche Mikroarchitekturen betreiben muss.
Aktuell muss sich AMD um zwei sehr unterschiedliche Ausführungsmodelle kümmern und Software für stark unterschiedliche Architekturen optimieren, man könnte versuchen das deutlich näher zusammen zu bringen und dennoch, je nach Zielmarkt, die Prozessoren stark anzupassen.

MI200 hat Komachi iirc als GFX909 identifiziert, Arcturus ist GFX908.
Ganz hervorragendender, differenzierter und hilfreicher Beitrag! :up:

[Hübie]

Iirc ist MI200 eine duale CDNA1 (Arcturus - Grüße von StarCraft) auf einem Board, aber ich kann mich auch täuschen... Ob das jetzt zwei Dies auf einem Interposer oder zwei Packages auf einem Board sind? Nun darüber können wir spekulieren.

[horn 12]

@Daredevil

Dann werde ich mir doch noch eine Radeon VII holen müssen.

[LasterCluster]

Iirc ist MI200 eine duale CDNA1 (Arcturus - Grüße von StarCraft) auf einem Board, aber ich kann mich auch täuschen... Ob das jetzt zwei Dies auf einem Interposer oder zwei Packages auf einem Board sind? Nun darüber können wir spekulieren.

Dann würde der Bezug der Produktbezeichnung zu einer Performancemetrik wegfallen, denn doppelte MI100/Arcturus-Leistung wird das allein aus TDP Gründen niemals geben. Aber letztendlich ist es aber natürlich nur ein Produktname...

[basix]

Dann würde der Bezug der Produktbezeichnung zu einer Performancemetrik wegfallen, denn doppelte MI100/Arcturus-Leistung wird das allein aus TDP Gründen niemals geben. Aber letztendlich ist es aber natürlich nur ein Produktname...

Wieso nicht? Die MI100 wird mit 200W angegeben und trägt offenbar nur den XL-Chip. Nimmt man den XT-Chip, taktet 10-20% niedriger und man kann das schon innerhalb 300-350W lösen. Ist viel, aber machbar.

[Leonidas]

Aber es stellt sich bei mir die Frage, ob es nicht doch eine gute Idee wäre auf Basis von RDNA eine Compute-Mikroarchitektur aufzubauen, anstatt von GCN?
Man könnte schließlich RDNA an einigen Stellen abspecken oder größere Änderungen vornehmen, ohne das man wirklich Aufwand für zwei unterschiedliche Mikroarchitekturen betreiben muss.


Angesichts des heftigen Flächenunterschieds beantwortet sich die Frage von alleine. RDNA braucht zu viele Transistoren pro CU - und HPC giert nach purer Rohleistung, da ist Auslastung überhaupt keine Frage. GCN bietet halt immer schon sehr viel Rohleistung mittels vieler Einheiten auf wenig Platz. Es lohnt sich für AMD wohl eher, dieses Grund-Design für HPC anzupassen, anstatt RDNA für HPC umzubauen.

[basix]

Nun Volta / Turing hat genau wegen dem Computing viele Transistoren investiert, hauptsächlich in vergrösserte Caches. Das bringt schon was, vor allem, wenn man keinen hochoptimierten Code am laufen hat. Viele wissenschaftliche Sachen werden mit Python und nicht C oder CUDA programmiert. Da ist hardwarenahe Optimierung nicht so einfach, ausser man verwendet so Sachen wie cupy.

Grössere Caches etc. federn im Prinzip die Ausreisser nach unten ab. Das sieht man bei RDNA als auch Zen 2, wo mehr Cache und niedrigere Latenzen die weniger gut optomierten Anwendungen dennoch performant abarbeiten. Deswegen denke ich schon, dass z.B. grössere L1 Caches wie bei Nvidia eingebaut werden. Wenn es optimal läuft, wiegen sich die zusätzlichen Features mit den Funktionen auf, welche man rausschmeist (z.B. ROPs oder TMUs). Dann hat man einen auf Compute optimierten Chip, welcher trotzdem nicht grösser ist als vorher.

[danarcho]

Weil RDNA im Kern einige Eigenschaften besitzt, die auch im Compute/HPC-Bereich für eine höhere Leistung und Effizienz sorgen (können).
- RDNA kann Instruction-Level-Parallelism ausnutzen
- Unterstützt sowohl Wave32, als auch Wave64
- Jeden Takt werden neue Waves für die Compute Units initialisiert und es gibt doppelt soviele Wave-Scheduler pro CU.
- Register-Pressure ist ein wenig geringer
- Zwei CUs können gemeinsam an einer Workgroup arbeiten
- I$/K$ versorgt nur noch insgesamt 128 ALUs, nicht 256 bzw. 192.
- Und noch vieles mehr, 128B Cache-Lines, weniger Memory-Request zum füllen der Maschine, mehr Scalar-Units, usw.

Kleine Anmerkungen:
- ILP spielt nur eine Rolle, wenn nicht genügend Waves da sind, um die execution units auszulasten. Wir haben ein paar Tests mit ILP-Scheduling gemacht, und konnten keinen wirklichen Unterschied feststellen.
- Wave32 spielt nur eine geringe Rolle bei Compute (außer ein paar Deppen meinen, Nvidia wäre das einzige auf der Welt und legen die workgroup size auf 32 fest)
- register pressure: 102 -> 107 SGPRs, und bei VGPRs nur ein Unterschied bei wave32 und ungerader wave Anzahl, ansonsten sind es gleich viele.
- Die maximale workgroup size ist gleich oder?
- kein bpermute/shuffle über 64 lanes mehr (zumindest nicht in einer Instruktion)
- register bank conflicts
- mehr scalar units wurden notwendig wegen wave32

Ich wills nicht schlecht reden, die Änderungen haben ihre Berechtigung, und die Performance gerade in Spielen zeigt das ja auch sehr gut, aber ob das 1:1 auf compute übertragbar ist, habe ich meine Bedenken. Du schreibst ja selbst nur von der Möglichkeit, ok :)

[pixeljetstream]

- Wave32 spielt nur eine geringe Rolle bei Compute (außer ein paar Deppen meinen, Nvidia wäre das einzige auf der Welt und legen die workgroup size auf 32 fest)
auch NV hw präferiert mindestens 2 warps (64 threads) bei compute, bei älterer hw sogar mehr pro workgroup für die Auslastung.

[danarcho]

auch NV hw präferiert mindestens 2 warps (64 threads) bei compute, bei älterer hw sogar mehr pro workgroup für die Auslastung.
Heh, sorry, wollte das auch nicht euch vorwerfen, sondern Entwicklern, die sich nicht ausreichend informieren. Passiert leider viel zu häufig :/

[Leonidas]

Auf Grund dieses Schnipsels geht Komachi davon aus, dass bei Van Gogh (Renoir Nachfolger) aus 8 Vega CUs 8 RDNA(2) CUs bzw- WGPs werden:


Eigentlich nicht. Seine Aussage ist eher, das es 16CU werden:
https://mobile.twitter.com/KOMACHI_ENSAKA/status/1240265060309581824

... was ich wieder für zu groß halte, das kann niemand mit Bandbreite versorgen.

[Berniyh]

Das is eher ne Frage als ne Aussage. ;)

[Unicous]

Vllt. sollte man nicht immer einzelne tweets betrachten sondern auch der Konversation folgen. https://twitter.com/KOMACHI_ENSAKA/status/1240265979893972992

[Leonidas]

Habe mich genau darauf bezogen. Bin ich zu blöd, um da was anderes als "16CU" zu lesen?

[Unicous]

Nein, er sagt es ist eine 16 CU bzw. 8 WGP GPU. Da er selbst festgelegt hat, dass die Van Gogh GPU RDNA 2 ist macht alles andere gar keinen Sinn. :rolleyes:

[Complicated]

... was ich wieder für zu groß halte, das kann niemand mit Bandbreite versorgen.
MS und Sony können sogar noch mehr versorgen in den Konsolen - die Frage ist eher wer solch eine SKU benötigt und wofür ein solches aufgebohrtes Interface (und zugehöriger Speicher) dann gut ist mit 16CUs.

[Leonidas]

Nein, er sagt es ist eine 16 CU bzw. 8 WGP GPU. Da er selbst festgelegt hat, dass die Van Gogh GPU RDNA 2 ist macht alles andere gar keinen Sinn. :rolleyes:


Dann frage ich mich, wie man 16 CU mit 128 Bit DDR4 füttern will.

[Unicous]

Es sind 8 WGPs nicht 16 CUs. Komachi hat nur geschlussfolgert, dass es mindestens 16 CUs sein müssen. Da RDNA deutliche Vorteile bei der Ausnutzung der gegebenen Bandbreite hat und zudem größere Caches sehe ich das Problem nicht?

[horn 12]

https://postimg.cc/yJxTnDXD

Interessantes Slide

September - Oktober sofern Corona nicht durchgreift wäre wohl angedachter Termin...

[Complicated]

Dann frage ich mich, wie man 16 CU mit 128 Bit DDR4 füttern will.Wo ist DDR4 gesichert?
die Frage ist eher wer solch eine SKU benötigt und wofür ein solches aufgebohrtes Interface (und zugehöriger Speicher) dann gut ist mit 16CUs.
Die Behauptung es kann keiner ist einfach irreführend - technisch ist das alles möglich.

[robbitop]

16CUs würden bei 1800 MHz und LPDDR4x-3733 DC bei 16-17 GB/s pro TF liegen. Das ist hoffnungslos bandbreitenlimitiert.
N10 liegt bei 50gb/s pro tflop. Turing ebenso. Die extremste dGPU war die 1070ti mit 33 gb/s pro TFLOP.

Da müsste man mMn schon etwas mehr haben als lpddr4x. :)
Mindestens doppelt so viel.