AMD/ATI - Navi 1X (7nm, RDNA1, 2019) & Navi 2X (7nm, RDNA2, 2020) [Archiv] - Seite 21

davidzo

2019-09-11, 20:57:48

Generell hat mich der extreme Unterschied zwischen Tahiti und Polaris überrascht. Tahiti war für mich eigentlich sehr gut gealtert und hat es dem vermeintlich modernerem Tonga-Chip echt schwer gemacht. Zudem ließ sich das Teil besser takten als alle anderen 28nm-GCNs (man denke nur an die Toxic@1200Mhz in 2012!).

Da hast du den Grund schon. Tonga hatte es nur schwer, da er einerseits mit weniger Chiptakt angetreten ist und außerdem mit viel weniger Speicherbandbreite.
Die R9 285 hatte außerdem nur 28CUs.
- 61% der Speicherbandbreite (176 vs 288gb/s)
- 80% der Rechenleistung (28CU@918mhz vs 32cu@1Ghz)

Ja, der deutliche Unterschied schon zw. Tahiti und Polaris in einigen Titeln hat mich auch überrascht.

Naja, wir haben damals in den Reviews Polaris mit Hawai verglichen. Dass 20% plus zwischen Tahiti und Hawai (GCN2) liegen war nichts neues und kann man direkt an Speicherbandbreite und Rechenleistung fest machen. Und Polaris lag entweder gleichauf oder hat Hawai in modernen Spielen meist leicht geschlagen. Ähnliche Rechenleistung bei etwas weniger Shadern und etwas mehr Takt und etwa halbierter Bandbreite. Wie der Tahitivergleich aus geht wundert mich jetzt gar nicht, man hätte Tinga und Hawai mit testen müssen, dann würde man sehen was für microsteps an Verbesserungen das wirklich waren.

Durch die Taktbereinigung sieht der Sprung zwischen Tahiti und Polaris beinahe größer aus als der zwischen Polaris und Navi. Das verzerrt etwas das Bild, denn bei Navi gab es eben auch gleichzeitig einen sehr großen Taktsprung, zumindest verglichen mit den ersten Polaris SKUs die noch nicht gnadenlos übervoltet und übertaktet waren.
Die RX480 hat mit 1120-1266 gegenüber der 7970 Ghz oder einer 280x (1Ghz) kaum mehr Takt dazu gewonnen. Das Hochprügeln auf 1340mhz (rx580) bzw. 1545mhz ist nur möglich weil der chip weit außerhalb seines sweet spot betrieben wird.
Der Baseclock von Navi mag da nicht viel höher aussehen, aber der Boost funktioniert endlich wie man es erwartet. 1,9-2Ghz ist für eine 5700xt eher die Regel als Seltenheit.

Setsul

2019-09-11, 21:39:49

Naja Tonga hatte es sehr schwer weil die Architektur nicht ganz das erreicht hat was sie sollte, vor allem in Sachen Bandbreiteneffizienz (DCC war erstmal sehr meh) und auch die Effizienz insgesamt war nicht so wie geplant nachdem 20nm weggefallen ist.

Hab ich ja vorhin schon kurz erwähnt aber bei Navi ist tatsächlich die Änderung bei den Pipelines fast wichtiger als jegliche IPC Gewinne. Die IPC zu halten und den Takt zu erhöhen ohne mit viel Spannung hochprügeln zu müssen ist Gold wert für die Flächeneffizienz und Skalierbarkeit. 128 CUs mit 500 MHz wären wunderbar effizient aber wie soll man einen großen Chip bauen, bezahlen und auslasten? Schneller als 40 CUs mit 1,9-2 GHz ist das nicht also wirds für High End noch viel schlimmer.

Wie gesagt prozessnormierter Takt wäre toll für faire Vergleiche, weiß aber leider keiner.

reaperrr

2019-09-12, 00:23:46

Naja Tonga hatte es sehr schwer weil die Architektur nicht ganz das erreicht hat was sie sollte, vor allem in Sachen Bandbreiteneffizienz (DCC war erstmal sehr meh) und auch die Effizienz insgesamt war nicht so wie geplant nachdem 20nm weggefallen ist.

Polaris ist architekturell kaum besser, das kommt fast alles vom Prozess und schnelleren Speicher (naja, und größeren L2).
Eine 380X und RX470 auf vergleichbaren Taktraten zeigen kaum Unterschiede.

Außerdem waren es Polaris 10 und 11 (bzw. Ellesmere und Baffin), die ursprünglich für 20nm geplant waren und daher auf 14LPP portiert werden mussten, sonst wären die nämlich schon früher erschienen (dafür dann aber takt- und effizienzmäßig auch deutlich schwächer ausgefallen).

Setsul

2019-09-12, 01:36:17

CLN20G war für Ende 2012 geplant, noch vor CLN20SOC. Das wäre schon sehr ungewöhnlich wenn AMD geplant hätte noch bis Fiji 3 Jahre später auf 28nm zu bleiben. AMD vermeidet normalerweise allzu große Dies. 2013 Hawaii als letzter großer 28nm Chip und spätestens 2014 auf einem bis dahin gut eingefahrenen 20nm Prozess Tonga als Testballon für Fiji. 2015 war dann wirklich der späteste Termin für Fiji, weil Ende 2014 schon 14nm (ja 14) hätte anlaufen sollen bei TSMC.

Tonga wäre so um die 200mm² und ein deutliches Upgrade zu Tahiti geworden anstatt ein Sidegrade, Fiji unter 400mm² und wohl deutlich sparsamer und kühler geblieben.

Was dann 2012 als CLN20G offiziell tot war auf CLN20SOC umgeplant wurde und dann 2013 oder spätestens 2014 als die Produktion lief und klar war dass das nicht für GPUs taugt, ist eine andere Sache.
Als für Tonga schon 28nm und 2013-2014 (und Fiji ein Jahr später) feststanden weil es einfach keinen 20nm Prozess gab der 2014-15 einen großen Chip mit vernünftigen Yields produzieren konnte waren P11/10 wohl noch für 2015 auf CLN20SOC geplant.

genervt

2019-09-12, 08:39:14

Ich habe im Kopf, dass Tahiti nur 2 ACEs hatte und dies später auf 8 ACEs aufgeweitet wurde. Google hat mich da bestätigt. Ich meine Sony hatte mit PS4 auch schon 8 ACEs drin.
Bei Polaris dachte ich schon, dass man den gordischen Knoten der Auslastung zerschlagen hätte. Die Performance war einfach zu gut im Vergleich. Vega hat dann eines besseren belehrt.
Ich vermute, dass Navi den Nimbus des gut reifenden Weins nicht mehr haben wird, dafür stimmt die Auslastung einfach schon von Beginn an. Mit Treibern und Intrinsics holt man da nicht mehr so viel raus. Vega kann aufgrund mehr Shadern Navi teils in id software Titeln schlagen.
Das Video ist in der Tat top. Und auf die neue Konsolengeneration freue ich mich.

mboeller

2019-09-12, 09:03:44

Ich vermute, dass Navi den Nimbus des gut reifenden Weins nicht mehr haben wird, dafür stimmt die Auslastung einfach schon von Beginn an. Mit Treibern und Intrinsics holt man da nicht mehr so viel raus.

Theoretisch ist RDNA 4x schneller pro Takt und CU als GCN. Die max. mögliche Auslastung liegt bei 1 während GCN nur 0,25 erreichen kann. Steht zumindest auf irgendeiner Folie zu RDNA so drauf.

Navi ist aber nur max. 2x schneller als zB. Vega und oftmals nur 30-40% (AFAIR), nicht 4x schneller wie theoretisch möglich.

Da sollte also noch was gehen :)

Der_Korken

2019-09-12, 10:05:45

Wie kommen diese 4x denn zu stande? Die Rohleistung pro CU ist gleich geblieben. Es könnte höchstens sein, dass GCN im worst case 4x so viel workload braucht, um eine CU komplett auszulasten, aber daraus könnte man nicht ableiten, dass RDNA oft oder immer ~4x so schnell werden kann.

mboeller

2019-09-12, 10:29:56

Bucklew

2019-09-12, 10:31:10

"Easy To Program" und "Easier Achieved" als Vergleich kann sich auch nur ne Marketingabteilung ausdenken ;D

AffenJack

2019-09-12, 10:38:32

daher:

Der IPC Vergleich kommt direkt von AMD

Das deine Interpretation Null Sinn macht, sollte dir doch schon dadurch auffallen, dass GCN laut dir ja nur 1/5 der Pre-GCN IPC haben soll.

Denniss

2019-09-12, 13:13:23

Man könnte in etwa sagen daß bei GCN einige Funktionseinheiten zu breit waren und bei kleineren Aufgaben dort viel Overhead bzw Leerlauf vorhanden war = theoretische Leistung verpufft im Nirvana.

Setsul

2019-09-12, 15:16:59

@mboeller:
Es ist ein komplizierter Weg um es auszudrücken, aber es geht darum wieviele Work-Items man braucht um die gleiche Auslastung zu bekommen.

Wenn man einer RDNA CU 2 volle Wave32 dann wird sie die auf den 2 SIMD32 ausführen und wenns im nächsten Takt unabhängige Instructions gibt dann gehen die in die SIMD32 und so weiter.
64 Work-Items und pro Takt werden 64 Work-Items bearbeitet. Wenn man nur 32 Work-Items hat entsprechend nur 32 pro Takt. Also theoretisch kann man pro Work-Item auch eines pro Takt bearbeiten.

Wenn man GCN eine Wave64 gibt dann kann die nur an eine einzelne SIMD16-Unit gehen und braucht dort logischerweise 4 Takte. Also 64 Work-Items, aber nur 16 bearbeitet pro Takt = 0.25 IPC pro Work-Item. Um alle 4 SIMD16 auszulasten braucht man mindestens 4 Wave64, aber dann arbeiten alle 4 und bearbeiten genauso wie RDNA 64 Work-Items pro Takt.

Es geht also darum dass man nicht unbedingt 256 Work-Items braucht um die vollen 64 pro Takt zu bekommen sondern 64 reichen schon.

Die Theorie hat natürlich einen Haken: Wenn bei GCN eine Instruction mit 4 Takten Latenz ausgeführt wird dann werden Elemente 1-16 in dem Takt fertig in dem 49-64 anfangen. Wenn die nächste Instruction davon abhängt kann die im 5. Takt problemlos loslegen weil sie ja erstmal nur das Ergebnis von 1-16 braucht und das ist fertig.
Das geht bei RDNA nicht. Alle Elemente von 1-32 haben in einem Takt angefangen und werden erst 4 Takte später fertig also wenn man das Ergebnis braucht muss man 3 Takte warten und nichts tun. Nur jeden 4. Takt kann man eine neue Instruction anfangen, also ist der Durchsatz der gleiche wie bei GCN. Wenn man 4 mal soviele Work-Items hat wie SIMD-Slots dann hat man natürlich in den 3 Takten 3 andere Waves die man ausführen kann und wieder volle Auslastung, genauso wie bei GCN.

Der große Unterschied ist dass RDNA eben weniger Work-Items braucht wenn ein paar Instruction unabhängig voneinander sind und noch viel wichtiger dass jetzt die Pipelinelänge verändert werden kann. GCN braucht die 4 Takte Latenz damit das System gut funktioniert, RDNA stören auch 6 Takte nicht. Klar für optimale Auslastung braucht man theoretisch bis zu 50% mehr Work-Items, aber wenn man durch die 50% längere Pipeline 50% höheren Takt schafft bekommt man selbst mit der gleichen Anzahl Work-Items immernoch die gleiche Performance.

Sobald eben nicht mehr der worst-case eintritt und jede Instruction von der vorherigen abhängt schlägt sich RDNA besser bei der Auslastung. Nicht viel, bei Weitem nicht 4x, aber es hilft. Der Takt ist der eigentliche Vorteil.
Dann gibts noch kleinere Vorteile bei der Latenz. Nehmen wir mal ein FMA das von 3 Instructions abhängt, die aber nicht untereinander abhängig sind. GCN schickt die 3 brav hintereinander in die SIMD-Unit und 3x4=12 Takte später das FMA. RDNA drückt die in 3 aufeinanderfolgenden Takte rein, die erste wird nach 6 Takten fertig und die dritte logischerweise nach 8 und dann kann das FMA schon loslegen.
Außerdem hat RNDA Wave32, GCN braucht Wave64. Wenn man nur 16 Work-Items zusammenkratzen kann hat GCN automatisch nur noch 25% Auslastung weil trotzdem eine ganze 64er Wave ausgeführt wird, nur eben mit 48 leeren Items. RDNA wird da nicht so stark getroffen weil nur 16 von 32 leer sind.

reaperrr

2019-09-12, 16:20:21

daher:

https://www.extremetech.com/wp-content/uploads/2019/06/Navi-Slide-14.jpg

Der IPC Vergleich kommt direkt von AMD
"Per Work-Item".

Mit "Work-Item" sind nicht Hardware-Einheiten gemeint.

Im Grunde ist damit nur die Granularität gemeint, wieviele Aufgaben mindestens an eine CU gestellt werden müssen um sie voll auszulasten, nicht wie viel IPC du maximal aus den Einheiten rausholen kannst.

Edit: Sorry, hatte nicht gesehen, dass das von Setsul schon beantwortet wurde.

mboeller

2019-09-12, 20:24:13

@mboeller:
Es ist ein komplizierter Weg um es auszudrücken, aber es geht darum wieviele Work-Items man braucht um die gleiche Auslastung zu bekommen.

....

Vielen Dank für die ausführliche Erklärung.

AMD benutzt hier also eine IMHO etwas sehr seltsame IPC ... war ich also auf dem Holzweg.

Wenn ich deine Erklärung richtig interpretiere, dann arbeitet RDNA kurze Shader besser ab als GCN, oder?

Setsul

2019-09-12, 21:06:33

Nicht unbedingt kürzer aber generell abhängig von Latenz und "schmälere" Waves natürlich auch. Eben generell besser wenn nicht alles perfekt läuft. Rohleistung hat GCN ja nie gefehlt, nur genügend davon auf die Straße zu bringen war schwierig.

gravitationsfeld

2019-09-12, 21:46:27

Theoretisch ist RDNA 4x schneller pro Takt und CU als GCN.
Noe. Die maximale Leistung ist exakt gleich. RDNA erreicht sie einfacher, aber ganz bestimmt nicht 4x einfacher.

Digidi

2019-09-13, 02:46:16

@gravitationsfeld

Ist RDNA denn nun einfacher zu programmieren? Oder hat es nun mehr Fallstricke?

Wie kommst du auf gleiche Leistung? Da sollten doch bei angepasster Programmierung locker 10% drin sein. Da sehe ich das alte Hauptprobelm das die Software mal wieder hart agnepasst werden muss umd die Architektur auszufahren

gravitationsfeld

2019-09-13, 06:30:30

Theoretische Leistung ist gleich. Praktische Leistung ist RDNA in der Regel schneller.

danarcho

2019-09-13, 09:58:19

Da sehe ich das alte Hauptprobelm das die Software mal wieder hart agnepasst werden muss umd die Architektur auszufahren
Ich behaupte mal, dass genau der Punkt mit besserer Programmierbarkeit gemeint ist. RDNA verringert die Anforderungen ein wenig. zB kann man jetzt eine workgroup size von 32 ohne performance einbußen nehmen, was insbesondere den Entwicklern entgegen kommt, die eh alles nur auf Nvidia optimieren. Außerdem kann auch bei hohem register pressure noch guter Durchsatz erreicht werden, wenn der Compiler gute Arbeit macht. Viel mehr seh ich aber auch nicht.

StevenB

2019-09-13, 10:47:24

AffenJack

2019-09-13, 12:12:04

Eine kleine Frage zum GPU Design bsp. RDNA 2 ist ja aktuell noch in der Design-Phase.

Wie läuft das ab? Ähnliche wie beim CPU Design, das zuerst die sogenannten "low hanging fruit's" abgearbeitet werden?

RDNA2 dürfte von der Architektur her nicht viel anders werden. Man wird zuerst einmal RT und weitere Features einbauen, wie Variable Rate Shading. In 1 Jahr reicht das schon an Aufwand.

Aber gut, dass du gerade erwähnst, dass RDNA2 in der Designphase ist. Das zeigt schonmal, dass RDNA2 noch kein Tapeout hatte und somit RDNA auf jeden Fall erst in H2 2020 kommt. Hier hatten ja auch einige vom Frühjahr geträumt.

unl34shed

2019-09-13, 13:08:18

Sicher, dass RDNA2 noch im Design ist?

Screemer

2019-09-13, 13:11:54

stand so auf den folien von vor ein paar tagen.

Der_Korken

2019-09-13, 13:24:14

RDNA2 könnte schon recht zügig kommen, da RDNA1 ähnlich wie Zen1 einfach ein Snapshot von einer noch nicht ganz fertig gebauten Architektur sein könnte, aber es war schon gut genug für ein Produkt. Ein Jahr sollte aber mindestens dazwischenliegen, denn so viele Entwicklungsteams hat AMD auch wieder nicht.

Bucklew

2019-09-13, 13:33:11

Aber gut, dass du gerade erwähnst, dass RDNA2 in der Designphase ist. Das zeigt schonmal, dass RDNA2 noch kein Tapeout hatte und somit RDNA auf jeden Fall erst in H2 2020 kommt. Hier hatten ja auch einige vom Frühjahr geträumt.
RDNA2 könnte auch später kommen, die 2020er Chips können ja auch einfach nur größere bzw. kleinere RDNA1-Chips sein.

basix

2019-09-13, 17:26:04

RDNA2 könnte schon recht zügig kommen,...

Wenn RDNA2 noch "in design" ist, dann wird das schon noch eine Weile dauern. Ist das Design fertig, dauert es ein paar Wochen bis Tapeout (Durchlaufzeit durch Fabrik). Dann das Bring-Up und die Validierungsphase und anschliessend Ramp Up für die Hochvolumenfertigung (ca. 3 Monate vor Release). Also ich würde von mindestens einem halben Jahr ausgehen, wenn heute das Design abgeschlossen wäre. Also März. Feilen sie noch etwas am Design entsprechend später.

Ich erwarte eher so was im Sommer rum. Das würde aus mehreren Gründen passen:

7nm+ sollte ready sein
Start Hochvolumenproduktion für Konsolen dürfte so im Frühling / Frühsommer sein. Passt also auch. Und wieso hier nicht noch zwei, drei Monate mehr ins Design investieren wenn man die Zeit bis zum Konsolenstart ja hat?
Allfällige Chance, Erfahrungen mit RDNA1 noch mitzunehmen

Momentan sehe ich deutlich mehr Gründe für einen Sommer+ Start von RDNA2 als einem Start Anfang 2020.

Der_Korken

2019-09-13, 17:37:09

RDNA2 könnte auch später kommen, die 2020er Chips können ja auch einfach nur größere bzw. kleinere RDNA1-Chips sein.

Irgendwas wird sich AMD aber einfallen lassen müssen, denn der Verbrauch des 250mm²-Chips ist schon so hoch, dass dadrüber nicht mehr viel Platz ist. Mit HBM schafft man es vielleicht noch einen 50% größeren und schnelleren Chip in 300W reinzuquetschen, aber dann ist Schicht. Danach muss man über weniger Takt und breitere Chips kommen, die entsprechend teuer werden. Wie sie noch zwei Chips über dem bereits vorhandenen 225W-Chip platzieren wollen, weiß ich nicht.

JVC

2019-09-13, 17:48:12

"in design" kann zu mindestens "N21" doch gar nicht mehr sein :confused:
Denn die Entwickler-Kits beinhalten ihn und die werden seit August doch schon ausgeliefert.
https://www.xboxdynasty.de/news/xbox-next/geruecht-scarlett-und-dante-dev-kit-spezifikationen-aufgedeckt/

M.f.G. JVC

Linmoum

2019-09-13, 17:55:19

Navi21 muss auch gar kein RDNA2 sein. Davon ab kriegen die Konsolen eh keine Stangenware, sondern ihre üblichen Custom-Lösungen.

JVC

2019-09-13, 18:03:03

Davon ab kriegen die Konsolen eh keine Stangenware, sondern ihre üblichen Custom-Lösungen.
Ich dachte das der Konsolen-Gpu der Desktop Lösung ähnelt.
Aber vielleicht hat AMD die eigene Entwicklung wirklich hinter die der Konsolen gestellt.

Wenn N21 nicht RDNA2 ist dann ist es N23 auch nicht,
aber beide sollen besser/gut RT können und HDMI 2.1 unterstützen :confused:

M.f.G. JVC

AffenJack

2019-09-13, 18:07:49

Wenn RDNA2 noch "in design" ist, dann wird das schon noch eine Weile dauern. Ist das Design fertig, dauert es ein paar Wochen bis Tapeout (Durchlaufzeit durch Fabrik). Dann das Bring-Up und die Validierungsphase und anschliessend Ramp Up für die Hochvolumenfertigung (ca. 3 Monate vor Release). Also ich würde von mindestens einem halben Jahr ausgehen, wenn heute das Design abgeschlossen wäre. Also März. Feilen sie noch etwas am Design entsprechend später.

Momentan sehe ich deutlich mehr Gründe für einen Sommer+ Start von RDNA2 als einem Start Anfang 2020.

Schon dein Sommer 2020 ist sehr optimistisch. Es dauert mindestens 9 Monate vom Tapeout bis zum Verkauf, oft ist eher mit 12 zu rechnen, da Respins öfter vorkommen. Es dauert alleine 8-10 Wochen bis du deine fertigen Chips nach dem Tapeout hast. Tapeout bedeutet übrigens die Übergabe des Designs an die Fabrik bzw Fertigstellung der Masken, nicht das erste fertige Silizium. Anschließend mindestens 6 Monate bis zum Produkt.

Mal abgesehen davon steht RDNA2 bestimmt auch nicht umsonst in den Folien immer auf der Zeitlinie, wo auch 2021 drauf ist. Würde mich nicht überraschen, wenn die erste RDNA2 GPU Ende 2020 kommt und 2 weitere eben erst 2021.

Wenn N21 nicht RDNA2 ist dann ist es N23 auch nicht,
aber beide sollen besser/gut RT können und HDMI 2.1 unterstützen :confused:

M.f.G. JVC

Gerüchte zu GPUs, die noch nichtmal ihren Tapeout hatten sind praktisch immer ausgedacht. Der Kreis der Leute die Details dazu wissen ist so klein, dass schon ein Wunder geschehen muss, damit was nach Außen dringt. Die einzigen Infos, die es gerade zu RDNA2 glaubwürdig sind, sind AMDs eigene Aussagen und teilweise Spekulationen basierend auf den Next-Gen Konsolen Dev-Kits.

gravitationsfeld

2019-09-13, 21:32:16

Navi21 muss auch gar kein RDNA2 sein. Davon ab kriegen die Konsolen eh keine Stangenware, sondern ihre üblichen Custom-Lösungen.
PS4 und Xbox One sind vanilla Southern Islands.

reaperrr

2019-09-13, 22:42:46

Mal abgesehen davon steht RDNA2 bestimmt auch nicht umsonst in den Folien immer auf der Zeitlinie, wo auch 2021 drauf ist. Würde mich nicht überraschen, wenn die erste RDNA2 GPU Ende 2020 kommt und 2 weitere eben erst 2021.

Nö, ich finde RDNA2 steht auf der Zeitlinie ziemlich eindeutig auf der Position von 2020.

PS4 und Xbox One sind vanilla Southern Islands.
Oder anders ausgedrückt, die auf Wünsche der Konsolenhersteller entwickelten Features, wie z.B. die ACEs, die auf Sony zurückgehen, schaffen es meist auch zeitnah zu - bzw. teils vor - den Konsolen in die dedizierten GPUs, weil die Vorlaufzeiten zwischen festzurren der uArch-Details und Release des fertigen Produktes für die Konsolen deutlich länger sind.

gravitationsfeld

2019-09-14, 01:03:04

Die ACEs sind die selben wie in den Desktop-Chips. Sony hat die leicht modernere Variante.

Digidi

2019-09-14, 02:19:03

Ich behaupte mal, dass genau der Punkt mit besserer Programmierbarkeit gemeint ist. RDNA verringert die Anforderungen ein wenig. zB kann man jetzt eine workgroup size von 32 ohne performance einbußen nehmen, was insbesondere den Entwicklern entgegen kommt, die eh alles nur auf Nvidia optimieren. Außerdem kann auch bei hohem register pressure noch guter Durchsatz erreicht werden, wenn der Compiler gute Arbeit macht. Viel mehr seh ich aber auch nicht.

Warum programmieren denn alle auf Nvidia? Ich verstehe die Entwickler nicht. Wenn man bedenkt die 300 Euro Aufpreis von Nvidia fehlen nun bei den Spielen. Von den Niedrigen Hardwarepreisen hätten doch auch etwas die Entwickler davon.

Gebrechlichkeit

2019-09-14, 04:09:41

Ich tippe weil Nvidia halt mit dem "Ueberschuss" an Knete, den einen oder anderen finanziell unter die Arme greift. Die mit SDK etc. wahrscheinlich einen besseren Support abliefert und AMD seit Jahren eher eine "... wir passen das Spiel XYZ an, wenn es draussen ist" Route faehrt weil die vor ein paar Jahren oder evtl. immernoch auf Grund von Nvidia "gesponserten" titel erst nach dem Release selbiger Zugriff haben / Patch bereit stellen koennen.

HOT

2019-09-14, 07:55:34

Eines sollte ganz klar sein: Da RDNA2 noch in Design ist, kommt der nicht vor 2.HJ 2021! Dann ist alles vorher nicht RDNA2, so einfach ist das.
Da die Konsolen aber RT haben, wird auch RDNA1 RT-fähig sein, wenn man es wünscht.
Ich fürchte nur, dass man bei AMD für Hardware-RT auf den Enthusiastenchip warten muss, der scheint ja später nachgeschoben zu sein.
Das stimmt das eben doch so: N14 5600 und N12 5800. N21 könnte irgendne Custom oder Minilösung sein und N23 ist all in, im Gegensatz zum Rest aber in N7FF+.
RDNA1-Chips könnten, so sie auf N7 designt sind, allerdings auch schon in N7 Pro kommen, der Prozess ist kompatibel und AMD könnte auch beide Prozesse (und den 6nm-Refresh) mit 7nm+ meinen. Das könnte außerdem für N12 schon gelten.

Damit wäre N12 dann ca. 400mm² groß, hätte 6x CUs und 384Bit GDDR6 und käme evtl. in 7nm Pro und ohne Hardware-RT.

Edit: Danke für den Hinweis, war falsch geschrieben.

basix

2019-09-14, 10:23:02

In Design heisst nicht, dass sie gerade erst angefangen haben, sondern dass sie noch nicht fertig sind ;) Zen 4 ist auch noch "in design", ist schon länger in Entwicklung und kommt 2021. Und neue CPUs haben zudem deutlich länger dauernde Validierungen vor sich. RDNA2 wird mit grosser Wahrscheinlichkeit 2020 kommen, spätestens 1.HJ 2021.

HOT

2019-09-14, 11:12:46

So optimistisch bin ich da bei Weitem nicht.

Ich denke, dass der Zeitplan realisitischer ist, wenn man die Zeiträume etwas verlängert:

Zen2: Juli 2019 (N7)
Navi10: Juli 2019 (N7)
Navi14: Oktober 2019 (N7)
Renoir mobil: Dezember 2019 (N7)
Navi12: Anfang 2020 (N7 (Pro))
Renoir Desktop Mai 2020 (N7)
Navi 23: 2. HJ 2020 (N7+)
Vemeer: Ende 2020 (N7+)
Renoir Refresh Ende 2020 (N6)
RDNA2 "10" Mitte 2021 (N7+)
Zen3 APU Ende 2021 (N7+)
Zen4: Anfang bis Mitte 2022 (N5 Pro)

in etwa so. Vielleicht gibts ja wie bei N7 -> N7 Pro -> N6 auch noch ne kompatible Verbesserung zu N7+, dann wäre zwischenzeitlich ein Zen3 Refresh denkbar.

JVC

2019-09-14, 11:31:10

Complicated

2019-09-14, 11:49:24

AMDs gesamte Dynamik basiert derzeit auf kleineren Chips als die Konkurrenz um damit schneller die neuen Fertigungen mit immer mehr EUV-Anteil zu adoptieren. Daher ist die Roadmap mit der von TSMCs Roadmap angeglichen. AMD wird direkt nach den SoC-Kunden seine Produkte in die Massenproduktion bringen wollen. Ansonsten geht der Vorteil der kleineren Chips verloren, sobald die Yields für große Chips wirtschaftlich sind. Ich denke hier wird entscheiden ab wann man mit EUV die Kosten wieder so weit runter gebracht hat, um auch wieder größere Chips wieder mit schlechteren Yields wirtschaftlich früher zu launchen. Diese Zeit scheint AMD dafür zu nutzen um die neue RDNA-Architektur konkurrenzfähiger zu machen um wieder etwas den großen Chips von Nvidia entgegen stellen zu können.

Ich denke das ergibt sich als komplementäre Strategie für den GPU-Markt, da es mit der CPU-Strategie mit Chiplets die besten Synergien ergibt. Bei AMDs 2-Fronten Kampf um Marktanteile wird das eine hohe Priorität einnehmen, die Ressourcen zu effizient wie möglich zu nutzen.

https://www.pcgameshardware.de/Playstation-5-Konsolen-265878/News/Verwirrung-um-RDNA-2-GPUs-der-Next-Gen-Konsolen-doch-auf-RDNA-Basis-1332477/
"Verwirrung um RDNA 2 - GPUs der Next-Gen-Konsolen doch auf RDNA-Basis?"

Ich denke die Verwirrung basiert auf der Annahme, dass die Roadmap für diskrete GPUs die Konsolen Chips mit einschließt mit der RDNA2 Architektur. Das muss nicht gegeben sein.
Da die Konsolen-Chips Semi-Custom sind, könnten diese in Massenproduktion mit RDNA2 gehen und im Anschluss wird dann erst das Design des diskreten GPU-Chips abgeschlossen, sozusagen finalisiert und optimiert für den PC. Das würde auch zu den Gerüchten der Konsolen Priorisierung passen die rumgeisterten.

Auch in dem Link zu lesen:
Da es sich um Custom-GPUs und keine Stangenware handelt, ist das nicht ausgeschlossen. Auch bei der Playstation 4 Pro fand ein ähnliches Vorgehen statt. Sony ließ die bereits betagte Grafikeinheit der Mid-Generation-Konsole, eine leicht beschnittenen Radeon HD 7870, um ein damals aktuelles Vega-Feature in Form von Rapid Packed Math erweitern.

JVC

2019-09-14, 11:59:49

Ich denke die Verwirrung basiert auf der Annahme, dass die Roadmap für diskrete GPUs die Konsolen Chips mit einschließt mit der RDNA2 Architektur. Das muss nicht gegeben sein.
Da die Konsolen-Chips Semi-Custom sind, könnten diese in Massenproduktion mit RDNA2 gehen und im Anschluss wird dann erst das Design des diskreten GPU-Chips abgeschlossen, sozusagen finalisiert und optimiert für den PC. Das würde auch zu den Gerüchten der Konsolen Priorisierung passen die rumgeisterten.
Danke :smile:
Also ist der Konsolen "N21" nicht gleich dem PC "N21".

Ich hoffe es kommen bald echte HDMI 2.1 Grakas!

M.f.G. JVC

dildo4u

2019-09-14, 12:07:09

https://www.pcgameshardware.de/Playstation-5-Konsolen-265878/News/Verwirrung-um-RDNA-2-GPUs-der-Next-Gen-Konsolen-doch-auf-RDNA-Basis-1332477/
"Verwirrung um RDNA 2 - GPUs der Next-Gen-Konsolen doch auf RDNA-Basis?"

Momentan bin ich auch Verwirrt ^^

M.f.G. JVC
Die Konsolen sind Custom Chips Sony und MS bekommen das serviert was sie wollen.Die PS4 Pro nutzt z.b die Polaris Generation kann aber trotzdem FP 16.
Das ist kein Neues Konzept,natürlich wollen sie keine weitere Generation ohne RT gehen.
Dann hätten alle PC GPUs in 2021 RT und die Konsolen 2025 noch nicht,ich vermute das sie vermeiden wollen das nur die späteren Konsolen Updates RT bekommen.
Weil damit die Hardware Bais für die Entwickler zu klein wäre und man die Optik nicht zu 100% auf RT Nutzung auslegen könnte.
Man hätte also die jetzige Situation wo es immer nur aufgesetzt wirkt.

Setsul

2019-09-14, 15:07:24

Die Konsolen sind Custom Chips Sony und MS bekommen das serviert was sie wollen.Die PS4 Pro nutzt z.b die Polaris Generation kann aber trotzdem FP 16.
Genau das isses, RT läuft ja auch auf GTX, nur eben langsamer. Genauso wie FP16 erfordert das keine fundamental andere Architektur oder größere Überarbeitungen, das sind einfach noch ein paar Funktionen zusätzlich in den Ausführungseinheiten.

gravitationsfeld

2019-09-14, 22:26:46

Die Konsolen sind Custom Chips Sony und MS bekommen das serviert was sie wollen.Die PS4 Pro nutzt z.b die Polaris Generation kann aber trotzdem FP 16.
PS4 und Xbox One (inklusive X) sind Southern Islands. PS4 Pro ist Southern Islands + FP16 in den ALUs + Checkerbox-Zeug. Nix Polaris.

Setsul

2019-09-14, 23:43:17

Dann lügt uns Sony an.
https://twitter.com/PlayStation/status/773600156356866048/photo/1
https://youtu.be/11XjMplfTd4?t=1135

gravitationsfeld

2019-09-15, 00:00:25

"Elements" = FP16. "Beyond" = Checkerboard. Marketing fuer 100 bitte.

Complicated

2019-09-15, 01:17:16

PS4 ist Polaris. Nur weil immer noch GCN ISA beim programmieren verwendet wirs ist es nicht Southern Island.
https://www.pcgameshardware.de/Playstation-4-Pro-Konsolen-264565/News/Bietet-Features-der-neuen-AMD-Vega-GPUs-1211169/
*Die neue PS4 Pro bietet zwei Features, die Polaris noch nicht beherrscht und wohl erst mit Vega auf dem Desktop erhältlich sein werden.

gravitationsfeld

2019-09-15, 01:54:41

Marketing. PS4 ist kein Polaris. Sie haben zwei drei Features zurueckportiert, das war's.

Grendizer

2019-09-15, 06:36:31

PS4 ist Polaris. Nur weil immer noch GCN ISA beim programmieren verwendet wirs ist es nicht Southern Island.
https://www.pcgameshardware.de/Playstation-4-Pro-Konsolen-264565/News/Bietet-Features-der-neuen-AMD-Vega-GPUs-1211169/

https://www.extremetech.com/extreme/171375-reverse-engineered-ps4-apu-reveals-the-consoles-real-cpu-and-gpu-specs

Die size on the chip is 328 mm sq, and the GPU actually contains 20 compute units — not the 18 that are specified. This is likely a yield-boosting measure, but it also means AMD implemented a full HD 7870 in silicon.

robbitop

2019-09-15, 08:03:51

Die Diskussion schon wieder...
Wenn jemand der für das Teil entwickelt es so sagt, wird er es wissen.

deekey777

2019-09-15, 08:32:40

PS4 und Xbox One sind vanilla Southern Islands.
Die Diskussion hatten wir definitiv.

Als SI wären PS4 und Xbox One hinter Kaveri/Puma-APUs.

HOT

2019-09-15, 09:19:25

Immer bedenken, dass die Konsolen in einem anderen Prozess hergestellt werden als die Grafikchips. Es werden also 16nm GCN1.1 sein, nicht Polaris.

xyleph

2019-09-15, 10:42:35

Marketing. PS4 ist kein Polaris. Sie haben zwei drei Features zurueckportiert, das war's.

Man hat also lieber Southern Island geshrinkt anstatt gleich Polaris zu nehmen?

Der Grund wird ja die Kompatibilität sein, auch wenn es mich wundert, dass der Unterschied der Architekturen dann doch so groß ist, sodass man diesen Aufwand gegangen ist.

Setsul

2019-09-15, 11:09:56

Marketing. PS4 ist kein Polaris. Sie haben zwei drei Features zurueckportiert, das war's.
Welche Features wurden denn nicht zurückportiert?
Ansonsten ist nach der Begründung alles von Bonaire bis Vega nur Southern Islands mit "zurückportierten" Features.

danarcho

2019-09-15, 11:10:01

SI und CI sind vom encoding zu 99% gleich, und dann wieder VI und Vega. Dazwischen hat sich das Encoding aber stark verändert, was wohl der Grund sein dürfte dann nicht zu wechseln.

reaperrr

2019-09-15, 14:12:59

PS4 und Xbox One (inklusive X) sind Southern Islands. PS4 Pro ist Southern Islands + FP16 in den ALUs + Checkerbox-Zeug. Nix Polaris.
Also DCC hat die PS4Pro laut diverser Berichte auch. Anhand der Taktraten müsste das Speicherinterface technisch auch mindestens auf Polaris-Niveau sein. Und zumindest 8 ACEs wie die CI-Gen hatte m.W. schon die original PS4 (auch wenn's vielleicht noch die ACEs von GCN1.0 waren, kA).
Da kann man dann nicht mehr von Southern Islands sprechen, bloß weil Instruction Set/Encoding etc. sich (bis auf die neuen Features) nicht geändert haben. Das ist dann schon mindestens eine Hybrid-Architektur.

Zumal Mark Cerny selbst bei der PS4Pro von Polaris sprach:
https://www.extremetech.com/gaming/238261-the-ps4-pros-chief-architect-shares-surprising-details-on-the-systems-architecture
Eventuell ist die Hardware intern weitgehend Polaris, aber man lässt es "nach außen", also API/Treiber (bis auf die neuen Features) wie SI/CI "aussehen", um es den Entwicklern einfacher zu machen und Rückwärts-Kompatibilität mit PS4(Slim) garantieren zu können?

Man hat also lieber Southern Island geshrinkt anstatt gleich Polaris zu nehmen?

Der Grund wird ja die Kompatibilität sein, auch wenn es mich wundert, dass der Unterschied der Architekturen dann doch so groß ist, sodass man diesen Aufwand gegangen ist.
Die R&D-Kosten bei sowas übernehmen mW die Konsolenhersteller, von daher konnte es AMD relativ egal sein, falls es tatsächlich nicht einfach Polaris ist.

https://www.extremetech.com/extreme/171375-reverse-engineered-ps4-apu-reveals-the-consoles-real-cpu-and-gpu-specs

Die size on the chip is 328 mm sq, and the GPU actually contains 20 compute units — not the 18 that are specified. This is likely a yield-boosting measure, but it also means AMD implemented a full HD 7870 in silicon.
Mich irritiert jedes Mal wieder, dass alle möglichen Hardware-Seiten es so darstellen, als wäre die PS4-GPU einfach ein Pitcairn. Pitcairn kann wie Tahiti CUs nur in 4er-Gruppen deaktivieren, und Pitcairn hat weniger ACEs als die PS4-GPU. Bloß weil es im Vollausbau die gleiche CU-Zahl wäre, ist die Implementierung noch lange nicht gleich, und mindestens das Frontend ist es ganz offensichtlich auch nicht, das sitzt laut Die-Shots bei der PS4-GPU nämlich an der Seite, nicht mittig zwischen den CUs wie bei Pitcairn.

xyleph

2019-09-15, 15:00:46

Die R&D-Kosten bei sowas übernehmen mW die Konsolenhersteller, von daher konnte es AMD relativ egal sein, falls es tatsächlich nicht einfach Polaris ist.

Schon klar, mir ging es ja auch um die Konsolenhersteller :-)

Complicated

2019-09-16, 11:42:34

Marketing. PS4 ist kein Polaris. Sie haben zwei drei Features zurueckportiert, das war's.
PS4 ist aber auch kein Southern Island. Typische Entwickleraussage wo alles über die API/ISA definiert wird. Richtig wird es dadurch nicht.

PS4 ist Semi-Custom und hat auch Vega Features. Polaris hat AMD, Sony und MS kommuniziert. Daran würde ich mich mal halten.

Nicht jedes neue Feature in Hardware ist programmierbar. Deshalb gibt es Hardwarefachleute die das besser wissen.

deekey777

2019-09-16, 12:15:54

Auch darum läuft Doom und Wolfenstein so bescheiden auf meiner Xbox One, id software hat die falsche ISA verwendet.

HOT

2019-09-16, 12:33:56

Polaris wurde für 14LPP entwickelt, nicht für 16FF+. Man würde also eine komplett neue Maske entwickeln, die ja völlig fürn popo ist, da sie ja nicht ausgenutzt wird. Das ist absurd, man wird die Technik dafür nutzen, die dafür gedacht ist, allein schon um den Chip so klein wie möglich zu halten.

robbitop

2019-09-16, 13:42:11

Vor allem wissen es irgendwelche Amateure in einem Forum, die das öffentliche Internet als Recherche nutzen es besser als Entwickler, die das SDK da haben, damit jahrelang arbeiten, die Doku da haben und diese inhaltlich kennen und aufgrund ihrer Profession wesentlich tiefere Kenntnisse über HW und ihre Funktionen haben. Ist doch klar. ;)

Jeder Akademiker [und das gilt sicher auch für so einige nicht akademische Berufe], der sich auch nur 1 Jahrzehnt auf eine Branche oder gar 1 Thema spezialisiert, weiß, dass er jeden anderen (auch gleiche Berufsrichtung aber andere Spezialisierung) in dem Thema blind mit beiden Händen hinter dem Rücken fachlich auseiandernehmen kann.
Zumindest wenn das Thema eine gewisse Grundkomplexität hat, die einfach auch Fachkenntnisse und Erfahrung bedürfen, bzw von ihnen profitieren. Entsprechend sollte man hier mit Anmaßung (sofern man weiß was Dunning Kruger bedeutet) in dieser Konstellation sehr zurückhaltend sein. Einfach weil unangebracht.
Fachkollegen könnten sich sowas IMO erlauben, da beide vergleichbare Kenntnise und Erfahrungen als Fundament haben. Tun es in der Praxis aber selten, wenn beide gut sind, da dann die Meinungen nicht so krass abweichen.

Scherz bei Seite: ich vermute, dass die Einschätzung/Bewertung selbst was nun SI ausmacht und was Polaris vermutlich auseiander geht.
Ich tippe darauf, dass gf sich in erster Linie auf die CUs bezieht und weniger auf weiter außen liegende Dinge wie dcc, aces.

In jedem Fall würde ich mich hüten, gf vorzuwerfen, dass er nur die API sieht und nicht weiß wovon er redet. Die Jungs haben garantiert detailierte Dokus über die GPU. Das macht AMD iirc eigentlich immer so.

JVC

2019-09-16, 14:05:51

Ich scheine ja wohl im vergleich zu anderen recht "genügsam" zu sein ^^
Ich erwarte nur möglichst bald einen vollen HDMI 2.1 Support ;)
(ist mir gleich ob von NV oder von AMD, +min 16GB wären nett)

M.f.G. JVC

gravitationsfeld

2019-09-17, 01:19:53

Welche Features wurden denn nicht zurückportiert?
Ansonsten ist nach der Begründung alles von Bonaire bis Vega nur Southern Islands mit "zurückportierten" Features.
So ziemlich alles. Der Chip ist cycle accurate base PS4 kompatibel.

Alles was Steuerungs-Logik ist und auch nur irgendwelche Timings haette aendern koennen wurde nicht angefasst. Polaris hat etliche Optimierungen, die das tun.

Koennt ihr butthurt sein wie ihr wollt, das ist die Realitaet.

ich vermute, dass die Einschätzung/Bewertung selbst was nun SI ausmacht und was Polaris vermutlich auseiander geht.
Noe. Polaris ist bei weitem effizienter als Southern Islands. Das liegt nicht an den Aenderungen die die PS4 Pro erhalten hat. Demzufolge zu behaupten die PS4 Pro sei Polaris ist lachhaft.

Man muesste eine Steigerung der Leistung sehen die ueber die blosse GFLOPs-Erhoehung hinaus geht. Das ist nicht der Fall.

robbitop

2019-09-17, 02:42:30

Du wirst es von allen hier am ehesten wissen. :)
Laut einer alten AMD Präse sollen die (edit: Polaris) CUs 15% mehr Leistung pro Takt (edit: ggü SI) rausbringen. Da muss es schon signifikante Änderungen geben.

gravitationsfeld

2019-09-17, 03:32:32

Das einzige was vielleicht was bringt in vereinzelten Faellen ist DCC. Tut es in der Praxis aber sogut wie nie, oder kostet sogar. Das ist bei Desktop-GCN auch nicht anders.

Wahrscheinlich kommen daher die cherry picked 15%.

Mir faellt echt kein besserer Weg ein wie ich das rueber bringen soll. Es ist kein Polaris weil man an drei Stellen im Chips was veraendert. Zwischen den Desktop-GCN-Revisionen aendert sich an jedem Subsystem was am Chip. Nichtmal das Instruction-Encoding ist Polaris.

robbitop

2019-09-17, 03:35:22

Ggf Missverständnis: Ich meinte Polaris ggü SI sind 15% :)

Frage: Was mich interessieren würde: warum funktioniert die DCC bei GCN nicht? Schließt du da Polaris, Vega und Navi mit ein oder gab es einen Punkt ab dem es sinnvoll funktionierte? Ggf im Zusammenspiel mit dem DSBR und der erhöhten Datenlokalität (Veränderungen am L2) bei Navi?

Locuza

2019-09-17, 03:46:33

Die PS4(Pro) als Southern Islands zu kategorisieren passt aber auch nicht.

Die PS4 hat einige (oder alle?) Sea Islands Instructions und zwei MECs (Micro Engine Compute), welche einer der Kernänderungen von GCN1 zu GCN2 waren.
Bei der PS4 mit insgesamt 8 Compute-Pipelines und 64 Queues.

Die PS4 Pro hat Delta Color Compression, Tessellation Redistribution(Fiji/GCN3 Stichpunkt), FP16-Instructions und auch DPP für Cross-Lane-Operations welche mit GCN3 Einzug erhielten, zusammen mit SDWA.

Paar Sachen, die aber bei der PS4 Pro potentiell fehlen könnten:
800 SGPRs (GCN3, 512 von GCN1-2)
Instruction Pre-Fetching (GCN4)
Größere Instruction Wave Buffer (16 statt 12, GCN4)
L2$-Cache Request Grouping (GCN4)
Theoretisch müsste die Tessellation Performance noch massiv bei zero area triangles anziehen, dank dem Primitive Discard Accelerator von Polaris, den gibt es wahrscheinlich auch nicht in der PS4 Pro?

Mal so grob gefasst.

Die PS4(Pro) als Southern Islands zu kategorisieren passt aber auch nicht.

Die PS4 hat einige (oder alle?) Sea Islands Instructions und zwei MECs (Micro Engine Compute), welche einer der Kernänderungen von GCN1 zu GCN2 waren.
Bei der PS4 mit insgesamt 8 Compute-Pipelines und 64 Queues.

Die PS4 Pro hat Delta Color Compression, Tessellation Redistribution(Fiji/GCN3 Stichpunkt), FP16-Instructions und auch DPP für Cross-Lane-Operations welche mit GCN3 Einzug erhielten, zusammen mit SDWA.

Paar Sachen, die aber bei der PS4 Pro potentiell fehlen könnten:
800 SGPRs (GCN3, 512 von GCN1-2)
Instruction Pre-Fetching (GCN4)
Größere Instruction Wave Buffer (16 statt 12, GCN4)
L2$-Cache Request Grouping (GCN4)
Theoretisch müsste die Tessellation Performance noch massiv bei zero area triangles anziehen, dank dem Primitive Discard Accelerator von Polaris, den gibt es wahrscheinlich auch nicht in der PS4 Pro?

Mal so grob gefasst.

Edit: AMD hat bis zu 15% mehr Leistung pro CU von einer RX480 gegenüber einer 290X angegeben:
https://images.anandtech.com/doci/10446/P9.png

@ Robbitop DCC funktioniert, nur ist das nicht in allen Fällen von Vorteil, was man aber steuern kann.
https://abload.de/img/vega-dccrnjke.jpg
Engine Optimization Hot Lap, Folie 19:
https://gpuopen.com/gdc-2018-presentation-links/

AMD hat bei Carrizo 5-7% angeben, ich glaube Intel hat für Skylake auch mal einstellige Zahlen angeben, insgesamt für die Performance.
https://scr3.golem.de/screenshots/1506/AMD-Carrizo-Tech-Day/AMD-Carrizo-Tech-Day-22.jpg

gravitationsfeld

2019-09-17, 04:00:21

Deine Informationen entsprechen nicht der Realitaet. Nix DPP oder SWDA. Keine Aenderungen an async compute.

Locuza

2019-09-17, 04:40:50

Ganz sicher das die PS4 Pro im Neo-Mode kein DPP/SDWA unterstützt?

Und welche Änderungen in Bezug auf Async Compute meinst du, die von GCN2 oder GCN3?
Nur um das klar zu stellen:
Southern Islands (S.I.) = GCN1
Sea Islands (C.I.) = GCN2
Volcanic Islands (V.I.) = GCN3
Arctic Islands/Polaris = GCN4
Vega = GCN5

Southern Islands/GCN1 hatte immer nur einen Command Processor mit einer GFX-Pipe und zwei Compute-Pipes, bzw. ACEs wie das Marketing es genannt hat.
Jede Compute-Pipe hat nur eine Queue verwalten können.
http://psx-scene.com/forums/attachments/f307/48912d1385194368-official-ps4-hardware-specs-ring.jpg

Bei GCN2 sieht es immer (abgesehen von Bonaire) so aus, dass man einen CP hat und daneben eine oder zwei MECs (Micro Engine Compute):
http://www.vgleaks.com/wp-content/uploads/2013/02/gpu_queues.jpg

Die PS4 besitzt zwei MECs bzw. 8 Compute-Pipes, wovon jede 8 Compute-Queues verwalten kann, für insgesamt 64-Queues.

Ab GCN3 und den HWS (Hardware Wave Scheduler) wird es etwas verwirrend.
AMD gab an, dass es für Compute Wave Preemption verwendet wird und dann eben für VR (Quick Response Queue) oder TrueAudio Next mit reservierten CUs.
Aber die Quick Response Queue wurde auch unter GCN2 mit einem Treiber-Update unterstützt.

gravitationsfeld

2019-09-17, 05:17:04

Ganz sicher das die PS4 Pro im Neo-Mode kein DPP/SDWA unterstützt?
100%. Das wuerde neues Instruction-Encoding erfordern.

Locuza

2019-09-17, 05:50:03

Man nehme an, dass stellt eine Erweiterung dar, die nur im Neo-Mode funktioniert und im Base-Mode ansonsten alles gleich bleibt, dann wäre das doch kein Problem?

gravitationsfeld

2019-09-17, 06:01:32

Viel zu viele Transistoren im CU-Hot-Path fuer zwei unterschiedliche Instruction-Encodings. GPUs haben keine Instruction-Decoder, da werden direkt Bits gesetzt.

Sony hat aber tatsaechlich die 8 pipe ACE, aber auch schon in der base PS4. Also ist es nich ganz nur Southern Islands, das geb ich zu.

deekey777

2019-09-17, 09:04:01

HOT

2019-09-17, 09:46:58

Die werden beide 1.0 sein, aber da die Architektur ja sehr modular ist, wird man da neuere Erweiterungen, falls eben machbar, übernommen haben. Das wird einfach dem geschuldet sein, dass man die Entwicklung des SoC in der 1.0-Ära begonnen hat. Das zieht sich auf der Konsole eben durch bis heute.
Für die neuen Konsolen wird das nicht viel anders sein, die bauen auf RDNA1 auf und fügen Erweiterungen der Nachfolgegenerationen hinzu mit weiteren Refreshes. PC-Grafik ist und bleibt ne andere Liga.

xyleph

2019-09-17, 14:20:23

So ziemlich alles. Der Chip ist cycle accurate base PS4 kompatibel.

Alles was Steuerungs-Logik ist und auch nur irgendwelche Timings haette aendern koennen wurde nicht angefasst. Polaris hat etliche Optimierungen, die das tun.

Interessante Info, gerade da der Tenor doch immer ein anderer ist. Ich gehe davon aus, dass dies dann auch auf die XBX zutrifft?

Complicated

2019-09-17, 15:18:32

Complicated

2019-09-17, 15:22:36

Vor allem wissen es irgendwelche Amateure in einem Forum, die das öffentliche Internet als Recherche nutzen es besser als Entwickler, ..
Da du Dunning Kruger zitiert hast hinterfrage mal die Prämise die du hier aufstellts selber. Besser mal per PN nachfragen welche beruflichen Qualifikationen jemand hat.

HOT

2019-09-17, 15:24:32

https://www.computerbase.de/2019-09/gpu-geruechte-amd-navi-12/

CB geht von meiner ursprünglichen Theorie aus, dass N12 und N14 jeweils kleine Chips sind (nur umgedreht, N12 der 5600 und N14 der 5500) und erst N21 und N23 die Großen sind.
Ich teile aber nicht die Ansicht, dass die großen RDNA2 sind. Ich denke, das wird RDNA1 mit RT sein. RDNA2 kommt mMn erst 2021. Da vertrau ich der Roadmap mehr.

robbitop

2019-09-17, 15:37:56

Da du Dunning Kruger zitiert hast hinterfrage mal die Prämise die du hier aufstellts selber. Besser mal per PN nachfragen welche beruflichen Qualifikationen jemand hat.

Na da bin ich aber gespannt. Erleuchte mich - gern auch per PN. Und wenn weder GPU Entwicklung noch AAA 3D Engine für Spiele Entwicklung dabei herauskommt, dann ist es nicht das gleiche fachliche Level in diesem spezifischen Punkt. Auch ist das Vorliegen und Kennen der Doku der beiden GPUs (die öffentlich nicht vorliegt afaik) und das Devkit essenziell um da wirklich auf Augenhöhe mitreden zu können.

Wenn das alles vorliegen sollte, korrigiere ich mich gern.

Gipsel

2019-09-17, 15:41:45

Die Xbox One hat damals auf die Cache Kohärenz mittels FCL und RMB (damals noch onion und garlic) verzichtet und eher Intels Ansatz mit LLC verfolgt mit dem zusätzlichen eSRAM.
https://www.heise.de/newsticker/meldung/Xbox-Scorpio-Microsoft-verzichtet-auf-ESRAM-3606866.htmlDer Link ist in Bezug auf die Aussage nicht zielführend und außerdem stimmt es auch nicht. Der 32MB SRAM war überhaupt kein Cache (also auch kein LLC) sondern einfach nur ein direkt adressierbarer Speicherbereich mit höherer Performance als der DDR3. War halt nur etwas klein.

Complicated

2019-09-17, 16:30:06

Wenn das alles vorliegen sollte, korrigiere ich mich gern.
Fühl dich korrigiert bis auf den Punkt mit dem Entwickler. Für deine Erleuchtung bin ich allerdings nicht zuständig. Ich gab dir lediglich den Hinweis, dass Softwareentwickler nicht die besseren Hardwareexperten sind. Zumal gravitationsfeld mittlerweile ja bestätigt hat dass seine Äußerung zu absolut war. Daran erkennt man Fachleute...das Forum dient eben diesem Austausch, wenn man nicht gerade damit beschäftigt ist andere sofort als Ahnungslos zu diskreditieren. Aber Schwamm drüber...

Complicated

2019-09-17, 16:33:16

Der Link ist in Bezug auf die Aussage nicht zielführend und außerdem stimmt es auch nicht. Der 32MB SRAM war überhaupt kein Cache (also auch kein LLC) sondern einfach nur ein direkt adressierbarer Speicherbereich mit höherer Performance als der DDR3. War halt nur etwas klein.
Mag als LLC zu salopp gewesen sein für die Xbox und referenzierte lediglich auf Intels Bezeichnung für den Extra-RAM auf seinen "APUs".

robbitop

2019-09-17, 16:48:27

Fühl dich korrigiert bis auf den Punkt mit dem Entwickler. Für deine Erleuchtung bin ich allerdings nicht zuständig. Ich gab dir lediglich den Hinweis, dass Softwareentwickler nicht die besseren Hardwareexperten sind. Zumal gravitationsfeld mittlerweile ja bestätigt hat dass seine Äußerung zu absolut war. Daran erkennt man Fachleute...das Forum dient eben diesem Austausch, wenn man nicht gerade damit beschäftigt ist andere sofort als Ahnungslos zu diskreditieren. Aber Schwamm drüber...
Also kein Zugriff auf die Doku und das SDK. Entwickler =/ Entwickler. Und GPUs =/ andere HW. Ergo: nicht auf Augenhöhe.

Dino-Fossil

2019-09-17, 16:54:56

http://giphygifs.s3.amazonaws.com/media/tFK8urY6XHj2w/giphy.gif

Complicated

2019-09-17, 17:15:27

Also kein Zugriff auf die Doku und das SDK. Entwickler =/ Entwickler. Und GPUs =/ andere HW. Ergo: nicht auf Augenhöhe.
Huuuuuhhhhh..Hexenwerk:
https://www.golem.de/news/playstation-4-sony-macht-jagd-auf-sdk-4-5-1707-129068.html
https://www.zdnet.de/88215044/hacker-veroeffentlichen-xbox-one-sdk/
Kindisch und vor allem argumentativ nicht schlüssig oder relevant für den Inhalt meines Postings. Du diskutierst Kompetenzen unnötigerweise wenn der Entwickler schon eingeräumt hat, dass seine Aussage eben nicht zugetroffen hat. Weiter mit dem Offtopic? Wenn du hier eine Mehrklassen-Foren-Gesellschaft etablieren willst wo nur ausgewählte Berufe sich äussern dürfen, bist du wohl mit dem Konzept eines Forums nicht ausreichend vertraut. Gibt es aus dieser Richtung auch noch sachdienliches zum Thema oder betreibst du hier nur eine Stellvertreter-Diskussion - Wo ist deine Augenhöhe?

Locuza

2019-09-17, 18:53:56

Vielleicht irre ich mich, aber die Diskussion hatten wir vor einigen Jahren, insbesondere im Hinblick auf Kabini und Temash. Und damals galt der allgemeine Konsens, dass die APU der PS4 GCN 1.1 hätte und die APU der Xbox One GCN 1.0. Oder eben umgekehrt.
Was beides nicht ganz zutrifft.

Die werden beide 1.0 sein, aber da die Architektur ja sehr modular ist, wird man da neuere Erweiterungen, falls eben machbar, übernommen haben. Das wird einfach dem geschuldet sein, dass man die Entwicklung des SoC in der 1.0-Ära begonnen hat. Das zieht sich auf der Konsole eben durch bis heute.
Für die neuen Konsolen wird das nicht viel anders sein, die bauen auf RDNA1 auf und fügen Erweiterungen der Nachfolgegenerationen hinzu mit weiteren Refreshes. PC-Grafik ist und bleibt ne andere Liga.
Eine Chimäre ist ja kein Löwe oder eine Schlange, sondern eben ein Mix.
Wenn es fast schon dazwischen ist, könnte man auch GCN1.5 sagen oder RDNA1.5, je nachdem wie es aussehen wird.

Die Xbox One hat damals auf die Cache Kohärenz mittels FCL und RMB (damals noch onion und garlic) verzichtet und eher Intels Ansatz mit LLC verfolgt mit dem zusätzlichen eSRAM.
https://www.heise.de/newsticker/meldung/Xbox-Scorpio-Microsoft-verzichtet-auf-ESRAM-3606866.html
FCL/RMB und Onion/Garlic sind ja das gleiche und je nach Marketingfolie und Dokumentation sieht man das eine oder andere.
http://1.bp.blogspot.com/-AXBc57ku98s/Uk_NjnegL3I/AAAAAAAABcw/8k3872bAC5E/s1600/Kaveri+Onion+++.jpg

Radeon Memory Bus bzw. Garlic sind dabei non-coherent Leitungen zum Speicher, die für den maximalen Durchsatz ausgelegt sind.
Den Bus bei der Xbox One könnte man genauso nennen, funktionell gibt es keinen Unterschied.
Interessant wird es aber bei dem Vergleich zu Onion bzw. Onion+ und wie das im Detail bei der Xbox One aussieht.
Über einen Bus für Cache-Kohärenz verfügt die Xbox One auch, sogar mit insgesamt höheren Durchsatz, als bei der PS4 (30GB/s vs. 20GB/s).
https://images.anandtech.com/doci/7528/Screen%20Shot%202013-11-20%20at%203.46.46%20AM.png

gravitationsfeld

2019-09-17, 21:00:59

Die Xbox hat natuerlich Garlic und Onion. Der ASSRAM ist unabhaengig davon und nur von der GPU addressierbar.

Das ist uebrigens ein Unterschied in den neueren Chips mit Infinity Fabric. Da ist einfach immer alles kohaerent.

Brillus

2019-09-17, 23:43:47

Navi 12/14 könnte weiter weg sein als gedacht, wenn der Linux-Treiber non-experimental gesetzt werden soll wenn der Launch näher rückt.

https://www.phoronix.com/scan.php?page=news_item&px=Navi-12-Navi-14-AMDGPU-Exp

Complicated

2019-09-18, 15:09:10

Die Xbox hat natuerlich Garlic und Onion. Der ASSRAM ist unabhaengig davon und nur von der GPU addressierbar.

Ja klar hat sie garlic und onion...nur wird es nicht genutzt wenn die GPU exklusiv auf einen zusätzlichen Speicherchip zugreift.
Wo ist das dann gemeinsamer Speicherbereich mit der CPU?
Bei der PS4 ist auch immer alles kohärent...dazu braucht es kein IF.

@Locuza
Ja...genau das habe ich geschrieben. Garlic und onion wurden durch FCL und RMB im Marketing ersetzt. Der mehr Datendurchsatz ist die Herstellung der Datenkohärenz des gemeinsam adressierbaren Speichers. Genau das habe ich geschrieben.
In diesen PDF ist das schön zusammengefasst. Leider nur einen Google Link gefunden auf die schnelle
https://developer.amd.com/wordpress/media/2013/06/1004_final.pdf

unl34shed

2019-09-18, 16:56:45

Ja klar hat sie garlic und onion...nur wird es nicht genutzt wenn die GPU exklusiv auf einen zusätzlichen Speicherchip zugreift.
Wo ist das dann gemeinsamer Speicherbereich mit der CPU?
Bei der PS4 ist auch immer alles kohärent...dazu braucht es kein IF.

Der Trick bei der Xbox ist die geteilte MMU, exklusiv dürfte der ESRAM damit nicht mehr sein, auch wenn er nur von der GPU genutzt wird.

https://www.extremetech.com/wp-content/uploads/2017/01/Xbox-One-Block.png

Wobei das irgendwie Offtopic ist.

Complicated

2019-09-18, 17:15:46

Das Bild zeigt doch exakt was ich schrieb. Der DDR ist gemeinsam adressierbar und der Zusatzspeicher nur durch die GPU exklusiv verwendbar. Das Sync der pagetables in der MMU wäre unnötig bei gemeinsamen Speicheradressen....das ist im Prinzip Intels Aufbau mit Kohärenz über den LLC (was auch L3 bedeuten kann)

Die PS4 hat nur eine Speichersorte die einen gemeinsamen Adressbereich hat für CPU und GPU.
PS4 mit hUMA Xbox one ohne hUMA.

Nur von der GPU genutzt ist die Definition eines exklusiven Speichers für die GPU.
Ja du hast recht es schweift zu sehr ab...bin dann auch raus dazu. Es gibt genügend Threads wo das alles schon vor Jahren diskutiert wurde.

Gipsel

2019-09-18, 18:47:43

Das Sync der pagetables in der MMU wäre unnötig bei gemeinsamen Speicheradressen....das ist im Prinzip Intels Aufbau mit Kohärenz über den LLC (was auch L3 bedeuten kann)Was? Nein!

Edit:
Gibt es keinen Konsolenthread, in dem man das auswälzen könnte? :rolleyes:

gravitationsfeld

2019-09-18, 19:01:14

Wo ist das dann gemeinsamer Speicherbereich mit der CPU?
Der gesamte DDR3. ESRAM ist nicht teil des gemeinsamen Speicherraums.

Bei der PS4 ist auch immer alles kohärent...dazu braucht es kein IF.
Nein, Garlic ist nicht kohaerent. CPU writes werden nicht von der GPU gesehen ohne GPU cache flush.

Complicated

2019-09-18, 20:00:36

Der gesamte DDR3. ESRAM ist nicht teil des gemeinsamen Speicherraums.
Schreibe ich chinesisch?

Das Bild zeigt doch exakt was ich schrieb. Der DDR ist gemeinsam adressierbar und der Zusatzspeicher nur durch die GPU exklusiv verwendbar.
Nein, Garlic ist nicht kohaerent. CPU writes werden nicht von der GPU gesehen ohne GPU cache flush.
Nett am Thema vorbei - Onion ist zuständig für Kohärenz, siehe Quelle:
https://developer.amd.com/wordpress/...1004_final.pdf (https://developer.amd.com/wordpress/media/2013/06/1004_final.pdf)

- AMD Fusion Compute Link (ONION):ƒThis bus is used by the GPU when it needs to snoop the CPU cache, so is a coherent busƒ This is used for cacheable system memory

– Radeon Memory Bus (GARLIC):ƒThis bus is directly connected to memory and can saturate memory bandwidth, so is a non coherent busƒThis is used for local memory and USWC (uncached speculative write combine)

Etwas seltsam dass hier alle wieder bei Adam und Eva anfangen - das ist Jahre alt das Zeug.

gravitationsfeld

2019-09-18, 21:12:42

:rolleyes:

Alter, willst du mich verarschen? Ich hab hier vier Dev-Kits stehen.

Du mappst Speicher entweder als Garlic oder Onion, nicht *beides* auf einmal. Das wird in den Page-Tables festgelegt und schliesst sich gegenseitig aus.

Wenn du Onion benutzt nuckelt die GPU mit 30GB/s am GDDR5. Alle Texturen etc. sind Garlic. Diese Daten sind nicht kohaerent mit der CPU.

Mit infinity fabric gibt es das nicht mehr. Die GPU liest Daten immer CPU kohaerent. IF ist praktisch Onion in voller Geschwindigkeit und Garlic faellt weg.

Complicated

2019-09-19, 04:14:42

Ja sag mal willst mir jetzt erzählen dass die Hardware die beides kann nur weil du dich für Garlic entscheidest beim mapping deshalb die PS4 kein Onion hat? IF ist nicht Voraussetzung für hUMA.

Wer verarscht denn hier wen?

gravitationsfeld

2019-09-19, 05:47:49

Ich zitiere:
Bei der PS4 ist auch immer alles kohärent...dazu braucht es kein IF.
Das ist einfach Schwachsinn. Ist es nicht. Es ist kohaerent wenn es Onion ist, was man nicht benutzen will, weil es zu langsam ist.

nur weil du dich für Garlic entscheidest
Als ob das eine Entscheidung waere. Wenn ich alles auf Onion setze hab ich noch 10 FPS. Du verlierst mal eben 90% der Speicher-Bandbreite und die GPU wuerde komplett verhungern. Onion setzt man vielleicht auf 50-100MB des Speicher und das war's. Und falls es noch nicht durchgesickert ist: Nein, du kannst nicht einfach Speicher mit Garlic und Onion benutzen. So funktioniert das nicht.

Garlic ist nicht kohaerent, aber schnell. Onion ist kohaerent, aber lahm. Infinity Fabric ist beides. Das ist ein massiver Vorteil.

Garlic ist im Uebrigen fuer die CPU langsam zu beschreiben, selbst wenn man den GPU-L2-Cache-Flush in Kauf nimmt, weil es write combined memory ist. Entweder du hast lahmen CPU- oder lahmen GPU-Zugriff auf den derzeitigen Konsolen. Im Prinzip ist das wie eine dedizierte Karte am PC zu haben, ausser dass man den Speicher aus einem Pool verteilen kann.

Complicated

2019-09-19, 11:45:48

LasterCluster

2019-09-19, 13:06:11

Im Prinzip ist das wie eine dedizierte Karte am PC zu haben, ausser dass man den Speicher aus einem Pool verteilen kann.

Wird das einen großen Unterschied machen, wenn sich das mit der neuen Generation ändert?

JVC

2019-09-19, 13:30:58

Ich hab hier vier Dev-Kits stehen....

Auch schon ein neues :uconf2:

M.f.G. JVC

gravitationsfeld

2019-09-19, 18:36:05

Ok kann ich so annehmen. Das war auch der erste Post der nicht Stückwerk war und der deinerseits die Zusammenhänge darstellt wie du Sie wahrnimmst als Entwickler.

Warum nicht gleich so sondern den ganzen halbgaren Mist mit Halbaussagen zuvor?
Danke. Zumindest ist jetzt alles präzise Ausgedrückt technisch..nach dem ganzen Schwachsinn zuvor. Jetzt weiss ich auch wo deine Hardware Kenntnisse anzusiedeln sind... das sah bis zu diesem Post nicht besonders aus. Zumindest kennst du deine API und dein SDK.
"Zumindest kennst du deine API und dein SDK"

Ich geh mal kurz lachen. Das ist so absurd :ugly:

Warum nicht gleich so? Weil ich mich nicht vor dir zu rechtfertigen habe. Wer Scheisse schreibt braucht keinen Aufwand erwarten.

Die Xbox One hat damals auf die Cache Kohärenz mittels FCL und RMB (damals noch onion und garlic) verzichtet und eher Intels Ansatz mit LLC verfolgt mit dem zusätzlichen eSRAM.
https://www.heise.de/newsticker/meld...M-3606866.html
Allein das zeigt mir dass du noch nie irgend was auf irgend einer Konsole programmiert hast, sonst wuerdest du nicht so einen Duenschiss von dir geben.

Die PS4 und die Xbox One haben exakt den gleichen Speicher-Aufbau, bis auf den ESRAM. Es gibt bei beiden Garlic und Onion und es funktioniert exakt gleich.

Der ESRAM ist auch kein "Last Level Cache. Er ist ueberhaupt kein Cache. Es ist scratch pad memory fuer die GPU.

Wird das einen großen Unterschied machen, wenn sich das mit der neuen Generation ändert?
Ja.

LasterCluster

2019-09-19, 21:31:04

Wo wird sich das deiner Meinung nach am deutlichsten auswirken? Gibt es da potenzielle Vorzeigeanwendungsfälle oder ist eher n deutliches 'quality of life improvement' für Entwickler?

robbitop

2019-09-19, 21:54:27

Reine Annahme eines Laiens - man möge mich gern korrigieren:
Wenn Kohäherenz ohne große Flaschenhälse funktioniert kann man ggf mehr Compute von der CPU auf die GPU schieben? ZB Physik - gern auch mehr als Effektphysik. Wenn Latenz und Bandbreite passen wäre das sicherlich nett. Ggf wäre deutlich mehr Zerstörbarkeit möglich? (ist ja auch immer eine Contentfrage)

Zossel

2019-09-20, 05:59:53

Complicated

2019-09-21, 08:51:25

Warum nicht gleich so? Weil ich mich nicht vor dir zu rechtfertigen habe. Wer Scheisse schreibt braucht keinen Aufwand erwarten.

Rechtfertigen? Erzähl einfach nicht Bullshit und dann musst du auch nicht zurück rudern. PS4 ist kein Southern Island in Hardware. Das ist dann ja wohl geklärt.
PS4 und Xbox One (inklusive X) sind Southern Islands. PS4 Pro ist Southern Islands + FP16 in den ALUs + Checkerbox-Zeug. Nix Polaris.Offensichtlich hilft es nicht eine Konsole programmieren zu können
...
Den Rest mit LLC und dem anderen Mist kannst du gerne nochmal nachlesen was ich dazu geschrieben habe- Textverständnis ist nicht so deins? Nichts von dem was du sagt "ist nicht" habe ich irgendwo behauptet. Das machst du hier die ganze Zeit im Verlauf der Diskussion...

robbitop

2019-09-21, 14:17:36

Wie viel Kenntnisse über die HW braucht man um mittels Shader Intrinsics besseren/schnellere Code als der Compiler (GCN GPU) zu erzeugen? Benötigt das genaues Verständnis des Aufbaus der CUs?

Complicated

2019-09-23, 07:23:28

pixeljetstream

2019-09-23, 09:21:24

Wie viel Kenntnisse über die HW braucht man um mittels Shader Intrinsics besseren/schnellere Code als der Compiler (GCN GPU) zu erzeugen? Benötigt das genaues Verständnis des Aufbaus der CUs?
Viele intrinsics liefern Funktionalität die der Compiler nicht von sich aus generieren könnte. Deswegen werden die shadersprachen ja auch um sie erweitert oder um Befehle die nah dran sind (z.bsp die wave operationen in HLSL/subgroup in glsl).
Ich weiß nicht was du mit "detailliert" meinst, im Grunde sollte man immer wissen was Durchsatz, Latenz und Synchronisierung ist. Aber imo reicht oft auch aus was die Motivation hinter den befehlen ist, ohne super Details. Bei Konsolen eher etwas mehr Details weil HW/Compiler eingefroren sind und man dann wirklich noch das letzte rausholen kann. Bei PC würde man imo eher Bugs gegen Compiler filen wenn der gewisse pattern nicht gut macht (afaik gibt's jenseits von CUDA keine Möglichkeit gpu binaries treiber unabhängig zu shippen).

robbitop

2019-09-23, 11:18:02

Wenn man es nicht benötigt muss man es auch nicht wissen. Warum schreibst du ihm dann Wissen zu das er nicht benötigt? Ich habe das nicht vorausgesetzt...du warst derjenige der das tat. Als Argument, dass man doch hier ihm nicht widersprechen solle. Und jetzt argumentierst du mit meinem Argument?
Du missverstehst da was. Ich wollte damit implizit darauf hinweisen, dass gf ziemlich genaue Kenntnisse über die HW haben muss, um deutlich schnelleren Code als den des Shadercompilers zu erzeugen. Dazu gab es von ihm einen Vortrag auf der GDC vor einigen Jahren. Der Mann gehört rein zufällig zu den besten (und in der Branche anerkannten) handvoll Engineentwicklern - und das auch noch von der best optimiertesten Engine die es im Moment gibt. Entwickler in dieser Branche dürfen oftmals aus NDA Gründen nicht zu sehr ins Detail gehen - entsprechend hat man in der Öffentlichkeit nur die Wahl ihnen zu glauben oder halt auch nicht.

Complicated

2019-09-23, 12:41:28

robbitop

2019-09-23, 13:32:05

Gipsel

2019-09-23, 14:12:22

Den Rest mit LLC und dem anderen Mist kannst du gerne nochmal nachlesen was ich dazu geschrieben habe-Ähm, Du sagst, es: Was Du zum (angeblichen) LLC (der eSRAM ist keiner) geschrieben hast, war Mist (hatte ich Dich auch schon vorher drauf hingewiesen). :rolleyes:

Complicated

2019-09-23, 15:10:26

Und wir haben das auch geklärt, oder nicht. Der Mist ist nicht was geschrieben wurde sondern wie man das versucht zu interpretieren. Dafür, dass keiner das Thema will reitet ihr alle ganz schön darauf rum. Ich schreibe was ich meine und nicht was andere gerne rein lesen.

Complicated

2019-09-23, 15:13:38

Ich denke er hat sich in Bezug auf das Featurelevel eher auf das Instructionset und die CU bezogen als das „drumherum“ (ACEs, DCC etc). Ist halt Definitionssache. IMO kann man da sehr schnell aneinander vorbei reden ohne in der tatsächlichen Angelegenheit unterschiedlicher Meinung zu sein.

Das sehe ich genauso. Daher halte ich es für deplatziert daraus dann ein Experte vs. Forenuser ohne Ahnung zu machen und "wage es nicht etwas zu schreiben Ketzer."
Es schadet keinem Experten für Klarheit zu sorgen in Aussagen. Sonst braucht man sie auch nicht in Foren wenn sie sowieso nichts erklären wollen.

Für arrogantes von oben herab braucht es keine Experten...das können auch ahnunglose User. ;)

robbitop

2019-09-23, 15:42:51

Wie gesagt stehen solche Leute unter NDA. Da ist dann wenig Spielraum für Erläuterungen ohne Hintergrundinfos preiszugeben. Entweder glaubt man es ihnen oder halt nicht.
Und solche Leute sind IMO wertvoll für das Forum. Insofern ist mMn Respekt angesagt.
Alphatier von dice wurde durch solches Anpflaumen bspw schon vertrieben. Und das ist echt schade.

sulak

2019-09-23, 21:02:25

Unicous

2019-09-23, 22:13:34

Das hat keine wirkliche Relevanz, der Typ stochert im Dunkeln.

Generell frage ich mich warum dieses PCGamesN seit eins, zwei Jahren halbgare und halbwahre Artikel streut und das auch durch social media und Co. weiter verbreitet wird. Davor hat kein Hahn nach denen gekräht?:confused:

y33H@

2019-09-23, 23:16:32

siehe WTF Tech ...

Unicous

2019-09-23, 23:49:17

Ich gebe dir ausnahmsweise nur teilweise recht:wink:, denn WTF-Tech hat ja zum Teil schon "Quellen" oder zumindest informierte Tippgeber. Die Artikel sind natürlich trotzdem Schrott und ein ständiges Wiederkäuen.

PCGamesN interpretiert hier ohne jegliche Anhaltspunkte etwas in einen Patch hinein, der mit der Realität von Linux kollidiert. Und sie sind in der Vergangenheit schon negativ mit ihrer Berichterstattung auf Kotaku/IGN-Niveau aufgefallen.

Complicated

2019-09-24, 16:39:11

Alphatier von dice wurde durch solches Anpflaumen bspw schon vertrieben. Und das ist echt schade.
Ich habe niemanden angepflaumt. Du hast als einziger jemanden angepflaumt...mich.
Und NDA ist wohl zu diesem Thema sehr an den Haaren herbeigezogen.

aufkrawall

2019-09-24, 16:47:39

Alphatier von dice wurde durch solches Anpflaumen bspw schon vertrieben. Und das ist echt schade.
Ist dir schon mal aufgefallen, dass Demirug nie angepflaumt wird?
Btw. hat der von dir genannte Member auch selber gerne ausgeteilt.

Gipsel

2019-09-24, 17:50:23

Das wird jetzt hier aber arg Offtopic. :rolleyes:

Leonidas

2019-09-25, 08:44:10

Ontopic ist eine Radeon RX 5500 im GFXBench:
https://gfxbench.com/device.jsp?benchmark=gfx50&os=Windows&api=gl&D=AMD+Radeon+RX+5500&testgroup=info

gravitationsfeld

2019-09-26, 08:49:39

Das mag ja alles stimmen. Das befreit doch nicht davor eine sinnvolle Diskussion in einem Forum zu führen. Argumente bestätigen sich nicht durch VIP Status. Und auch Referenten können Fehler machen, wie er selber doch eingeräumt hat mit dem pauschalen SI Schuss der sich eben als unwahr rausgestellt hat.

Also was ist hier die Diskussion?
Es ist nicht unwahr. Deine Einbildungen haben mit der Realität nichts zu tun.

Ich kenn die HW specs. Du glaubst irgendwelchen Marketing-Slides.

Und PS4 Peo ist auch ganz bestimmt nicht Polaris, ESRAM ist kein Cache, es ist nicht "alles immer kohärent" und der Mond nicht aus Käse.

Laber nicht.

Ich spreche dir sogar ab überhaupt zu verstehen was Cache-Kohärenz überhaupt ist. Maximal Dunning Kruger mal wieder. Keine Ahnung von nichts haben aber große Klappe.

Complicated

2019-09-26, 15:23:37

Und PS4 Peo ist auch ganz bestimmt nicht Polaris, ESRAM ist kein Cache, es ist nicht "alles immer kohärent" und der Mond nicht aus Käse.

Laber nicht.

PS4 Neo du Genie. Und zeig mir wo ich schrieb der ESRAM sei Cache. Wenn du so die Hardware Spec liest wie meine Beiträge, wissen wir schon wo das Problem ist. Dunning Kruger my ass. Ich bin dann mal raus...einmal mit Profis reden in diesem Forum.

BoMbY

2019-09-26, 16:47:43

gravitationsfeld

2019-09-26, 18:28:30

PS4 Neo du Genie. Und zeig mir wo ich schrieb der ESRAM sei Cache. Wenn du so die Hardware Spec liest wie meine Beiträge, wissen wir schon wo das Problem ist. Dunning Kruger my ass. Ich bin dann mal raus...einmal mit Profis reden in diesem Forum.
Jup, Neo ist kein Polaris. Das ist die Klarheit die du willst.

Bye Felicia. Niemand wird dich vermissen. "Einmal mit Profis reden" hahahahaha ;D

Im Gegensatz zu dir weiss ich genau was du schreibst. Und es ist Duennschiss.

Rabiata

2019-09-26, 18:39:21

Ontopic ist eine Radeon RX 5500 im GFXBench:
https://gfxbench.com/device.jsp?benchmark=gfx50&os=Windows&api=gl&D=AMD+Radeon+RX+5500&testgroup=info
Deutet irgendwas bei den Werten darauf hin dass es sich um eine Navi handelt? Ich gehe immer noch von Rebrands am Lower-End aus, die Frage ist wo das anfängt, und wo es aufhört?
Der Link von Leo zeigt leider nur einen Score, 87,6 FPS in Manhattan (onscreen) mit OpenGL. Sehr dünne Datenbasis. Aber im selben Test hat eine RX560 84.8 FPS geschafft. Das gibt schon einen guten Anhaltspunkt:
Falls es ein Rebrand ist, dann ziemlich sicher etwas auf Baffin-Basis, wegen der übereinstimmenden Leistung.

Gehen wir mal auf den "Info"-Reiter im Link und schauen uns parallel die Info zur RX560 an. Dann zeigen sich folgende Unterschiede:
GL_DEPTH_BITS: 16 für RX560, 24 für RX5500
Zusätzliche GL-Extensions für RX5500: GL_AMD_gpu_shader_half_float_fetch, GL_ARB_polygon_offset_clamp

OpenGL-Experten an die Front:
Seht ihr hier eher einen Unterschied in der Hardware oder im Treiber?

Locuza

2019-09-26, 20:21:36

Jup, Neo ist kein Polaris. Das ist die Klarheit die du willst.
[...]
Neo ist aber auch nicht pauschal Southern Islands, ebenso wenig die original PS4.

reaperrr

2019-09-26, 20:47:35

Der Link von Leo zeigt leider nur einen Score, 87,6 FPS in Manhattan (onscreen) mit OpenGL. Sehr dünne Datenbasis. Aber im selben Test hat eine RX560 84.8 FPS geschafft. Das gibt schon einen guten Anhaltspunkt:
Falls es ein Rebrand ist, dann ziemlich sicher etwas auf Baffin-Basis, wegen der übereinstimmenden Leistung.
Es würde aber auch sehr gut zu einem Navi12 passen, wenn der ein halbierter Navi14 ist (außer beim SI, aber da halt dann G5 statt G6).

Gipsel

2019-09-27, 14:12:41

Also wenn sich der Umgangston einiger Kandidaten hier sich nicht deutlich bessert, gibt es Konsequenzen.

Gipsel

2019-09-27, 14:28:07

Und zeig mir wo ich schrieb der ESRAM sei Cache.
Erkläre mir mal in vernünftiger Weise genauer, wie Du das meintest:
Die Xbox One hat damals auf die Cache Kohärenz mittels FCL und RMB (damals noch onion und garlic) verzichtet und eher Intels Ansatz mit L[ast]L[evel]C[ache] verfolgt mit dem zusätzlichen eSRAM.Wie von mir (und Anderen) schon damals geschrieben, ergibt das nicht wirklich Sinn, genausowenig wie Deine damalige Erläuterung dazu:
Mag als LLC zu salopp gewesen sein für die Xbox und referenzierte lediglich auf Intels Bezeichnung für den Extra-RAM auf seinen "APUs".Intels Cache ist tatsächlich ein (gemeinsamer) LLC-Cache (keine Ahnung, welche intel-APUs Du meinst, aber meinst Du Broadwell-C mit dem eDRAM? Wobei das eigentlich auf ziemlich egal ist) und funktioniert deutlich anders als der eSRAM der XB1. Insofern ist keinem so recht klar, wovon Du da redest.

Egal, wir müssen das hier nicht weiter OT auswalzen. Aber manchmal würde es gut sein, wenn auch die eigene Fehlbarkeit einkalkulieren würde. ;)

Leonidas

2019-09-27, 15:37:39

AMDs Navi 14 kommt wohl mit 128-Bit-Interface, Navi 12 hingegen mit 256-Bit-Interface:
https://www.3dcenter.org/news/amds-navi-14-kommt-wohl-mit-128-bit-interface-navi-12-hingegen-mit-256-bit-interface

BoMbY

2019-09-27, 15:49:04

SDP hat nicht direkt was mit dem Speicher zu tun. Es deutet eigentlich nur darauf hin dass der Chip größer sein könnte:

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

Edit: Ein GDDR6 Controller ist 32 Bit breit, wenn ein Controller je über einen SDP angebunden ist, bräuchte man für 256 Bit folglich 8 SDPs?

Auch hier ist nur von einem SDP pro MC die Rede: http://www.freepatentsonline.com/10037150.pdf

LasterCluster

2019-09-27, 16:22:58

Die Meldung mit dem kommenden GloFo 12nm+ Prozess fügt sich doch ganz gut ins Bild. P21 (und P12?) werden noch ne Weile mitgeschleift und irgendwann auf 12nm+ portiert. Navi ist leistungstechnisch dann N14-N10-N12.

amdfanuwe

2019-09-27, 17:26:10

Ist die Lücke zwischen N14 und N10 nicht zu groß?
N14 mit 24 CU dürfte ca. 580/590 Leistung bringen. Da würde AMD den 200€ Bereich Nvidia mit 1660, 1660Ti und 2060 komplett überlassen. Momentan steht da noch gut Vega 56, aber die dürfte ja auch mal auslaufen und sollte durch etwas effizienteres ersetzt werden.
Ich tippe da eher auf N12-N14-N10. Nächstes Jahr diese auf 6nm refreshed und N21 N23 als 5800 und 5900 mit RDNA.

Leonidas

2019-09-27, 17:28:14

Ist die Lücke zwischen N14 und N10 nicht zu groß?

Ist eher ungewöhnlich klein. Normalerweise setzt AMD glatte Halbierungen an, die 24CU von N14 sind aber 60% der 40CU von N10. Zwischen 5600XT mit 24CU und 5700Vanilla mit 36CU sind es sogar nur 67%. Da bekommt man bestenfalls noch eine Grafikkarten dazwischen, aber keinen Grafikchip.

reaperrr

2019-09-27, 17:36:15

Ist eher ungewöhnlich klein. Normalerweise setzt AMD glatte Halbierungen an, die 24CU von N14 sind aber 60% der 40CU von N10. Zwischen 5600XT mit 24CU und 5700Vanilla mit 36CU sind es sogar nur 67%. Da bekommt man bestenfalls noch eine Grafikkarten dazwischen, aber keinen Grafikchip.
Jup, die Lücke zwischen Polaris 10 und 11 war prozentual noch deutlich größer und trotzdem hat AMD nix dazwischengesetzt (wenn man die Intel- und Apple-exklusiven Modelle mal ignoriert).
Schon ein N10 mit weiteren 4 deaktivierten CUs hätte nur noch 33% mehr CUs als der N14-Vollausbau. Viel zu wenig Platz für einen Chip dazwischen.

Da würde AMD den 200€ Bereich Nvidia mit 1660, 1660Ti und 2060 komplett überlassen.
Ich schätze, dass N14XT in der 8GB-Version die 1660 schlagen wird. Scheint NV angesichts der kommenden 1660S auch anzunehmen. Den Rest kann man über das P/L-Verhältnis regeln.

Die 2060 non-S kostet aktuell genauso viel wie die 5700 (günstigste Modelle bei ~325€) und dafür gibt's auch noch weniger Speicher, was genau hat die mit dem 200€-Bereich zu tun?...

Und irgendwann wird auch die 5700 unter die 300€-Grenze fallen und von oben Druck auf die 1660Ti ausüben. Man muss nicht zwingend ein Gegenstück zu jedem exakten Preispunkt der Konkurrenz haben.

Locuza

2019-09-27, 17:48:30

Es wäre auf jeden Fall ein sehr fließender Überging.
Die Frage bei Navi14 war, ob er mit 24 CUs/1536 ALUs sich unter, über oder direkt gegenüber einen TU116 platzieren würde, welcher auch 1536 ALUs hat und ein 192-Bit Interface.
Jetzt macht es den Anschein, dass Navi14 sich darunter platzieren wird und auf ein 128-Bit Interface setzen.

Mit Navi12 dazwischen wäre das Leistungsspektrum aber wirklich sehr flüssig, aber einen großen Chip über Navi10 kann ich mir auch nicht ganz vorstellen.

@ Bomby

GDDR6 ist Dual-Channel memory, jeder Channel ist 16-Bit breit, entsprechend könnte ein SDP pro Channel passen.

BoMbY

2019-09-27, 18:17:34

amdfanuwe

2019-09-27, 18:19:23

Locuza

2019-09-27, 18:40:55

Joa, aber bei HBM können die SDPs anscheinend dann 64 bzw. 128 Bit breit sein? Wobei der Bezug auf die Channels schon sein könnte wenn man Virtuelle Channels bei HBM2 betrachtet.

Naja, will nicht heißen dass es falsch ist, aber für mein Gefühl lehnt man sich im Moment mit solchen Aussagen in Bezug auf SDPs und Speicherkanäle noch sehr weit aus dem Fenster. Vielleicht lässt sich das auch anders konfigurieren und man kann mit 16 SDPs 512 bit GDDR6 anbinden.
Die Portbreite fällt vermutlich je nach GPU anders aus, Raven Ridge verwendet pro SDP 256-Bit (32 Bytes) bzw. 512-Bit bidirektional, bei 1.6 Ghz kommen da entsprechend 102.4GB/s bzw. 204.8 GB/s durch.
https://fuse.wikichip.org/wp-content/uploads/2018/08/raven_ridge-sdf_plane_bandwidth.png

Das sieht heftig oversized aus, für DDR4-3200, welches nur 51.2 GB/s liefern kann.
Jedenfalls mit 16 SDPs mit 256-Bit (32 Bytes) SDPs bei 1.75 Ghz (14Gbps GDDR6) könnte man theoretisch 896 GB/s durchschaufeln bzw. wenn sie nur halb so breit sind, genau 448GB/s, die GDDR6-Bandbreite von Navi10.

Keine Ahnung wie das im Detail wirklich läuft, aber mit 16 SDPs würde ich z.B. kein krummes Interface erwarten, sondern 256-Bit oder 512-Bit GDDR6, letzteres wäre aber ein fetter Kostentreiber, den jedes Unternehmen gerne scheut.
HBM2(e) ist auch ein Kostentreiber, den man ungern benötigen würde, aber das wäre auch noch eine Möglichkeit die Bandbreite hoch zu treiben, falls Navi12 wirklich größer und schneller werden soll, als Navi10.

BoMbY

2019-09-27, 18:49:10

Es gibt auch eine weitere Möglichkeit: Der Wert im Code ist noch nicht final, und vielleicht wird noch eine 24 eingeschoben, oder eine 12, oder was auch immer.

Setsul

2019-09-27, 18:50:01

@BoMbY:
HBM Channels sind zwar 8 Mal so breit aber die Transferrate pro pin ist ~1/8 also sollte sich das nichts nehmen. Es geht ja nur darum die Daten zum MC zu bringen. Wieviele Leitungen der nach außen führt interessiert IF doch nicht.

BoMbY

2019-09-27, 19:38:59

Ja, wenn ich das richtig sehe definiert die Anzahl SDPs wie viele Datenpakete bzw. Datenblöcke gleichzeitig übertragen werden können. Da macht es natürlich schon Sinn sich an den Speicherkanälen zu orientieren. Die bei Vega verwendeten HBM2-Module dürften alle 4Hi mit je zwei virtuellen Kanälen pro Ebene sein.

Das war mir neu dass GDDR6 auch pro Modul zwei Kanäle nutzt, aber es ist zumindest offensichtlich dass Navi10 acht Speichercontroller zu haben scheint.

Berniyh

2019-09-28, 08:26:58

HBM2(e) ist auch ein Kostentreiber, den man ungern benötigen würde, aber das wäre auch noch eine Möglichkeit die Bandbreite hoch zu treiben, falls Navi12 wirklich größer und schneller werden soll, als Navi10.
Sollte nicht HMB2 bis 2020 deutlich günstiger und wettbewerbsfähiger werden?

Zudem würde ich nach wie vor nicht ausschließen, dass Navi12 evtl. gar nicht in Consumerprodukte kommt, sondern, dass es sich eher um einen Workstation Chip handelt und da wäre der Mehrpreis von HBM wieder nicht so gravierend.
Es gibt auch eine weitere Möglichkeit: Der Wert im Code ist noch nicht final, und vielleicht wird noch eine 24 eingeschoben, oder eine 12, oder was auch immer.
Klar, die Möglichkeit besteht natürlich immer.

Letztendlich war für mich die wichtigste Erkenntnis eigentlich eher, dass Navi12 kein Chip unterhalb von Navi14 ist, denn das war ja nach der bisherigen Gerüchtelage eine der beiden Optionen.
Und die Erkenntnis kann man basierend auf dem Code wohl als recht gesichert ansehen.

Das bzgl. der Speicherinterfaces ist hingegen nur Spekulation.

HOT

2019-09-28, 10:04:26

N12 hat bestimmt 2 HBM2E Stapel, die ja schon koloportiert wurden. Damit wäre man auf ca. 700-800MT/s, was gut zu 64CUs passen würde.

reaperrr

2019-09-28, 13:40:56

N12 hat bestimmt 2 HBM2E Stapel, die ja schon koloportiert wurden. Damit wäre man auf ca. 700-800MT/s, was gut zu 64CUs passen würde.
Und zumindest was Packaging/Interposer angeht, wäre es schon noch günstiger als Vega20, da ja nur halb so viele Stacks.

Außerdem würde ein Navi mit den kolportierten 64CUs nur so in der Lage sein, 5700XT-nahe Taktraten innerhalb von 300W zu bewerkstelligen, was wiederum nötig wäre, um im Bereich >= 2080Ti zu landen. Und das würde dann auch Preise erlauben, mit denen auch die höheren Kosten durch HBM nicht das große Problem sein sollten.

BoMbY

2019-09-28, 13:58:26

Naja, ich schätze ein Navi mit 64 CUs und zwei Stacks Flashbolt mit zusammen 820 GB/s Bandbreite dürfte NVidia auf jeden Fall nicht gut gefallen.

Locuza

2019-09-28, 14:09:41

Sollte nicht HMB2 bis 2020 deutlich günstiger und wettbewerbsfähiger werden?

Zudem würde ich nach wie vor nicht ausschließen, dass Navi12 evtl. gar nicht in Consumerprodukte kommt, sondern, dass es sich eher um einen Workstation Chip handelt und da wäre der Mehrpreis von HBM wieder nicht so gravierend.

Klar, die Möglichkeit besteht natürlich immer.

Letztendlich war für mich die wichtigste Erkenntnis eigentlich eher, dass Navi12 kein Chip unterhalb von Navi14 ist, denn das war ja nach der bisherigen Gerüchtelage eine der beiden Optionen.
Und die Erkenntnis kann man basierend auf dem Code wohl als recht gesichert ansehen.

Das bzgl. der Speicherinterfaces ist hingegen nur Spekulation.
Allgemein sind die DRAM-Preise aktuell Gott sei Dank deutlich geringer, als zum Vega10-Start.
Die Preisdifferenz zwischen HBM und G5/6-Speicher ist möglicherweise auch gesunken, aber nach wie vor möchte jedes Kind und die Oma HBM-Speicher für HPC/Datacenter-Produkte verwenden, egal ob GPUs, FPGAs, irgendwelche AI-Beschleuniger oder sonst etwas.
Die Packaging-Sache wird in aktueller Form nach wie vor teuer bleiben.
Cool wäre es, wenn man sich den ganzen Interposer sparen könnte und eine kostengünstigere Alternative anbieten könnte.
InFO_MS/UHD von TSMC könnte sich in naher Zukunft für so etwas anbieten:
https://fuse.wikichip.org/news/2567/tsmc-talks-7nm-5nm-yield-and-next-gen-5g-and-hpc-packaging/2/

Das Navi12 schneller, als Navi14 wird, konnte man auch von anderer Stelle erraten.
Navi12 hat das P-Kürzel (Performance), während Navi14 mit M (Mainstream) beschrieben wird:
https://twitter.com/TUM_APISAK/status/1140818866316013568

V für Value sollte bei Low-End-Ablegern stehen.

Bezüglich Navi12 habe ich so meine Zweifel über Leistungsambitionen von AMD mit RDNA1.
Mit 16 SPDs denke ich nicht, dass Navi12 ein Flaggschiff mit 4096 ALUs wäre.

TU104 (2080 Super) mit 3.072 ALUs verwendet auch nur 256-Bit GDDR6-Speicher und liegt 24% vor Navi10.
https://abload.de/img/n120dkvc.jpg
https://www.computerbase.de/2019-07/geforce-rtx-2080-super-test/2/#abschnitt_benchmarks_in_2560__1440

Das könnte AMD mit 20-30% über Navi10 in Angriff nehmen.
Aber wie bei Nvidia wären die Abständen pro GPU-Chip dann ziemlich klein, weswegen das Argument bezüglich dem Abstand zwischen den Chips insofern erhalten bleibt, egal ob Navi12 langsamer oder schneller als Navi10 wäre.
Navi14 hat laut Benchmark-Einträgen 24 CUs/1.536 ALUs (schon max oder gar mehr?), Navi10 hat 40 CUs/2.560 ALUs, also trennen beide Chips nur 16 CUs, nehmen wir die gleichen 16 CUs plus für N12, dann wären wir auch schon bei 3.584 ALUs.
Und Navi12 mit 56-64 CUs würde ich halt anzweifeln, der Chip hat auch nur 16 SDPs, ist RDNA1, wäre ein entsprechend großer Chip unter 7nm usw., da bin ich nicht positiv gestimmt.
HBM2e ist auch erst für 2020 zu erwarten und eher eine High-End-Geschichte, da denke ich nicht das AMD irgendwo in H1 2020 mit Navi12 damit auftaucht.

robbitop

2019-09-28, 14:30:56

Dem würde ich auch so zustimmen. 256 bit GDDR6 hat endliche Bandbreite für eine Leistungssteigerung ggü Navi 10. Ich würde 48 CUs tippen. Damit kommt man auf einen doppelten Navi14 (der ja mit 128 bit auch funktionieren sollte ) und kommt in etwa auf 2080 Super Niveau. (bzw liegt ggf zwischen der 2080 und der 2080 super).

Im Hinterkopf sollte man behalten, dass TSMC aktuell der einzige Fertiger mit 7 nm Wafern für nicht-mobiles ist, dessen Serienfertigung auch schon seit Monaten reif ist. Die Waferstarts sind begrenzt. Und wie man sieht, kann AMD mit Rome wesentlich mehr Geld verdienen als mit Ryzen und Navi. Dazu sinkt der Yield bei gleicher defect density mit steigender Chipgröße. Ich tippe darauf, dass aufgrund beider Hintergründe nicht all zu sehr abdrehen wird.

Navi 2x wird nächstes Jahr, wenn mehr 7 nm Kapazität da ist und das Featurelevel auch bei RT ist, ggf eher im High End Markt mitmischen.

reaperrr

2019-09-28, 14:56:17

Ich würde 48 CUs tippen.
In 7nm, wo die Fix-Kosten für Design und Masken viel höher als in 16/14/12nm sind, einen weiteren Chip aufzulegen, der außer 20% mehr CUs keine nennenswerten Änderungen beinhaltet?
Ergibt null Sinn.

So gering ist nicht mal der Abstand zwischen TU104 und TU106, denn wie man an der 2070S sieht, bringt die doppelte Zahl GPCs durchaus was für die IPC je SM.
Dann wäre es sinnvoller gewesen, N10 direkt mit 48 CUs auszustatten. Die CUs dürften nur ca. die Hälfte der Die-Fläche ausmachen, von daher hätte das nur ~10% mehr Fläche bedeutet.

Nein, alles unter 56 CUs macht für einen Chip oberhalb von N10 absolut keinen Sinn. Und dann macht HBM2 mehr Sinn, als bei GDDR6@256bit zu bleiben.

Agent117

2019-09-28, 15:00:46

reaperrr

2019-09-28, 15:05:57

N14 (768 SP, 128 Bit, 8 GT/s GDR5)
N12(1536 SP, 256 Bit, 8 GT/s GDR5)
N10 (2560 SP, 256 Bit, 14 GT/s GDR6)

Für N14 sind 24CUs (also 1536 SP), 128bit SI und GDDR6 de facto bestätigt durch Treibereinträge etc.
Und für N12 ist inzwischen so gut wie sicher, dass er über N10 liegt.

BoMbY

2019-09-28, 15:44:36

Ich würde 48 CUs tippen.

Es macht absolut null Sinn einen Chip mit so geringem Abstand zu Navi10 zu bauen.

Agent117

2019-09-28, 15:50:55

Für N14 sind 24CUs (also 1536 SP), 128bit SI und GDDR6 de facto bestätigt durch Treibereinträge etc.

Das mit den 24 CUs war doch noch nicht gesichert. Da gab es doch bei N10 den Irrtum dass man vor Release von nur 20 CUs ausging und dann später rauskam, dass das eine Fehlauslesung war, da jew. 2 CUs sich nun viele Ressourcen teilen und als 1 CU erkannt wurden.

Wenn es wirklich 24 Cus sind dann denke ich auf Basis der restlichen Einträge zu N12 auch dass er größer als N10 wird. Wäre erfreulich, denn so wird es in Q4 nochmal spannend:smile:

Locuza

2019-09-28, 15:51:15

Bei Nvidia liegen zwischen TU106 (36 SM) und TU104 (48 SM) 768 ALUs bzw. 12 SMs.
Navi10 hat 40 CUs vs. 36 SMs bei TU106, würde AMD einfach weiter so skalieren und sich an Nvidia orientieren, wären wir bei theoretisch 52 CUs für Navi12, welcher sich gegenüber einem TU104 positionieren würde, ähnlich wie Navi10 gegenüber TU106.

Edit: @Agent117

Die ComputeBench-Einträge zu Navi14 listen auch 12 CUs:
https://compubench.com/device.jsp?benchmark=compu20d&os=Windows&api=cl&D=AMD+7340%3AC1&testgroup=info

Was bei Navi eben die Dual-Compute-Units sind, mit jeweils 128-ALUs, weswegen das mit 24 CUs passen sollte.

robbitop

2019-09-28, 15:55:39

HOT

2019-09-28, 16:07:43

Bei einem Chip oberhalb von Navi 10 würde fehlendes Raytracing aber shon ein wichtiges Argument für Nvidia, besonders wo jetzt sicher ist, dass die Next Gen Konsolen es können. Als Pro Argument könnten da nur mehr Speicher und geringerer Preis oder gleicher bei mehr als 2080 Super Leistung herhalten.

Dann muss man sich auch langfristig gegen Ampere positionieren können.

Ich halte daher für am wahrscheinlichsten für das RDNA Gen1 Lineup:

N14 (768 SP, 128 Bit, 8 GT/s GDR5)
N12(1536 SP, 256 Bit, 8 GT/s GDR5)
N10 (2560 SP, 256 Bit, 14 GT/s GDR6)

N14 wird damit oberhalt der neuen 3000er APUs angesiedelt was Grafikpower betrifft. Man wollte ja auch mehr ins Notebookgeschäft. N12 beerbt P10.

Andrerseits sollten die Konsolenchips deutlich längere Vorlaufzeiten haben. Fand es von den Fachzeitschriften auch sehr gewagt diese einfach als RDNA 2 einzustufen. Das ist erstmal zeitlich sehr sportlich und auch sonst sehr einfach gedacht. Will sagen: Raytracing in Hardware sollte RTG schon lauffähig haben und vlt wird das ja doch was mit N12 > N10 und Raytracing. Mglw. ist aber das Gegenteil Teil des Konsolendeals:wink:
Na die machen bestimmt 256Bit, wenn man was mit 128 machen könnte, so ein Quatsch... davon abgesehen, dass 8GT auch noch richtig Saft brauchen, 128Bit GDDR6 mit 1200-1500 Shader ist sinnvoll, sonst nix. Bei NV ist GDDR5 ja salvage, das ist was anderes.

Eher N14: 1,5k shader mit 128Bit GDDR6, salvage dann 1,2k.
N10 kennen wir
N12 ist dann mindestens (!!!) 30% mehr als N10. 64 CUs passt also gut. Und gepaart mit HBM2E hätte das auch problemlos genügend Bandbreite. Das dürfte schon die wahrscheinlichste Variante sein.

BoMbY

2019-09-28, 16:11:47

Die ComputeBench-Einträge zu Navi14 listen auch 12 CUs:
https://compubench.com/device.jsp?benchmark=compu20d&os=Windows&api=cl&D=AMD+7340%3AC1&testgroup=info

Was bei Navi eben die Dual-Compute-Units sind, mit jeweils 128-ALUs, weswegen das mit 24 CUs passen sollte.

Das ist der WGP-Mode welcher bei OpenCL für Navi10 standardmäßig eingeschaltet ist. Der lässt sich auch per Environment-Variable ausschalten:

http://browser.geekbench.com/v4/compute/4355420

reaperrr

2019-09-28, 16:27:49

Wenn es mehr CUs sein sollten, passt doch die SDP Anzahl aber nicht, oder? 16 SDPs bedeuten 256 bit Memoryinterface, oder ist das falsch?
Wesentlich mehr CUs bräuchten jedenfalls IMO mehr Bandbreite.
Siehe Update der News.
16 SDPs kann auch 2048bit HBM-SI bedeuten, wie bei Vega10.

Außerdem hängt die 5700XT verglichen mit früheren AMD-Karten so gut wie gar nicht im Bandbreiten-Limit.
Mit 16-18 Gbps GDDR6 (der ja schon verfügbar ist) und verdoppeltem L2$ könnte auch ein 256bit G6 SI noch für bis zu 56 CUs reichen. HBM2 halte ich aber für wahrscheinlicher.

deekey777

2019-09-28, 16:35:25

Locuza

2019-09-28, 17:16:12

Wenn es mehr CUs sein sollten, passt doch die SDP Anzahl aber nicht, oder? 16 SDPs bedeuten 256 bit Memoryinterface, oder ist das falsch?
Wesentlich mehr CUs bräuchten jedenfalls IMO mehr Bandbreite.
TU104 mit 3072 ALUs bzw. 48 SMs hat auch nur ein 256-Bit Interface.
Nur der TU102 mit maximal 4608 ALUs bzw. 72 SMs hat ein 384-Bit Interface.

48-52 CUs wären noch in dem Rahmen, indem sich auch Nvidia mit einem 256-Bit-Interface bewegt.
Eine 2070 verwendet einen vollen TU106 (14Gbps G6, 448GB/s), eine 2080 Super einen vollen TU104 (15.5Gbps G6, 496GB/s), bei CB liegt ein Perf-Unterschied von 33% zwischen beiden, wobei dank der Taktraten die 2080 Super ungefähr 5-10% schneller läuft und der Unterschied eher bei 40-45% liegen sollte.
https://www.computerbase.de/2019-07/geforce-rtx-2080-super-test/2/#abschnitt_benchmarks_in_2560__1440

https://www.computerbase.de/2018-10/nvidia-geforce-rtx-2070-test/2/#abschnitt_die_tatsaechlichen_taktraten_unter_last_mit_gpuboost_40
https://www.computerbase.de/2019-07/geforce-rtx-2080-super-test/2/#abschnitt_die_tatsaechlichen_taktraten_unter_last

Ich denke die Bandbreite kostet hierbei schon einige Prozent.

Man muss sich ja sowieso überraschen lassen, ich bin vorerst pessimistisch und sehe wenn dann eher TU104-Niveau vor uns.
Das wäre noch ein relativ sinniges Produkt, ohne das AMD das die übermäßig aufblasen müsste, samt Interface-Speed oder Breite.

BoMbY

2019-09-28, 18:13:51

reaperrr

2019-09-28, 18:56:39

Da halte ich die Wahrscheinlichkeit von zwei HBM2 oder HBM2e Stapeln mit 600 (z.B. Aquabolt 2.4 Gbps) bis 800 GB/s (z.B. Flashbolt) für deutlich höher als irgendwas das weniger als 16 CUs von Navi10 entfernt ist.
Jup, am wahrscheinlichsten ist mMn, dass folgendes Gerücht schlicht und ergreifend stimmt:

https://www.gamestar.de/artikel/radeon-rx-5800-xt-navi-12-mit-4096-shadern-gegen-geforce-rtx-2080-ti,3347214.html

Lehdro

2019-09-29, 12:34:03

Jede Menge fragwürdiges Spekulatius: (https://www.youtube.com/watch?v=lzJWS3gLOuw)

https://abload.de/img/mooreslawisdead17kif.jpg

robbitop

2019-09-29, 12:49:45

Mit HBM hat man such nun 2x im Consumermarkt in die Nesseln gesetzt (Verfügbarkeit/Preis). Es ist wahrscheinlich besser geworden - aber wäre GDDR nicht sinniger/günstiger? Zur Not eben breiteres SI.

tEd

2019-09-29, 12:57:30

Hauptgrund für die Entscheidung für HBM bei den Highend Modellen wird die Stromaufnahme sein.

robbitop

2019-09-29, 13:08:38

Ja den Grund hört man häufig. So groß kann der Unterschied in der Praxis nicht sein. Vega 10 und 7 hat es in Bezug auf Perf/W nie sonderlich geholfen. Polaris hingegen hatte da nicht die großen Probleme. Mit UV sieht es anders aus und hat auch mit dem Betriebspunkt zu tun.
Wenn es sich unterm Strich unter Berücksichtigung aller Randbedingungen lohnen würde (Preis, Verfügbarkeit/Perf/W etcpp) - hätte NV dann im High End nicht auch das gleiche gemacht? Bis dato machen sie das nur im Bereich der HPC GPUs.

aufkrawall

2019-09-29, 13:16:06

Der Vergleich hinkt, weil Polaris nur ein 256 bit Interface hat.

LasterCluster

2019-09-29, 13:26:31

Fast 50% deaktivierte CU's in manchen Modellen und das bei einem teuren Prozess. Das will ich irgendwie nicht glauben. Und zwei verschiedene Speichertypen für N12? Vielleicht sind die 5900er N21 oder N23

BoMbY

2019-09-29, 13:31:58

Ja, ziemlich sicher sind die 5900er 20er Navis. 5800 Möglicherweise Navi12, 5600 Navi14, alles darunter vermutlich Rebrands von Polaris oder Vega12.

Der_Korken

2019-09-29, 13:38:58

Die ganzen Spekulationen um Big-Navis vergessen immer gerne wie groß der Verbrauch sein müsste. 56 oder 60CUs mit leicht reduziertem Takt und HBM (oder 256bit GDDR6) könnten noch unter 300W landen, aber 80CUs ist doch total abgehoben. Chips mit >2080Ti-Leistung erwarte ich erst mit der zweiten Navi-Gen. Da nimmt man noch 7nm+ mit und hat sicherlich auch noch an der Effizienz der gerade erst releasten Architektur geschraubt.

Lustig, dass in dem Video bei 4:20 nochmal alte "Leaks" zu Navi gezeigt wurden. Da stimmt quasi nichts. Absolut nichts. Die Namen sind falsch, die CUs passen nicht zu den Chips, Navi 20 gibt es als Chipnamen glaub ich gar nicht, Performanc passt auch nicht zu CUs, Verbrauch und Preise sind meilenweit entfernt.

Sunrise

2019-09-29, 14:06:19

Mehr als 4096 ALUs auf 7nm bei identischem Design ist IMHO sowieso ausgeschlossen. Wenn 7nm+ auch nur ansatzweise so gut funktioniert wie bei Apple (evtl. nicht direkt vergleichbar, es gibt noch nicht genug Informationen), dann hat man da wieder etwas Spielraum, das wird aber dieses Jahr nichts mehr.

Ich verstehe den Drang da jetzt eine High-End GPU nachzulegen, aber von 7nm+ und Navi Gen. 2 verspreche ich mir da ein ausgewogeneres Produkt.

Setsul

2019-09-29, 14:53:33

80 CUs ginge schon, 5700 braucht doch nur 150W bei 1600 MHz oder so, dann HBM statt GDDR und es geht gerade so in 300W.
Aber das ist Wunschdenken, AMD plant nicht danach was gerade so in 300W reingeht um zu zeigen dass die den längsten haben, sondern danach was sinnvoll ist.

1,8/1,6/1,2 Gbps sind Schwachsinn. Es gibt 1,5; 1,75 und 2 Gbps für 12/14/16 GT/s. 1,2 sind doppelt Schwachsinn weil man das fast/knapp mit GDDR5 erreicht und mit GDDR5X locker. Das ist reines Wunschdenken für eine noch billigere Vega 56 weil N14 das offensichtlich nicht schafft. Wenn N14 die 1660 Ti schlägt oder zumindest konkurrenzfähig ist gibts keinen Grund für noch eine GPU dazwischen. AMD ist kein Wohltätigkeitsverein. Wenn Full 40 CUs hat und Salvage 36 CUs und dann ist noch ein Salvage mit 28 CUs sind entweder ein Verlustgeschäft oder die Yields stimmen nicht. Mit "1.2 Gbps" GDDR6 stinkt das nach Wunschdenken und Bullshit.

80 CUs oder noch mehr wären sicherlich möglich und auch sinnvoll als Ersatz für Vega 20, sonst müsste AMD warten bis auf 5nm relativ große Chips gut zu fertigen sind. Die Entwickler sollen sich lieber früher als später an Wave32 gewöhnen, nVidia gibt sich eine Blöße dadurch dass sie auf 12nm bleiben und die letzte 1/2 DP Karte ist auch ne Weile her. Es wäre nicht völlig abwegig da auf 7nm oder eher 7nm EUV später noch was zu bringen aber so einen Chip schneidet man dann nicht klein um 500$ GPUs draus zu machen.
Zwei Speicherinterfaces würden den Chip nur noch größer machen. Wenn man einen 80 CU Chip als 52 CU Salvage verkaufen muss, läuft irgendwas ganz falsch mit den Yields oder man wirft Geld zum Fenster raus. Aber dann beim Speicherinterface knausern und mit nichtmal 3% mehr Bandbreite fast 40% mehr Performance rausprügeln einfach durch rohe Gewalt und einen Haufen CUs? Na das wird bestimmt ein fürchterlich effizienter Chip. AMD macht sich doch lächerlich wenn sie mit 7nm weniger effiziente Chips liefern als nVidia mit 12nm.

80 CUs würden auch 4 Shader Engines bedeuten und dazu passt kein einziger der Salvage Chips. 70 offensichtlich nicht aber auch 60 und 52 lassen sich nicht gleichmäßig in die 2 Hälften der SEs aufteilen und dann wäre da noch das unwichtige Detail dass es eigentlich DCUs sind. Was soll das denn für ein asymmetrisches Gemurkse werden? Bei 80/72/64/56 hätte man wenigstens noch geglaubt dass sich jemand Gedanken gemacht hat, aber das sind einfach runde Zahlen weil sie schön sind und 52 CUs für die 5800 wegen der RTX 2080.

Abgesehen von den Namen ergibt da nichts einen Sinn und dafür zu erraten dass es eine 5800 (XT) geben wird gibts keine Preise.

reaperrr

2019-09-29, 17:08:37

So groß kann der Unterschied in der Praxis nicht sein. Vega 10 und 7 hat es in Bezug auf Perf/W nie sonderlich geholfen.
Da liegst du meiner Meinung nach falsch.
Selbst die Fury X hatte weniger Verbrauch als eine 390X, trotz viel größerem Chip. Der Unterschied zwischen den jeweiligen Speichersystemen muss daher angesichts der Flächenunterschiede und identischen Taktraten der Chips locker um die 100W betragen haben.

Übertragen auf Vega10, mit einem 512bit GDDR5-SI und 8Gbps Speicher hätte V10 für die gleiche Leistung m.E. mindestens 100W mehr gebraucht. Was aber zu viel gewesen wäre und AMD deshalb gezwungen hätte, den Chiptakt noch ein ganzes Stück niedriger anzusetzen, womit V10 dann performance-technisch deutlich gegen GP104 verloren hätte.

Bezüglich der VII, das ist halt kein Gaming-Chip (dafür hätten ein 2048bit-SI und zwei Aquabolt-Stacks @ 1.2 Ghz gereicht), veraltete Technik und zum Zweck der Konkurrenzfähigkeit auch (zu) weit überm Sweetspot betrieben. Schon runtergetaktet auf ~V64-Takt lässt die sich unter 200W bringen. Aber auch hier gilt, für die gleiche Bandbreite mit GDDR hätte es 512bit GDDR6 @ 16Gbps gebraucht, ob man damit innerhalb von 300W die gleichen Taktraten geschafft hätte, wage ich zu bezweifeln.

Wenn AMD bei dem größten Navi1x auf HBM2(E) setzen sollte, dann weil die Vorteile in Sachen Perf/W groß genug sind um den höheren technischen Aufwand zu rechtfertigen. Die werden das in ihren Testlaboren schon genau genug simuliert und getestet haben, um das besser abschätzen zu können als du oder ich...

Abgesehen von den Namen ergibt da nichts einen Sinn und dafür zu erraten dass es eine 5800 (XT) geben wird gibts keine Preise.
Jup, die Tabelle ist dermaßen lächerlich, dass sie a) Fake und b) von jemandem erstellt sein muss, der von der Technik nicht mal genug Ahnung hat, um wenigstens was halbwegs glaubwürdiges hinzukriegen.
Das könnte ich um Längen besser :wink:

robbitop

2019-09-29, 17:46:24

Der Vergleich hinkt, weil Polaris nur ein 256 bit Interface hat.
Ich meine Polaris ggü GP106 und Vega ggü GP104/102. Polaris konnte sich noch halbwegs halten.

-----
@reaperrr und@aufkrawall
OK - ergibt Sinn. Aber Preis und Verfügbarkeit sind offenbar schon noch wesentliche Kriterien.

Der_Korken

2019-09-29, 18:02:52

Da liegst du meiner Meinung nach falsch.
Selbst die Fury X hatte weniger Verbrauch als eine 390X, trotz viel größerem Chip. Der Unterschied zwischen den jeweiligen Speichersystemen muss daher angesichts der Flächenunterschiede und identischen Taktraten der Chips locker um die 100W betragen haben.

100W ist etwas übertrieben. Fiji war eine GCN-Stufe höher und dadurch möglicherweise etwas effizienter. Außerdem wurden die CUs auf der Fury sehr schlecht ausgelastet. Aber 50-75W könnten es durchaus gewesen sein. V10 musste "nur" ein 384bit Interface durch HBM ersetzen, nicht 512bit wie bei Hawaii, also auch etwas weniger. Aber ja, die Ersparnis ist dennoch nicht zu verachten. Das lässt Navi gegenüber Vega nochmal etwas besser aussehen.

Leonidas

2019-10-02, 08:55:06

Vorerst kommt eine Radeon RX 5500 mit 1408 Shader-Einheiten, Vorstellung wohl schon am 7. Oktober:
https://www.3dcenter.org/news/amds-radeon-rx-5500-mit-1408-shader-einheiten-soll-am-7-oktober-vorgestellt-werden

robbitop

2019-10-02, 08:58:55

22 CUs. Ich vermute mal, dass die GPU 24CUs hat und 2x deaktiviert sind.
IMO sinnvoll, die GPU zu bringen. Sicherlich sinnvoll für den mobile Markt, wo es seit Jahren kein sinnvolles Produkt von NV abseits der APUs gab und sicherlich auch Geld zu verdienen ist.
Auch im Desktopbereich kann man gute Umsätze (aber schmale Margen) in diesem untern Midrangesegment machen.

Schon wow, dass man GDDR6 in diesem Segment einsetzen will und dass man deutlich mehr Rohleistung einsetzt als die 1650. Die wird man recht deutlich besiegen können IMO.

Allerdings sind 7 nm Starts aktuell begrenzt. Mit Epyc Silizium kann man vermutlich wesentlich bessere Margen pro Wafer machen. Kann mir also vorstellen, dass die Lieferfähigkeit nicht berauschend werden wird.

Linmoum

2019-10-02, 09:03:15

Sehe da kein wirkliches Problem, die 5700(XT) war und ist ebenfalls gut verfügbar. Das kannte man aus der Vergangenheit auch komplett anders.

Brillus

2019-10-02, 09:42:07

Dass das explizit als mobile Version da steht lädst mich hoffen, jetzt noch 7nm mobile cpu und es gibt wohl wieder einen neuen lapi.

HOT

2019-10-02, 09:44:57

Ist wieder die berühmte AMD-Drittelung. 24 * 133% = 40 * 133 = 54. Passt alles gut. Der N12 könnte dann zusammen mit 20+GT/s GDDR6 laufen oder aber 2,4GHz HBM.

Mangel76

2019-10-02, 10:20:42

Ist wieder die berühmte AMD-Drittelung. 24 * 133% = 40 * 133 = 54. Passt alles gut. Der N12 könnte dann zusammen mit 20+GT/s GDDR6 laufen oder aber 2,4GHz HBM.

Du meinst wohl zwei Drittel?
24* 1,6667=40

Aber 40* 1,6667=67

54 CUs wären viel zu dicht an N10.

HOT

2019-10-02, 10:42:37

aaaah stimmt lol, danke :D!

Jo passt also 24 -> 40 -> 64
Dann ist das klar.

N23 wär dann potenziell 96 CUs, das ist dann aber wirklich sportlich :D.
Und GDDR6 scheidet bei 64CUs @256Bit mMn aus. Da wird man auf HBM2E setzen müssen, damit man da nicht permanent an der Bandbreite hängt. Ich fürchte nur, dass das zulasten der Menge geht, man wird wieder 8GB sehen, was mich doch etwas ankotzen würde.
Na ja, hab mir gestern ne Asus 5700XT bestellt, das wird das Dilemma schon ne Weile überbrücken :D.
Vielleicht hol ich mir die Großen dann beim 6nm-Refresh :D.

LasterCluster

2019-10-02, 12:40:47

Aus was besteht dann die 5600er? Stärker beschnittene N10er? Oder vielleicht hochgetaktete N14er GPUs, also 5600 vs 5500 wie 590 vs 480 (oder 470?).

Zergra

2019-10-02, 12:54:30

Sie 5600er Serie kommt auch noch, aber das dauert noch ne ganze Zeit. Aktuell wäre der Abstand zwischen 5500 und der 5700 viel zu groß. Vega ist ja EOL und das vor polaris

robbitop

2019-10-02, 13:01:11

So groß ist der Abstand zwischen 24 CUs bis 36 CUs (höchste Navi 14 und kleinste Navi 10) jetzt auch nicht. Bei RX460 zu RX470 und auch RX560 zu RX570 war der relative Abstand größer.
Ggf. kommt noch eine stark beschnittene N10 als 5600.
Jede weitere Maske kostet Geld.

Linmoum

2019-10-02, 14:01:20

Jop, der Abstand passt schon. Vielleicht machen sie es jetzt wie bei Ryzen, sodass es dann halt nur 5300, 5500, 5700, 5900 von der Bezeichnung her geben wird.

dargo

2019-10-04, 08:45:04

JVC

2019-10-04, 08:53:38

Hab nur gehört, das N12 auf der 5900 und eventuell noch heuer kommen soll...
(warte ja auch auf "N21" und HDMI 2.1, DP 2.0, der soll das können...)

M.f.G. JVC

Der_Korken

2019-10-04, 08:59:19

Sagt mal... ist was an dem Gerücht dran, dass ein Navi 21 (RX 5800?) mit 64 CUs dieses Jahr noch kommt? Es ist diesbezüglich ganz schön still geworden. Und da das Jahr nur noch knapp 3 Monate hat glaube ich nicht mehr dran.

Ich glaube das wäre nicht Navi 21, sondern Navi 12. Für den gibts unterhalb von Navi 10 irgendwie nicht so viel Platz. Die 20er werden wohl eher zweite Gen sein, also RDNA 1.1 und in 7nm+ kommen. Ansonsten geisterte noch ein angeblicher Speicherausbau von Navi 12 im Raum, den man entweder als 256bit GDDR6 oder 2048bit HBM2 interpretieren kann. Releasedaten und sonstiges sind nicht bekannt.

amdfanuwe

2019-10-04, 09:30:28

10 sec googeln:
https://images.tweaktown.com/news/6/6/66829_01_amd-confirms-working-high-end-navi-gpus.png
nix RDNA 1.1

Bucklew

2019-10-04, 13:32:17

10 sec googeln:
nix RDNA 1.1
Da sieht man RDNA2 aber nicht vor 2020, evtl sogar 2021.

mboeller

2019-10-04, 13:41:24

Da sieht man RDNA2 aber nicht vor 2020, evtl sogar 2021.

RX580X/590 = 2018 (GCN)

RX5700/XT = 2019 (RDNA1)

RXxxx = 2020 (RDNA2)

passt doch :)

Der_Korken

2019-10-04, 13:59:19

nix RDNA 1.1

Dann nenn das Kind halt anders. Jedenfalls dürfte es Verbesserungen bei der Architektur geben bei den großen Chips. Eigentlich würde das auch in Bezug auf RT gut passen, denn wenn RDNA2 eine RT-Beschleunigung bekommt, dann ist es sinnvoll sich die großen Chips dafür aufzuheben. Bei den Karten, die dafür schnell genug sind, wäre das sonst ein zu großer Nachteil gegenüber Nvidia.

Bucklew

2019-10-04, 14:37:13

RXxxx = 2020 (RDNA2)
1. nix weiter schrieb ich
2. War die Frage, ob es 2019 noch was bezüglich RDNA2 gibt.

gedi

2019-10-04, 15:20:03

Zumal ich bei Navi12 fest von einer RX5600(XT) ausgehe. Resteverwertung von Navi10. Die 5600 wird sich dann dem 1660-Portfolio annehmen nur halt mit einem 256-Bit SI plus 4/8GB GDDR5-Ram. P/L muss halt in dem Preisbereich rocken und zudem sollen ja auch mal wieder OEMs AMD-Kärtchen verbauen.

Linmoum

2019-10-04, 15:42:54

Warum sollte man zwischen N14 und N10 denn noch einen Chip quetschen? Das lohnt sich doch bei bereits 24CU (5500XT) und 36CU (5700) gar nicht. Dafür ist die Lücke viel zu klein.

amdfanuwe

2019-10-04, 16:32:45

Dann nenn das Kind halt anders.
Ne, dass überlass ich den offiziellen Stellen. Wenn jeder seine eigenen Bezeichnungen einführt, dann blickt doch keiner mehr durch.

davidzo

2019-10-04, 17:01:57

Ggf. kommt noch eine stark beschnittene N10 als 5600.
Jede weitere Maske kostet Geld.
Mit nem weiter beschnittenen N10 rechne ich auch, die Lücke beim SI ist nämlich +100%.

Warum sollte man zwischen N14 und N10 denn noch einen Chip quetschen? Das lohnt sich doch bei bereits 24CU (5500XT) und 36CU (5700) gar nicht. Dafür ist die Lücke viel zu klein.

Ja, aber die 5500 hat soweit ich weiß nur 22CUs, die 24 von N14 spart man sich vllt. für die 5600er auf.
Um der 1660ti paroli zu bieten reicht das aber nicht, da bremst das SI trotz GDDR6 einfach zu stark. Die 5600xt muss also auf N10 basieren, ggf. mit beschnittenem SI.

Möglich aber auch dass AMD trotzdem einfach das 256bit GDDR6 SI stehen lässt und nur CUs deaktiviert, denn es scheint kaum finanzielle Anreize zu geben noch GDDR5 irgendwo einzusetzen. Das hätte man schließlich bei der 5700 non-xt oder bei der 5500 machen können, hat diese chance aber offensichtlich nicht genutzt.

Berniyh

2019-10-04, 17:28:19

Zumal ich bei Navi12 fest von einer RX5600(XT) ausgehe. Resteverwertung von Navi10.
Wenn das Resteverwertung wäre, dann gäbe es die Karte schon längst im Handel. Warum warten? Die Chips zu lagern kostet doch auch nur Geld.

Zudem zeigt der Source Code im Open Source Treiber, dass Navi10/14 recht ähnlich sind, Navi12 aber ein bisschen davon abweicht.
Auch das spricht gegen Resteverwertung von Navi10.

Damit ist natürlich nicht ausgeschlossen, dass Navi12 als 5600(XT) kommt, aber das werden ziemlich sicher dediziert gefertigte Chips sein.

Brillus

2019-10-04, 18:40:26

Mit nem weiter beschnittenen N10 rechne ich auch, die Lücke beim SI ist nämlich +100%.

Seltsames Argument wann hatte AMD/ATI den es letzte mal ein krummes Interface, wenn man nur 2er Potenzen hat sind halt zwischen 2 benachbarten 100%, außerdem sieht es so aus als gäbs noch was größeres mit gleichen Interface wie Navi10 also hätte so gesehen Navi10 schon ein übergroßes Interface.

Berniyh

2019-10-04, 18:47:17

Seltsames Argument wann hatte AMD/ATI den es letzte mal ein krummes Interface, wenn man nur 2er Potenzen hat sind halt zwischen 2 benachbarten 100%, außerdem sieht es so aus als gäbs noch was größeres mit gleichen Interface wie Navi10 also hätte so gesehen Navi10 schon ein übergroßes Interface.
Nicht zwangsläufig, Navi12 könnte ja auch mit HBM2e kommen.

Complicated

2019-10-04, 18:55:42

Erkläre mir mal in vernünftiger Weise genauer, wie Du das meintest:
Wie von mir (und Anderen) schon damals geschrieben, ergibt das nicht wirklich Sinn, genausowenig wie Deine damalige Erläuterung dazu:
Intels Cache ist tatsächlich ein (gemeinsamer) LLC-Cache (keine Ahnung, welche intel-APUs Du meinst, aber meinst Du Broadwell-C mit dem eDRAM? Wobei das eigentlich auf ziemlich egal ist) und funktioniert deutlich anders als der eSRAM der XB1. Insofern ist keinem so recht klar, wovon Du da redest.

Egal, wir müssen das hier nicht weiter OT auswalzen. Aber manchmal würde es gut sein, wenn auch die eigene Fehlbarkeit einkalkulieren würde. ;)
Die Konfiguration als Victim-Cache wie bei Haswell/Broadwell im ersten Bild war was ich meinte.

https://www.anandtech.com/show/9582/intel-skylake-mobile-desktop-launch-architecture-analysis/5
https://images.anandtech.com/doci/9582/27_575px.jpg
This is the current eDRAM representation for Haswell and Broadwell processors. Here we see that the eDRAM is accessed by a store of L4 tags contained within the LLC of each core, and as a result acts more as a victim cache to the L3 rather than as a dynamic random access memory implementation. Any instructions or hardware that requires data from the eDRAM has to go through the LLC and do the L4 tag conversion, limiting its potential (although speeding up certain specific workloads by virtue of a 50 GB/s per-link bi-directional interface.
https://images.anandtech.com/doci/9582/28_575px.jpg

Rather than acting as a pseudo-L4 cache, the eDRAM becomes a DRAM buffer and automatically transparent to any software (CPU or IGP) that requires DRAM access. As a result, other hardware that communicates through the system agent (such as PCIe devices or data from the chipset) and requires information in DRAM does not need to navigate through the L3 cache on the processor.

Locuza

2019-10-04, 20:22:07

Und so läuft es bei der Xbox One ja nicht ab.
Der eSRAM ist kein transparenter Cache und muss vom Entwickler explizit und manuell verwendet werden.
Es gibt keine automatische Steuerlogik, wo Datenblöcke von den CPU- oder GPU-Caches dort gespeichert werden.

Die einzige Gemeinsamkeit ist insofern, dass beide Konzepte eine Menge extra Speicherzellen im Megabyte-Bereich verwenden, um die Systemperformance zu erhöhen.
Die Implementierung und Funktionsweise ist aber völlig anders, entsprechend herrscht Verwirrung darüber, inwiefern das Intels Ansatz verfolgt.

Gipsel

2019-10-04, 20:40:42

Sehe gerade, daß Complicated das auch hier im Thread gepostet hat. Ist jetzt durch Locuzas Post ist das jetzt zwar etwas redundant, aber schon heute morgen (9:38Uhr) habe ich ihm daraufhin das geantwortet:
Im Prinzip sagt der Text [von Anandtech] doch das, was ich schrieb: Bei intel ist der eDRAM ein Cache (und funktioniert auch normal als solcher). Bei der XB1 ist der eSRAM dagegen keiner, sondern ein separater RAM-Bereich, der explizit adressiert wird. Vom eDRAM bei intel muß der Programmierer nichts wissen, der funktioniert einfach und wird wie andere Caches automatisch genutzt. Beim eSRAM der XB1 ist das anders, weil ohne explizite Ansprache wird der schlicht überhaupt nicht genutzt. Es ist eben kein Cache.

Complicated

2019-10-05, 09:26:11

Die einzige Gemeinsamkeit ist insofern, dass beide Konzepte eine Menge extra Speicherzellen im Megabyte-Bereich verwenden, um die Systemperformance zu erhöhen.
Die Implementierung und Funktionsweise ist aber völlig anders, entsprechend herrscht Verwirrung darüber, inwiefern das Intels Ansatz verfolgt.
Was ja das ist was ich schrieb. Ein schneller Zusatzspeicher ohne hUMA ist der gemeinsame Ansatz den ich meinte. Sicherlich flapsig, wie ich schon einräumte, doch ganz sicher auch nicht so völlig unverständlich wie hier getan wird. Gipsel hat es ja schon zitiert.
Die Xbox One hat damals auf die Cache Kohärenz mittels FCL und RMB (damals noch onion und garlic) verzichtet und eher Intels Ansatz mit LLC verfolgt mit dem zusätzlichen, nicht gemeinsam adressierbaren, eSRAM.<- so verständlicher?
Das bezog sich auf den nicht gemeinsam adressierbaren Zusatzspeicher. Streich meinetwegen LLC aus dem Satz wenn das verwirrend ist, doch ich hatte nach über 3 Jahren noch im Kopf, dass der LLC beteiligt war und später auch von Intel geändert wurde. Relevant für meinen Gleichnis war es nicht.

Gipsel

2019-10-05, 09:32:55

<- so verständlicher?Nein.
Intels eDRAM-Cache wird ganz offenbar für Speicherzugriffe von CPU und GPU genutzt. Das Konzept der XB1 ist schlicht ein deutlich anderes (und Onion und Garlic hatte die auch).

Edit:
Und OT ist es immer noch hier.

robbitop

2019-10-05, 09:37:52

24 CUs reichen grob für TU116 um gleichzuziehen. Bzw wäre man ggf 5-10% langsamer. Ein extra Chip lohnt dafür kaum. Dennoch könnte man N10 weiter deaktivieren um eine 5600 zu machen. Ggf mit 192 bit SI. Das ist aber N10 und nicht N12.
Navi 12 könnte eher eine 5800 werden. GDDR6 ist mit 18 gt/s und wohl auch 20 gt/s verfügbar. 28-42% mehr Bandbreite. Da N10 nicht stark bandbreitenlimitiert ist kann man sicher etwas das Bandbreiten/Rohleistungsverhältnis erhöhen (siehe NVs 1070ti).

robbitop

2019-10-05, 09:51:30

Mal ein paar GB/TFLOP Werte:

1080ti: 42,68 GB/TFLOP
1060 9gbps: 49,53 GB/TFLOP
1070ti: 31,3 GB/TFLOP
2080 Super: 44,48 GB/TFLOP
2080ti: 45,80 GB/TFLOP
5700XT: 45,92 GB/TFLOP
N12@64CUs@18gbps: 36,9 GB/TFLOP
N12@64CU@20gbps: 40,01 GB/TFLOP

Also ich denke da ist schon noch was drin.... :) (sofern Navi ähnlich effizient ist in Bezug auf Bandbreite wie Pascal/Turing)

HOT

2019-10-05, 10:00:11

Igor geht ja von 22CUs bei N14 als Vollausbau aus. Das wird denke ich auch zutreffen. Es wird mMn nach später, wenn 20 und 22GT/s GDDR6 mal verfügbar ist, ein weiterer Chip nachgeschoben werden, der mit 128Bit eben 28 (und 26) CUs bedienen wird und solange das eben dauert, überbrückt man das mit N10-Salvage, der sonst nicht verwertet werden kann (und den es sicherlich gibt). Also bringt man die 5600XT mit 28 CUs und 256Bit als N10 und im Laufe des nächsten Jahres dann einen 5650(XT) oder 6600(XT) mit den gleichen Leistungswerten, nativen 28CUs und 128Bit 20GT GDDR6.

Krumme Speichercontroller machen die nicht, weil AMD konsequent 8GB fahren wird und 256Bit wird man dem Segment auf jeden Fall vermeiden, es sei denn als Salvage.

robbitop

2019-10-05, 10:11:33

Bei so wenig CUs kann man bei 256 bit dann auch GDDR5 nehmen. Mal sehen.

HOT

2019-10-05, 10:59:32

Niemand wird mehr GDDR5 benutzen und vor allem nicht 256Bit damit machen und wertvollen 7nm-Platz damit verschwenden.

robbitop

2019-10-05, 11:20:19

Du sprachst von N10 als 5600XT mit 256 bit.
Da das unnötig viel BB mit GDDR6 wäre, schlug ich ein reduziertes SI oder GDDR5 jeweils zur Kostensenkung vor.

HOT

2019-10-05, 11:22:52

Ja als Salvage, bis der neue Chip dann zur Verfügung steht. Man schlägt ja 2 Fliegen mit einer Klappe: Man spart beim neuen Chip dann Fläche ein und setzt den ganzen N10 "Müll" solange ab. Aber auch der N10-5600XT wird keinen GDDR5 benutzen, vielleicht GDDR6 mit 12GT. Wer weiss ob der überhaupt für GDDR5 noch spezifiziert ist.

robbitop

2019-10-05, 12:11:58

Wie viele extra Chips lohnen wirklich? Gerade wenn Ressourcen nicht zu Hauf vorhanden sind? So extrem viel Platz ist zwischen N10 und N14 auch nicht gerade. Zumal sich die 22 CUs als Vollausbau erstmal beweisen müssen. Ich tippe eher auf 24.

Linmoum

2019-10-05, 12:15:30

Igor spricht bei der 5500XT von 22CU, das dürfte schon passen. Zumal er ja auch schon mehr weiß, aber halt noch nicht alles sagen darf. Offizielle Vorstellung soll ja iirc am Montag sein.

robbitop

2019-10-05, 12:26:04

Die Frage ist ob die 5500XT den Vollausbau hat.

Linmoum

2019-10-05, 12:36:21

Was ist "XT" denn sonst bei AMD? ;)

robbitop

2019-10-05, 12:53:05

Für alles gibt es ein erstes Mal. ;)
Siehe NV und das Ti Suffix. Und auch das GTX Suffix. Beide waren jahrelang Vollausbauten.
Aber ja: klingt schon relativ überzeugend. :)

y33H@

2019-10-05, 13:03:32

XT mit 22 CUs von wenn es Benchmarks von 24 CUs mit 128 Bit gibt?

vinacis_vivids

2019-10-05, 13:40:01

Bei AMD gibs das Label "XTX" bspw.: X1950 XTX

robbitop

2019-10-05, 14:15:25

Ist aber schon verdammt lang her.

vinacis_vivids

2019-10-05, 15:27:05

:biggrin:
https://www.computerbase.de/2017-07/ati-radeon-x1950-xtx-rueckblick/#diagramm-rating-2560x1600-4xaa-16xaf
https://abload.de/img/screenshot_2019-10-0567ks8.png

N10 ist ja Mittelklasse mit 251mm² und N14 mit vmtl. 125mm² wirds max. XT geben.

XTX ist reserviert für höherklassige Modelle wie "RX5900 XTX" :cool:

mczak

2019-10-05, 17:29:27

N10 ist ja Mittelklasse mit 251mm² und N14 mit vmtl. 125mm² wirds max. XT geben.

Ich habe noch nirgends Grössenangaben gesehen aber im Vergleich zu N10 sehe ich nicht wie N14 nur 125mm^2 werden soll - da würde ich eher so 150mm^2 vermuten.

Der_Korken

2019-10-05, 17:59:29

Es gab eine RX560XT, die auf P20 basierte, während die 560nonXT P21 war. Ist zwar eine hässliche Nomenklatur, aber es wäre nicht unmöglich, dass es noch eine 5600 mit N14-Full und eine 5600XT mit einem weiter beschnittenem N10 gibt.

das_Apo

2019-10-07, 10:37:38

Ist die heutige Vorstellung seitens AMD bzgl. Radeon RX 5500 (XT) und/oder Radeon RX 5600 (XT) geben nur eine Ankündigung, wann uns was erwartet, oder ein Launch, so dass auch mit Tests und baldiger Verfügbarkeit zu rechnen ist?

Leonidas

2019-10-07, 11:00:35

Verfügbarkeit soll sowieso erst später sein. Ergo gehe ich (Vermutung!) von einer Ankündigungs-Show ohne unabhängige Benchmarks aus. Es werden wohl Specs und AMD-eigene Benchmarks sowie ein Termin kredenzt.

PS: Videocardz haben sich bereits die Slides ansehen können:
https://videocardz.com/82162/amd-announces-radeon-rx-5500-series-with-gddr6-memory
Es bleiben aber noch Fragen offen, welche dann zur offiziellen Vorstellung hoffentlich angesprochen werden. Es scheint tatsächlich eine reine Vorstellung ohne Launch zu werden.

unl34shed

2019-10-07, 11:06:40

https://videocardz.com/82162/amd-announces-radeon-rx-5500-series-with-gddr6-memory

22CUs schneller als 480
128bit GDDR6
Release Q3 aber nichts genaues
Leider keine Preise

HOT

2019-10-07, 11:12:18

251 zu 158 mm², da ist auf jeden Fall kein Chip mehr dazwischen. Ich denk mal, dass N21 dann noch mal ne Stufe darunter ist, also 80-100mm², der dürfte dann mit 64Bit Interface aufschlagen.
Ich würd auch davon ausgehen, dass der 5600 die non-salvage-Variante ist und der 5600XT ein stark kastrierter N10 (28CUs würd ich tippen), also dass man hier die Polaris-Taktik wiederholt.

Der 5500 ist deutlich stärker als P10/20, die 5500XT dürfte V56 schlagen.

BoMbY

2019-10-07, 11:13:08

Könnte gut sein dass die vollständige Navi14 mit 24 CU erst mal Apple-Exklusiv wird. Jedenfalls sollte es die laut den Benchmark-Einträge prinzipiell geben.

Der_Korken

2019-10-07, 11:14:58

dildo4u

2019-10-07, 11:32:15

Schätze mal die bekommt 200€ für die 8GB Version,die 1650 zu vernichten ist natürlich leicht die GPU ist ein Witz.

Leonidas

2019-10-07, 11:34:03

Bin ich blind oder gibt es keinen Unterschied zwischen 5500XT und nonXT? Nicht mal 2 CUs abgeschaltet und nichtmal etwas weniger Takt. Verbrauch wäre noch interessant bzw. Perf/W im Vergleich zu N10.

4GB bei non-XT, 8GB bei XT.

Leider ist technische Info ohne eine Preisangabe einfach nicht wirklich gut einordenbar. Ich warte mit einer eigenen Meldung ab, ob AMD noch was zu Preisen sagt.

HOT

2019-10-07, 11:44:24

Powertarget wird entsprechend niedriger sein. Vllt. hat die non-XT keinen Stromanschluss. Aber das muss ja salvage sein, wenn sowohl 5500 als auch die XT gleiche CUs haben.
Dann wird man sicherlich

5600XT -> 28 CUs N10
5600 -> 24 CUs N14 mit GDDR6 16 oder 18GT (Apple Exklusivität vorerst möglich, sowas wie die 380X)
5500XT -> 22CUs
5500 -> 22 CUs
5300 -> 16 CUs N14 oder sowas.

vinacis_vivids

2019-10-07, 11:50:05

Der 5500 ist deutlich stärker als P10/20, die 5500XT dürfte V56 schlagen.

P10/P20/P30 mit 6-7 Tflops werden auch mit 22CUs von Navi überboten, da gehe ich mit.

Gehen wir mal davon aus, dass die 5500XT volle 24 CUs hat -> 1536 SP beim Takt von 1,85Ghz -> 5.6 Tflops. Das reicht nicht um V56 zu schlagen, da liegen immer noch 10-11 Tflops zur Buche bei 410GB/s Bandbreite.

tm0975

2019-10-07, 12:16:26

Leider ist technische Info ohne eine Preisangabe einfach nicht wirklich gut einordenbar.

Bei Benchmark-Ergebnissen (quasi den meßbaren technischen Infos) ist das doch regelmäßig auch kein Problem...

Eine Karte im Sweetspot bei max. 70 Watt wäre schön, gerne im Vollausbau.

Leonidas

2019-10-07, 12:57:38

Bei Benchmark-Ergebnissen (quasi den meßbaren technischen Infos) ist das doch regelmäßig auch kein Problem...

Stimmt natürlich. Aber Preise sind hier wichtig, weil schon 20$ Differenz den Unterschied zwischen "so-lala" und "P/L-Granate" ausmachen können. Gerade da es in diesem Segment ja mit Polaris eine Vorgänger-Generation mit exzellentem P/L gibt. Eine Vorstellung ohne jeden Preispunkt wäre sowieso gaga.

Piefkee

2019-10-07, 13:03:52

Der 5500 ist deutlich stärker als P10/20, die 5500XT dürfte V56 schlagen.

Die 5500 wird auf 590 Niveau liegen. Nicht umsonst wurde sie mit der 480 verglichen und nicht mit der 590...:freak:

Sie wird aber niemals an eine V56 rankommen...

V56 ist bei 1080p ca. 50% schneller als eine 580...

dildo4u

2019-10-07, 13:05:16

Stimmt natürlich. Aber Preise sind hier wichtig, weil schon 20$ Differenz den Unterschied zwischen "so-lala" und "P/L-Granate" ausmachen können. Gerade da es in diesem Segment ja mit Polaris eine Vorgänger-Generation mit exzellentem P/L gibt. Eine Vorstellung ohne jeden Preispunkt wäre sowieso gaga.

Kommt drauf an ob es ein OEM Launch ist,laut Videocardz gibt es weit und Breit keine Custom Karten.Wenn noch zu viele 580/590 im Umlauf sind kann AMD mit den Retail Karten noch warten.

Der_Korken

2019-10-07, 13:21:33

Unter 75W wird schwierig. Man hat im Vergleich zur 5700XT halben Speicherausbau und etwas mehr als halb so viele CUs bei etwas weniger Takt. Dürfte also ca. bei der Hälfte der 5700XT rauskommen, also so 105W. Klar kann man das unter 75W drücken, aber nicht mit nur 40Mhz weniger als die 5700XT. Eventuell ist der Takt bei der 5500nonXT auch einfach falsch und er ist in Wirklichkeit niedriger.

@Leonidas: Bei der 5500XT steht "up to 8GB", was für mich impliziert, dass es auch <8GB gibt. Außerdem gab es das noch nie bei AMD, dass es zwei Modellnamen gab, die sich nur durch die Speichermenge unterscheiden.

Brillus

2019-10-07, 13:23:35

Das ist die GPU Chip der mich aktuell am meisten interessiert. Als jemand der auf Lapi setzt hoffe die mobile hat min doppelter Speed meiner Radeon 560. Und natürlich das es gute Lapis damit gibt (vorzugsweise mit einer flotten 7/10 nm CPU.)

Leonidas

2019-10-07, 13:45:13

@Leonidas: Bei der 5500XT steht "up to 8GB", was für mich impliziert, dass es auch <8GB gibt. Außerdem gab es das noch nie bei AMD, dass es zwei Modellnamen gab, die sich nur durch die Speichermenge unterscheiden.

So gesehen könnte diese Specs noch fehlerhaft sein. Auch die Benchmarks lassen mich rätselnd zurück: Gegenüber der RX480 sieht es gut aus, Performance-Niveau RX590. Gegenüber der 1650 sieht es mau aus, Performance-Niveau RX580 +3%. Ergibt einen deutlichen Unterschied von ca. 6%, was in diesem Feld eine Menge ausmacht.

Locuza

2019-10-07, 15:06:38

Hier gibt es ein paar Folien:
https://www.bug.hr/pc-komponente/radeoni-rx-5500-u-lovu-na-full-hd-igrace-11736

https://www.bug.hr/img/radeoni-rx-5500-u-lovu-na-full-hd-igrace_0TyE28.jpg
Die Folie sorgt natürlich für Verwirrung, wenn man eine Spec angibt, aber oben allgemein von der 5500 Series redet.
Ich würde vermuten, es handelt sich nur um die 5500.

Die Folie ist von der angegeben die-size für Polaris10 interessant:
https://www.bug.hr/img/radeoni-rx-5500-u-lovu-na-full-hd-igrace_YPbKw8.jpg

Zu Beginn hat AMD 232mm² angegeben, was OC_Burner/Fritzchen Fritz ziemlich exakt auch so vermessen konnte:
physical die-size 243,78mm² (17,64mm x 13,82mm)

the inner die-size 231,67mm² (17,25mm x 13,43mm)
https://www.flickr.com/photos/130561288@N04/43550162214

Jetzt gibt AMD bei Polaris10 221mm² an.