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

nordic_pegasus

2019-07-28, 18:50:45

https://hardforum.com/threads/oled-hdmi-2-1-vrr-lg-2019-models.1974798/#post-1044015061
"Navi almost certainly will have HDMI 2.1, the chipset has been out for the better part of a year."

https://www.overclock3d.net/news/gpu_displays/hdmi_2_1_vrr_support_will_come_to_amd_radeon_rx_gpus_with_a_future_driver_update/1
"Radeon Software will add support for HDMI 2.1 Variable Refresh Rate (VRR) technology on Radeon RX products in an upcoming driver release. This support will come as an addition to the Radeon FreeSync technology umbrella, as displays with HDMI 2.1 VRR support reach market."

Hmmm ... ich Hirngespinste nur grad rumm ...

Denkt ihr nicht auch da fehlt/kommt noch was :confused:

M.f.G. JVC

Navi kann hardware-seitig kein HDMI 2.1. Darum wird man hier weder mit Firmware noch mit Treiber etwas zaubern können. AMD hatte doch zum Release von Navi erklärt, dass die finale Spec für HDMI 2.1 zu spät kam um noch bei Navi10 berücksichtigt zu werden.

Das mit dem VRR wird sicherlich irgendwann nachgereicht. Derzeit unterstützt AMD nur FreeSync (da kann ja selbst Nvidia Adaptive-Sync Standards :-) ). VRR ist ein offener Standard der VESA, welcher für HDMI genutzt werden soll. Es ist ein Teil der HDMI 2.1 Specs. AMD wird also irgendwann VRR-Support für HDMI 2.0 Geräte nachreichen.

JVC

2019-07-28, 18:57:49

AMD hatte doch zum Release von Navi erklärt, dass die finale Spec für HDMI 2.1 zu spät kam um noch bei Navi10 berücksichtigt zu werden.

Ich denke, ich meine nicht navi10 ...

M.f.G. JVC

N0Thing

2019-07-28, 18:58:58

Screemer

2019-07-28, 19:01:15

Man braucht aber für high refresh rate + 4k eben 2.1 und darum ist es eher minus dass n10 es nicht hat.

N0Thing

2019-07-28, 19:02:05

Keine Frage, ich hätte es auch lieber gesehen, wenn HDMI 2.1 schon von Navi unterstützt worden wäre.

BoMbY

2019-07-28, 19:06:48

Warum nicht? Die Lücke zwischen einem Navi 10 und Navi 21 mit 5120 CUs wäre viel zu groß. Dazwischen passt wunderbar ein Chip mit 4096 CUs rein. Völlig latte ob mit oder ohne RT.

Das Texturprozessor basierte RT (http://www.freepatentsonline.com/20190197761.pdf) ist doch praktisch schon fertig. Die Instruktionen dafür (bvh_intersect_ray und bvh64_intersect_ray) haben die schon jetzt in den Treibern eingebaut, und Hinweise darauf waren auch schon in einen entsprechenden LLVM-Patch (https://github.com/llvm/llvm-project/commit/c43e67bfffdb4afe14e96864fc737cdaf17ad55b) gerutscht. Und das ist alles gerade mal auf Navi11/Navi12-Level.

Der_Korken

2019-07-28, 19:15:12

64CUs klingen so, als würde AMD wieder einfach nur das Shader-Array aufpumpen und das Frontend so lassen. Von taktnormiert +60% sollte man daher auf keinen Fall ausgehen. Vielleicht eher so 40% wenn ich Polaris vs Vega grob überschlage. Ich hätte einen 1,5-fachen N10 logischer gefunden. Mit RT-Beschleunigung, eventuell getrennten FP+INT-Einheiten und 12GB VRAM@384bit würde man einen 400mm2-Chip bekommen, der mit der 2080Ti mithält. Eventuell minimal langsamer, da man den Takt eindampfen muss, um unter 300W zu bleiben.

nordic_pegasus

2019-07-28, 19:20:00

AMD hat doch im Gegensatz zu Nvidia Adaptive Sync in der Form von Free-Sync von Anfang an umgesetzt und sogar bei der VESA auf dessen Implementierung gedrängt. VRR über HDMI geht auch seit einer Weile bei AMD. VRR über HDMI 2.0 wurde schon von Samsung und AMD auch schon umgesetzt.

https://www.hardwareluxx.de/index.php/news/hardware/monitore/46085-ausgewaehlte-samsung-2018-tvs-sollen-freesync-und-vrr-unterstuetzen.html

AMD unterstützt aktuell kein VRR über HDMI. Es wurde bislang noch nicht treiberseitig implementiert, soll aber kommen. Die 2018er Samsung TVs mit VRR kann man aktuell nur mit der XboxOne nutzen.

Ich werde mir nächsten Monat den Alienware/Dell 55" OLED Monitor auf der Gamescom anschauen, der wird ja HDMI 2.1 und DP1.4 haben bei 120Hz@UHD. Über irgendeine Form von Async wird ja auch gerütchet. Ich bin sehr gespannt auf das Teilchen.

][immy

2019-07-28, 19:45:55

Navi scheint pro ALU taktnormiert auf Turing Niveau zu liegen. In manchen Spielen rund 10% darunter.
Ein 4096 ALU Navi wäre schneller als die 2080 Super. Ungefähr 20% schneller. Die 2080 Ti sollte 10% in Feont liegen.
An AMDs Stelle würde ich noch einen doppelten Navi 10 bringen. Damit würde man TU102 deutlich besiegen und man hätte mal wieder ein Halo Produkt womit man die Marke stärken würde und die kleinen Geschwister besser verkaufen könnte.
Naja, könnte AMD theoretisch machen, aber sie werden wohl ihre Gründe haben, das sie es derzeit nicht machen.
Entweder ist die 7nm Fertigung für so große Chips noch nicht gut genug (zu viel Ausfall) oder AMD sieht nicht wie sie die Investition wieder reinbekommen werden.

Sicher ist, als Prestige-Objekt müsste man die 2080TI schlagen sonst lohnt sich das ganze nicht als Prestige-Objekt.

Ich würde aber erst mal drauf tippen das die 7nm Fertigung noch nicht ausgereift genug ist (abgesehen davon, das die Kosten je Transistor in etwa genauso hoch sind wie bei der 12-14nm Fertigung) um so große Chips Problemlos fertigen zu können. Ansonsten hätte nvidia wohl auch schon was in dieser Richtung angekündigt. Eine 7nm 2080Ti dürfte insgesamt ziemlich schrumpfen und auch noch ein wenig Taktspielraum bringen, oder zumindest die Leistungsaufnahme stark verringern. Derzeit ist der Chip ja einfach nur "unwirtschaftlich" riesig und allein der extreme Verkaufspreis rechtfertigt die Fertigung.

Linmoum

2019-07-28, 19:54:56

Turing ist erst seit September auf dem Markt, das ist noch nicht einmal ein Jahr her. Vor wenigen Wochen bzw. sogar erst Tagen haben sie einen Teil des Portfolios nochmals mit Produkten "erneuert". Natürlich kündigt Nvidia da jetzt noch nichts an, zumal sie ja scheinbar direkt auf 7nm EUV gehen und das schlicht noch Zeit braucht.

Und was AMD derzeit macht hat auch nichts mit dem (aktuellen) Markt zu tun, solche Entscheidungen hast du vor fünf Jahren, oder sogar noch früher, bereits getroffen. Turing z.B. war ganze 10 Jahre in der Entwicklung.

BoMbY

2019-07-28, 20:03:23

[immy;12060980']
Entweder ist die 7nm Fertigung für so große Chips noch nicht gut genug (zu viel Ausfall) oder AMD sieht nicht wie sie die Investition wieder reinbekommen werden.

Seit wenigstens einem Monat ist diese Spekulation hinfällig (https://fuse.wikichip.org/news/2567/tsmc-talks-7nm-5nm-yield-and-next-gen-5g-and-hpc-packaging/):

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

Und die Kosten pro Transistor sind auch nicht schlecht. Ein Navi10 in 7nm (251mm²) kostet sehr wahrscheinlich ähnlich viel wie ein TU106 in 12nm (445 mm²) (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12043144#post12043144).

Edit: Besseres Bild und Link.

Brillus

2019-07-28, 20:28:14

Navi kann hardware-seitig kein HDMI 2.1. Darum wird man hier weder mit Firmware noch mit Treiber etwas zaubern können. AMD hatte doch zum Release von Navi erklärt, dass die finale Spec für HDMI 2.1 zu spät kam um noch bei Navi10 berücksichtigt zu werden.

Das mit dem VRR wird sicherlich irgendwann nachgereicht. Derzeit unterstützt AMD nur FreeSync (da kann ja selbst Nvidia Adaptive-Sync Standards :-) ). VRR ist ein offener Standard der VESA, welcher für HDMI genutzt werden soll. Es ist ein Teil der HDMI 2.1 Specs. AMD wird also irgendwann VRR-Support für HDMI 2.0 Geräte nachreichen.
FreeSync = Marketing Name für VESA VRR.

Auserdem hat AMD schon VRR über HDMI. Hier im Einsatz weil mein Lapi nur HDMI-Ausgang hat.

Gipsel

2019-07-28, 20:33:05

AMD unterstützt aktuell kein VRR über HDMI.Das funktioniert im Prinzip schon seit mindestens drei Jahren oder so. ;)

Edit: Habe das selber schon vor eniger Zeit bei meinem Bruder auf einem Samsung (der per HDMI an einer RX480 [gekauft im Jahre 2016] hing) ausprobiert. Ging einwandfrei. Die VRR-Erweiterung kann ja optional auch bei älteren HDMI-Versionen unterstützt werden (und wird es bei verschiedenen Monitoren und Fernsehern auch).

nordic_pegasus

2019-07-28, 20:54:24

@Gipsel @ Brillus

VRR ist nicht identisch mit FreeSync.

Die 2018/2019er Samsung TVs unterstützen anscheinend explizit FreeSync. Hingegen unterstützen die LG 2019er OLEDs mit HDMI 2.1 nur VRR und können aktuell nicht mit AMD GraKas in einem Async-Modus betrieben werden. Hier soll noch ein Treiber-Update von AMD kommen.

https://www.rtings.com/tv/reviews/lg/c9-oled#comparison_2477
https://community.amd.com/thread/239290
https://www.hardwareluxx.de/index.php/artikel/consumer-electronics/heimkino/47248-samsung-q9fn-qled-tv-mit-freesync-kurz-angeschaut.html

Screemer

2019-07-28, 20:56:34

Freesync ist ein Aufkleber von AMD für VRR. Mit zum Teil erweiterten Vorgaben. Auch die LG oleds laufen mit AMD gpus und VRR. Jedoch nicht mit 4k und >30hz. Glaub es oder lass es.

Gipsel

2019-07-28, 21:09:29

VRR ist nicht identisch mit FreeSync.Stimmt. VRR ist das allgemeine Funktionsprinzip. FreeSync ist (wie GSync) immer VRR, aber nicht jedes VRR ist FreeSync ;). Der Standard heißt über DP "Vesa Adaptive Sync" und die HDMI Group hat nun ihren Standard (der wohl nur minimale Änderungen gegenüber den bisherigen Lösungen mit FreeSync über HDMI besitzt) wenig einfallsreich halt einfach HDMI 2.1 VRR (als Unterpunkt der "Enhanced refresh rate features") genannt.
Die 2018/2019er Samsung TVs unterstützen anscheinend explizit FreeSync.Fernseher weiß ich nicht genau, aber bei Monitoren gibt es Support schon seit 2016.
Hingegen unterstützen die LG 2019er OLEDs mit HDMI 2.1 nur VRR und können aktuell nicht mit AMD GraKas in einem Async-Modus betrieben werden. Hier soll noch ein Treiber-Update von AMD kommen.Die XBox hat es wohl schon und die LG 2019er machen dann nur "HDMI 2.1 VRR", während die Samsungs auch VRR über ältere HDMI-Verbindungen mit alten Treibern hinbekommen (weil man sich [auch] an das von AMD schon 2015 mitgeteilte FreeSync@HDMI als VRR Protokoll [herstellerspezifische Erweiterung] halten kann). Wie gesagt, ein wenig einfallslos und damit verwirrend die Namensgebung seitens der HDMI group. Wenn das angekündigte Treiberupdate kommt, ist es vermutlich sowieso nur noch eine Fußnote.

Edit:
Ich würde ja fast wetten, das unterscheidet sich nur in ein paar Flags bei der Kommunikation der Fähigkeiten und ähnlichen Kleinigkeiten.

Unicous

2019-07-28, 21:11:02

@nordic_pegasus

Das Prinzip ist das Gleiche (wenn nicht gar identisch zur VESA Adaptive Sync Spec), das HDMI-Konsortium hat es lediglich offiziell in die Spec geschrieben und "VRR" genannt.

"FreeSync" bzw. VRR per HDMI wurde von AMD vor 3 1/2 Jahren das erste Mal gezeigt und wurde erfolgreich bei 1.4 und 2.0 implementiert. Sowohl in Monitoren als auch Fernsehern, keine Ahnung was du uns hier erzählen willst.:confused:

edit:
Gipsel war schneller.

nordic_pegasus

2019-07-28, 21:31:11

https://www.digitaltrends.com/tv-reviews/lg-c9-oled-tv-review/

To be clear, a certain flavor of VRR using AMD’s FreeSync technology is already available in the Xbox One X and with various PC graphics cards, but the LG C9 doesn’t work with FreeSync. Instead, it relies on HDMI 2.1 to make VRR work, hence the requirement that the source device also support HDMI 2.1 We’ve deeper info on HDMI 2.1 here if you’d like to learn more.

https://www.rtings.com/tv/reviews/lg/c9-oled

The LG C9 has a native 120Hz refresh rate, and it supports VRR, which is great. Unfortunately, it only supports HDMI Forum's new HDMI-VRR format, which is not compatible with FreeSync or G-SYNC.

https://www.flatpanelshd.com/review.php?subaction=showfull&id=1559035462

As for the optional features, we were very eager to try out HDMI VRR (variable refresh rate), which is similar to FreeSync but not identical

https://www.chip.de/test/LG-OLED55C97LA-Test_168936245.html

Und Unterstützung für variable Bildwiederholraten gemäß HDMI-Standard ist ebenfalls an Bord. Mit dem LG C9 lässt sich somit bestens zocken. AMDs Freesync unterstützt er zum Testzeitpunkt aber nicht.

Ich habe weder einen FreeSync / VRR kompatiblen TV noch eine AMD GraKa. Darum kann ich es nicht selber testen. Aber für mich sind die Anmerkungen in den Tests eindeutig. FreeSync und VRR mögen quasi identisch sein, aber ein VRR-TV kann nicht mit einer FreeSync GraKa umgehen und umgekehrt. Entweder muss der TV explizit FreeSync können (siehe Samsung TVs) oder die GraKa muss ein VRR-Signal ausgeben (was wohl per Treiber-Update zumindest bei AMD bald kommen soll, bzw. zumindest unter Linux schon klappt).

Ich habe jetzt genug Quellen geliefert. Wenn Ihr es alle besser wisst, dann bitte ich um einen Link mit der Demonstration von FreeSync auf einem HDMI 2.1 VRR kompatiblen TV (=aktuell nur LG 2019er Geräte).

Gipsel

2019-07-28, 21:58:51

https://www.digitaltrends.com/tv-reviews/lg-c9-oled-tv-review/
[..]Mit 'ner aktuellen XBox (One S und One X) geht "HDMI 2.1 VRR" schon auf den LGs (LG hat dafür sogar noch ein Firmwareupdate nachgeschoben, weil das anfangs noch völlig hakte (https://www.forbes.com/sites/johnarcher/2019/07/10/lg-fixes-its-2019-oled-xbox-problem/)). Sogar Dein verlinkter Test sagt, daß es funktioniert (https://www.rtings.com/tv/reviews/lg/c9-oled#comparison_2477) (zumindest mit SDR, irgendwo steckt da offenbar noch ein Bug und LG hat das ja sogar bestätigt und inzwischen einen Fix dafür, mal einen Test mit der neuen LG-Firmware vom Juli abwarten).
Und der Rest ist einfach der durch die HDMI Group hervorgerufenen Begriffsverwirrung bei der Benennung ihres Standards. Steht doch oben schon Alles: VRR über HDMI geht bei AMD seit 3 Jahren, "HDMI 2.1 VRR" geht bisher nur bei der XBox und auf den AMD-PC-Grafikkarten dann mit einem bisher nur angekündigten Treiberupdate.

Übrigens können einige aktuelle Samsung TVs auch bereits HDMI 2.1 (inklusive VRR).

nordic_pegasus

2019-07-28, 22:22:20

Mit 'ner aktuellen XBox (One S und One X) geht "HDMI 2.1 VRR" schon auf den LGs. Gibt auch Tests dazu.

ich habe auch nie das Gegenteil behauptet. Ich sprach immer nur von PC-Grafikkarten, welche an TVs (nicht Monitore) angeschlossen werden.

Und der Rest ist einfach der durch die HDMI Group hervorgerufenen Begriffsverwirrung bei der Benennung ihres Standards. Steht doch oben schon Alles: VRR über HDMI geht bei AMD seit 3 Jahren, "HDMI 2.1 VRR" geht bisher nur bei der XBox und auf den AMD-PC-Grafikkarten dann mit einem bisher nur angekündigten Treiberupdate.

und mehr habe ich auch nie behauptet, bzw. dass war der Inhalt meines erster Kommentars als Antwort auf den Beitrag von JVC. AMD hat ein Treiber-Update angekündigt. Was gleichzeitig bedeutet, dass man derzeit mit keiner AMD Grafikkarte VRR auf einem TV nutzen kann, welcher nur die HDMI 2.1 VRR Spezifikation erfüllt (und nicht zusätzlich FreeSync).

Nightspider

2019-07-28, 23:30:30

Gipsel

2019-07-28, 23:59:04

und mehr habe ich auch nie behauptet, bzw. dass war der Inhalt meines erster Kommentars als Antwort auf den Beitrag von JVC.Na ja, irgendwo erschien mir das mit den Begrifflichkeiten von VRR über HDMI (was übrigens kein VESA-Standard ist, weder die FreeSync-Variante von AMD noch die Variante des HDMI forum in der 2.1 Spec) und HDMI 2.1 VRR arg durcheinander. Und Sätze wie: "AMD unterstützt aktuell kein VRR über HDMI." sind eben so nicht korrekt. Aber wenn jetzt Alles klar ist, ist doch gut.

Edit:
Achja, wie schon vermutet ist der Unterschied wohl tatsächlich nur ein paar Bits (https://forums.blurbusters.com/viewtopic.php?f=17&t=4423&start=10), mit denen der Monitor/Fernseher den Support signalisiert. Also eigentlich Alles kein Problem für Firmware- bzw. Treiberupdates, um Kompatibiliät herzustellen.

Screemer

2019-07-29, 00:01:36

Hab jetzt hier seit dem Release nicht nachgelesen also dorry falls ich so plump frage aber wie sinnvoll ist denn jetzt Radeon Anti Lag?

Der Test auf PCGH las sich ja gar nicht so schlecht. Die Redakteure konnten den Unterschied wohl spüren.
Gab nicht wirklich viel dazu zu lesen. Aufkrawall meinte aber, dass das durchaus gut und brauchbar ist. Sowas kommt von ihm ja nicht so oft ;)

N0Thing

2019-07-29, 00:07:46

Hab jetzt hier seit dem Release nicht nachgelesen also dorry falls ich so plump frage aber wie sinnvoll ist denn jetzt Radeon Anti Lag?

Je nach Spiel und Anwender wird es sehr positiv wahrgenommen, einige Leute hier im Forum hier haben es schon ausprobiert. Es kostet unter Umständen ein paar fps, aber der Effekt der reduzierten Latenz, scheint in kompatiblen Spielen seine Wirkung nicht zu verfehlen.

nordic_pegasus

2019-07-29, 07:01:23

Und Sätze wie: "AMD unterstützt aktuell kein VRR über HDMI." sind eben so nicht korrekt. Aber wenn jetzt Alles klar ist, ist doch gut.

ich bin an der Stelle zu stark Verwaltungsangestellter ;-)

Async ist meines Wissens der Oberbegriff. Darunter fallen die Standards Gsync (Nvidia), FreeSync (AMD) und VRR (HDMI Forum). Mit dieser Definition ist die Aussage korrekt, dass AMD derzeit kein VRR (= HDMI 2.1 Implementation) mit seinen Grafikkarten unterstützt, dies aber durch ein Treiber-Update nachreichen wird.

Wenn VRR und FreeSync zu 100% identisch wäre, müsste es ja "out of the box" funktionieren auf den neuen HDMI 2.1 TVs. Selbst wenn nur 2 Bits beim Handshake beider Geräte gedreht werden müssten, es ist nicht einfach nur ein Unterschied im Marketing-Namen. Und damit ist auch meine Aussage korrekt, dass VRR nicht identisch zu FreeSync ist.

Mit den Samsung TVs und der XBox One X/S haben wir zusätzlich noch die verwirrende Situation, dass beide Geräte neben dem HDMI 2.1 VRR auch noch FreeSync unterstützen. Bei der XBox wohl darum, weil Microsoft explizit die XBox auch für Monitore nutzbar machen wollte (es gibt ja afaik auch einen 1440p Modus, der mit TVs keinen Sinn macht).

Complicated

2019-07-29, 07:52:50

Das was du unterscheidest zwischen Gsync, Freesync und VRR mit HDMI ist alles das selbe. VRR ist die Bezeichnung des Features auch bei Freesync und bei Gsync.
Die Implementierung "zweier" Standards bei Samsung ist nichts weiter als die Nutzung zweier Bits als Dongle, um zu sehen ob das andere Gerät die entsprechende Lizenzierung hat. Bei AMD ist es kostenlos, bei VRR mit HDMI muss man ein HDMI zertifiziertes Gerät haben und bei Nvidia eines mit Gsync als Ausgabegerät/TV.

Auch HDMI muss um seine Berechtigung in Consumer Produkten kämpfen um nicht verdrängt zu werden von USB4 oder DP.
USB4 kommt ja mit 40 Gbit/s (ehemals Thunderbolt3)

Achill

2019-07-29, 10:43:53

ich bin an der Stelle zu stark Verwaltungsangestellter ;-)
[..]

Und das bedeutet was genau?

Gipsel

2019-07-29, 11:29:42

Async ist meines Wissens der Oberbegriff. Darunter fallen die Standards Gsync (Nvidia), FreeSync (AMD) und VRR (HDMI Forum).Nein. Allgemein nennt man das Feature normalerweise VRR (Variable Refresh Rate), weil es schlicht beschreibt, was es tut. Es gibt den VESA Adaptive Sync Standard (ASync, von AMD damals vorgeschlagen und gepusht), der die Umsetzung des Features über DisplayPort standardisiert. DisplayPort ist (wie seine optionale Komponente ASync) ein offener, freier Standard der "Video Electronics Standards Association" (VESA). FreeSync und GSync sind die Namen, unter denen AMD und nV ihre VRR-Funktionalität vermarkten.
FreeSync nutzt über DisplayPort von Anfang an den VESA Adaptive Sync Standard und über HDMI eine (offene) Erweiterung des HDMI-Standards (HDMI sieht herstellerspezifische Erweiterungen vor, bei der von AMD kann aber jeder das einfach so umsetzen, ohne zusätzliche Lizenzgebühren zu bezahlen), die auch mit HDMI 1.4 oder 2.0 funktioniert. G-Sync setzt dagegen traditionell auf eine proprietäre (nicht offene) Erweiterung des DP-Protokolls (macht im Prinzip am Ende nicht viel Anderes, ist aber nicht offen [und sogar "verdongelt"] und es gibt wohl noch irgend so einen Handshake bei jedem Frame [den sich VESA ASync spart, weil unnötig, wenn der Displaycontroller der GPU bestimmte Timings garantieren kann]). Erst seit kurzem unterstützt nV den VESA Adaptive Sync Standard unter dem Namen "GSync compatible".
Das HDMI-Forum (HDMI ist nicht wie DisplayPort ein offener, freier Standard sondern muß kostenpflichtig lizensiert werden und wird von einem Zusammenschluß von Herstellern [dem "HDMI Forum"] definiert) hat sich mit ihrer HDMI 2.1 Spec nun auch entschlossen, so ein Feature einzubauen. Und das haben sie eben einfallslos "HDMI 2.1 VRR" genannt, was vermutlich Einige verwirrt. Und nach Auskunft von Leuten, die sich damit auskennen (oben verlinkt), macht die HDMI 2.1 VRR- Erweiterung offenbar genau das Gleiche, wie AMDs älteres FreeSync über HDMI, lediglich die Kommunikation der Fähigkeiten des Displays (das muß der GPU ja sagen, daß es VRR kann und auch den möglichen Refreshratenbereich mitteilen) über EDID/E-EDID mit diversen Erweiterungen wie EIA/CEA/CTA-861 bzw. DisplayID läuft offenbar etwas anders und ist momentan noch nicht kompatibel (weswegen man das eventuell sogar über CRU entsprechend umbiegen kann [damit konnte man bei einigen Monitoren sogar VRR über DVI hinbekommen], in Zukunft aber ziemlich sicher über entsprechende Firmware- und Treiberupdates).

Aber ich denke, das reicht jetzt mit dem OT.

amdfanuwe

2019-07-29, 11:31:21

Und das bedeutet was genau?
Das er keine technische Ausbildung hat und ihm am liebsten eine Tabelle wäre, aus der hervorgeht welcher Monitor mit welcher GPU in welchem Modus zusammenarbeitet :-)

dargo

2019-07-30, 14:55:48

Was lese ich auf der Hauptseite? Navi 12 ist nun doch ein größerer Navi mit 64 CUs und soll schon Herbst/Winter 2019 kommen? :eek:

JVC

2019-07-30, 16:03:25

Was lese ich auf der Hauptseite? Navi 12 ist nun doch ein größerer Navi mit 64 CUs und soll schon Herbst/Winter 2019 kommen? :eek:
Jep, ist jetzt der "Big Navi" und kommt doch noch Heuer.

Aber irgendwas soll noch nächstes Frühjahr-Sommer kommen.
Ich hoffe auf n 16GB Monster mit HDMI 2.1 :smile:
(Gerüchte sprechen von merklich mehr als 300Watt)

Glaub nicht das es das mit der 5800(XT) dann war ...

M.f.G. JVC

HOT

2019-07-30, 16:25:35

Da wird mit RDNA2 noch ein dickerer kommen nächstes Jahr.

Dural

2019-07-30, 17:08:12

Vor allem kommt von amd innerhalb von nicht mal einem jahr zwei high end gpus...

Entwender kommt gleich was, oder nächstes jahr die 2. auflage.

dildo4u

2019-07-30, 17:11:07

Die RDNA2 Konsolen kommen vermutlich erst im November 2020,64 CU ohne RT Ende 2019 und mehr CUs + RT zusammen mit den Konsolen in 7nm+.
Die 2080 Super war ein zu kleines Update das sollten sie in der Tasche haben.

dargo

2019-07-30, 18:46:11

Löl? Mit 64 CUs hat das Teil bei gleicher Frequenz 60% mehr Shaderpower als Navi 10. Ich gehe davon aus, dass ca. 45-50% durchschlagen sollten (mit viel Glück 50-55%). Damit ist man nur knapp unter der 2080TI. Eine 2080 S ist nur 26% schneller in 4k als die 5700XT Referenz.
https://www.computerbase.de/2019-07/geforce-rtx-2080-super-test/2/#abschnitt_benchmarks_in_3840__2160

Edit:
Mir wäre dennoch lieber wenn dieser Navi 12 nur mit 1,6Ghz taktet. Das Teil hätte immer noch damit 42% mehr Shaderpower als Navi 10 und bei 200Mhz weniger könnte man die Spannung erheblich niedriger betreiben. Ergo geht der Verbrauch nicht durch die Decke. Wieder ~300W sind nicht unbedingt so pralle.

basix

2019-07-30, 19:00:31

Ein 64 CU Navi mit 384b SI wäre wohl <400mm2. Noch etwas geringere Taktraten als Navi 10 und man ist auf 2080Ti Schlagdistanz was Performance als auch Verbrauch anbelangt.

Irgendwie erwarte ich aber eher ein RDNA2 Dickschiff ("dick" mit 400mm2 :D) Mitte nächstes Jahr als noch was grösseres auf RDNA1. Nvidia hat den Bereich >500 Euro abgesteckt. Alles darunter kann Navi 10 und potentiell Navi 12 abdecken, wo das Volumen deulich höher ist. Da AMD wie gesagt ja nicht so viele Design- und Implementationsteams haben, lieber die Ressourcen bündeln.

dargo

2019-07-30, 19:12:52

:confused:

Die Gerüchte sind aktuell Navi 12 = 64 CUs.

Nightspider

2019-07-30, 19:45:46

dargo

2019-07-30, 19:48:52

7nm EUV wird denke ich erst bei RDNA2 ein Thema. Also eher Ende 2020.

fdk

2019-07-30, 19:59:29

Ende 2020 plant TSMC schon mit 5nm.
https://fuse.wikichip.org/news/2567/tsmc-talks-7nm-5nm-yield-and-next-gen-5g-and-hpc-packaging/

dargo

2019-07-30, 20:07:19

Planen kann man viel. Bis da was Brauchbares bei rumkommt dauerts (erst recht bei größeren Dies) wesentlich länger. Vor 2021 erwarte ich nichts mit 5nm. Und selbst da nur kleinere Sachen.

Linmoum

2019-07-30, 20:25:54

Planen kann man viel. Bis da was Brauchbares bei rumkommt dauerts (erst recht bei größeren Dies) wesentlich länger. Vor 2021 erwarte ich nichts mit 5nm. Und selbst da nur kleinere Sachen.
Brauchbares wird genug rumkommen und das schon sehr früh.

https://fuse.wikichip.org/wp-content/uploads/2019/07/vlsi-2019-tsmc-n7-yield-2.jpg
https://fuse.wikichip.org/news/2567/tsmc-talks-7nm-5nm-yield-and-next-gen-5g-and-hpc-packaging/

They attributed much of this to learning from their 10nm half-node. 5N is on a similar trajectory FWIW.https://twitter.com/david_schor/status/1145012516616957952

Das dürfte nur eine Kostenfrage (für AMD) werden.

JVC

2019-07-30, 20:32:28

Schlagt mich nicht gleich aber sagt mal, soll mit EUV nicht die Fertigung und die Yields besser werden?

Wäre es denkbar das dann im Frühjahr 2020 ein größerer Navi Chip schon in 7nm EUV kommt, mit noch besserer Effizienz?
Wäre denkbar :smile:

Die 570-590 rutschen auf lowend und sichern den GF Deal mit ... auch möglich ...

M.f.G. JVC

ChaosTM

2019-07-30, 20:47:41

Denniss

2019-07-30, 20:54:06

Wann ist eigentlich die nächste Techmesse auf der man informationen dazu erhoffen kann?
Lisa Su: "I have one more thing to show you ........" kurz vor Ende der Vorstellung der nächsten Threadripper ......

JVC

2019-07-30, 20:59:51

Vielleicht hat Navi 12 12Gb :confused:
Fände ich geil ^^

M.f.G. JVC

dargo

2019-07-30, 21:03:27

Wenn Navi 12 keinen HBM bekommt sind die 12GB garantiert. Mit einem 256Bit SI kommt man selbst mit 16Gbps nicht weit genug. Ergo braucht es 384Bit.

Palpatin

2019-07-31, 08:22:15

Da man Navi 10 sehr stark mit 1440p Gaming beworben hat wird man Navi 12 logischerweise dann sehr stark mit 4k bewerben und dafür eignen sich 384 bit und 12 GB perfekt. An HBM glaub ich nicht wenn er noch 2019 aufschlagen soll.

JVC

2019-07-31, 08:55:06

*träum* mhmm 12Gb und gute 4K Leistung, VRR auch über HDMI 2.1 , Software-RT ....*träum*
Könnte interessant werden für eine Neuanschaffung :smile:

M.f.G. JVC

Fragman

2019-07-31, 08:55:26

Wenn AMD sowas noch 2019 bringt, könnte man ja vermuten, das der Nachfolger frühestens Ende 2020 kommen wird, vielleicht sogar erst 2021. Andernfalls bleibt ja nicht viel Zeit zum Geldverdienen.

JVC

2019-07-31, 09:07:52

Wenn AMD sowas noch 2019 bringt, könnte man ja vermuten, das der Nachfolger frühestens Ende 2020 kommen wird, vielleicht sogar erst 2021. Andernfalls bleibt ja nicht viel Zeit zum Geldverdienen.
Aber das Gegenteil scheint Stadt zu finden...
Navi10 5700(XT) kommen bald die Customs.
Navi12 5800(XT) vermutlich noch vor dem Weinachtsgeschäft.
Navi"21" 5900(XT) nächstes Frühjahr ?

AMD tauscht schon länger nicht mehr das ganze Portfolio auf einmal.
Kann mir gut vorstellen das AMD immer 1-2 GPUs oben drauf setzt...

Ich frag mich eher, ob NV wirklich noch 2020 in 7nm kommt?
(die fangen doch grad erst an damit zu experimentieren?)

M.f.G. JVC

Raff

2019-07-31, 09:09:51

*träum* mhmm 12Gb und gute 4K Leistung, VRR auch über HDMI 2.1 , Software-RT ....*träum*
Könnte interessant werden für eine Neuanschaffung :smile:

M.f.G. JVC

Hab ich hier seit über zwei Jahren im Rechner, Titan X Pascal (sieht man von HDMI 2.1 ab). Interesse? :biggrin:

MfG,
Raff

JVC

2019-07-31, 09:14:35

Hab ich hier seit über zwei Jahren im Rechner, Titan X Pascal (sieht man von HDMI 2.1 ab). Interesse? :biggrin:

MfG,
Raff
Fast :wink: (Ein GB mehr macht den Braten auch ned fett ^^)

16GB und volles HDMI 2.1 plus die passende Leistung
und ich wäre wunschlos glücklich :freak:

Mich fuckt meine NV einfach irgendwie an :mad:
Irgendwie sind die "soooo kurzlebig" ...
Ein hoch auf die 390(X) und den "baldigen 16/24GB Nachfolger" :ubeer:

M.f.G. JVC

Fragman

2019-07-31, 09:50:35

Navi"21" 5900(XT) nächstes Frühjahr ?

Deshalb glaub ich nicht an einen Gaming High End 2019.
Ausser, der Neue kommt erst ende 2020.

JVC

2019-07-31, 10:08:48

Deshalb glaub ich nicht an einen Gaming High End 2019.
Navi 12 sollte vor dem Weihnachtsgeschäft kommen und merklich schneller sein als Navi 10...
Wan der wirklich auch noch mit 12Gb daher kommt, würde ich das schon High-End nennen.
(zu mindestens wäre sie es eher, als NVs 2080-Super es ist ^^)

M.f.G. JVC

Schnitzl

2019-07-31, 10:16:26

first: please stop the Hypetrain and wait for the next Announcement :tongue:
Wenn der große Navi dieses Jahr noch kommt wäre das genial.
Warum?
1. Mehr Wettbewerb
2. Dann hab ich endlich nen Grund, auf Ryzen+Navi umzurüsten. die 5700XT bringts nicht so von der 1070, imho (die Steigerung von der 7702GB auf die 10708GB war schon fett. >Sowas ähnlich nochmal bitte, diesmal von AMD)

MfG

HOT

2019-07-31, 10:16:30

Radeon 5300/400 -> P12 12nm Refresh
Radeon 5500(XT) -> P11 12nm Refresh
Radeon 5600(XT) -> N14
Radeon 5700(XT) -> N10
Radeon 5800(XT) -> N12 (64CUs, 7 DUV, RDNA1 (leider))
Radeon 59x0(XT) -> N21 (96CUs, 7 EUV, RDNA2, losless RT)

RT werden alle Navis können, nur wird es mit RDNA2 quasi verlustfrei gehen.

Im 2.HJ 2021 werden dann die ersten 5nm-GPUs ausgerollt.

Im Grunde ist das ähnlich, wie ich mir das zu Jahresanfang schon ausgemalt hatte. Nur, dass N10 nicht der 64 CU-Chip ist und die tatsächlich mit dem kleineren gestartet sind.

JVC

2019-07-31, 10:20:43

Radeon 5300/400 -> P12 12nm Refresh
Radeon 5500(XT) -> P11 12nm Refresh
Radeon 5600(XT) -> N14
Radeon 5700(XT) -> N10
Radeon 5800(XT) -> N12 (64CUs, 7 DUV, RDNA1 (leider))
Radeon 59x0(XT) -> N21 (96CUs, 7 EUV, RDNA2, losless RT)

RT werden alle Navis können, nur wird es mit RDNA2 quasi verlustfrei gehen.

In 2021 werden dann die ersten 5nm-GPUs ausgerollt.

Im Grunde ist das ähnlich, wie ich mir das zu Jahresanfang schon ausgemalt hatte. Nur, dass N10 nicht der 64 CU-Chip ist und die tatsächlich mit dem kleineren gestartet sind.
Schöne Glaskugel :smile:
Scheint im Groben gut eingestellt zu sein :biggrin:
("quasi verlustfrei" hängt wahrscheinlich von der verbauten CPU ab ;))

M.f.G. JVC

Schnitzl

2019-07-31, 10:32:13

sorry ich bin nicht so informiert. Gab schon nen Tapeout für N12?

JVC

2019-07-31, 10:33:58

sorry ich bin nicht so informiert. Gab schon nen Tapeout für N12?
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-29-juli-2019
Aber: "(bis auf den Chip-Namen) reine Gerüchte-Meldungen"

M.f.G. JVC

KrisNeme

2019-07-31, 10:36:32

Or, na super. Sehe mich schon Weihnachten ne 5800XT kaufen und nächstes Jahr ne 5900XT. Kann AMD nicht einfach das gesamt Portfolio auf einmal bringen.;D

JVC

2019-07-31, 10:37:31

Or, na super. Sehe mich schon Weihnachten ne 5800XT kaufen und nächstes Jahr ne 5900XT. Kann AMD nicht einfach das gesamt Portfolio auf einmal bringen.;D
Ich sag mir auch schon "Füße ruhig halten, das Warten lohnt sich" :freak:

M.f.G. JVC

Käsetoast

2019-07-31, 11:06:59

Wenn ich mir AMDs Salami Taktik angucke (es wurde ja immer nur so wenig wie möglich angekündigt um für spätere News noch was im Köcher zu haben und so im Gespräch zu bleiben) rechne ich zur Gamescom mit einem entsprechendem Teaser und einer groben zeitlichen Einordnung ab wann man mit mehr Infos oder gar einem Release von einer schnelleren Navi GPU rechnen kann...

mironicus

2019-07-31, 11:16:28

Es macht doch Sinn, dass Karten mit der Raytracing-Einheit erst Ende 2020 erscheinen und sie stattdessen jetzt noch größere Navis mit der RDNA 1.0-Architektur zeitnah veröffentlichen. Ist doch kein Problem für AMD einen leicht breiteren Chip rauszubringen. Bis 300 Watt gibt es viel Spielraum und mit den Verbesserungen kann AMD locker mit NVidia mithalten. Der eigentliche Nachfolger-Chip wird dann imho im verbesserten Fertigungsverfahren kommen, wahrscheinlich dann zeitnah mit den RTX 3000-Karten von NVidia.

HOT

2019-07-31, 11:21:18

sorry ich bin nicht so informiert. Gab schon nen Tapeout für N12?
Muss ja schon Ende letzten Jahres gewesen sein. Von AMD gibts eigentlich nie Informationen zum Tapeout.

mironicus
Muss nicht zwingend Ende 2020 sein, die Konsolen sind ja grob für 2. HJ angekündigt und haben das gleiche Featureset. Ich gehe davon aus, dass man immer ein Paar Monate zwischen den Launches hat. N10 Juli -> N14 September -> N12 Dezember -> N21 März (?)

Danach gibts noch den Super-Vega für KI und HPC und dann ist erst mal 1 1/2 Jahre Sendepause mit GPUs würd ich mal schätzen. Man wird 5nm mit Zen4 "offkicken".

Nightspider

2019-07-31, 11:36:21

RT werden alle Navis können, nur wird es mit RDNA2 quasi verlustfrei gehen.

Und ich bin der Weihnachtsmann!

JVC

2019-07-31, 11:39:56

Es macht doch Sinn, dass Karten mit der Raytracing-Einheit erst Ende 2020 erscheinen ...

Bei AMD deutet vieles auf eine hauptsächlich Software/CPU basierte Lösung hin.
(welche mir auch wesentlich lieber wäre als "spezialisierter Müll")

Theoretisch kann jetzt schon eine jede NV und eine jede AMD DXR/RT

Und ich bin der Weihnachtsmann!
Dann würde ich gerne nen 3950X und ne 5900XT ordern :smile:
(vielleicht kommt ja noch ne 5950 "SUPER"XT(X)?)
Schön einpacken und mit Schleife bitte :freak:

M.f.G. JVC

dargo

2019-07-31, 12:29:25

Wenn AMD sowas noch 2019 bringt, könnte man ja vermuten, das der Nachfolger frühestens Ende 2020 kommen wird, vielleicht sogar erst 2021. Andernfalls bleibt ja nicht viel Zeit zum Geldverdienen.
Wieso vermuten? Davon ging ich von Anfang an aus. Der Nachfolger kommt erst mit 7nm EUV. Und das kann nur frühestens Ende 2020 bedeuten.

HOT

2019-07-31, 12:45:39

Und ich bin der Weihnachtsmann!
Das ist ja nicht die NV-Lösung, sondern die, die die Konsolen anwenden werden. Kaum einer versteht ja auch, dass NV DLSS und RT als Gesamtpaket betrachtet. Mit DLSS ist RT ja gut nutzbar. Leider ist die DLSS-Implementation fast immer beschissen. Das ist einfach ein anderes Konzept als das, was die Konsolen umsetzen werden.

aufkrawall

2019-07-31, 12:57:22

Sorry, dude, but no.

dildo4u

2019-07-31, 13:11:47

Das ist ja nicht die NV-Lösung, sondern die, die die Konsolen anwenden werden. Kaum einer versteht ja auch, dass NV DLSS und RT als Gesamtpaket betrachtet. Mit DLSS ist RT ja gut nutzbar. Leider ist die DLSS-Implementation fast immer beschissen. Das ist einfach ein anderes Konzept als das, was die Konsolen umsetzen werden.
Es kostet immer massig Leistung wenn AMD auf Compute setzt ist die Performance genau so unterirdisch die HQ Version Cryenine Demo lief mit 1080p 30fps,auf Vega 56.Ich glaube kaum das Crytek das für alte AMD Hardware baut sondern das wird die Lösung für Navi sein.

deekey777

2019-08-05, 12:40:58

Lisa Su: High-End Navi GPUs Are On Track (https://www.tomshardware.com/news/lisa-su-high-end-navi-gpus-are-on-track,40068.html)

Keine RX 5870XT? :biggrin:

The RX 5950 XT is one of the more intriguing models as it's speculated to come with a dual-GPU configuration. How crazy would that be, having two Navi dies on the same PCB? Other equally interesting models are the RX 5x50-series. They appear to be more powerful models of their respective series, or they can be a refresh of the Navi offerings. It's anyone's guess for now.

Wer weiß, wer weiß. Sapphire hat alles verraten.

aufkrawall

2019-08-05, 12:53:45

Hoffentlich sind die nicht wirklich so blöd und vergeuden Energien in ein AFR-Schrottprodukt...

maximus_hertus

2019-08-05, 13:07:02

Alles wird gut, ein AFR Schrottprodukt wird nicht kommen.

mironicus

2019-08-05, 14:06:43

Sowas baut AMD doch höchstens für Apple.

HOT

2019-08-05, 14:23:01

Das wird wenn dann eine Lösung wie Zen2 sein. Ein Chiplet für die 5800 und zwei für die 5900.

Relic

2019-08-05, 14:41:31

Das wird wenn dann eine Lösung wie Zen2 sein. Ein Chiplet für die 5800 und zwei für die 5900.

Das funktioniert bei GPUs aber nicht so einfach...

HOT

2019-08-05, 14:59:48

Relic

2019-08-05, 15:22:59

Dafür hat man ja IF.
Wenn es Multichip wird, dann sowas. Ansonsten kein Multichip, ganz einfach.

Für die Anzahl der Verbindungen wird dann ein MCM natürlich nicht mehr reichen, da muss dann ein Interposer her.

Dafür ist IF aber zu langsam... der Multichip muss nach außen aussehen wie ein monolithischer, wenn man ohne Krücken wie AFR oder SFR auskommen will.

Käsetoast

2019-08-05, 15:29:36

Also an Multichip glaube ich noch nicht - ansonsten hätten wir sowas bei den APUs sicherlich schon gesehen / davon gehört, denn hier CPU und GPU Chiplets einzusetzen wäre ja auch sehr kostengünstig und für die unkritischeren Performancebereiche wären IF Datenraten und dergleichen sicherlich eher zu realisieren...

Ansonsten wäre es natürlich interessant, wenn man sowas wie einen Xilinx Raytracing Chip an eine GPU koppeln würde - aber da ja schon durchgesickert ist, dass AMD Raytracing über ihre TMUs realisieren will ist das wohl durch...

Der_Korken

2019-08-05, 15:56:36

Ich frage mich, wie sinnvoll es ist GPUs in Chiplets zu unterteilen. Der Aufbau von Ryzen 3000 sieht vielleicht erstmal verlockend aus, das Problem ist aber, dass bei GPUs das Speicherinterface mit der Anzahl der Chiplets mitwachsen muss. Ein IO-Die mit 256 Bit SI läuft vielleicht mit einem Chiplet gut, für zwei Chiplets ist die Bandbreite aber zu gering. Verbaut man aber gleich 384 oder 512bit, hat man einen riesigen IO-Die, der für das billige Modell mit nur einem Chiplet eigentlich zu teuer ist.

Außerdem muss die Bandbreite des IFs auch mit dem Speicher mithalten können. Ein 3700X kann nur mit 51,2/25,6GB über den IF lesen/schreiben. Eine 5700XT hat aber schon 448GB theoretische Bandbreite, d.h. der IF-Bus müsste mindestens um Faktor 4 wenn nicht gar Faktor 8 pro Chiplet aufgebohrt werden, damit diese nicht verhungern.

Und dann ist immer noch die Frage, wo man die GPU zerschneidet. Im Gegensatz zu einer Multicore-CPU hat eine GPU sowas wie ein zentrales Frontend. Eventuell kann man die Shader Engines in Chiplets auslagern, aber das Frontend müsste dann teilweise trotzdem in den IO-Die rein (den man dann eigentlich auch in 7nm fertigen müsste, was der Kostenersparnis eines IO-Dies in 14nm zuwider läuft) oder man regelt alles dezentral über die Chiplets, aber die bräuchten dann eine sehr schnelle und latenzarme Verbindung untereinander. Keine Ahnung ob sowas realistisch ist. Wenn AMD es vorhat, wird RDNA natürlich bereits drauf ausgelegt sein, denn sowas muss tief in der Architektur verankert sein.

Ansonsten wäre es natürlich interessant, wenn man sowas wie einen Xilinx Raytracing Chip an eine GPU koppeln würde - aber da ja schon durchgesickert ist, dass AMD Raytracing über ihre TMUs realisieren will ist das wohl durch...

Ich fürchte einen extra RT-Die an die GPU zu flanschen könnte ungefähr so sinnvoll sein, wie wenn AMD bei den CPUs die Chiplets nicht nach Kernen aufteilt, sondern auf den einen Chip alle INT-ALUS und auf den anderen Chip alle FP-ALUs packen würde.

HOT

2019-08-05, 15:56:58

Dafür ist IF aber zu langsam... der Multichip muss nach außen aussehen wie ein monolithischer, wenn man ohne Krücken wie AFR oder SFR auskommen will.
Das ist offen skalierbar. Alle Grafikchips ab Vega arbeiten intern mit IF, genau wie die CPUs.

AMDoderNvidia

2019-08-05, 16:32:23

Das ist offen skalierbar. Alle Grafikchips ab Vega arbeiten intern mit IF, genau wie die CPUs.

Das ist richtig, aber trotzdem ist der IF kein Mittel für die Skalierung der "Grafikberechnung". Wirf mal einen Blick ins Vega White Paper von AMD, da sieht man schön im Aufbau des Chips, für was der IF eingesetzt wird: Er verbindet nur den HBCC (an dem dann der HBM2-Speicher hängt) mit dem Rest, wobei der Graphics-Core eben nur eine komplette Einheit ist.

Für eine Skalierung müsste man mehrere Graphics-Core über den IF skalieren, was jedoch nicht so einfach ist... zumindest meine Vermutung.

Zitat:

In “Vega” 10, Inﬁnity Fabric
links the graphics core and the other main logic blocks on
the chip, including the memory controller, the PCI Express
controller, the display engine, and the video acceleration
blocks.

Mangel76

2019-08-05, 16:53:37

Lisa Su: High-End Navi GPUs Are On Track (https://www.tomshardware.com/news/lisa-su-high-end-navi-gpus-are-on-track,40068.html)

Keine RX 5870XT? :biggrin:

Wer weiß, wer weiß. Sapphire hat alles verraten.

Siehst du, was du angerichtet hast? Mit dem Zitieren dieser Hirngespinste wurde mal wieder eine Grundsatzdiskussion über GPU-Chipletdesigns und AFR losgetreten. Und alles nur, weil Sapphire sich ein paar Nummern vorsorglich schützen lies ;D

mboeller

2019-08-05, 17:38:28

für die SuperComputer Sachen arbeiten sie aber dran:

https://www.guru3d.com/news-story/amd-is-considering-chiplets-to-connect-future-cpus-and-gpus.html

... das Bild am Ende des Artikels. Im PDF darüber geht es um 32CU und 16CU Chiplets.

https://okayiran.github.io/docs/pdf/Routing-ISCA2018.pdf

BoMbY

2019-08-05, 17:39:19

Nur ist das immer noch kein "Schutz" sondern eine Registrierung für den Import von Produkten mit Kryptokomponenten. Das heißt aber nicht dass es irgendwelche Dual-Chip-Karten geben wird.

unl34shed

2019-08-05, 18:54:16

Das ist richtig, aber trotzdem ist der IF kein Mittel für die Skalierung der "Grafikberechnung".

Dein Zitat hast du aber schon gelesen? IF ist genau das, was dies ermöglicht. Es verbindet die Kernkomponenten miteinander und kann auch extern genutzt werden.

Dazu kommt noch der HBCC, der es erlaubt den Speicher zu splitten und schnellen "lokalen" Speicher pro Die zu nutzen.

robbitop

2019-08-05, 19:58:10

Also ich vermute IF verbindet nicht Shadercluster miteinander (was ja relativ bandbreitenintensiv und latenzarm sein müsste) sondern eher die GPU mit ihrem IMC und andere Komponenten.

AMDoderNvidia

2019-08-05, 20:50:08

Dein Zitat hast du aber schon gelesen? IF ist genau das, was dies ermöglicht. Es verbindet die Kernkomponenten miteinander und kann auch extern genutzt werden.

Die benötigten Bandbreiten innerhalb eines Graphics-Core kriegst Du nicht über einen IF sinnvoll geroutet. Das wird das ganze System ausbremsen. Letztlich ist das ja ein Zusammenspiel von Rasterizer, Scheduler, Shader, den L1-Caches - demgegenüber ist ein IF richtig lahm, das passt einfach (noch) nicht.

HOT

2019-08-05, 22:34:07

Wir werden ja sehen. Entweder ist das alles monolithisch, oder wir sehen eine IF-Lösung. Andere Möglichkeiten gibts da kaum.

aufkrawall

2019-08-05, 22:34:59

...oder der schon erwähnte Apple-Kram?

gravitationsfeld

2019-08-05, 23:56:51

ber das Frontend müsste dann teilweise trotzdem in den IO-Die rein (den man dann eigentlich auch in 7nm fertigen müsste
Weshalb muss man das in 7nm bauen? Solang die CUs in 7nm sind ist der Rest eigentlich egal. Man koennte die CUs durchaus in Chiplets stecken und der IO-Teil hat alles andere + L2.

Das wirkliche Problem ist dass man halt echt viel Bandbreite braucht zwischen den Chips.

Tatwaffe

2019-08-06, 00:37:17

Bei der Ps4 pro haben sie grösstenteils den Chip einfach gespiegelt, werden sie hier wieder machen denk ich, erstmal Leckströme
beseitigen und Ausbeute erhöhen beim aktuellen Design, dann den Chip spiegeln und ein paar ROP Register hinzufügen, fertig ist der neue Chip .

Der_Korken

2019-08-06, 00:44:33

Weshalb muss man das in 7nm bauen? Solang die CUs in 7nm sind ist der Rest eigentlich egal. Man koennte die CUs durchaus in Chiplets stecken und der IO-Teil hat alles andere + L2.

Das wirkliche Problem ist dass man halt echt viel Bandbreite braucht zwischen den Chips.

Was ist mit dem Geometry und Graphics Command Processor? Da steckt doch sicher eine Menge Logik drin, die man ungern in 14nm fertigen will, genau wie den gesamten L2.

https://hothardware.com/ContentImages/Article/2874/content/small_navi-die.jpg

Zur Bandbreite: Würde ein Interposer helfen? V20 schaufelt 1TB/s an benachbarte HBM-Dies, ohne dass Verbrauch und Flächenbedarf durch die Decke gehen. Könnte die GPU-internen Daten auf die selbe Art transportieren oder wäre das verbrauchsmäßig immer noch Irsinn im Vergleich zu einem monolithischen Design?

Langlay

2019-08-06, 01:19:20

Zur Bandbreite: Würde ein Interposer helfen? V20 schaufelt 1TB/s an benachbarte HBM-Dies, ohne dass Verbrauch und Flächenbedarf durch die Decke gehen. Könnte die GPU-internen Daten auf die selbe Art transportieren oder wäre das verbrauchsmäßig immer noch Irsinn im Vergleich zu einem monolithischen Design?

Die Anbindung zum HBM ist pro Datenleitung (HBM ist 1Bit pro Takt, HBM2 ist 2 Bit pro Takt) nicht besonders schnell, es gibt aber 1024 Datenleitungen pro HBM Stack.

Tatwaffe

2019-08-06, 01:27:06

das würde die GPU sehr groß und damit teuer und auch komplizierter machen inkl. mehr Stromverbrauch, Vega7 hat die 1 tb/s über 4 HBM2 stacks realisiert damit ist das package quasi voll.
Sie müssten die beiden GPU´s dann zusätzlich mit 20 IF verbinden aka 1 tb/s , oder man kannibalisiert die bisherige Bandbreite wenn die chips zusätzlich kommunizieren, was sie ja müssten um alles synchron zu halten.

Auch ist Bandbreite ja nicht alles, Latenzen sind genauso wichtig.

Glaub nicht das AMD diesen Weg geht, von möglichen Softwareproblemen noch garnicht gesprochen.

Die ps5 und XBOX two apu´s stehen ja auch noch an mit angeblich 4k @120fps oder sogar 8K Inhalt , hier wurde in der Vergangenheit auch monolithisch gearbeitet.

gravitationsfeld

2019-08-06, 04:51:19

Zur Bandbreite: Würde ein Interposer helfen?
Ja, sowas wie EMIB auch. Ich glaube da wird's drauf hinaus laufen. Fragt sich nur ob AMDs Zulieferer das schon bauen koennen in grossen Stueckzahlen?

Zossel

2019-08-06, 06:10:48

Grendizer

2019-08-06, 06:21:00

Es gibt ja DX12 MultiGPU und Vulkan MultiGPU, wo sich sogar GPUs verschiedener Hersteller zusammenschalten lassen.

Und obwohl die meisten Spiele GPU limitiert sind implementiert das niemand und die Zielgruppe beschäftigt sich lieber mit Speichertimings.

Weil das wohl in der Vergangenheit einfach zu wenige auf Grund der doppelten Kosten genutzt haben und die Skalierung in der Vergangenheit halt auch nicht immer so prall war und oft auch einfach gar nicht unterstützt wurde. Als Spielhersteller würde ich für 1% (?) auch keine Zeit / Geld investieren.

Zossel

2019-08-06, 07:02:35

Weil das wohl in der Vergangenheit einfach zu wenige auf Grund der doppelten Kosten genutzt haben und die Skalierung in der Vergangenheit halt auch nicht immer so prall war und oft auch einfach gar nicht unterstützt wurde. Als Spielhersteller würde ich für 1% (?) auch keine Zeit / Geld investieren.

Hier (https://hexus.net/tech/news/graphics/121844-amd-boasts-vulkan-multi-gpu-support-strange-brigade/) sind es 190%.

Hier (https://hardforum.com/threads/dx12-multi-gpu-live-and-well-in-shadow-of-the-tomb-raider.1967930/) sind es 167%.

Grendizer

2019-08-06, 07:08:30

Hier (https://hexus.net/tech/news/graphics/121844-amd-boasts-vulkan-multi-gpu-support-strange-brigade/) sind es 190%.

Hier (https://hardforum.com/threads/dx12-multi-gpu-live-and-well-in-shadow-of-the-tomb-raider.1967930/) sind es 167%.

Ja, das bestreite ich ja gar nicht ...

Allerdings auch:

https://www.computerbase.de/2019-03/titan-rtx-sli-test/

Zwar läuft SLI auf Turing ein wenig besser als SLI auf Pascal, was in erster Linie an der höheren Bandbreite über den NVLink liegt, und die doppelten PCIe-Lanes pro GPU bringen in manchen Spielen auch nochmal einen kleinen Schub. Das ändert aber nichts daran, dass die meisten neuen Spiele – und das gilt auch für Triple-A-Titel – Multi-GPU überhaupt nicht mehr unterstützen. Und bei den Titeln, die damit umgehen können, zeigen sich oft sehr schlechte Frametimes. So bleibt das Spielgefühl schlechter als mit einer einzelnen Grafikkarte.

Zossel

2019-08-06, 07:41:24

....... Zwar läuft SLI auf Turing ein wenig besser als SLI auf Pascal .......

(DX12 MultiGPU und Vulkan MultiGPU) != SLI

Locuza

2019-08-06, 09:23:26

Hiroshige Goto hat vor kurzem einen Artikel zu Nvidias Testchip RC18 geschrieben, wo mehrere Chips über GRS-Verbindungen (Ground Referencing Signaling) kommunizieren.

Letztendlich wird bei GPUs auf so etwas hinauslaufen:
https://pc.watch.impress.co.jp/img/pcw/docs/1197/355/03.png

Wichtig ist es aber die Bandbreite hoch genug zu bekommen, damit Chiplets mit mehreren Hunder GB/s kommunizieren können.
In einer älteren Nvidia Studie waren es glaube ich 768 GB/s die nötig waren, um nicht zuviel Performance zu verlieren (Bei X TF an Leistung, weiß ich nicht mehr und bin zu faul nach zu schauen).
Dann ein paar Anpassungen bei der Memory-Hierarchie und der Verwaltung der Daten.

Die Verbindung muss neben einer massiven Bandbreite zwischen den Chiplets natürlich auch noch sehr energieeffizient ausfallen, ein Kernthema bei Nvidias Forschungsarbeit bezüglich den GRS-Links und dem aktuellen Ziel bei einem Pikojoule pro Bit zu landen.

https://pc.watch.impress.co.jp/docs/column/kaigai/1197355.html

JVC

2019-08-06, 10:05:28

Letztendlich wird bei GPUs auf so etwas hinauslaufen:
https://pc.watch.impress.co.jp/img/pcw/docs/1197/355/03.png

Höchst wahrscheinlich, aber vermutlich erst 2021...
(könnte die Antwort auf NVs 7nm werden)

M.f.G. JVC

HOT

2019-08-06, 11:03:52

Ehrlich gesagt glaube ich nicht daran, dass das AMDs Zukunft ist. Das mag NVs Zukunft sein.

aufkrawall

2019-08-06, 11:10:40

Es gibt ja DX12 MultiGPU und Vulkan MultiGPU, wo sich sogar GPUs verschiedener Hersteller zusammenschalten lassen.

Nur weil es die Anwendung komplett selbst managed, funktioniert es trotzdem leider nicht automatisch fehlerfrei. In SotTR DX12 gibt es etwa fieses Geflacker, genau wie "früher" mit dem Treiber-Schrott und <=DX11.
Wenn es überall wie in Strange Brigade funktionieren würde (nämlich mit perfekter Skalierung, perfekten Frametimes und offenbar ohne Grafikfehler, btw. auch mit Vulkan), ok. Aber so...

Tatwaffe

2019-08-06, 11:27:03

3nm steht ja bei TSMC bereits vor der Tür, 5nm bereits 2020, 3nm für 2022, erst wenn man hier nicht mehr weiterkommt wird das ne Option denk ich.

Auch weitere 7nm Prozesse sollen noch Vorteile im Verbrauch und bei der Packdichte machen 7nm+ zB wird für die Zen3 2020 (vermutlich ab Mitte) benutzt; ca 15% sparsamer.
7nmP ist eine aktuell verfügbare performance Version des aktuellen 7nm und soll nochmal 10% sparsamer rangehen.

Das dürfte ungleich schwerer werden die "Needs a few TB/s of Bi-Section Bandwitch to emulate a Giant GPU" bereit zu stellen, das sind ganze Faktoren mehr als 786GB/s

Studien sind immer eine Sache, eine wirtschaftliche Lösung zu bauen ein ganz andere.

Multi GPU ist immer auf darauf ausgelegte Engines angewiesen und da der Marktanteil Richtung <1% geht hat das 0 priorität bei den Entwicklern, da stehen Sachen wie Raytracing, Ki, VR deutlich höher.

unl34shed

2019-08-06, 11:52:49

Nur weil es die Anwendung komplett selbst managed, funktioniert es trotzdem leider nicht automatisch fehlerfrei. In SotTR DX12 gibt es etwa fieses Geflacker, genau wie "früher" mit dem Treiber-Schrott und <=DX11.
Wenn es überall wie in Strange Brigade funktionieren würde (nämlich mit perfekter Skalierung, perfekten Frametimes und offenbar ohne Grafikfehler, btw. auch mit Vulkan), ok. Aber so...

Nicht nur in SotTR auch in AOTS gab's das Flackern. Meiner Meinung nach wird da durch Optimierungen im Treiber der beiden Hersteller einfach unterschiedlich gerendert und es kommt zu unterschiedlichen Ausgaben und eben deshalb zum Flackern. Das Spiel kann da denke ich eher weniger für.
Die Redaktionen scheint so ein Verhalten aber wie immer nicht zu interessieren, weshalb man wohl ewig auf eine Antwort warten muss.

y33H@

2019-08-06, 11:58:20

Ich spiele Tomb Raider nicht ^^ davon ab ist Multi-GPU halt quasi tot.

Raff

2019-08-06, 12:23:25

Die Redaktionen scheint so ein Verhalten aber wie immer nicht zu interessieren, weshalb man wohl ewig auf eine Antwort warten muss.

Das "wie immer" ist unfair. Unfairness führt dazu, dass man erst recht nicht das bekommt, was man haben will.

Redaktionen machen zuerst das, was die Masse der Leute interessiert. Da das bereits ~120 % der Arbeitszeit bindet (mathematisch korrekt -> Überstunden), bleibt wenig Zeit für Nischenthemen. Wartet mal auf einen echten Sommer mit Sommerloch. Der 2019er-Sommer ist das krasse Gegenteil (was gut ist). :)

MfG,
Raff

aufkrawall

2019-08-06, 12:34:49

Nicht nur in SotTR auch in AOTS gab's das Flackern. Meiner Meinung nach wird da durch Optimierungen im Treiber der beiden Hersteller einfach unterschiedlich gerendert und es kommt zu unterschiedlichen Ausgaben und eben deshalb zum Flackern. Das Spiel kann da denke ich eher weniger für.
Die Redaktionen scheint so ein Verhalten aber wie immer nicht zu interessieren, weshalb man wohl ewig auf eine Antwort warten muss.
Das Flackern war mit 2x RX 580.

unl34shed

2019-08-06, 12:34:59

Das Problem mit Flackern bei MultiGPU ist ja kein aktuelles. Das gab es schon vor Jahren in AotS. Ich kann mich noch an ein Video erinnern, ich glaube von der PCGH, da war das Flackern mit einer Fury und Titan auch deutlich zu sehen und würde damals mit einem Satz abgefertigt. Frei aus dem Gedächtnis "jetzt ist die Fury raus und das Flackern ist weg." Damit war das Thema erledigt.

JVC

2019-08-06, 14:37:30

Ich spiele Tomb Raider nicht ^^ davon ab ist Multi-GPU halt quasi tot.
Noch!

M.f.G. JVC

JVC

2019-08-06, 16:27:27

Ehrlich gesagt glaube ich nicht daran, dass das AMDs Zukunft ist. Das mag NVs Zukunft sein...
Wer hat mehr Erfahrung im "kleben" ?

M.f.G. JVC

p.s.: ups SRY Doppelpost ...

Zossel

2019-08-06, 17:31:07

Ich spiele Tomb Raider nicht ^^ davon ab ist Multi-GPU halt quasi tot.

Alle Welt will schnellere Frames, und da gibt es eine technische Möglichkeit und dann wird die nicht genutzt?

JVC

2019-08-06, 17:34:59

... und da gibt es eine technische Möglichkeit und dann wird die nicht genutzt?
NV hats vergeigt ^^ (die dachten mit vorzeitigem RT können sie ne menge kohle machen/mehr begeistern...)

M.f.G. JVC

Thomas Gräf

2019-08-06, 17:54:18

Wenn NV es mit Echtzeit RT ernst meint werden sie iwann schon mit mGPU Lösungen rüberkommen müssen.
Zumal Grafik ihr Kerngeschäft ist und Leistung auch für VR un AI gebraucht wird.
Mein Bauchgefühl sagt erst wenn die 3nm durch sind und es wirklich nicht mehr weitergeht wird man auf diesen 3nm Prozess dann mGPU versuchen.

gravitationsfeld

2019-08-06, 18:14:08

Mehr Infos zur Architektur in den Slides hier:
https://gpuopen.com/wp-content/uploads/2019/08/RDNA_Architecture_public.pdf

gravitationsfeld

2019-08-06, 18:53:48

y33H@

2019-08-06, 19:15:34

NV hats vergeigt ^^ (die dachten mit vorzeitigem RT können sie ne menge kohle machen/mehr begeistern...)Wohl eher schon mal das Ökosystem bereiten, siehe CUDA ...

JVC

2019-08-06, 19:21:49

Mehr Infos zur Architektur in den Slides hier:
https://gpuopen.com/wp-content/uploads/2019/08/RDNA_Architecture_public.pdf
Super, aber nicht jeder versteht das ...
Wohl eher schon mal das "Ökosystem" bereiten, siehe CUDA ...
"Tu" ich seit meinem Elektroauto schon länger ^^ (need mehr Strom :freak:)

M.f.G. JVC

gravitationsfeld

2019-08-06, 21:34:09

Super, aber nicht jeder versteht das ...
Und?

Der_Korken

2019-08-06, 22:23:12

Mehr Infos zur Architektur in den Slides hier:
https://gpuopen.com/wp-content/uploads/2019/08/RDNA_Architecture_public.pdf

Interessant, da versteht sogar ein Noob wie ich einiges von. Trotzdem zwei Fragen in die Runde:

1. Wie ist die Syntax der Befehle auf Folie 8? fma und f32 verstehe ich noch, aber was ist fmac und wie liest man die ganzen Targets dahinter?

2. Wie muss man das verstehen, dass alle Caches read-only sind, bis auf den L2? Bedeutet das, dass man bei einem cache-miss zwar die Daten vom Speicher in den Cache bekommt, diese aber nicht verändern darf? Wie würden dann Schreibzugriffe aufgelöst?

pixeljetstream

2019-08-06, 22:55:53

1. Es gibt auch ein ISA PDF
2. Wenn du in Speicher schreibst
blah[idx] = blubb
Dann wird der neue wert (blubb) erst im L2 gecached. Da der L2 coherent für die ganze GPU ist und nicht wie der L1 es mehrere gibt, ist blubb für alle sichtbar (so lange sie von blah coherent lesen, oder ihr L1 geflusht wurde).

Du kannst damit ein "working set" im Cache halten, sagen wir ein Compute pass berechnet etwas was der nächste Pass ließt. Dazwischen könntest du dann L1 flushen, so dass der für die reads dann die Werte erst aus dem L2 holt, oder Du machst memory loads die am L1 cache vorbei gehen, z bsp. wenn du weißt dass du die Daten eh nur einmal ließt.

Der L2 ist für die GPU die einzige schnelle Möglichkeit über den Chip hinweg zu kommunizieren.

Der_Korken

2019-08-06, 23:12:20

1. Es gibt auch ein ISA PDF

OK, hab jetzt tatsächlich nachgeguckt :D: Die farbigen Targets sind die Zielregister und fmac schreibt ins selbe Register, aus dem es einen Summanden liest, deswegen stallt der obere Code (falls jemand die gleiche Frage hat).

2. Wenn du in Speicher schreibst
blah[idx] = blubb
Dann wird der neue wert (blubb) erst im L2 gecached. Da der L2 coherent für die ganze GPU ist und nicht wie der L1 es mehrere gibt, ist blubb für alle sichtbar (so lange sie von blah coherent lesen, oder ihr L1 geflusht wurde).

Du kannst damit ein "working set" im Cache halten, sagen wir ein Compute pass berechnet etwas was der nächste Pass ließt. Dazwischen könntest du dann L1 flushen, so dass der für die reads dann die Werte erst aus dem L2 holt, oder Du machst memory loads die am L1 cache vorbei gehen, z bsp. wenn du weißt dass du die Daten eh nur einmal ließt.

Dass das was mit der Kohärenz zu tun hat, habe ich mir schon gedacht. Aber würde das nicht zu dem Problem führen, dass ich in den L2 zwar blah[idx] = blubb schreibe, aber wenn ich dann nochmal blah[idx] lese, ich dann wieder den alten Wert aus dem L1 bekomme? Wird hier dann lokal invalidiert, statt wie bei CPUs write-through zu machen?

Locuza

2019-08-06, 23:14:02

Super, aber nicht jeder versteht das ...

Ist eine super Deck, was viele Sachen erklärt.

Eine selektive Zusammenfassung:
- Es gibt 20 Waves (WAVE64 oder WAVE32) pro SIMD32, dass würde bedeuten das es 40 Waves pro Compute Unit gibt, wie bisher auch.
GCN kann bis zu 10 Waves pro SIMD16 verwalten (4x10 statt 2x20).
Einfach wie viele Waves (Threads) RDNA verwalten kann, was eine interessante Info bezüglich Latency-Hiding und Compute-Durchsatz ist.

- Eine Wave32 kann jeden Takt abgeschickt werden oder eine Wave64 alle zwei Takte, dass ist bekannt, ebenso das FMA ops nun 5-Takte benötigen und nicht mehr nur 4 wie bei GCN oder Volta/Turing.
Instruction Dependencies werden über die HW gelöst, gab es bei GCN nicht und Nvidia encoded das über die SW bzw. den Driver-Compiler.

- Navi kann Transzendente Funktionen wie Wurzelziehen, Sinus, Cosinus etc. nun gleichzeitig mit anderen Mathematik-Operationen berechnen.
Bei GCN gab es laut dem anderem Slide-Deck pro SIMD16 eine Special Function Unit, welche selber als SIMD4 operiert hat und entweder die eine oder andere SIMD-Unit konnte arbeiten, aber nicht beide gleichzeitig.
Bei Navi können die SIMD32 Units parallel zu den breiteren SFUs (SIMD8) arbeiten, dass blockiert sich nicht mehr gegenseitig und insofern können die Latenzen massiv kürzer ausfallen.

https://pbs.twimg.com/media/EBT3Ou9WsAElq1F?format=jpg&name=large
https://pbs.twimg.com/media/EBT3OvAWkAA24KV?format=jpg&name=large

- Allgemein die Notiz das RDNA mit weniger Theads nun viel besser ausgelastet werden kann, als GCN.

- Der Compiler achtet darauf, ob WAVE32 oder WAVE64 verwendet werden sollte, je nachdem ist das eine oder andere besser.
Für Vertex-Shader und Compute-Shader wird meistens WAVE32 verwendet, während für Pixel-Shader meistens WAVE64 zum Einsatz kommt.

- Tatsächlich hat Navi10 nur zwei Shader-Engines bzw. 2 Shader-Arrays pro Shader-Engine, während bei GCN es noch so war das jede Shader-Engine nur ein Shader-Array hatte.
RDNA kann sowohl im WGP-Mode (Work-Group-Processor) arbeiten, wo zwei CUs praktisch eine Einheit mit shared Ressources darstellen, als auch im CU-Mode, wo jede Compute-Unit einzeln agiert, aber AMD verwendet immer die Darstellung mit WGPs.
Das könnte bedeuten, dass die 5700 z.B. zwei WGPs deaktiviert hat (insgesamt 4 CUs), was bedeuten würde das AMD z.B. zwei Shader-Arrays mit 4 WGPs hätte und zwei mit 5 WGPs.

Also wie auf der linken Seite:
https://pbs.twimg.com/media/D-51JHVX4AAjyPg?format=jpg&name=large

- AMD stellt die Evolution der Memory-Hierarchie vor, auch in Bezug auf den L2$.
Bei GCN1-4 wurden nur die Compute-Units vom L2$ bedient, was dann bei Operationen von anderen Units dazu führen konnte, dass der L2$ geflushed (geleert) werden musste, um Datenkohärenz sicher zu stellen.
Das verschwendet natürlich viele Zyklen und Energien.
Ab GCN5 hat AMD die ROPs (Render-Backend) und den CP (Command Processor) unter den L2$ gestellt und damit viele L2$ Flushes eliminiert.

Aber die Copy-Engine war noch kein Client vom L2$, dass ändert sich mit Navi.
Zusätzlich hat Navi 128KB L1$ pro Shader-Array, der die WGPs (Dual Compute Units) und die ROPs (Render Backend) bedient und damit den Druck auf den L2$ bezüglich der Anfragen reduziert.

- Die Delta Color Compression funktioniert nun in deutlich mehr Fällen.

- Full-Rate FP16 Texture-Filtering und ein paar Änderungen, um eine höheren Load/Store-Durchsatz zu erreichen bei den Texture Units zu erreichen.
Ebenso hat Navi jetzt eine dedizierte Warteschlange für Stores und nicht mehr eine gemeinsame, was zu weniger Wartezyklen führt.

basix

2019-08-07, 00:07:46

Die benötigten Bandbreiten innerhalb eines Graphics-Core kriegst Du nicht über einen IF sinnvoll geroutet. Das wird das ganze System ausbremsen. Letztlich ist das ja ein Zusammenspiel von Rasterizer, Scheduler, Shader, den L1-Caches - demgegenüber ist ein IF richtig lahm, das passt einfach (noch) nicht.

IF Bandbreite von Vega 64 liegt chipintern bei genau 512 GB/s. Jetzt rate mal, wie hoch die Speicherbandbreite von dem Ding war ;) Ich vermute, dass die Bandbreite für sehr viele Dinge ausreichend wäre.

Latenzen würde ich zumindest bei GPUs nicht so extrem bewerten, da schon heute massivst Latency Hiding verwendet wird.

Bandbreite und Latenz von den Caches ist eine andere Sache. Man müsste bei jedem Chiplet lokal L1/L2$ haben, darum wird man wohl nicht herumkommen.

Eine weitere Frage ist die Skalierbarkeit und der Kommunikationsaufwand der Rasterizer untereinander. Da kenne ich mich überhaupt nicht aus.

Wenn ich jetzt irgendwie raten müsste, würde ich beim Makroaufbau auf etwas Zen 2 mässiges tippen: Ein zentraler "Command Processor" mit Multimedia-Engine, Display Engine, PCIe, Command Processor und was es sonst noch generell für eine GPU braucht. Sowas würde auch in einen aktiven Interposer passen. "Compute Chiplets" mit allen skalierbaren Einheiten wie Rasterizer, SI, TMUs, CUs und genug Cache für die einzelne Einheit.

Problemstelle bleibt allerdings die nötige Bandbreite vs. Energieverbrauch: IF benötigt 2pJ/bit. Das entspricht 9W für 512GB/s. Würde im Powerbudget drin liegen, ist aber ein signifikanter Anteil. Es sind also Ideen gefragt, um entweder pJ/bit oder die benötigte Bandbreite zu senken. Nvidia hat hier mit GRS etwas interessantes entwickelt. Bei max. 6mm Abstand liegt man on-package bei 0.58pJ/bit. Damit läge man bei 2.5W bei 512GB/s, was wohl für die allermeisten GPUs gangbar wäre, auch bei mehreren Chiplets und entsprechender bidirektionaler Kommunikation.

pixeljetstream

2019-08-07, 00:45:45

aber wenn ich dann nochmal blah[idx] lese, ich dann wieder den alten Wert aus dem L1 bekomme? Wird hier dann lokal invalidiert, statt wie bei CPUs write-through zu machen?
Genau, deswegen mein Hinweis dass du im shader dann halt uncached read machst (am lokalen L1 vorbei) oder in der api zwischen den passes mittels barriers L1 flush/invalidate auslöst.

TheAntitheist

2019-08-07, 03:16:44

Alle Welt will schnellere Frames, und da gibt es eine technische Möglichkeit und dann wird die nicht genutzt?
mit AFR Multi GPU werden die Frametimes aber 0 besser, der delay wird sogar schlechter und die frame distribution auch.

Zossel

2019-08-07, 07:39:29

mit AFR Multi GPU werden die Frametimes aber 0 besser, der delay wird sogar schlechter und die frame distribution auch.

IMHO ist das kein AFR, sonst könnte DX12- und Vulkan-MGPU keine GPUs unterschiedlicher Geschwindigkeit und Hersteller zusammenschalten.
Als das aufkam gab es ein paar Artikel über dieses Thema wo die Quintessenz war das das taugt wenn die Anwendung das implementiert.

Ist jemand anwesend der sich damit besser auskennt?

Dural

2019-08-07, 10:52:43

Alle Jahre wieder?

Wenn man nach den Gerüchten geht, hätten wir schon vor 10 Jahren solche Multi GPUs Designs gehabt. :freak:

Und ich habe schon vor 10 Jahren gesagt dass es im Gaming Bereich nicht wirklich viel Sinn macht! GPUs kann man hervorragend Skalieren und auch Bescheiden. Der Aufwand und die Nachteile übertreffen doch bei weitem den Nutzen.

Stand 2019 könnte es Dank RT vielleicht mehr Sinn machen, oder die Fertigung macht dicht, das dürfte in jüngerer Zeit aber noch nicht eintreffen.
Der Grosse Einsatzbereich sehe ich aber viel mehr im HPC.

Leonidas

2019-08-07, 13:48:35

RDNA White Paper:
https://gpuopen.com/wp-content/uploads/2019/08/RDNA_Architecture_public.pdf

Der_Korken

2019-08-07, 15:27:04

RDNA White Paper:
https://gpuopen.com/wp-content/uploads/2019/08/RDNA_Architecture_public.pdf

Siehe Beitrag #4869 ;)

danarcho

2019-08-07, 16:54:56

Ich finde, es sind schon einige interessante Sachen dabei, auch wenn mir nicht bei allen slides gefällt wie es aufbereitet wurde (z.B instruction latency & occupancy).
z.B. könnte man denken, dass das register file vergrößert wurde (RDNA 1024 register vs vorher 256), was aber gar nicht der Fall ist. Nur die Zählweise hat sich geändert. Bei der latency kann man RAW hazards bekommen, was vorher nicht ging etc.
Ich bin mir sicher, dass dieser Aufbau seine Vorteile bei kurzen Shadern hat, bei wenigen Prims und bei viel divergence, und das sieht man ja auch schön in den Benchmarks. Intel macht das ja schon lange mit dem Wave8/16 modi, und Nvidia scheint sich ja die 32 als goldene Mitte gepickt zu haben. Bin mal gespannt wie AMD von hier weitergeht, ob sie irgendwann Wave64 droppen, oder ob das jetzt der neue status quo wird erstmal.

gravitationsfeld

2019-08-07, 19:03:51

IMHO ist das kein AFR, sonst könnte DX12- und Vulkan-MGPU keine GPUs unterschiedlicher Geschwindigkeit und Hersteller zusammenschalten.
Natuerlich kann man das. SFR mit unterschiedlichen GPUs waere ein viel groesseres Problem.

Ich versteh aber nicht warum sich irgernd jemand den Aufwand macht das zu unterstuetzen. Multi-GPU mit GPUs die verschiedene Performance haben ist noch viel unnuetzer als es ohnehin schon ist.

Heterogeneous Multi GPU ist ein Zombie. Lasst es sterben.

gedi

2019-08-07, 20:46:22

Kann mir mal einer erklären, was die SoC-Clock ist?

https://s18.directupload.net/images/190807/kb5byr5h.png (https://www.directupload.net)

Zergra

2019-08-07, 21:30:48

War bei Vega doch der Speicher Controller.

gedi

2019-08-07, 21:35:29

Schon klar, allerdings taktet der anders als die GPU oder der Vram. Kann sein der springt kurzzeitig auf 1,3G, obwohl die GPU lediglich mit 330Mhz taktet und der Vram bei 500 oder so hängt.

Tatwaffe

2019-08-07, 21:42:52

Wenn ich das richtig verstanden habe,

Ist das in etwa das was zb ein 4 takt system im Auto ist. Grob gesagt erzeugt ein Auto ja nicht nur Bewegung und Abgas,
1 takt einspritzen, 2 Verdichten, 3 Zünden, 4 Ausstoß

Hier ist das halt die elektronische Variante davon mit deutlich mehr Schritten.
quasi die Arbeitsuhr /Zusammenspiel aller internen Komponenten
zB
1. Prefetch/Fetch: Instructions are fetched from the instruction cache and aligned for decoding.
2.Decode1: Instructions are decoded into the internal instruction format. Branch prediction also takes place at this stage.
3.Decode2: Same as above. Also, address computations take place at this stage.
4. Execute: The hardware executes the instruction.
Write-back:

Also ein Arbeitszyklus.

gedi

2019-08-07, 22:05:26

Eigentlich dachte ich dass Arbeitszyklen immer im Takt der CPU ausgeführt werden.

danarcho

2019-08-08, 08:16:52

Kann mir mal einer erklären, was die SoC-Clock ist?
Wunderst du dich nicht mehr über die GPU-Clock von 17 Mhz? :tongue:
Wenn ich das richtig verstanden habe,
...
Also ein Arbeitszyklus.
Das, was du beschrieben hast, wird gemeinhin als instruction latency verstanden, also die Anzahl der Taktzyklen, die eine Instruktion benötigt, um vollständig ausgeführt zu werden, und das ist bei jedem Prozessor (auch GPUs) unterschiedlich und hängt in der Regel auch von der Instruktion selbst ab, kann also gar nicht allgemein angegeben werden, sondern wird mehr oder weniger in irgendwelchen Tabellen dokumentiert.

AMDoderNvidia

2019-08-08, 13:27:40

Hallo Locuzua (und die anderen), bitte helft mir mal ein bisschen mit den Begriffen. Ich bin zwar Softwareentwickler und kenn mich auch mit hardware-nahen Dingen aus, aber hier wird es doch sehr fachspezifisch. Auch wenn ich bereits OpenGL und auch ein wenig OpenCL Code geschrieben habe, kann ich folgendes nicht ganz in Relation zueinander setzen:

Eine selektive Zusammenfassung:
- Es gibt 20 Waves (WAVE64 oder WAVE32) pro SIMD32, dass würde bedeuten das es 40 Waves pro Compute Unit gibt, wie bisher auch.
GCN kann bis zu 10 Waves pro SIMD16 verwalten (4x10 statt 2x20).
Einfach wie viele Waves (Threads) RDNA verwalten kann, was eine interessante Info bezüglich Latency-Hiding und Compute-Durchsatz ist.

- Eine Wave32 kann jeden Takt abgeschickt werden oder eine Wave64 alle zwei Takte, dass ist bekannt, ebenso das FMA ops nun 5-Takte benötigen und nicht mehr nur 4 wie bei GCN oder Volta/Turing.
Instruction Dependencies werden über die HW gelöst, gab es bei GCN nicht und Nvidia encoded das über die SW bzw. den Driver-Compiler.

- Navi kann Transzendente Funktionen wie Wurzelziehen, Sinus, Cosinus etc. nun gleichzeitig mit anderen Mathematik-Operationen berechnen.
Bei GCN gab es laut dem anderem Slide-Deck pro SIMD16 eine Special Function Unit, welche selber als SIMD4 operiert hat und entweder die eine oder andere SIMD-Unit konnte arbeiten, aber nicht beide gleichzeitig.
Bei Navi können die SIMD32 Units parallel zu den breiteren SFUs (SIMD8) arbeiten, dass blockiert sich nicht mehr gegenseitig und insofern können die Latenzen massiv kürzer ausfallen.

- Tatsächlich hat Navi10 nur zwei Shader-Engines bzw. 2 Shader-Arrays pro Shader-Engine, während bei GCN es noch so war das jede Shader-Engine nur ein Shader-Array hatte.
RDNA kann sowohl im WGP-Mode (Work-Group-Processor) arbeiten, wo zwei CUs praktisch eine Einheit mit shared Ressources darstellen, als auch im CU-Mode, wo jede Compute-Unit einzeln agiert, aber AMD verwendet immer die Darstellung mit WGPs.

Es geht mir um die fettgedruckten Begriffe. Wie muss sich folgende Einheiten vorstellen?

WAVE
SIMD
Shader-Arrays
Shader-Engines
Work-Group-Processor

Die Suffixe 8, 16, 32 und 64 sind wahrscheinlich die Datengenauigkeit bzw. Datentypen, mit denen eine Instruktion arbeiten kann, korrekt?

Danke

Der_Korken

2019-08-08, 13:56:01

SIMD16 bzw. SIMD32 sind die Vektor-ALUs und die Zahl dahinter die Breite der ALUs. Bei GCN hatte eine CU jeweils vier SIMD16-Einheiten, d.h. es können 16 Operandensätze (=Daten) parallel mit der gleichen Instruktion bearbeitet werden. Die Daten wurden als 64er Pakete (d.h. eine Instruktion, aber 64 Daten zum Anwenden) in vier Takten abgearbeitet. RDNA hat stattdessen zwei SIMD32-Einheiten, die aber in jedem Takt ein Paket abarbeiten, allerdings nur 32 Daten statt 64.

Ein Work-Group-Processor ist der Zusammenschluss aus zwei CUs. Bei GCN haben sich nur jeweils mehrere CUs einen Cache geshared, waren sonst aber autark. Bei RDNA sharen zwei CUs deutlich mehr Ressourcen, weswegen man auch sagen kann, dass RDNA nicht 40 CUs, sondern 20 "Doppel-CUs" hat, die AMD jetzt WGP nennt.

Als Shader-Array bezeichnet AMD auf den Folien den Zusammenschluss aus 5 WGPs bzw. 10 CUs. Jedes Shader-Array hat ein (vermutlich, da müssen andere mehr zu sagen) ein Frontend für Geometrie, ROPs und einen L1-Cache.

Zwei Shader-Arrays ergeben bei RDNA eine Shader-Engine. Was die genau macht weiß ich nicht. Bei Vega waren es vier Shader Engines mit nur einem Shader-Array aus 16 CUs.

AMDoderNvidia

2019-08-08, 14:34:09

pixeljetstream

2019-08-08, 16:45:15

https://simonschreibt.de/gat/renderhell-book2/

Dort unter "Shader Execution" ist das ein bisschen animiert.
Warps = Waves. Bei NV 32 breit, bei AMD nun 32 oder 64.
Was in dem Artikel ein core ist, ist hier als ALU bezeichnet worden.
Im Prinzip teilt sich der Wave (Warp, thread Gruppe...) einen Satz Register und vor allem den instruction pointer.
Wenn du Mal mit SSE gearbeitet hast, stell dir vor die Instruktionen sind halt 32 oder 64 breit und du machst mehr oder weniger alles mit solchen Instruktionen.

Gipsel

2019-08-08, 17:24:22

Danke für die Erklärungen, das macht das Bild etwas klarer. Was jetzt noch fehlt sind die Wave(s), Wavefront(s) usw. Kann es sein, dass man damit nun vom statischen Bild (also das simple Blockschaltbild der Komponenten) zum dynamischen Teil kommen, d.h. Waves bilden die aktuelle Ausführung von Shadercode ab?
Wavefronts bzw. oft kurz nur Waves genannt sind das gleiche wie bei nV die Warps. Dies sind traditionell die eigentlichen Threads der zugrunde liegenden Hardware, also wie eigentlich der Shadercode ausgeführt wird. Die Größe dieser ist die (logische) Vektorbreite der Ausführungseinheiten (gezählt in 32bit breiten Lanes). Es entspricht damit so grob der Vektorbreite bei CPUs (AVX-512 ist z.B. für Floats SIMD16, da dort eben mit einem Befehl 16 floats gleichzeitig abgearbeitet werden; bei GPUs ist die Vektorbreite unabhängig vom Datentyp fest). Bei GCN wurden die 64 Elemente (2048bit bei int/float32) breiten Vektoren (Wavefronts) aber physisch auf 512bit breiten Einheiten ausgeführt (konzeptionell ganz grob ähnlich wie AVX256 auf den 128bit breiten Ausführungseinheiten bei Zen1 läuft [nur ohne Vervielfachung der internen Ops]). Auch bei nV waren die logischen Vektorbreiten lange nicht identisch mit der physischen Breite der Ausführungseinheiten (spart etwas Scheduling-Logik und -Aufwand).

Falls Dir der OpenCL-Sprech was sagt: Jeder Hardware-Thread der GPU (Wavefront/Warp) arbeitet auf einer compute unit (CU/WGP, SM) nach dem SIMD-Prinzip mehrere "data elements" einer OpenCL workgroup gleichzeitig ab (nämlich so viele, daß es der logischen Vektorbreite der Einheiten entspricht, was eben gerade durch die Größe der Wavefronts bzw. Warps angegeben wird). Für beste Effizienz wählt man die Größe einer workgroup dabei als Vielfaches der Breite einer Wavefront/eines Warp (aber nicht strikt nötig, Verschnitt wird entsprechend ausmaskiert, was dann aber natürlich die Hardware nicht voll nutzt und Performance kostet).
Über eine OpenCL extension kann man im Prinzip auch an die hersteller- und implementationsspezifischen Wavefronts/Warps kommen (nennt OpenCL "subgroups" (https://www.khronos.org/registry/OpenCL/sdk/2.0/docs/man/xhtml/cl_khr_subgroups.html)). Da OpenCL herstellerunabhängig ist, mappen die Wavefronts/Warps nicht perfekt auf die Workgroups, aber da die Hardware von AMD und nV auch mehrere Warps/Wavefronts kommunizieren lassen und synchronisieren kann, paßt das mit den Workgroups (in DirectCompute nennt sich das übrigens "thread groups") dann auch wieder ganz gut als Abstraktionsebene.
Bei RDNA teilen sich nun zwei CUs den gemeinsamen local memory, weswegen die Wavefronts einer Workgroup auch über diese zwei CUs verteilt werden können (und Syncs gehen eben auch über die 2 CUs). Vorher mußte eine workgroup immer auf einer einzigen CU oder bei nV auf einem SM laufen, da sonst die Kommunikation und das gemeinsame Nutzen von Daten im local memory natürlich nicht geht. Und da AMD seit geraumer Zeit ihren Slang auch an OpenCL orientiert, heißt so eine Gruppe aus zwei CUs nun eben "work group processor" oder kurz WGP.

AMDoderNvidia

2019-08-08, 17:31:00

Danke, pixeljetstream, das werde ich mir heute Abend mal ansehen.

danarcho

2019-08-08, 21:06:13

Gipsel

2019-08-08, 21:08:59

Weiß eigentlich jemand wie jetzt shuffles auf 64 lanes gehen, wenn laut ISA bpermute nur noch auf 32 lanes geht?Genauso wie bisher? Die ISA bleibt doch praktisch gleich und Wave64 wird immer noch unterstützt (Wave32 ist optional).

Edit: Ist meine Vermutung. In die ISA-Doku (https://gpuopen.com/wp-content/uploads/2019/08/RDNA_Shader_ISA_7July2019.pdf) muß ich noch reinschauen. Außerdem erwarte ich, daß da Fehler drin sein werden (zumal in der ersten Iteration, war bisher immer so).

Edit2: Kommando zurück. Steht tatsächlich gleich ganz vorne, daß DS_permute nur noch auf 32 Lanes geht (und DPP-Instruktionen nur noch über 16 Lanes). Und wie man das löst? Na in dem man LDS alloziert und tatsächlich reinschreibt und wieder liest, um Daten zwischen den Lanes auszutauschen.

BoMbY

2019-08-08, 21:18:58

Weiß eigentlich jemand wie jetzt shuffles auf 64 lanes gehen, wenn laut ISA bpermute nur noch auf 32 lanes geht? Mir schwant übles, wenn ich darüber nachdenke (register tauschen, maskieren, etc)...

Da steht doch relativ klar:

Note that in wave64 mode the permute operates only across 32 lanes at a time of each half of a wave64. In other words, it executes as if were two independent wave32’s. Each half-wave canuse indices in the range 0-31 to reference lanes in that same half-wave.

danarcho

2019-08-08, 23:55:37

Außerdem erwarte ich, daß da Fehler drin sein werden (zumal in der ersten Iteration, war bisher immer so).

Edit2: Kommando zurück. Steht tatsächlich gleich ganz vorne, daß DS_permute nur noch auf 32 Lanes geht (und DPP-Instruktionen nur noch über 16 Lanes). Und wie man das löst? Na in dem man LDS alloziert und tatsächlich reinschreibt und wieder liest, um Daten zwischen den Lanes auszutauschen.
Fehler sind leider recht häufig, wir haben auch schon welche gefunden, aber gut.
edit: es gab leider noch nie iterationen oder erratas.

Du kannst nicht in jeder stage einfach lds alloziieren.

Gipsel

2019-08-09, 08:19:59

Fehler sind leider recht häufig, wir haben auch schon welche gefunden, aber gut.
edit: es gab leider noch nie iterationen oder erratas.Ich meinte auch Hardware-Iteration. Also im Vega ISA-Manual sind tendentiell weniger Fehler drin als im GCN1.0 Manual.
Du kannst nicht in jeder stage einfach lds alloziieren.Ich bin ziemlich sicher, daß die Hardware das im Prinzip kann. Und der LDS wird ja manchmal auch implizit verwendet, selbst wenn man selber im high level code gar nichts damit macht (ein Beispiel wäre die Übergabe der Vertexparameter durch die Pipeline [die stehen ja im LDS] und der Interpolation im Pixelshader ). Bei den VLIW-Architekturen wurde der LDS in den Hull- und Domainshader implizit genutzt (warum sollte das jetzt nicht mehr gehen? Einer CU dürfte es ziemlich egal sein, welche Shaderstage gerade offiziell ausgeführt wird, das setzt nur bestimmte Dinge um, wie z.B. bestimmte States für den CP gesetzt und Daten außerhalb der CU geroutet werden). Und in Pixel- und Compute-Shadern ist es ja sowieso vorgesehen.

Also im RDNA-ISA manual findet man zu ausnahmslos jeder Hardware-Shader Stage eine Referenz auf den LDS (Kapitel 3.12, in jeder Stage wird entweder etwas im LDS initialisiert oder ein SGPR kann mit der lds_base befüllt werden [wozu dann SPI_SHADER_PGM_RSRC2_[B]GS.oc_lds_en gesetzt sein muß; das fett Kursive gibt's für die Shaderstages, bei denen nicht sowieso per Default was geladen wird]). Wozu sollte das denn dienen, wenn die Hardware dann nicht auf den LDS zugreifen könnte? Sagt natürlich nichts über die Kopfstände aus, die man eventuell machen müßte, um das wirklich zu nutzen.

Für was willst Du das denn eigentlich verwenden? Bisher hat AMD ds_permute auch nicht unbedingt empfohlen, weil die DPP-Geschichten aus Performancegründen vorzuziehen waren. Workarounds könnten also gar nicht so viel langsamer sein. Und hast Du Dir schon mal die "wave shared vgprs" angesehen? Die sind neu.
3.6.5. Wave Shared VGPRs

Wave64’s can be allocated wave-private and wave-shared VGPRs. Private GPRs are the normal ones where each lane has a unique value. Shared VGPRS are shared between the high and low halves of a wave64. This can be useful to reduce overall VGPR usage when combined with subvector execution. Shared VGPRs are allocated in blocks of 8 Dwords. Shared VGPRs logically occupy the VGPR addresses immediately following the private VGPRs. E.g. if a wave has 8 private VGPRs, they are V0-V7 and shared VGPRs start at V8. If there are 16 shared VGPRs, they are accessed as V8-23. Shared VGPRs cannot be used for: Exports or GDS.
Auf diese geteilten Register können beide Hälften einer Wave64 zugreifen, also darüber auch Daten austauschen (ist ja fast ein Callback zu den alten VLIWs, wo man sowas auch machen konnte [zwischen den zwei Waves, die alternierend auf einer CU/SIMD liefen]).

danarcho

2019-08-09, 11:28:32

Ich meinte auch Hardware-Iteration. Also im Vega ISA-Manual sind tendentiell weniger Fehler drin als im GCN1.0 Manual.
Hm ok. Die Vega ISA hat weniger Fehler als Polaris, aber Polaris mehr als CI... Bei RDNA sind jetzt wieder die VOP3 offsets falsch. Ich glaube, die benutzen einfach zu viel copy-paste :P
Ich bin ziemlich sicher, daß die Hardware das im Prinzip kann. Und der LDS wird ja manchmal auch implizit verwendet, selbst wenn man selber im high level code gar nichts damit macht (ein Beispiel wäre die Übergabe der Vertexparameter durch die Pipeline [die stehen ja im LDS] und der Interpolation im Pixelshader [bzw. einem automatisch eingefügtem "Prolog" vor dem Pixelshader]).
Ich muss mir das nochmal genau anschauen. Wäre natürlich klasse, wenn man zusätzlich ein paar LDS bytes reservieren könnte (z.B. auch zum spillen, und SI/CI haben kein DPP und bpermute), aber zumindest aktuell setzt radv S_00B84C_LDS_SIZE ausschließlich für CS.

Für was willst Du das denn eigentlich verwenden? Bisher hat AMD ds_permute auch nicht unbedingt empfohlen, weil die DPP-Geschichten aus Performancegründen vorzuziehen waren. Workarounds könnten also gar nicht so viel langsamer sein. Und hast Du Dir schon mal die "wave shared vgprs" angesehen? Die sind neu.

Auf diese geteilten Register können beide Hälften einer Wave64 zugreifen, also darüber auch Daten austauschen (ist ja fast ein Callback zu den alten VLIWs, wo man sowas auch machen konnte [zwischen den zwei Waves, die alternierend auf einer CU/SIMD liefen]).
Hab doch geschrieben für shuffle und dafür funktioniert DPP nicht. Ich glaube, was du meinst ist ds_swizzle, was nicht mehr empfohlen wird. Die shared VGPRs muss ich mir ansehen, vielleicht ist das jetzt the way to go. Danke.

AMDoderNvidia

2019-08-09, 13:22:53

Gibts eigentlich ein Online-Tool, um aus Shader-Code direkt die Instructions für einen (beliebigen) Grafikchip zu sehen, so ähnlich wie GodBold - Compiler Explorer (https://godbolt.org/)?

Gipsel

2019-08-09, 13:26:06

Achill

2019-08-09, 14:44:28

Gipsel

2019-08-09, 15:23:38

Auch auf die Gefahr hin, dass ich schon abgehängt wurde und irgendwas nicht verstanden habe ...

Danarcho arbeitet doch aktiv am ACO (https://www.forum-3dcenter.org/vbulletin/showthread.php?t=595575) mit, der Compiler wird doch damit Binäre-Code entsprechend AMD's ISA erzeugen. Damit ist die mögliche Einschränkung der API beim Frontend der Shader-Typen erstmal nicht direkt ausschlaggebend oder?Das weiß ich nicht. Aber für mich sieht es danach aus, daß die Hardware im Prinzip immer auf den LDS zugreifen könnte (bzw. das in verschiedenen Situationen auch implizit tut, ohne daß der HLSL Code eines Shaders explizit danach verlangt), und die Nichtnutzbarkeit in bestimmten Situationen eher an den APIs liegt. Wenn man den Binärcode dann selber erzeugt (oder sich das irgendwie hinpatched), müßte es tatsächlich möglich sein, das zu umgehen (und wenn man im Zweifelsfall irgendwelche Fake-Parameter erzeugt, die standardmäßig im LDS landen und dann den dadurch belegten Platz nutzt). Wieviel Aufwand das im Einzelnen wird, bin ich aber überfragt (und wir wissen ja auch noch nicht, um welche Shaderstage es geht). Da wird es dann vielleicht irgendwann doch einfacher, die permutes in einer kompletten Wave64 über die shared vGPRs zu realisieren.

danarcho

2019-08-09, 15:27:11

@danarcho:
Also in radv_shader.c (https://gitlab.freedesktop.org/mesa/mesa/blob/ee21bd7440c3222cc01a630c4ef49d33bf431807/src/amd/vulkan/radv_shader.c) sehe ich, daß die lds_size auch für ein paar mehr Dinge gesetzt wird als nur Compute_shader (wenn ich mich nicht versehen habe, dann auch Pixel und Geometry Shader und zumindest bei GFX10 auch Vertex Shader). Aber vielleicht muß man mal die Konsolenleute fragen, was die so machen können, wenn es etwas weniger Beschränkungen durch die API gibt? Hilft Dir dann aber auch nicht unbedingt weiter, außer die Neugier zu befriedigen.
Hast recht, auch Gfx10 NGG.. der Rest sind input daten.
Theoretisch sollten wir doch in der Lage sein alles zu nutzen, was die Hardware hergibt :)
Muss mal rumfragen, ob wir einfach LDS_SIZE für andere stages manipulieren dürften (dann natürlich vorher schauen, was belegt ist, und wie viel Platz bleibt).

Auch auf die Gefahr hin, dass ich schon abgehängt wurde und irgendwas nicht verstanden habe ...

Danarcho arbeitet doch aktiv am ACO (https://www.forum-3dcenter.org/vbulletin/showthread.php?t=595575) mit, der Compiler wird doch damit Binäre-Code entsprechend AMD's ISA erzeugen. Damit ist die mögliche Einschränkung der API beim Frontend der Shader-Typen erstmal nicht direkt ausschlaggebend oder?
Weiß er doch :)
Naja, klar können wir einfach auf dem LDS rumschreiben, bzw. code erzeugen, der das tut. Ob das sinnvoll ist, wenn dort vielleicht andere, wichtige Daten liegen, ist aber eine andere Frage. Das backend liefert halt nur ein binary blob zurück und ein paar config infos (zB wie viele register benötigt werden oder auch wie viel LDS). Das mit dem LDS ist aber zur Zeit nur für CS, daher die Diskussion.

Leonidas

2019-08-10, 10:43:45

Sunrise

2019-08-10, 11:27:18

Gerüchteküche:
Angeblich gibt es neben "Navi 21" noch "Navi 23", letzter soll AMD-intern als "nVidia Killer" firmieren. Technische Daten zu beiden Chips gibt es nicht, Architektur könnte RDNA-Refresh oder RDNA2 sein, RayTracing ist nicht bestätigt, Terminlage soll beiderseits Mitte 2020 sein:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-89-august-2019

Insgesamt ein eher durchschnittliches Gerücht, welches eigentlich nur einen neuen Codenamen in die Runde wirft, damit aber für mehr Verwirrung als Aufklärung sorgt. Die Quelle ist nicht gerade weltbewegend (auch wenn jene dies für sich in Anspruch nimmt), ergo wartet dies IMO erst einmal auf eine Bestätigung aus anderer Quelle, ehe man es ernst nehmen könnte.
Der NV-Killer wäre aktuell noch durchaus mit dickem Navi möglich, Mitte 2020 ist NV aber wieder am Zug und das wird - gefühlstechnisch - eher nicht so lustig für AMD, da dann Prozess-Parität herrscht und NV natürlich ebenso an der Architektur gebastelt hat.

Kommt es mir eigentlich nur so vor oder ist Turing hoffnungslos outdated? Ja, schnellste GPU usw., aber so richtig langweilig...NV ist auch extrem still geworden. Ich erwarte sowas wie Pascal relativ zu Maxwell, aber zusätzlich mit deutlichen Architekturverbesserungen. Allerdings bin ich natürlich auch gespannt auf RDNA2.

Complicated

2019-08-10, 15:44:57

Xbox Next: Gerücht: PlayStation 5 mit RDNA Monolith, Xbox Scarlett mit RDNA2 Chiplets (https://www.xboxdynasty.de/news/xbox-next/geruecht-playstation-5-mit-rdna-monolith-xbox-scarlett-mit-rdna2-chiplets/)
Die GPU von Sony soll dabei 7nm betragen, während Microsoft 7nm+ einsetzt. Beim RDNA-Verfahren scheint Sony bei der PlayStation 5 auf ein RDNA Monolith Verfahren zu setzen, während Microsoft auf die RDNA2 Chiplets Technik setzt. RDNA2 oder RDNA+ ist eine Weiterentwicklung von RDNA, welche Hardware-RayTracing erlaubt.

Laut AMD ist RDNA die Architektur, auf der die 7nm Gaming GPU von AMD basiert und die 1,25-fache Leistung pro Takt im Vergleich zu früheren 14nm-Prozessoren bringt. Die mit GDDR6-Speicher und PCI Express 4.0-Unterstützung ausgestattete RDNA-Architektur ist für die neue Generation von Spielen bereit. Während Sony eine weiterentwickelte Form dieses Verfahrens einsetzen soll, gibt es Gerüchte, dass bei Microsoft das 7nm+ Verfahren mit RDNA2 zum Einsatz kommen wird.

Wenn man das Gerücht zur Xbox und RDNA2 mit rein nimmt könnte das einfach GPU Chiplets bedeuten -> Nvidia-Killer. Ein I/O-Die mit HBM (Oder auch GDDR6) und Memorycontroller könnte als Navi23 zwei Chiplets von Navi21 beinhalten. 7nm+ mit EUV und ein GPU-Die ohne Speicherinterface sondern nur mit IF-Interface. Die 8-Core Ryzens sind ja auch nur 2 Chips mit dem I/O und sicherlich ist es sinnvoll einige Monate mit dieser Kombination das Packaging und die Performance einzuschätzen bevor man einen zweiten Die drauf packt.

Kommt Ende 2020 eine Xbox mit RDNA2 und Chiplet, dann könnte das auch die erste APU mit Chiplets sein von AMD. Und zum gleichen Zeitpunkt sind auch die eigenen Zen2 APUs dran. Man könnte die ganze RDNA1 GPU-Generation überspringen für APUs und gleichziehen mit den dann aktuellen dGPUs und Konsolen bei der GPU Architektur.

Die Tests sind vielleicht so erfolgreich, dass Mitte 2020 die ersten diskreten GPUs mit Chiplets kommen.

Zunächst mal kann ich mir gut vorstellen, dass Microsoft nicht mehr den selben Fehler machen will wie letzte Generation, als die PS4 auf die neuere Technologie gesetzt hat und damit den Markt für diese Generation für sich entschieden hat. Für Matisse hatte ja AMD GPU-Chiplets ausgeschlossen, doch Vermeer ist Mitte 2020 da und mit 7nm+ (EUV) wäre die diskrete GPU das bessere Testfeld bevor Konsolen und APUs dann beides kombinieren.

Es wäre der konsequente nächste Schritt. Auch mit dem Hintergrund, dass Ende 2020 Intel wieder aus den Pushen kommen wird und vor allem die neuen GPUs angekündigt wurden, die erneut versuchen AMD und Nvidia einzuholen. Hier einen Sprung zu machen wenn alle wieder die selbe Fertigung nutzen werden ist vielleicht schon zwingend um die beiden anderen technologisch unter Druck zu setzen.

Auch nicht zu vergessen ist der Vorsprung, um wie viel früher Chiplets wirtschaftliche Yields abwerfen gegenüber monolithischen Chips - da könnte es schwer werden für Nvidia, wenn Sie dann 3-6 Monate später erst mit ähnlicher Performance aufwarten können wegen der Größe des Chips. Das heisst die Reaktion darauf muss etwas kleinere Chips sein, was dann aber AMD die Möglichkeit gibt näher ran zu kommen mit der Performance. Also ist Nvidia zu Samsung gegangen und hat deren Vorsprung bei 7nm EUV zur Kompensation des Chiplet-Vorteils genutzt, so dass Sie im Frühjahr mit Am104 und Mitte 2020 mit Am102 mit wirtschaftlichen Produkten gegen AMDs RDNA2(Chiplets) antreten können. Bei TSMC läuft derweilen die restliche Produktpalette basierend auf AM106, AM107 und AM108. Nvidia muss auch deutlich mehr Stückzahlen in EUV abliefern als AMD um den Marktanteil zu halten.

BoMbY

2019-08-10, 17:40:00

Wenn Microsoft schlau wäre würden die PC und Konsole viel näher zusammen bringen, über ein wirklich gemeinsames System. Also die Konsolen-Oberfläche als Alternative zum Windows-Desktop in Windows 10 einbauen, und auf beiden Systemen ermöglichen entsprechend umzuschalten, dann können die auch ihren Konsolen- und PC-Shop verbinden. Das spart nicht nur Aufwand, sondern würde auch den Kunden viel mehr Möglichkeiten geben, und eventuell Leute animieren das jeweils andere System zu kaufen.

aufkrawall

2019-08-10, 17:49:01

Nur gehen die Pläne mit zukünftigen MS-Spielen auf u.a. Steam in genau die entgegengesetzte Richtung, weil offenbar irgendjemand im Management realisiert hat, dass der shared ModernUI/UWP-Kram Müll ist und wahrscheinlich auch immer bleiben wird.

Grendizer

2019-08-10, 17:53:55

Hatte die PS4 nicht eigentlich die "ältere" Entwicklungsstufe , aber mit deutlich mehr SP, ROPs und TMUs und vor allem DDR5 statt DDR3 Ram als die XBOX?

reaperrr

2019-08-10, 17:55:35

Bei TSMC läuft derweilen die restliche Produktpalette basierend auf AM106, AM107 und AM108.
Wenn die Gerüchte stimmen, dass Samsung deutlich (30-40%) niedrigere Wafer-Preise verlangt, wäre es Quatsch ausgerechnet die kleinen, Margen-sensitiven Mainstream-Chips bei TSMC zu fertigen.

mironicus

2019-08-10, 18:27:53

dargo

2019-08-10, 18:41:02

Erstmal abwarten ob und vor allem wie das ganze in der Praxis funktioniert bevor hier wieder irgendein Hypertrain losgetreten wird. Ich glaubs erst wenn ich es sehe.

AffenJack

2019-08-10, 18:41:47

Heißt das jetzt, das AMD mehrere GPU-Chiplets auf einer IF zusammenschalten kann wie bei den Zen2 CPU-Chiplets und dann einfach beliebig erweitern (1,2,3,4...8 GPUs)? Dann kann NVidia mit einem monolithischen Design wahrscheinlich bald nicht mehr konkurrieren.

Ja macht AMD doch schon seit 10 Jahren, wenn man den Gerüchten glauben darf. ;D

Chiplet heißt noch gar nix, bisher hat niemand gezeigt, dass 2 GPU Chiplets für Gaming ordentlich wie einer funktionieren und sich lohnen. HPC ist ein anderes Gebiet, da deutlich besser einzusetzen und nicht mal da haben wir schon sowas schon.
Deutlich wahrscheinlicher wäre 1 CPU Chiplet und 1 GPU Chiplet, die über einen IO Die miteinander reden.

Ghost1nTh3GPU

2019-08-10, 18:44:09

Nvidia hat doch auch divers angedeutet, dass es in Richtung MCM gehen wird.

sulak

2019-08-10, 19:10:39

Habt ihr den Artikel und die "Quelle" mal gelesen ;D

Das ist typisches Random Bullshit Bingo ohne irgend einen Hintergrund, kein bekannter Leaker, typischer BlaPost, wie es seit einem Jahr schon etliche Male aufgetaucht ist. Glaube im NeoGaf Forum gibt es sogar ein Sammelthread, 8 verschiedene "Specs" :freak:

Allein zur E3, als Microsoft was von 8x so schnell quasselte, und das eine Welle an 24TF Gerüchten verursachte, es am Ende aber "nur" die CPU Power war... Hirn...

Fakt ist nur eines, das Microsoft nicht 2 sondern nur eine Konsole weiter verfolgt.

Beide Hersteller-Konsolen werden auf Navi basieren mit einer ZEN2 CPU in 7nm.
Da beide zur Holiday Season 2020 erscheinen werden, sind die Chips Stand heute nicht Final. Tapeout im Dezember vielleicht oder Frühjahr?

Secret Sauce werden beide haben, die Anbindung der GPU an die CPU wird interessant in Kombination mit der SSD. Schätze mal ab Februar 2020 kommen die Einschläge näher und die Spekulatius somit auch dem End-Resultat.

Den Endpreis nicht vergessen, 399-499€ und 16GB GDDR6 sollte das mindeste sein.

Leonidas

2019-08-11, 05:32:59

Tapeout im Dezember vielleicht oder Frühjahr?

Viel zu spät. Ein Konsolen-SoC ist ein singulärer Chip ohne vorherige Erfahrungswerte. Sprich eher lange Evaluierungsphase, sprich 1 Jahr. Dazu kommt noch die Vorproduktion, damit man am Launchday auch mal 2 Mio. fertige Konsolen rumliegen hat. Ergo eher 1¼ Jahre zwischen Tape-Out und Launch. Sprich, Tape-Out sollte jetzt herum stattfinden.

PS: Aber vielen Dank für die Einschätzung der vorherigen Hardware-Gerüchte.

HOT

2019-08-11, 09:05:16

Wenn die Gerüchte stimmen, dass Samsung deutlich (30-40%) niedrigere Wafer-Preise verlangt, wäre es Quatsch ausgerechnet die kleinen, Margen-sensitiven Mainstream-Chips bei TSMC zu fertigen.
Das spiegelt eh nicht die realen Kosten wieder. NV kann duchaus in 7nm Pro und später in 6nm den Mainstreamkram fertigen.

Bezüglich der Gerüchte:

Da würd ich mal darauf tippen, dass da jemand was falsch verstanden hat, wie so oft.
Navi 14 und 12 dürften eher die kleinen neuen GPUs sein und die großen neuen dann Navi 21 (High-End) und Navi 23 (Enthusiast). RT-fähig wird das ganze Lineup sein, aber nur die großen beiden werden extra Hardware mitbringen.

JVC

2019-08-11, 09:56:33

https://www.xboxdynasty.de/news/xbox-next/geruecht-scarlett-und-dante-dev-kit-spezifikationen-aufgedeckt/ (08.08.2019)
"GPU: Custom Navi 21, Full 56 Compute Units @ 1623MHz"

"Navi 21" muss demnach HDMI 2.1 unterstützen :up:

M.f.G. JVC

Screemer

2019-08-11, 10:00:44

Viel interessanter finde ich havok und directml onchip. Sag bloß wir bekommen mehr Physik?

JVC

2019-08-11, 10:03:21

@Screemer. Auf jeden fall scheint die CPU mehr zu tun zu bekommen ^^
(CPU mit integriertem DXR ...)

"Flexible Dedizatet vRam starts with 32GB (up-to 64GB)(up-to 84GB for Game)"
8K Texturen incoming? (20GB nur für die GPU?)

M.f.G. JVC

Complicated

2019-08-11, 12:45:46

Wenn die Gerüchte stimmen, dass Samsung deutlich (30-40%) niedrigere Wafer-Preise verlangt, wäre es Quatsch ausgerechnet die kleinen, Margen-sensitiven Mainstream-Chips bei TSMC zu fertigen.Nur ist Samsung auch 3-6 Monate früher dran. Nvidia nützt ein Midrange-Launch nicht so wie er AMD nützt Marktanteile zu gewinnen. Die kleineren Chips sind ja später eingeplant, also hat man da noch Zeit die Kosten zu reduzieren, was wie du selber sagst in diesem Segment wichtig ist. Nvidia muss um die hohen Margen halten zu können den schnellsten Chip am Markt bieten können, und zwar zu jeder Zeit. Das darf dann auch teurer und somit früher bei schlechteren Yields in den Markt, solange die Margen stimmen.

reaperrr

2019-08-11, 20:23:41

Nur ist Samsung auch 3-6 Monate früher dran. Nvidia nützt ein Midrange-Launch nicht so wie er AMD nützt Marktanteile zu gewinnen. Die kleineren Chips sind ja später eingeplant, also hat man da noch Zeit die Kosten zu reduzieren, was wie du selber sagst in diesem Segment wichtig ist. Nvidia muss um die hohen Margen halten zu können den schnellsten Chip am Markt bieten können, und zwar zu jeder Zeit. Das darf dann auch teurer und somit früher bei schlechteren Yields in den Markt, solange die Margen stimmen.
Nochmal: Warum sollte NV ausgerechnet die Mainstream-Chips bei TSMC fertigen lassen, wenn Samsungs 7nm EUV früher fertig und billiger ist?

Um das "Dickschiff" geht es mir nicht. Das kann ja durchaus trotzdem von Samsung kommen. Wobei ich skeptisch bin, ob NV nur wegen ein paar Monaten einen ungeeigneteren Prozess nehmen würde.

Ich halte einfach die Prognose von "Performance: Samsung, Mainstream: TSMC" für unlogisch, entweder es kommt wie bei Pascal anders herum, oder die Gen kommt komplett oder zumindest größtenteils von Samsung (was ich für unwahrscheinlicher halte, aber man weiß ja nie).

BoMbY

2019-08-12, 11:11:13

HOT

2019-08-12, 11:31:13

fast 400mm², wow die wollens aber wissen :O

davidzo

2019-08-12, 19:21:00

Wovon redet ihr eigentlich TSMC 7nm+ ist seit Mai, oder so, im Volume Ramp. Samsung vielleicht jetzt gerade. Und ich kann mir kaum vorstellen dass die beim Preis inkl. Yield schon deutlich besser sind.

Samsung hat 7nm LPP schon seit Oktober 2018 in Produktion. Wo sonst sollte so plötzlich der Exynos 9825 herkommen?

Ich denke mal das es vom Zeitrahmen einfach so am besten für nvidia gepasst hat. Jeder Prozess wird irgendwie im Laufe der Zeit an den Chip angepasst der damit gefertigt werden soll. Insofern glaube ich kaum dass NV da vorweg irgendwelchen Gerüchte um den vermeintlich "besseren" Prozess glauben schenkt. Wenn Nvidia bestimmte Performance-Ziele hat, dann wird das mit Verträgen festgeschrieben und die Samsung Prozess-Ingenieure schieben halt Überstunden bis sie die Ziele erreicht haben.

Vielleicht hatte TSMC für den Zeitraum den Nvidia anvisiert hatte einfach gerade nicht die Kapazitäten. Entweder weil andere Kunden die Scanner-Kapazitäten früher reserviert hatten(AMD, Apple, Huawei) bzw., noch für 7nm DUV genutzt werden. Oder man hätte mit dem Prozess Fine-tuning erst später beginnen können weil die Ingenieure noch mit anderen Produktstarts zutun haben.
Sowas ist alles schon Jahre im vorraus organisiert.
Und wenn AMD frühzeitig entschieden hat seine Prozessoren, GPUs und Konsolenchips bei TSMC in 7nm DUV zu machen, dann ist es nur logisch dass TSMC erstmal kaum Kapazitäten hat für schnelle Umrüstung auf 7nm EUV in den Kapazitäten die NV benötigt. Dass TSMC dann einen hohen preis aufruft ist verständlich, da verhältnismäßig kurzfristige Kapazitätserweiterungen mit neuen Scannern, Reinräumen, Personal, extrem teuer sind. Das muss aber nicht unbedingt heißen dass auch AMD den höheren Preis bezahlt, vielleicht waren sie auch nur früher dran. Navi passt da von den Stückzahlen vielleicht gerade noch bei TSMC rein, aber man muss bedenken dass Nvidia bei den aktuellen Marktanteilen auch locker 2x bis 3x mehr Chips pro Modell benötigt.

BoMbY

2019-08-13, 11:34:06

dann ist es nur logisch dass TSMC erstmal kaum Kapazitäten hat für schnelle Umrüstung auf 7nm EUV in den Kapazitäten die NV benötigt.

TSCM hat scheinbar 18 neue EUV-Scanner alleine für dieses Jahr geordert, die Gesamtproduktion bei ASML soll wohl etwa 30 Stück in 2019 sein:

https://hexus.net/tech/news/industry/127382-tsmc-begin-7nm-euv-mass-production-march/

Sunrise

2019-08-13, 21:06:38

Da fällt einem doch direkt auf, wie stark die Semis an ASML hängen...eigentlich fast beängstigend.

Ich will auch nicht wissen, was Apple da an Kapazität nachgefragt hat, man darf nicht vergessen dass EUV in der Massenproduktion ein Wunder ist, und der Output ist immernoch begrenzt, trotz dessen dass nur wenige Layer mit EUV gefertigt werden.

Während AMD ja schon Jahre zuvor aggressiv 7nm "and beyond" eingeplant hatte, und Apple quasi vorgibt, wo die TSMC-Prioritäten liegen, will NV wohl mehr Unabhängigkeit und Samsung benötigt Kunden. Das passt eben zusammen, vor allem wenn NV dann auch noch bessere Preise bekommt. Jetzt ist nur die Frage ob Theorie und Praxis an einem Punkt zueinander finden, der in der Realität mindestens da ist, wo ihn NV sich vorstellt.

JVC

2019-08-13, 23:21:41

Während AMD ja schon Jahre zuvor aggressiv 7nm "and beyond" eingeplant hatte, und Apple quasi vorgibt, wo die TSMC-Prioritäten liegen,
will NV wohl mehr Unabhängigkeit und Samsung benötigt Kunden....

Ja, das passt zusammen ... :)

M.f.G. JVC

Zossel

2019-08-14, 06:28:17

TSCM hat scheinbar 18 neue EUV-Scanner alleine für dieses Jahr geordert, die Gesamtproduktion bei ASML soll wohl etwa 30 Stück in 2019 sein:

https://hexus.net/tech/news/industry/127382-tsmc-begin-7nm-euv-mass-production-march/

Und die restlichen 12 gehen an Intel und Samsung, dann wird sich ja Volume-EUV bei Intel noch hinziehen .......
Und die Flash und DRAM Hersteller werden sicherlich auch irgendwann mit EUV anfangen wollen ....

Weiß Donald eigentlich schon das da gerade "Make Asia great again" läuft, oder will der wirklich weiter Dampfmaschinen bauen?

https://www.servethehome.com/wp-content/uploads/2018/05/AMD-This-is-EPYC-Xeon-Was-Great-So-Was-Coal.jpg

TheAntitheist

2019-08-14, 07:35:16

Weiß Donald eigentlich schon das da gerade "Make Asia great again" läuft, oder will der wirklich weiter Dampfmaschinen bauen?
[/URL]
ASML ist doch ein Niederländisches Unternehmen... in Asien geht es alles andere als Berg auf :rolleyes: Wirtschaftlich wie auch politisch.

Piefkee

2019-08-14, 07:58:21

Nochmal: Warum sollte NV ausgerechnet die Mainstream-Chips bei TSMC fertigen lassen, wenn Samsungs 7nm EUV früher fertig und billiger ist?

Um das "Dickschiff" geht es mir nicht. Das kann ja durchaus trotzdem von Samsung kommen. Wobei ich skeptisch bin, ob NV nur wegen ein paar Monaten einen ungeeigneteren Prozess nehmen würde.

Ich halte einfach die Prognose von "Performance: Samsung, Mainstream: TSMC" für unlogisch, entweder es kommt wie bei Pascal anders herum, oder die Gen kommt komplett oder zumindest größtenteils von Samsung (was ich für unwahrscheinlicher halte, aber man weiß ja nie).

Samsung 7nm EUV ist ziemlich identisch zu TSMC 7 DUV. Und auch zeitlich ziemlich gleich was Volumeramping angeht.

TSMC 7nm+ (EUV) ist seit April 19 in Volume production. Ist aber nicht mehr oder wenig dasselbe als 7nm DUV (10% Die Size, 10% speed)

https://fuse.wikichip.org/news/2567/tsmc-talks-7nm-5nm-yield-and-next-gen-5g-and-hpc-packaging/

(zu 5nm TSMC) Ramping early next year, by our estimate TSMC will be a ‘full node’ ahead of both Intel and Samsung.

davidzo

2019-08-14, 09:43:23

TSCM hat scheinbar 18 neue EUV-Scanner alleine für dieses Jahr geordert, die Gesamtproduktion bei ASML soll wohl etwa 30 Stück in 2019 sein:

https://hexus.net/tech/news/industry/127382-tsmc-begin-7nm-euv-mass-production-march/

Eben, dieses Jahr erst. Was meinst du wann die aufgebaut und einsatzfähig sind? Das passt nicht mehr in den NV Zeitplan für einen Ampere Release in 2020. Hinweise auf Samples zu GA104 gibt es seit Juli 2018 und auch die anderen Chips der Ampere Generation dürften ihren Tapeout schon lange hinter sich haben.

Samsung 7nm EUV ist ziemlich identisch zu TSMC 7 DUV. Und auch zeitlich ziemlich gleich was Volumeramping angeht.

Wie kommst du darauf? Samsung hatte das Tapeout von GA104 (siehe EEC Tests) und den exynos 9825 bereits im ersten Halbjahr 2018. Und das sind keine kleinen Testchips, das sind Chipgrößen die man erst machen kann wenn der Prozess Reif ist. TSMC hat zu der Zeit noch an Testwafern mit SRAM herumgebastelt und liegt beim Volume Ramp gute 6 Monate hinten.

EDIT: achja du bezogst dich auf TSMC7nm DUV, nicht EUV, überlesen. Nee, vom tooling her und den Mask Costs sollte es erhebliche Unterschiede zwischen DUV und EUV geben. Ich rechne damit dass die Kosten pro Maske viel niedriger ausfallen werden und viele Prozesschritte entfallen können.

Zitat:
(zu 5nm TSMC) Ramping early next year, by our estimate TSMC will be a ‘full node’ ahead of both Intel and Samsung.
Ja, das ist sehr wahrscheinlich. Denn 7nm EUV wird für TSMC kaum ein major node, als viel mehr eine Iteration von 7nm DUV mit ein paar EUV layern, um die Masken gegenüber 7nm DUV zu vereinfachen und Erfahrungen mit der EUV Toolchain zu sammeln. Stattdessen ist 5nm EUV bei TSMC das nächste große Entwicklungsziel und diesmal hat man mit der Entwicklung früher angefangen als Samsung.

Complicated

2019-08-14, 09:46:06

Etwas merkwürdig EUV und DUV als das selbe zu bezeichnen. Inwiefern sind die das selbe?

w0mbat

2019-08-14, 09:54:50

Sie meinen die Prozesse unterscheiden sich nicht groß, die paar EUV Masken bringen keinen so enormen Flächen- oder Effizeinz-Vorteil gegenüber dem reinen 7nm DUV Prozess.

Piefkee

2019-08-14, 10:45:18

Etwas merkwürdig EUV und DUV als das selbe zu bezeichnen. Inwiefern sind die das selbe?

Ich bezog mich auf die Design-Werte (Dichte, Leistung etc). Schon klar das man mit EUV sich einige Prozessschritte einsparen kann. Samsung wird 7nm+ billiger als TSMC 7nm DUV anbieten, jedoch ist Samsung was Yield angeht deutlich TSMC unterlegen. TSMC behauptet 7nm DUV hat den selben Yield wie 16nm :eek:

Gipsel

2019-08-14, 11:02:40

TSMC behauptet 7nm DUV hat den selben Yield wie 16nm :eek:Pro Fläche oder pro Transistor?

Piefkee

2019-08-14, 12:05:12

Pro Fläche oder pro Transistor?

https://fuse.wikichip.org/news/2567/tsmc-talks-7nm-5nm-yield-and-next-gen-5g-and-hpc-packaging/

A key highlight of their N7 process is their defect density. TSMC says that learning from their N10 node, N7 D0 reduction ramp was the fastest ever, leveling off to comparable levels as the prior nodes.

TSMC’s N7+ is their first process technology to adopt EUV for a few critical layers. N7+ entered mass production last quarter (Q2). TSMC says they have demonstrated similar yield to N7.

https://fuse.wikichip.org/wp-content/uploads/2019/07/vlsi-2019-tsmc-n7-yield-2.jpg

Complicated

2019-08-14, 13:19:56

Samsung wird 7nm+ billiger als TSMC 7nm DUV anbieten, jedoch ist Samsung was Yield angeht deutlich TSMC unterlegen.
Auch TSMC wird 7nm+ deutlich billiger anbieten als 7nm DUV. Deshalb ist ja der Prozess alles andere als das selbe. Die EUV Layer werden in dieser Generation fast nur zur Kostenersparnis eingesetzt und ersetzen die DUV Layer. Wo sollen da grosse Sprünge her kommen?

Samsung hat einen Zeitvorteil bei den zusätzlichen EUV-Layern...mehr nicht. Das ist aber aus strategischen Gründen so, da Samsung keinen externen Kunden für DUV hatte, so wie TSMC.

In deinem Zitat ist übrigens nichts von 16nm und selber Yield enthalten.

Gipsel

2019-08-14, 13:32:03

https://fuse.wikichip.org/news/2567/tsmc-talks-7nm-5nm-yield-and-next-gen-5g-and-hpc-packaging/

https://fuse.wikichip.org/wp-content/uploads/2019/07/vlsi-2019-tsmc-n7-yield-2.jpgNun, die Hersteller lassen sich hier wie sonst auch selten in die Karten schauen und rücken kein konkreten Zahlen raus. Solche Plots sind häufig auf irgendwas normalisiert (wobei nicht gesagt wird auf was genau) und erlauben breiten Spielraum (zumal da keinerlei vertikale Achse dran ist). Und warum haben eigentlich größere Dies (laut Text hat TSMC die Grenze bei 250mm² gezogen) deutlich niedrigere Defektdichten als kleinere Dies? Was rechnen die denn da noch Alles rein? Wir wissen es nicht. Und wir wissen ebenfalls nicht, wie das bei den anderen Prozessen mit einer ähnlichen Unterteilung aussehen würde.

AffenJack

2019-08-14, 14:06:11

Ich bezog mich auf die Design-Werte (Dichte, Leistung etc). Schon klar das man mit EUV sich einige Prozessschritte einsparen kann. Samsung wird 7nm+ billiger als TSMC 7nm DUV anbieten, jedoch ist Samsung was Yield angeht deutlich TSMC unterlegen. TSMC behauptet 7nm DUV hat den selben Yield wie 16nm :eek:

Wir haben viel zu wenig Ahnung von den richtigen Design-Werten, um irgendwie zu solchen Schlußfolgerungen zu kommen. Sogut wie alle öffentlichen Daten beschreiben auch High-Density Zellen, die in Mobileprodukten verwendet werden. Wie man an Vega20 und Navi sieht, sieht es bei High-Performance Zellen bei TSMC schon ganz anders aus. Ich kanns gerade nicht mehr finden, aber irgendwo bei Wikichip gabs nen Bild das gezeigt hatte, dass bei Samsung 7nm EUV kein so großer Unterschied zwischen den Zellen sein soll, wie bei TSMC 7nm DUV. Wenn das stimmt, wäre anzunehmen, dass dies aufgrund von EUV der Fall ist.

Dementsprechend könnte es aber genauso sein, dass TSMC 7nm EUV für HPC Produkte wie GPUs einen deutlich größeren Sprung, als der Mobileprozess hinlegt.

HOT

2019-08-14, 14:35:31

Das macht man ja nicht ohne Grund so. Die Grafik zeigt ja einen Yield, der dem von 16nm entspricht. Das ist noch mal deutlich besser als der mobile-Yield.

basix

2019-08-14, 15:06:50

Nun, die Hersteller lassen sich hier wie sonst auch selten in die Karten schauen und rücken kein konkreten Zahlen raus. Solche Plots sind häufig auf irgendwas normalisiert (wobei nicht gesagt wird auf was genau) und erlauben breiten Spielraum (zumal da keinerlei vertikale Achse dran ist). Und warum haben eigentlich größere Dies (laut Text hat TSMC die Grenze bei 250mm² gezogen) deutlich niedrigere Defektdichten als kleinere Dies? Was rechnen die denn da noch Alles rein? Wir wissen es nicht. Und wir wissen ebenfalls nicht, wie das bei den anderen Prozessen mit einer ähnlichen Unterteilung aussehen würde.

Wissen tun wir das nicht, aber Defect Density wird normalerweise pro Fläche angegeben.

Und wieso Large Die niedrigere Defektraten hat? HPC vs. Mobile Prozess? HPC idt deutlich weniger dicht gepackt. Oder andere Dedignrules / mehr Redundanz?

AffenJack

2019-08-14, 15:12:06

Wissen tun wir das nicht, aber Defect Density wird normalerweise pro Fläche angegeben.

Und wieso Large Die niedrigere Defektraten hat? HPC vs. Mobile Prozess? HPC idt deutlich weniger dicht gepackt. Oder andere Dedignrules / mehr Redundanz?

Redundanz spielen bei der Defect Density keine Rolle, aber HPC vs Mobile ist genau das Ding. Das ein 50% dichterer Prozess am Rande des mit DUV machbaren eine schlechtere Yield hat, davon ist von auszugehen.

Gipsel

2019-08-14, 16:28:57

Wissen tun wir das nicht, aber Defect Density wird normalerweise pro Fläche angegeben.Die Hersteller normalisieren wie gesagt sehr häufig bei solchen unscharfen Darstellungen. Da ist es dann meinetwegen "defect density per equivalent area", was dann eben der Defektrate pro Transistor entspricht (die durchaus auch ab und zu dargestellt wird). Ohne daß da vernünftige Achsenbezeichnungen dranstehen, kann man streng genommen von gar nichts ausgehen.
Und wieso Large Die niedrigere Defektraten hat? HPC vs. Mobile Prozess? HPC idt deutlich weniger dicht gepackt.
Redundanz spielen bei der Defect Density keine Rolle, aber HPC vs Mobile ist genau das Ding. Das ein 50% dichterer Prozess am Rande des mit DUV machbaren eine schlechtere Yield hat, davon ist von auszugehen.Gibt es überhaupt separate HPC und Mobile Prozesse (oder hat man nicht nur schlicht die Wahl zwischen verschiedenen Standardzellen-Bibliotheken [6T, 7.5T, 9T, wo die Pitches bei allen identisch dicht am mit DUV Machbaren agieren und auch längst nicht bei allen Prozeßschritten der Yield mit der Größe der Standardzellen {also der inversen Packdichte} skaliert ;)])? Die Grafik nennt den Prozeß bei beiden explizit nur "N7", die Unterscheidung ist laut Text die Diegröße von <250mm² bzw. >=250mm² (wobei zugegeben Mobilchips tendentiell unter 250mm² fallen).
Kurz: So wirklich sicher kann man das gar nicht sagen (auch wenn natürlich ein gewisser Zusammenhang suggeriert wird). Ich würde da ein wenig Restskepsis behalten (schon allein weil eine Grafik ohne vertikale Achse streng genommen gar nichts Genaues sagen kann).

Locuza

2019-08-14, 17:18:36

Es gibt HD-Zellen (6T) und HP-Zellen (7.5T), wobei die Gate-Pitches unterschiedlich sind.
57nm beim ersteren, 64nm beim letzteren.
Interessant ist, dass man auch Beides gleichzeitig verwenden kann.

Aber wenn man sich für jeweils nur eine Bibliothek entscheidet, dann kommt man ungefähr auf 91.2 MTr/mm² mit HD-Zellen hinaus oder ~65 91.2 MTr/mm² bei HP-Zellen.

https://fuse.wikichip.org/wp-content/uploads/2019/06/tsmc-7nm-density.png
https://fuse.wikichip.org/news/2408/tsmc-7nm-hd-and-hp-cells-2nd-gen-7nm-and-the-snapdragon-855-dtco/

robbitop

2019-08-14, 17:38:19

Demnach könnte man 128 MiB L4 Cache in rund 65 sqmm mit HD Libs und 6T Zellen erreichen. IMO keine schlechte Option für zukünftige 7 nm I/O Chips. Vermutlich wird AMD das zu teuer sein. Und damit es etwas bringt, sollte man besser unter 40ns liegen. Mit aktueller IF ist das wohl nicht möglich.

Gipsel

2019-08-14, 18:02:27

Demnach könnte man 128 MiB L4 Cache in rund 65 sqmm mit HD Libs und 6T Zellen erreichen.SRAM benutzt sowieso speziell optimierte Zellen (mit anderen Abmessungen als die Standard-Logikzellen). Ein Bit SRAM mit HD-Zellen mißt bei TSMC 0,027µm² (und da sind 6 Transistoren pro Bit drin, also erreicht man da eine deutlich höhere Dichte [222 Millionen pro mm²]).
128 + 220 * 9 (8 Bit pro Byte + ECC) = 1,21 * 109 Bits * 0,027 µm² = 32,6mm².
Das sind aber rein die SRAM-Blöcke (ohne Tags). Da kommt noch Einiges dazu, um die dann auch ansprechen zu können (sieht man ja an Zen2 Die-Shots; und wer weiß ob AMD überhaupt die HD-Zellen da benutzt).

robbitop

2019-08-14, 19:34:41

Bei Matisse scheint es als wären die 32 mib rund für 40% der Fläche verantwortlich. Also bräuchten bei gleichem Aufbau 128 MiB L4 dann eher rund 120-130 sqmm. Wobei ich davon ausgehe, dass beim L4 die Anforderungen an Takt und Assoziativität geringer wären als beim L3. Das hätte doch sicher positive Auswirkungen auf die Dichte.
Aber wie gesagt: ohne schnelleren Interconnect wäre das als L4 im IO Die eh sinnfrei.

Setsul

2019-08-14, 20:29:08

Richtig, L3 liegt normalerweise ungefähr bei 4x der reinen SRAM-Größe.
Assoziativität wird da nicht viel ändern und wie viel niedriger als 16 soll man gehen? Es müssen schließlich Daten im L4 bleiben die aus den L3s rausgeworfen wurden.
Auch niedrigerer Takt bringt wenig. Wenn man den Takt halbiert, was nicht die Fläche halbiert, muss man einiges verdoppeln um den Durchsatz zu halten. Der L4 bringt nichts wenn er nicht genug Bandbreite hat.

danarcho

2019-08-15, 08:37:54

Assoziativität wird da nicht viel ändern und wie viel niedriger als 16 soll man gehen? Es müssen schließlich Daten im L4 bleiben die aus den L3s rausgeworfen wurden.
Wenn der L4 4mal so groß ist, reicht 4x Assoziativität um alles aus dem L3 jederzeit fangen zu können, oder rechne ich falsch? Ich denke daher eher man bräuchte nicht höher als 4x gehen.

Edit: steht überhaupt irgendwo, dass der L4 ein victim cache ist?

robbitop

2019-08-15, 08:50:03

Welche Cache Art wäre denn am besten geeignet für einen L4?
Hier hatte Intel iirc von BDW zu SKL auch einiges geändert. Bei SKL mit eDRAM wird der L4 gar nicht mehr explizit angezeigt.

Brillus

2019-08-15, 09:42:05

Wenn der L4 4mal so groß ist, reicht 4x Assoziativität um alles aus dem L3 jederzeit fangen zu können, oder rechne ich falsch? Ich denke daher eher man bräuchte nicht höher als 4x gehen.

Edit: steht überhaupt irgendwo, dass der L4 ein victim cache ist?

Nein kann immernoch sein das alles auf den gleichen Punkt mapped.

Pirx

2019-08-15, 09:55:03

Ob der IO in "7 nm" überhaupt genug schrumpfen würde, um einen solchen L4 unterzubringen?

edit: ähh völlig falsches Thema in diesem Thread:ucoffee:

robbitop

2019-08-15, 10:20:39

Nein, bei weitem nicht. Der IO Die ist dominiert durch IO die kaum schrumpft. Und rund 120 sqmm kämen noch dazu. Wird AMD wahrscheinlich nicht machen. Davon ab ist die IF zu langsam damit sich das lohnt (Latenz).
Ich tippe darauf, dass irgendwann mal DRAM in 3D gestackt wird. Dann hat man schnell mal 1 GB. Ggf gibt es bis dahin auch einen Link, der schnell genug ist in der AMD Welt.

Dural

2019-08-15, 10:45:04

Tapeout von GA104 (siehe EEC Tests)

Habe ich was verpasst?

davidzo

2019-08-15, 11:52:52

Habe ich was verpasst?

Ist das nicht schon sehr alt?
https://videocardz.com/76967/nvidia-board-partner-registers-ampere-ga104-400-gpu-at-eec

andererseits setht hier, dass man erst im Oktober mit 7nm EUV angefangen hat: https://www.zdnet.de/88366155/samsung-fertigt-exynos-9825-im-7nm-euv-verfahren/

Setsul

2019-08-15, 13:03:12

@danarcho:
Ganz so einfach ist es nicht und 4-fache Größe wird auch nicht drin sein. Wurde ja schon erwähnt, L3 in der Größe wären >120 mm² und so viel dichter wäre ein L4 auch nicht.

Es steht nirgendwo, dass es ein Victim-Cache ist, weil es ihn ja nicht gibt.
4x ist unrealistisch, aber selbst wenn man großzügig ist und sagt 2x L3, dann wäre inklusiv immernoch Schwachsinn weil die Hälfte nutzlos ist.

An sich muss ein Victim-Cache L4 nicht groß sein, er muss ja nur das auffangen was überquillt, dann bringt er schon etwas. Aber er muss halt mehr bringen als die Alternativen. Wenn irgendwas innerhalb des CCX bleibt ist ein größerer L3 viel besser und einfacher. Wenns innerhalb von den 2 CCX auf einem Chiplet bleibt ist das immernoch schneller als zum I/O-Die zu gehen. Oder ein unified L3 (siehe 8 Kern CCX Diskussion) oder zumindest ein on-chiplet L4. Nur wenn man Daten hat die auf mehreren Chiplets gebraucht werden, sodass man sich Duplikation spart mit einem L4 und deshalb mehr von der gleichen Menge SRAM hat, dann wird ein L4 auf dem I/O-Die sinnvoll. Dann muss der L4 aber immernoch in allen Fällen eine ausreichende Hitrate haben, dass die durchschnittliche Latenz immer sinkt. Schließlich muss man jetzt auch bei einem L4 Miss erst die L4 Tags checken und das kostet Zeit.

Zusätzliches Problem: Der Preis pro Fläche steigt stärker als der I/O schrumpft. Deshalb ja 14 nm I/O-Dies. Wenn der L4 nicht irgendwie die Hälfte davon ausmacht, ist ein etwas größerer 14nm I/O-Die mit L4 billiger als ein kaum geschrumpfter 7 nm I/O-Die.

@robbitop:
Kommt darauf an wofür. Für Matisse wohl eher gar keiner (siehe oben). Egal wie schnell das Interconnect wird, kein Interconnect ist schneller. Bei 1 oder 2 Chiplets gibts überhaupt keinen Grund nicht einfach den L3 zu vergößern wenn man es für nötig hält. Zen 2 mit 4 MB/Kern verhungert auch nicht gerade. Auch die klassischen Google/Facebook/was auch immer Workloads mit 8-10 MB Working Set + 1-2 MB/Kern laufen bei 16 MB für 4 Kerne problemlos.
Für Rome und Nachfolger wird es kompliziert, weil da die Topologie mitspielt.

Für Navi, was hier eigentlich das Thema sein sollte, ist das Ziel eher Bandbreite als Latenz. Niedrigere durchschnittliche Latenz war bei BDW/SKL zwar ein netter Nebeneffekt, aber existierte hauptsächlich um die CPU nicht langsamer zu machen. Das eigentliche Ziel ist den Flaschenhals von Dual-Channel RAM aufzuweiten. Eine GPU ist sowieso eine latency hiding machine, dafür hat man die 2000 Threads, aber das braucht Bandbreite. Dann hat man aber selbst in einer Chiplet-APU keinen Grund den L4 (bzw. L3 von der GPU aus gesehen) auf den I/O-Die zu setzen, weil das alles nur schwieriger macht. Das Interconnect muss aufgebohrt werden für höhere Bandbreite, die CPU interessiert sich eigentlich nicht für diesen Cache und der I/O-Die wird unnötig teuer weil entweder SRAM in 14nm oder ein Haufen I/O in 7nm gebaut wird.

Wenn man wirklich wollte wäre es sinnvoller es so zu machen wie Intel. Einen Teil des L2 auf dem GPU-Chiplet für eDRAM Tags umfunktionieren, einen reinen eDRAM (oder SRAM, keine Ahnung ob GF 14HP eDRAM oder TSMC 7nm SRAM billiger ist) Die als privaten GPU L3 dranhängen und sich über die zusätzliche Bandbreite freuen.

@Pirx:
Ja, eigentlich ist das nicht Navi. Keine Ahnung wieso der L4 immer wieder ausgegraben wird. Das ist kein Allheilmittel.

mboeller

2019-08-15, 14:40:51

@danarcho:
Ganz so einfach ist es nicht und 4-fache Größe wird auch nicht drin sein. Wurde ja schon erwähnt, L3 in der Größe wären >120 mm² und so viel dichter wäre ein L4 auch nicht.

eDRAM? IBM zumindest hatte 14nm eDRAM

https://en.wikichip.org/wiki/14_nm_lithography_process

Der I/O Chip würde sich dafür sehr gut eignen und 0.0174 µm² pro bitcell sind um einiges kleiner als die 0.027 µm² für 7nm (TSMC)

Setsul

2019-08-15, 15:13:52

Dafür braucht man dann 14HP, teurer als 14/12LPP. EDRAM braucht auch ein bisschen mehr drum herum.
Ändert aber nichts daran, dass der L4 auf dem I/O-Die wie gesagt an sich nicht wirklich sinnvoll ist.

Locuza

2019-08-21, 10:23:29

RDNA Whitepaper ist draußen:
https://www.amd.com/system/files/documents/rdna-whitepaper.pdf

Funny thing:
The SIMDs use separate execution units for double-precision data. Each implementation includes between two and sixteen double-precision pipelines that can perform FMAs and other FP operations, depending on the target market. As a result, the latency of double-precision wavefronts varies from as little as two cycles up to sixteen. The double-precision execution units operate separately from the main vector ALUs and can overlap execution.

Nvidia was right all along. :D

danarcho

2019-08-21, 11:44:32

Nvidia was right all along. :D
Ich glaube nicht, dass der Unterschied so ist, wie du ihn verstehst. Rein von der HW-Implementierung her dürften die 64bit execution units vorher schon separat gewesen sein, anders würden die unterschiedlichen Konfigurationen von 1:16 bis 1:2 kaum Sinn ergeben. Der Unterschied bei RDNA ist, dass jetzt teilweise out-of-order ausgeführt wird, was insbesondere shader mit low occupancy helfen soll. Bei Nvidia sind die Int und Float SIMD EUs getrennt, das hat mit DP wenig zu tun. AMD hat dafür die kleine scalar unit (bzw. jetzt 2 davon).

Locuza

2019-08-21, 12:40:27

basix

2019-08-21, 13:09:45

Käsetoast

2019-08-21, 13:11:53

Hat AMD auf der Gamescom eigentlich sowas wie eine Keynote oder dergleichen? Ich rechne da eigentlich mit einem Radeon 5800 Teaser...

MR2

2019-08-21, 13:16:05

Auf die hoffe ich auch noch dieses Jahr!

danarcho

2019-08-21, 13:40:06

Darüber habe ich auch schon nachgedacht, analog zu den SFU SIMDs die AMD damals bei GCN nie aufgemalt hat.

Meine aktuelle Auffassung bisher war/ist aber, dass AMD unterschiedliche Multi-Precision-ALUs verbaut und nur die Adder/Multiplier-Bits erweitert und keine dedizierten Pipelines für FP64-Ops zum Einsatz kommen.

Darüber wurde damals viel diskutiert in Bezug auf den GK110 und ob Nvidia tatsächlich dedizierte DP-Units verbaut und das Sinn ergibt.
Ich bin mir da auch nicht 100% sicher, aber während man bei Int einfach 2 ALUs zusammenschalten kann (oder in 2 Takten), wird das ganze bei FP deutlich komplexer. Auch wüsste ich nicht, wie man da auch 1:16 kommen soll, wenn zB nur eine der 4 SIMDs DP beherrscht. Dazu kommt, dass bei GCN die waves an ihre SIMD unit gebunden sind. Man könnte natürlich hier noch die Frage aufwerfen, was eigentlich eine execution unit überhaupt ausmacht... Wenn man das zB an einem eigenen Port festmacht, dann gehörte es zur gleichen EU (ja, ich korrigier mich hier), auch wenn es über einen anderer Block von Transistoren läuft.

Wäre mit einer FP64 Einheit nicht "Packed FP32" möglich? So habe ich bis anhin zumindest die AMD Implementation verstanden. Macht man mit Packed FP16 doch auch?
Das ergibt wenig Sinn. Der Hauptnutzen von packed FP16 sind die gesparten Register, und sekundär nur die gesparten Instruktionen. Aber man muss halt auf der upper half auch rechnen können, wenn man dort die Daten hat. Aber überleg mal: DP ist höchstens halb so schnell wie SP. Wenn du also statt einer DP Instruktion jetzt 2xSP machen kannst, sparst du genau nichts gegenüber 2 einzelnen SP Instruktionen.

Dino-Fossil

2019-08-27, 14:33:17

Weiteres Lebenszeichen von Navi14 (im Linux-Treiber/Mesa):
https://www.phoronix.com/scan.php?page=news_item&px=AMD-Navi-14-For-Mesa-19.2

JVC

2019-09-09, 13:12:55

"Stammtischgerüchte!" (was man hald so plaudert, also eigentlich "nix wert" ^^)
"Navi 21" soll 3-5.2020 kommen (ganz grob ~2080Ti Leistung ~650.-)
"Navi 23" soll erst "im Sommer"2020 kommen (ganz grob ~2080Ti +25%! ~900.-)
(von jeder sollte es 2 Varianten geben)

Naja, ich lass mich mal "überraschen" ^^
Hauptsache beide haben definitiv :massa:HDMI 2.1 :up:

M.f.G. JVC

Schnitzl

2019-09-10, 09:38:06

HOT

2019-09-10, 09:44:11

Navi 12 wird auch das ganz kleine Ding sein.

Fragman

2019-09-10, 09:55:55

2080Ti +25% ;D

Wobei man das eigentlich auch erwarten sollte, wenn wir von High End reden.
Aber ob AMD wirklich wieder ganz oben mitspielen will oder einfach eine andere Definition von High End hat, wissen wir ja noch nicht.

Schnitzl

2019-09-10, 09:58:05

Navi 12 wird auch das ganz kleine Ding sein.
ist (für mich) dann noch sinnloser. Es gibt doch unter der 5700 den Navi 14 der bald kommt.
Darunter NOCH WAS?
Und dann darüber noch 2 verschiedene Chips? Glaube ich nicht. Wie will AMD 5 verschiedene finanzieren ...

deekey777

2019-09-10, 10:33:29

Genauso wie schon vorher unterschiedliche Grafikchips finanziert worden sind. Selbst vom Polaris gibt es drei Versionen mit 10 CUs, 16 CUs und 36 CUs.

AMD hat anscheinend zum 100. Mal die uralten mobilen GCN 1.0 Chips umbenannt. Dann noch die kleinsten Polaris zu 630/RX 640. Irgendwann werden die Hersteller die Schnauze voll haben und gänzlich von AMD abwenden.

HOT

2019-09-10, 11:38:49

ist (für mich) dann noch sinnloser. Es gibt doch unter der 5700 den Navi 14 der bald kommt.
Darunter NOCH WAS?
Und dann darüber noch 2 verschiedene Chips? Glaube ich nicht. Wie will AMD 5 verschiedene finanzieren ...
Bei Polaris gab es noch kleinere Chips, P12 und P11. P12 ist als P23 jetzt in 12nm erneuert worden, da gibts halt ne Lücke zwischen P23 und N14, diese wird mit N12 mMn ausgefüllt. Der kleinste Polaris ist halt der neue Oland quasi.

deekey777 Was fürn BS, sry... :freak:

crux2005

2019-09-10, 17:47:12

Tahiti vs. Polaris vs. Navi:

fzPo7gu-fTw

Der Herr. Leadbetter hat da viel Arbeit hineingesteckt. Gibt es einen Fred wo es besser passt?

woodsdog

2019-09-11, 07:25:12

Das Video ist spitze.

basix

2019-09-11, 10:44:59

Das Video ist spitze.

Ich habe schon im Konsolenthread gepostet:
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=12093710&postcount=5769
Ich bin etwas überrascht, dass Tahiti so stark abfällt. Und noch mehr überrascht, wie gross der Sprung von Tahiti zu Navi effektiv ist, das ist Rohleistungsnormiert locker +50-70% schneller im Schnitt und in einigen Spielen sogar 100%.

Das lässt auf stärkere Konsolen hoffen, als erwartet :) Nicht von der Rohleistung her aber von Output am Bildschirm.

Schnitzl

2019-09-11, 12:34:49

kann jemand das video irgendwie kurz-zusammenfassen? Ich kann das bei der Arbeit nicht anschauen ^^

Dino-Fossil

2019-09-11, 12:46:15

tl;dw:

Gegenüber GCN1.0 (was mehr oder minder die Gen ist, die in der XBone und PS4 verbaut ist) bietet Navi einen erheblichen Fortschritt. Deutlich mehr Perf/Flop, interessanterweise auch bei einigen low-level-Implementierungen, obwohl das natürlich am PC getestet wurde.
Im Endeffekt heißt das, dass die Performance der next-gen Konsolen erheblich größer ausfallen dürfte, als die reinen Flop vermuten lassen.

Der_Korken

2019-09-11, 13:03:29

Nicht nur auch, sondern gerade bei Lowlevel-Titeln. Allerdings wird auch gemutmaßt, dass es vielleicht ein Treiberproblem sein könnte. 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!).

Ein Punkt wurde schon im Video rausgearbeitet: Die Geometrie ist ein Problem. Bei Witcher 3 max. hatte Tahiti in 1080p und 1440p fast die gleichen Frames. Hat man dann die Konsolensettings genommen, die die Geometrie deutlich entschärft haben, ist der Unterschied zu Polaris stark geschmolzen. Das andere Problem könnte die Speicherbandbreite sein. Bei Tahiti war das Verhältnis (1,05Ghz vs 288GB/s) @stock deutlich speicherlastiger als bei Polaris (~1,2Ghz vs 224GB/s), weil letzterer dann doch über die Jahre einige Verbesserungen wie DCC erhalten hat. Wenn man das Verhältnis dann angleicht, leidet Tahiti da vielleicht unter der verringerten Bandbreite.

Es ist halt nicht leicht so unterschiedliche Architekturen zu testen.

Dino-Fossil

2019-09-11, 13:14:17

Ja, der deutliche Unterschied schon zw. Tahiti und Polaris in einigen Titeln hat mich auch überrascht. Es gab mal einen ähnlichen Vergleich bei CB zw. Tahiti, Tonga und Polaris kurz nach Release der 480, da war der Unterschied noch nicht so deutlich.
Allerdings hat sich seitdem eben einiges in den Treibern getan und AMD dürfte seitdem treiberseitig erheblich mehr an Polaris verbessert haben, als an Tahiti, der vermutlich eh schon relativ ausoptimiert war.
Die Hardware-Verbesserungen kommen natürlich noch obendrauf - da wäre es auch interessant mal zu vergleichen, wie sich der Schwerpunkt in den Engines verlagert hat.

Schnitzl

2019-09-11, 13:26:57

danke! Es scheint doch in die richtige Richtung zu gehen. Benötigt eben etwas Zeit, und das ist auch gut so. Alles auf Einmal wäre dann ein 2.Vega - also warten und auf neue Naavis freuen :)

HOT

2019-09-11, 13:27:54

Bei vielen heutigen Titeln wird das Frontend von Tahiti einfach die Bremse sein. Nicht vergessen, ist nur ein halber Fiji mit dem schwachen Frontend, das auch Hawaii zu schaffen macht. Er hat ja viele neue Titel getestet.

Der_Korken

2019-09-11, 13:27:56

Ja, der deutliche Unterschied schon zw. Tahiti und Polaris in einigen Titeln hat mich auch überrascht. Es gab mal einen ähnlichen Vergleich bei CB zw. Tahiti, Tonga und Polaris kurz nach Release der 480, da war der Unterschied noch nicht so deutlich.

Das war dieser hier: https://www.computerbase.de/2016-08/amd-radeon-polaris-architektur-performance/2/#diagramm-the-witcher-3-1920-1080

Tahiti -> Tonga: +10%
Tahiti -> Polaris: +18%

Eigentlich auch schon mehr als ich in Erinnerung hatte. Täuscht vielleicht aber, weil man ab 2015 nicht mehr so viel mit Tahiti verglichen hat, sondern eher mit Hawaii, welcher deutlich näher an Tonga als Tahiti liegen sollte.

Was man auch sieht:
Polaris 32CUs -> 36CUs: +4%

Das war im Video von DF auch so. Die +12,5% Shader bringen total wenig, d.h. der Unterschied bei der "IPC" zwischen RX470 und RX480 ist allein schon 8%. Oder anders: Vergleicht man 32 Tahiti und 36 Polaris CUs, ist der IPC-Gewinn nicht mehr deutliche 18%, sondern nur noch überschaubare 10%. Das müsste man bei Navi eigentlich auch mal prüfen.

JVC

2019-09-11, 13:34:44

Tahiti vs. Polaris vs. Navi:

https://youtu.be/fzPo7gu-fTw

Der Herr. Leadbetter hat da viel Arbeit hineingesteckt. Gibt es einen Fred wo es besser passt?
Danke, toller vergleich :up:

So etwas zwischen Pa und Tu ... wäre spitze :smile:

M.f.G. JVC

][immy

2019-09-11, 14:09:15

Das war dieser hier: https://www.computerbase.de/2016-08/amd-radeon-polaris-architektur-performance/2/#diagramm-the-witcher-3-1920-1080

Tahiti -> Tonga: +10%
Tahiti -> Polaris: +18%

Eigentlich auch schon mehr als ich in Erinnerung hatte. Täuscht vielleicht aber, weil man ab 2015 nicht mehr so viel mit Tahiti verglichen hat, sondern eher mit Hawaii, welcher deutlich näher an Tonga als Tahiti liegen sollte.

Was man auch sieht:
Polaris 32CUs -> 36CUs: +4%

Das war im Video von DF auch so. Die +12,5% Shader bringen total wenig, d.h. der Unterschied bei der "IPC" zwischen RX470 und RX480 ist allein schon 8%. Oder anders: Vergleicht man 32 Tahiti und 36 Polaris CUs, ist der IPC-Gewinn nicht mehr deutliche 18%, sondern nur noch überschaubare 10%. Das müsste man bei Navi eigentlich auch mal prüfen.
Wie ich schon im anderen Thread geschrieben hab, wurde da nicht auch die Anzahl der Textur-Einheiten und ROPs verändert zwischen den GCN Iterationen.
Zumindest hat aber Polaris noch neue Kompressionsverfahren um Bandbreite zu sparen. Was ihm bei gleicher Bandbreite natürlich schon mal einen Vorteil verschafft.

edit: achne, die ROPs und TMUs sind gleich geblieben, aber der Cache wurde stark vergrößert.

Aber ja, Polaris war schon ein nettes upgrade von GCN 1.0 gesehen (so oder so).

SKYNET

2019-09-11, 14:19:47

Wobei man das eigentlich auch erwarten sollte, wenn wir von High End reden.
Aber ob AMD wirklich wieder ganz oben mitspielen will oder einfach eine andere Definition von High End hat, wissen wir ja noch nicht.

naja, wird dann wohl auf level des 2080Ti refresh mit 7nm liegen(so +/-), passt doch... weil viel an rohleistung wird NV da nicht gewinnen können, die werden eher bezüglich RT in die breite gehen.

][immy

2019-09-11, 14:28:22

naja, wird dann wohl auf level des 2080Ti refresh mit 7nm liegen(so +/-), passt doch... weil viel an rohleistung wird NV da nicht gewinnen können, die werden eher bezüglich RT in die breite gehen.
kommt drauf an. Die 2080 TI ist ja nicht grad für Leute die wenig ausgeben.
Wenn sich also nvidia entscheiden sollte, ihren ultra-high end chip wieder ähnlich groß werden zu lassen und trotzdem in 7nm zu fertigen, wäre das zwar ziemlich teuer, die Kundschaft würde es aber wohl nicht stören. Wird sicherlich auch noch Kunden geben, die >2000€ dafür ausgeben. Vom Firmensektor mal ganz abgesehen.
Zumindest könnte man damit AMD mühelos in Schach halten. Schon die 2080 TI ist ja nichts anderes als ein prestige Projekt.

SKYNET

2019-09-11, 14:35:38

[immy;12093926']kommt drauf an. Die 2080 TI ist ja nicht grad für Leute die wenig ausgeben.
Wenn sich also nvidia entscheiden sollte, ihren ultra-high end chip wieder ähnlich groß werden zu lassen und trotzdem in 7nm zu fertigen, wäre das zwar ziemlich teuer, die Kundschaft würde es aber wohl nicht stören. Wird sicherlich auch noch Kunden geben, die >2000€ dafür ausgeben. Vom Firmensektor mal ganz abgesehen.
Zumindest könnte man damit AMD mühelos in Schach halten. Schon die 2080 TI ist ja nichts anderes als ein prestige Projekt.

sehe ich nicht so, das ding ist zwar ein wenig (über)teuer(t), aber halt must have bei gewissen games mit gewissen settings, wo dir sonst der speicher ausgeht, alternativ gäbs nur noch die VII die genug vram hat.

Setsul

2019-09-11, 14:49:36

Das war im Video von DF auch so. Die +12,5% Shader bringen total wenig, d.h. der Unterschied bei der "IPC" zwischen RX470 und RX480 ist allein schon 8%. Oder anders: Vergleicht man 32 Tahiti und 36 Polaris CUs, ist der IPC-Gewinn nicht mehr deutliche 18%, sondern nur noch überschaubare 10%. Das müsste man bei Navi eigentlich auch mal prüfen.
ROPs, L2 und Bandbreite bleiben gleich, dadurch ist das natürlich nicht ganz fair.

Höhere IPC kommt ja nicht davon dass die Polaris SIMD Units irgendwie magische FLOPs besserer Qualität produzieren. Bei GCN wurde an der Latenz nicht viel gedreht also kommt praktisch alles an IPC von außerhalb der SIMDs durch höhere Auslastung. Wenn man dann einen Großteil dieser Resourcen konstant hält und nur mehr FLOPs hat kommt natürlich nicht viel mehr Leistung raus.

Man darf auch nicht vergessen dass IPC nicht das einzige ist. Wenn man als Extrembeispiel die Pipeline massiv verlängert und dadurch die IPC um 20% reduziert sieht das erstmal schlecht aus, aber wenn man dadurch 50% höher takten kann gibt das alles wieder einen Sinn.

Ohne interne Informationen kann man natürlich nicht sagen wie das Taktverhältnis prozessnormiert aussehen würde.

So wie DF das gemacht hat ist eigentlich optimal. Vergleiche mit unterschiedlicher Anzahl CUs/ROPs/Shader Engines usw. kann man in die Tonne treten weil die selbst für die selbe Architektur unterschiedliche IPC liefern würden. Der niedrige Takt und Bandbreite sind natürlich schlecht für die neueren Architekturen, aber andererseits haben sie durch DCC einen Vorteil und bei höherem Takt, selbst mit höherer Bandbreite, wird die IPC wieder etwas runtergehen, also hat man insgesamt ein Ergebnis das zumindest einigermaßen die Richtung vorgibt wenn man GCN 1.0 in RDNA FLOPs umrechnen will.

Dino-Fossil

2019-09-11, 14:58:28

Tahiti -> Tonga: +10%
Tahiti -> Polaris: +18%

Eigentlich auch schon mehr als ich in Erinnerung hatte.

Es gab, glaube ich, einen ähnlichen Test bei PCGH, der etwas weniger gesehen hat, v.a. zw. Tonga und Polaris.

Vergleicht man 32 Tahiti und 36 Polaris CUs, ist der IPC-Gewinn nicht mehr deutliche 18%, sondern nur noch überschaubare 10%. Das müsste man bei Navi eigentlich auch mal prüfen.

Es wurden doch bei CB Chips mit gleicher Menge an CUs verglichen, also 32 CU Tahiti vs 32 CU Polaris (470), oder verstehe ich dich da gerade falsch?

Der_Korken

2019-09-11, 15:23:52

ROPs, L2 und Bandbreite bleiben gleich, dadurch ist das natürlich nicht ganz fair.

Höhere IPC kommt ja nicht davon dass die Polaris SIMD Units irgendwie magische FLOPs besserer Qualität produzieren. Bei GCN wurde an der Latenz nicht viel gedreht also kommt praktisch alles an IPC von außerhalb der SIMDs durch höhere Auslastung. Wenn man dann einen Großteil dieser Resourcen konstant hält und nur mehr FLOPs hat kommt natürlich nicht viel mehr Leistung raus.

Das stimmt natürlich alles, ich würde aber trotzdem "kritisieren", dass wenn man einen IPC-Vergleich zwischen einem vollen und einem Salvage-Chip macht, letzterer da tendenziell besser bei wegkommt, weil er das drumherum eigentlich für mehr Recheneinheiten ausgelegt ist.

Es wurden doch bei CB Chips mit gleicher Menge an CUs verglichen, also 32 CU Tahiti vs 32 CU Polaris (470), oder verstehe ich dich da gerade falsch?

Guck mal in meinem Link weiter unten. Da ist auch eine CU-Skalierung drin zwischen 470 und 480 jeweils @1150/4000.

Dino-Fossil

2019-09-11, 15:52:36

Guck mal in meinem Link weiter unten. Da ist auch eine CU-Skalierung drin zwischen 470 und 480 jeweils @1150/4000.

Naja, es ging halt um den Vergleich bei gleicher Hardware-Ausstattung und da war der Zuwachs eben 18%.
Jetzt könnte man eine hypothetische Betrachtung machen und zeigen, dass der IPC-Gewinn geringer wird, wenn ich mehr Recheneinheiten draufklatsche, weil die schlechter Ausgelastet werden, aber das wäre doch bei Tahiti das gleiche.

Dann wäre es aber immer noch sowas wie 1,18(Polaris ggü. Tahiti bei 32CU)*1,08(36 vs 32 CU)*32/36(Normierung auf die CUs)=1,13, also noch 13%

Ein 36CU Tahiti wäre CU-normiert ja auch nicht mehr so gut wie bei 32CU.

Setsul

2019-09-11, 19:27:59

@Der_Korken:
Ist in dem Fall aber fair weil man bei einem 64 CU Polaris alles verdoppelt und nicht vereinskommasiebenachtfacht hätte und bei Polaris 11 alles halbiert wurde. Polaris 10 ist in Sachen CUs überbestückt um eine bestimmte Performance noch zu erreichen.
Das Verhältnis verschiebt sich natürlich ein bisschen je nach Chip. Bei 12-16 CUs sieht alles etwas anders aus als bei 32-40 und obs 12, 14 oder 16 CUs werden in der nächsten Generation werden hängt weniger davon ab was für die Architektur optimal wäre als was für das Produktportfolio gebraucht wird.

Die Bandbreite anzupassen wäre das Minimum wenn man unterschiedliche CU-Anzahlen vergleicht, sonst hat der größere Chip immer ein Handicap.
Also wenn man jetzt theoretisch zwei Chips mit 32 bzw. 48/64 CUs vergleicht und der größere hat von allem außer vielleicht Shader Engines auch 50/100% mehr dann führt ein Vergleich 32 vs 32 CUs natürlich zu nichts, aber 32 vs 48/64 CUs bei gleicher Bandbreite ist genauso sinnlos.