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

[fondness]

Zurzeit spekulierte Daten:
- skalierbares Design (mehrere Dies auf einem Interposer?)
- Nextgen Memory (HMB3?)
- PCIe 4.0
- 7nm GF

http://www.fudzilla.com/news/graphics/41671-navi-is-7nm-late-2018-early-2019


Offizielle Roadmap von AMD:

http://s22.postimg.org/ll6azorfl/AMD_Next_Gen_Vega_GPU_and_Navi_GPU_2017_2018.jpg

[Schaffe89]

Ja es ist offensichtlich, dass du Verständnisschwierigkeiten beim dem Thema hast. Ein bekanntes Phänomen:

Ich sage im Prinzip nur das was auf der Mainseite des 3D Centers heute steht.

"Allerdings holt sich AMD mit dieser Entscheidung auch die Problematik ins Haus, ausgerechnet jetzt wieder verstärkt auf MultiChip-Konstrukte als sogar Teil des regulären Produktprogramms zu setzen. Ohne diese Entscheidung AMDs hätte man schließlich SLI & CrossFire auf einem aussterbenden Ast gesehen, da der Support der Spieleentwickler doch merkbar nachgelassen hat und es mit DirectX 12 noch komplizierter (für die Spieleentwickler) wird, diese MultiChip-Technologien zu unterstützen. Mit der Entscheidung zugunsten von DualChip-Grafikkarten als Teil des regulären Produktprogramms sollte AMD natürlich dann auch mehr Kräfte in die Zusammenarbeit mit den Spieleentwicklern zugunsten eines (allseits) funktionierenden CrossFire-Supports legen – ansonsten würden die entsprechenden DualChip-Grafikkarten gleich als "dead on arrival" gelten müssen."

So eine Strategie erfordert immer um die Abhängigkeiten zwischen den Chips geregelt zu bekommen, eine gute und vor allem einfach zu realisierende Softwarebasis.
Dass AMD diesen Weg der Dual GPU´s geht, ist imho ein Eingeständnis dass die Leistung eines Chips nicht ausreichend ist. Mit Navi wird man jedenfalls kein skalierbares Design mit "mehreren Dies" auf einem Interposer sehen, das ist imho ein Hirngespinst und wird so garantiert noch viel länger dauern, sondern es werden viel wahrscheinlich erstmals Dual GPU´s werden und vermutlich wird man den Designsansatz mit Stacking dann wieder verwerfen, weil es massive Nachteile auf Seiten der Software hat. Das ist nur ein mittelfristiges hätte wäre wenn Projekt mit ein bisschen Marketinggelaber um die Dual GPU´s die man bauen will zu supporten, später steigt man dann wieder um, falls man wieder das nötige Kleingeld hat.

[iuno]

Die Plaene fuer 2018-19 sind sicherlich schon ziemlich.. "ambitioniert". Welcher 7 nm Prozess ist da denn gemeint? Eine Weiterentwicklung von dem Samsung 14 LPE/LPP Zeug oder etwas von IBM?
Fuad hat ja nochmal die Geruechte zu Vega 20 bekraeftigt, max. 6-9 Monate nach V10. Allerdings schreibt er dabei nichts ueber 7 nm.
Dafuer aber etwas von embedded APUs fuer 2019.

[AnarchX]

Die Plaene fuer 2018-19 sind sicherlich schon ziemlich.. "ambitioniert".
Vom na(t)iv Quadcore zur Naiv-GPU? Aber das wird sich wohl zeigen, wenn kleinere 7nm Design erscheinen.

[Rabiata]

Dass AMD diesen Weg der Dual GPU´s geht, ist imho ein Eingeständnis dass die Leistung eines Chips nicht ausreichend ist. Mit Navi wird man jedenfalls kein skalierbares Design mit "mehreren Dies" auf einem Interposer sehen, das ist imho ein Hirngespinst und wird so garantiert noch viel länger dauern, sondern es werden viel wahrscheinlich erstmals Dual GPU´s werden und vermutlich wird man den Designsansatz mit Stacking dann wieder verwerfen, weil es massive Nachteile auf Seiten der Software hat.
Teilweise Zustimmung, das wird wohl nur was wenn der Treiber die mehreren Chips transparent (aus Sicht der Anwendung) zu einem großen, leistungsfähigen Chip zusammenfassen kann.

Ob das klappt, sei mal dahingestellt, ich kenne mich in der Treiberentwicklung nicht so gut aus :redface:.

Falls ja, steht dem skalierbaren Design nichts im Weg. Falls nein, werden die größeren Navi-Designs wohl wenig Absatz finden. Aber darüber hat sich AMD hoffentlich auch Gedanken gemacht, und ich neige zu der Ansicht, daß sie das Konzept wohl nicht in Angriff nehmen würden, ohne eine Lösung in petto zu haben.

[Foobar2001]

Mit Vulkan und DX12 hat der Treiber keine Chance da was zu machen. Im Gegenteil, traditionelles Multi GPU wird komplett auf die Entwickler abgewaelzt - und kommt mir jetzt nicht mit irgendwelchen Libraries, das sind Krueckstoecke.

Es ist nicht ausgeschlossen, dass ein Interposer genuegend Bandbreite bieten koennte um zwei Chips zusammenzuschalten, die dann wie ein einziger arbeitet. Es hat aber noch niemand demonstriert.

[Achill]

Immer dieses Zerreden ... ich behaupte (und es gibt dafür keine Quellen) das eine Multi-Core-GPU, also eine GPU die aus mehreren kleineren (Teil)GPUs besteht, ganz anderes funktionieren wird als ein CFX/SLI Verbund wie man diesen heute kennt.

Altes CFX/SLI => 2 Socket-CPU-System (mit den gleichen Problemen wenn CPU1 auf den RAM von CPU2 zugreifen muss)

Neues Multi-Core-GPU => Multi-Core-CPU (alle Cores haben Zugriff auf L3/L4 Cache und RAM)

Ich denke jegliche Aussagen die "unterschiedlich Wahr" zu CFX/SLI gemacht wurden / bestehen, sind komplett neu zu betrachten bzgl. einen solchen neuen Ansatz.

Warum? Weil es eklatante Unterschiede gibt, die mit einer spekulativen mCore-GPU auf einen Interposer möglich sind:
- Alle GPU-Cores haben Zugriff auf eine gleiche L3 Cache
- Jeder GPU-Core hat Zugriff auf den gemeinsam verfügbaren und shared! VRAM
- Jeder GPU-Core wird ein Tile des Framebuffers bearbeiten, sprich mit solch einen Design geht dann:
-- 1x, 2x, 3x, ... Cores (Vert.Tiling)
-- 2*2x, 2*3x, ... Cores (Horiz. & Vert. Tiling)
==> Super-Teilbar um für VR zwei Bilder zu berechnen
==> Super Sklierbar für verschiedene Marktsegmente
- 2D Modus dann nur ein GPU-Core aktiv, der Rest ist deaktiviert
=> Es muss kein State zwischen zwei Frames und der jeweiligen berechneten GPU (SLI/CFX) übermittelt werden, State-Based-Engines funktionieren wunderbar mit diesen Konzept
-- Keine Warten auf eine andere GPU
-- Keine PCIe Latenz oder Bandbreiten-Problem

Das ganze sollte ohne SW-Lösung möglich sein / wird mittels HW wegen Perf. umgesetzt (ggf. beschränkt programmierbar, z.B. für VR).
=> Eine "Art" vorgelagerte Vertex-Enginge (Vertext-Schedular) prüft die Operationen und leitet den Befehl an die GPU-Core(s) weiter, in dessen Tile der jeweilige Vertex fällt / ein Teil davon.
=> Für VR werden die Operationen dubliziert und dann genauso auf die GPU-Core verteilt, nur das pro Bild jeweils die Hälfte der GPU-Cores zur Verfügung steht.

Das ist einfach mal so aus dem Bauch geschrieben, weiß natürlich nicht ob es "so" möglich ist, soll auch nur dazu diesen, man die Scheuklappen abnimmt und wirklich mal spekuliert.

[iuno]

Es ist nicht ausgeschlossen, dass ein Interposer genuegend Bandbreite bieten koennte um zwei Chips zusammenzuschalten, die dann wie ein einziger arbeitet. Es hat aber noch niemand demonstriert.
Oeffentlich hat AMD vorher meines Wissens auch nie die Stacking demonstriert, trotzdem hat man natuerlich Experimente gemacht: https://www.computerbase.de/2015-08/amd-fiji-vom-ersten-schritt-zum-fertigen-produkt-in-8.5-jahren/
Das halte ich hier auch nicht fuer ausgeschlossen. Es ist schon ein spannendes Thema, aber ich weiss nicht, ob man es mit Navi schon (oder ueberhaupt) wirklich machen will und dann auch zu dem Zeitpunkt schon hinbekommt.

Theoretisch koennte man schon interessante Sachen machen, etwa Logik mit in den Interposer nehmen, ganze Teilbausteine ueber die Produktpalette wiederverwenden, einzelne CU-Dies einzeln shrinken oder sowas :ulol:

[Schaffe89]

T Aber darüber hat sich AMD hoffentlich auch Gedanken gemacht, und ich neige zu der Ansicht, daß sie das Konzept wohl nicht in Angriff nehmen würden, ohne eine Lösung in petto zu haben.

Solange dabei AFR und SFR weiterhin als Möglichkeiten im Raum stehen wird das nix werden, dann AMD sagt ja, dass sich die Entwickler darauf vorbereiten sollen ( auf was genau eigentlich?), nur auf was sollen sich die Entwickler vorbereiten, wenn der Dualchip mit Interposern noch gar nicht da ist. Henne-Ei Problem. Mit Directx11 würde so eine Abstrahierung von zwei Chips per Interposer verbunden sogar noch besser klappen als aktuell mit Directx12.

Gibt es denn irgendwo Materialen die einem erklären, wie die sinnvolle Zusammenarbeit bei einem Skalierbaren Design mit mehreren Chips funktionieren soll, ohne die üblichen Probleme? Also mir ist da nichts bekannt, eher ist man doch von dem Zug schon lange abgesprungen.

==> Super Sklierbar für verschiedene Marktsegmente

Wenn man Koduris Aussagen bei Capsaicin jetzt für Bare Münze nimmt und an das Interposer Ding bei Navi glauben möchte, dann spricht er erstmal nur von Dual GPU´s mit kleineren bzw. midrange Chips um keinen großen zu produzieren, ein zu großes Risiko einzugehen und so wahrscheinlich Kosten zu sparen. Das wäre natürlich von einer Skalierbarkeit weit entfernt.

http://wccftech.com/amd-vega-gpu-navi-gpu-hbm2-2017-2018/

Die Grafik veranschaulicht das unter Moores Law vs. GPU Performance per Dollar, so nach dem Motto es lohne sich nicht mehr so gewaltig große Dies herzustellen.
Das sieht mir eher nach einer Strategie aus langfristig oder zumindest mittelfristig die Kosten zu senken, was neben der 1GPU pro Jahr Politik wohl auch eine Politik von kleinen Chips vorsieht, die man im "Boyond Crossfire Spezialmodus" laufen lässt.

[Setsul]

Sowas ähnliches wollte ich auch schon schreiben.

L2 Kohärenz ist wirklich kein Problem, man muss auch sonst Daten von den verschiedenen SIs an verschiedenen Seiten des Dies herumschieben, da ändert sich nicht viel.
AMD hat zwar kein TBR aber es gibt einige Möglichkeiten.

Die Frage ist einfach nur wieviel ist man bereit dafür zu zahlen, entweder in Performance/Takt oder in Aufwand/Geld.
Jetzt mal ganz naiv könnte man zum Beispiel Fiji auseinandernehmen, jede Shader Engine mit einem 1024b HBM SI und 2 ACEs kommt auf einen eigenen Die und dann funktioniert das schon mehr oder weniger. Alles was Feedback benötigt ist natürlich unangenehm und niemand hat sowas bis jetzt gemacht, dementsprechend dauert es natürlich das wirklich umzusetzen, aber es ist definitiv möglich.


Ich bin mir nicht sicher ob man bei Navi schon so weit ist, das in verschiedene Dies aufzuteilen.
Für mich wäre der erste Schritt zu einer "skalierbaren Architektur" die Teile unabhängiger voneinander zu machen. Also anstatt wie bei Tonga zu Fiji die SEs aufzubohren mit viel Designaufwand entwickelt man einen Block ähnlich einer SE + Steuerungslogik + evtl SI. Den kann man dann so oft man will (1-8 mal nehme ich an) zusammen mit den restlichen Komponenten zu einem Floorplan zusammenbauen ohne dass man für jeden Die viel neu designen muss.

Der nächste Schritt ist dann diese Blöcke auf verschiedene Dies zu verteilen und per Interposer zu verbinden. Ob wir das schon bei Navi sehen werden ist schwierig zu beantworten. Aber ich nehme an AMD will das so bald wie möglich machen.


Im vorherigen Thread hat jemand was zu Kosten gesagt, dass das erst möglich ist wenn 1 HBM stack + Interposer auch billig genug ist für den kleinsten Chip.
Bloß weil man einen Interposer hat, braucht man kein HBM. Man kann auch einen Die mit GDDR5(X) SI bauen mit normal großen Bumps und das einfach durch den Interposer ans Package Substrate weiterreichen und den Interposer nur für die Verbindung zwischen den Dies wirklich nutzen.

Man kann dann zum Beispiel einen Kleinstchip mit 64b bauen, einen mit 128b, den man dann ohne Interposer alleine oder mit IP dann zu zweit verbaut und dann einen mit 1024b HBM, eventuell die Display Controller und ähnliches Gedöns auf einen eigenen Die, da man mit HBM sowieso einen IP braucht und dann bei der größten GPU nicht alles vierfach vorhanden ist, was man nur einmal braucht.

Wenn Interposer dann billig genug sind kann man DC und andere Sachen (z.B. TrueAudio DSPs, was weiß ich) generell auf andere Dies auslagern, die man dann durch die ganze Generation verwenden kann. Dann kann man sich auch ganz andere Späße erlauben. Man betreibt dann effektiv Rebranding mit alten Dies, ersetzt aber die "Hilfsdies" und schon hat man eine GPU die HDMI 3.0 unterstützt und ja viel besser ist als das Vorjahresmodell.


Generell will, soweit ich weiß, AMD sehr stark auf Interposer setzen. Gerade bei Semi-Custom APUs kann man dann den "Custom" Anteil seeeehr weit einschränken. Man nehme einen CPU Die und einen GPU Die die man sowieso produziert, vielleicht noch einen custom Die dazu, einen Interposer und dann freut man sich über die Marge.

[Hübie]

Noch habe ich Zweifel ob es kostenmäßig tatsächlich optimal ist. Man hat für den GPU-Die eine Maske, aber braucht einen komplexen Interposer (auch hierfür ne Maske, Tooling etc.) und muss die Assembly-yield so hoch halten, dass die Kosten abgefedert werden. Wir diskutieren hier glaub ich schon seit 10 Jahren über diese Interposer-Geschichte. Gekommen ist bisher Fiji mit einem passivem Interposer ohne mGPU-Ambitionen.

Eure Ideen in Ehren, aber ich glaube nicht dass es sich rentieren wird. Wenn EUV-Prozesse für GPUs starten, dann könnte es sein... Könnte. Vorher glaub ich es einfach nicht.

[Skysnake]

Xillinx nutzt das schon seit einigen Jahren (wobei die Preise auch gesalzen sind...). Also es KANN sich durchaus rechnen. Man muss allerdings dann wirklich das komplette Lineup darauf auslegen. Ansonsten rechnet es sich eher nicht.

Interessant wäre es, ob man eventuell den "gesanten" Graphicspart auf einem Chip konzentrieren kann und die Shader dann auf mehreren anderen. Damit könnte man für Compute und Graphics sich die Produkte so Bauen wie man will.

Gearbeitet wird daran ganz ganz sicher. Wann es kommt kann aber wohl keiner außer AMD sagen.

[Gouvernator]

Falls ja, steht dem skalierbaren Design nichts im Weg. Falls nein, werden die größeren Navi-Designs wohl wenig Absatz finden. Aber darüber hat sich AMD hoffentlich auch Gedanken gemacht, und ich neige zu der Ansicht, daß sie das Konzept wohl nicht in Angriff nehmen würden, ohne eine Lösung in petto zu haben.
Ich neige zur Ansicht, das die einfach die kleinen GPUs auf ALLE Boards klatschen werden (was ja durch 7nm Fertigungsprozess TDP mäßig endlich gehen kann). Und dann, mit Crossfire-Profil von einem der DX9 Games (wo CF gut läuft) diese Lösung an den Mann bringen. Wie mit allen CF Boards bis jetzt.

Ihr müsst einfach die Unternehmenslogik verstehen. AMD befindet sich zur Zeit in der Konkursverschleppung. Sie haben restlichen Ressourcen für den Dummenfang verplant und nicht für bahnbrechende technische Neuerungen - um "Crossfire" in einem Chip in DX12 Games, für billig Geld, für alle verfügbar zu machen. ;D

[fondness]

Noch habe ich Zweifel ob es kostenmäßig tatsächlich optimal ist. Man hat für den GPU-Die eine Maske, aber braucht einen komplexen Interposer (auch hierfür ne Maske, Tooling etc.) und muss die Assembly-yield so hoch halten, dass die Kosten abgefedert werden. Wir diskutieren hier glaub ich schon seit 10 Jahren über diese Interposer-Geschichte. Gekommen ist bisher Fiji mit einem passivem Interposer ohne mGPU-Ambitionen.

Eure Ideen in Ehren, aber ich glaube nicht dass es sich rentieren wird. Wenn EUV-Prozesse für GPUs starten, dann könnte es sein... Könnte. Vorher glaub ich es einfach nicht.

Das sind nicht "unsere Ideen", das wurde von der offiziellen Roadmap allgemein so interpretiert. Oder was sollte man sonst unter "scalability" bei einer GPU verstehen?
Im übrigen gibt es ja schon einige Paper von AMD, welche in diese Richtung gehen (Stichwort EHP oder Exascale Heterogeneous Processor). Und auch Folien, die offensichtlich von AMD stammen und die Verbindung von einer Greenland-GPU mit einem Zeppelin-Die über einen Interposer mittels GMI-Links beschreiben.

[Hübie]

Xillinx nutzt das schon seit einigen Jahren (wobei die Preise auch gesalzen sind...). Also es KANN sich durchaus rechnen. Man muss allerdings dann wirklich das komplette Lineup darauf auslegen. Ansonsten rechnet es sich eher nicht.

Interessant wäre es, ob man eventuell den "gesanten" Graphicspart auf einem Chip konzentrieren kann und die Shader dann auf mehreren anderen. Damit könnte man für Compute und Graphics sich die Produkte so Bauen wie man will.

Gearbeitet wird daran ganz ganz sicher. Wann es kommt kann aber wohl keiner außer AMD sagen.

Ich glaube kaum dass man das vergleichen kann. Xilinx hat keine komplexen Dice und ob der Interposer Controller-Logik und Scheduling hat weiß ich gerade nicht.

@fondness: Mit eure Ideen meinte ich die Ideen zur Umsetzung (siehe Achills, durchaus schlüssigen, Beitrag).
Die Andeutungen können eher so skalierbare Dinge sein wie ein Zeppelin+P11 oder in der Art. Aber ich will das auch madig reden, denn AMD ist ja für Spielereien bekannt. Ich sagte lediglich aus der Ökonomie heraus betrachtet ist es schwer vorstellbar dass es sich rechnet. :smile:

[Setsul]

Navi kann auch wie gesagt nur die Vorbereitung sein. Alleine Blöcke zu haben, die man nicht anpassen muss für jeden Die dürfte schon massiv Kosten sparen.

Selbst wenn man minimal Performance pro Block/SE opfert wird man dann eventuell auch das Problem los, das man sonst beim hochskalieren hatte. Siehe Fiji und Tonga, 100% mehr Rohleistung draufgeworfen, 60% mehr Performance rausbekommen.


Wenn ich mich richtig erinnere, rechnet man bei SoCs mit etwa Faktor 2 Kostensteigerung fürs Design. Ohne EUV hat man halt Spaß mit Quadruple Patterning und ähnlichen Spielereien, mit EUV darf man momentan ein Vielfaches pro Wafer berappen.
Also 14nm doppelt so viel wie 28nm, 10nm dann 4 mal, 7nm 8 mal und so weiter. Ein 45nm passiver Interposer ist dagegen einfach spottbillig. Also solange man es zum laufen bringen kann, wird sich das definitiv lohnen, schließlich kann man dann 3 oder maximal 4 GPUs mit einem Die fertigen und die Entwicklungskosten ungefähr auf 14nm Niveau halten.


Ich nehme nicht an, dass es einfach wird und weiß auch nicht wie die Kostensteigerung bei GPUs genau aussieht, also könnte Navi wie gesagt nur Vorbereitung mit aber schon deutlichen Einsparungen sein und AMD versucht sich mit CF zu retten bis das Ganze dann mit Interposern funktioniert.

[Hübie]

Du meinst also das Rasterizer, Tesselator, Scheduler, ACE usw linear mit skalieren? Das muss unter einander ja auch kommunizieren. Ist schon ne recht schwierige Ssche. Im Vorfeld muss es ja dann so etwas wie einen Arbiter geben...

[Rabiata]

Wenn ich mich richtig erinnere, rechnet man bei SoCs mit etwa Faktor 2 Kostensteigerung fürs Design. Ohne EUV hat man halt Spaß mit Quadruple Patterning und ähnlichen Spielereien, mit EUV darf man momentan ein Vielfaches pro Wafer berappen.
Also 14nm doppelt so viel wie 28nm, 10nm dann 4 mal, 7nm 8 mal und so weiter. Ein 45nm passiver Interposer ist dagegen einfach spottbillig. Also solange man es zum laufen bringen kann, wird sich das definitiv lohnen, schließlich kann man dann 3 oder maximal 4 GPUs mit einem Die fertigen und die Entwicklungskosten ungefähr auf 14nm Niveau halten.


Ich nehme nicht an, dass es einfach wird und weiß auch nicht wie die Kostensteigerung bei GPUs genau aussieht, also könnte Navi wie gesagt nur Vorbereitung mit aber schon deutlichen Einsparungen sein und AMD versucht sich mit CF zu retten bis das Ganze dann mit Interposern funktioniert.
Die 45nm für den Interposer sind vielleicht noch nicht mal nötig, es könnte noch größer und billiger gehen. Was ich so auf die Schnelle bei Google finde (z.B. Tsuto et al (http://www.jiep.or.jp/hp_e/journal/6/transaction6_1_13-17.pdf)), redet von einem Contact Pitch für die TSVs im Bereich 2µm oder mehr.

Und wenn die Kontakte für die TSVs schon solche Mindestabstände brauchen, dann könnte ich mir auch vorstellen, daß 0,5µm für die Leiterbahnen auf dem Interposer den Kohl nicht mehr fett machen. Das ginge dann mit Fertigungstechnik von vor 10 Jahren :wink:.

[Complicated]

Gibt es denn irgendwo Materialen die einem erklären, wie die sinnvolle Zusammenarbeit bei einem Skalierbaren Design mit mehreren Chips funktionieren soll, ohne die üblichen Probleme? Also mir ist da nichts bekannt, eher ist man doch von dem Zug schon lange abgesprungen.
Also irgendwie befindest du dich da im Nirwana mit deinem Kenntnisstand:
http://www.planet3dnow.de/vbulletin/threads/422600-AMD-Interposer-Strategie-Zen-Fiji-HBM-und-Logic-ICs
http://www.amd.com/Documents/AMD-Research-Report-2014-1776.pdf
https://tspace.library.utoronto.ca/bitstream/1807/70378/3/Kannan_Ajaykumar_201511_MAS_thesis.pdf


Wenn man Koduris Aussagen bei Capsaicin jetzt für Bare Münze nimmt und an das Interposer Ding bei Navi glauben möchte, dann spricht er erstmal nur von Dual GPU´s mit kleineren bzw. midrange Chips um keinen großen zu produzieren, ein zu großes Risiko einzugehen und so wahrscheinlich Kosten zu sparen. Das wäre natürlich von einer Skalierbarkeit weit entfernt.
Warum ist das von Skalierbarkeit weit entfernt? Verstehst du den Begriff nicht?

[Complicated]

Wenn ich mich richtig erinnere, rechnet man bei SoCs mit etwa Faktor 2 Kostensteigerung fürs Design. Ohne EUV hat man halt Spaß mit Quadruple Patterning und ähnlichen Spielereien, mit EUV darf man momentan ein Vielfaches pro Wafer berappen.
Also 14nm doppelt so viel wie 28nm, 10nm dann 4 mal, 7nm 8 mal und so weiter.
Hier hat ja GF den 12FDX und folgend den 7FDX Prozess die kein EUV nutzen (https://www.computerbase.de/2016-09/globalfoundries-12-nm-fd-soi/), dafür aber SOI. Was Ihnen 10% weniger Masken einbringt und dadurch genug Durchläufe beim Patterning einspart um deutlich kostengünstiger zu sein als EUV basierte 7nm und damit auch früher den Markt bedienen zu können.
http://www.planet3dnow.de/vbulletin/threads/412508-Prognose-Board-Wie-geht-es-bei-AMD-weiter-Entwicklungen-Strategien-Massnahmen-die-AMD-betreffen-bzw-die-AMD-treffen-koennte?p=5115036&viewfull=1#post5115036
AMD hat sich mit dem WSA ziemlich deutlich ausgerichtet die 7nm direkt anzuvisieren und mit GF gemeinsam hier einen Vorsprung rauszuarbeiten.
Also Designkosten für einen Soc:
28nm: $ 30 Mio.
14nm: $ 80 Mio.
10nm: $ 192 Mio.
7nm: $ 271 Mio.

Hier kommen ja nun die Produktionskosten dazu. Und wenn man hier auch ohne EUV schon etwas bieten kann in 7nm, dann könnte man tatsächlich an den anderen vorbeiziehen die für 7nm EUV vorsehen. EUV verzögert sich ja schon länger.
GF will klar vor EUV Markteinführung die 7nm in den Markt bringen, während sie ebenfalls 7 nm EUV für 2020 anvisieren mit hohen Forschungsinvestitionen.
http://www.electronicsweekly.com/blogs/mannerisms/manufacturing-mannerisms/glofo-looks-for-7nm-leadership-2016-05/
GLoFo’s 7nm process is so aggressive that, says Patton, it will deliver lower wafer cost even if EUV is delayed and they have to use multiple patterning. Patton reckons that EUV will be used in production in 2020 with “small usage in the 2018/19 timeframe.”

http://www.globalfoundries.com/newsroom/press-releases/2016/02/09/suny-poly-and-globalfoundries-announce-new-$500m-r-d-program-in-albany-to-accelerate-next-generation-chip-technology
In support of Governor Andrew M. Cuomo’s commitment to maintaining New York State’s global leadership in nanotechnology research and development, SUNY Polytechnic Institute (SUNY Poly) and GLOBALFOUNDRIES today announced the establishment of a new Advanced Patterning and Productivity Center (APPC), which will be located at the Colleges of Nanoscale Science and Engineering (CNSE) in Albany, N.Y. The $500 million, 5-year program will accelerate the introduction of Extreme Ultraviolet (EUV) lithography technologies into manufacturing. The center is anchored by a network of international chipmakers and material and equipment suppliers, including IBM and Tokyo Electron, and will generate 100 jobs.

[Setsul]

@Hübie: Meine grundlegende Idee war, dass man anstatt die SEs immer zu verändern lieber nur die Anzahl ändert. Je größer die CU Gruppen sind (2-4) und je mehr Gruppen es sind, desto größere Probleme bekommt man bei der Auslastung. Siehe Tonga das kam mir einfach nicht so glorreich vor und ich nehme an die 4er Gruppen hatten damit auch etwas zu tun und besonders dann Fiji mit 4 Gruppen pro SE.

Zum Beispiel bilden eben 1 oder 2 SE und dann entsprechend 2 oder 4 ACEs usw. einen Block und dann baut man sich aus 1, 2, 4 oder 8 Blöcken eine GPU. Ewig drücken kann man sich sowieso nicht, 4 SEs werden bald nicht mehr reichen.
Also man opfert dann z.B. 20% Leistung pro CU weil Kommunikation minimiert werden muss, aber dafür skaliert die doppelte Konfiguration dann fast linear und man hätte sowieso 20% verloren (siehe Fiji) und darüber hinaus gewinnt man. Spart auch Designkosten, solange man keine Interposer verwendet, mit IPs spart man sich dann eben einen ganzen Haufen Dies.
Bei dem Beispiel werden dann die kleinsten GPUs 20% teurer für die gleiche Leistung, aber die gesparten Kosten bei den Großen tragen das mit.

Ist natürlich alles Spekulatius.

@Rabiata: Der Fiji Interposer war 45nm UMC, glaube ich. Die Dinger sind ja deshalb so billig, weil man nur die oberen (3-5 oder so) Metallayers verwendet. Pi mal Daumen 1/3 Pitch (=Node Name) x4 = M1 Pitch, die oberen Layers dann nochmal mindestens doppelt so breit und vield dicker, da kommt man schon auf 0,5µm. Ich nehme mal an AMD wird Gründe gehabt haben, oder ich erinnere mich einfach falsch.

@Complicated: Keine Ahnung was EUV momentan kostet. Mein letzter Stand war ungefähr 3x. Letztendlich ist es eine Entscheidung der Foundry, machen wir 193i+193i SAQP (TSMC hat glaube ich sogar schon Patente in die Richtung) oder machen wir 193i+EUV. SAQP und andere Spielereien treiben die Entwicklungskosten hoch, EUV treibt die Waferkosten hoch.

[HOT]

Grad gefunden:
http://arstechnica.com/gadgets/2016/08/hbm3-details-price-bandwidth/
Technik größtenteils gleich, deutlich kleinere Fertigungsprozesse.

[vinacis_vivids]

Gibs schon irgendwo Tflops Schätzung?
MI25 = 12,5 Tflops
Dazwischen gibs ein refresh V20 ~ 15-20 Tflops
Navi ~ 30-50 Tflops​? 64GB HBM3?

[Hübie]

Normale Steigerungen bewegen sich im Raum von 30-40%. Nun kannst du dir was zusammen reimen. Ist der Sprung mal deutlich grösser nimmt er in darauf folgenden Jahren mehr ab. Aus Interesse könnte man dies tatsächlich mal nachrechnen und Mitteln.

[Leonidas]

Also zwischen 14nm und 7nm ist ja ein fetter Sprung. -60% bis -65% beim Flächenbedarf. Da sollte locker das Doppelte drin sein.

[AffenJack]

Also zwischen 14nm und 7nm ist ja ein fetter Sprung. -60% bis -65% beim Flächenbedarf. Da sollte locker das Doppelte drin sein.

Du vergisst allerdings, dass der große Sprung nur bei der Fläche da ist. 7nm vs 14nm ist bei der Power/Performance ein kleinerer Sprung als 14/16nm vs 28nm. Da hattest du 50% Area Reduction und mehr als 50% Power Reduction, weshalb die taktraten hoch gingen. Da bei 7nm der Flächenvorteil aber größer ist, werden wir wahrscheinlich sinkende Taktraten sehen, da die W/mm² sonst stark ansteigen und die Dinger nicht mehr kühlbar werden. Das könnte allerdings viel Spielraum für Übertakter einräumen, denen die TDPs eh egal sind. Dazu ist 7nm tierisch teuer, so dass die Die Sizes für die verschiedenen Segmente wohl deutlich nach unten gehen werden (und es noch mehr dämlich Gemecker gibt von wegen der Chip ist zu klein für die Marktpositionierung und Abzocke) .

[HOT]

GloFo gibt 30% mehr Power an (Vega könnte also anstatt auf 1,6GHz auf 2,1GHz betrieben werden beispielsweise) und 60% Stromersparnis bei 7nm DUV (also nicht EUV), aber nur 50% Flächenreduktion verglichen zu 14LPP. Das ist, wie alle 7nm-Prozesse, die nicht voll EUV sind, mehr so ein 7-10nm Hybrid.

http://www.anandtech.com/show/11337/samsung-and-tsmc-roadmaps-12-nm-8-nm-and-6-nm-added

Bei TSMC 7FF spart man beispielsweise mehr Fläche ein, allerdings kommt man ja von dem recht großen 16FF+, nicht dem kleineren 14LPP. Dürften etwa gleich sein, TSMC kommt wohl geringfügig kleiner, dafür später. Wie bei 20SoC belässt man es bei TSMC anscheinend bei 10FF ohne +. Lohnt ja auch nicht die Weiterentwicklung. 10nm ist bei denen also auch eher Stiefkind.

[vinacis_vivids]

Also zwischen 14nm und 7nm ist ja ein fetter Sprung. -60% bis -65% beim Flächenbedarf. Da sollte locker das Doppelte drin sein.

HD4870, 1200 Gflops, 55nm
HD5870, 2700 Gflops, 40nm

Zwar schon ne Weile her, aber das war ein Quantensprung.

[ndrs]

HD4870, 1200 Gflops, 55nm, ~250mm^2
HD5870, 2700 Gflops, 40nm, ~330mm^2
Nur ein paar schnell ergoogelte Werte (und eventuell nicht exakte) eingefügt. Schon sieht man, dass der Quantensprung doch keiner mehr war.

[robbitop]

Der Quantensprung war eher RV670 -> RV770. ;)
2,5x so viel arithemetische Ausführungseinheiten

[w0mbat]

Der Quantensprung war eher RV670 -> RV770. ;)
2,5x so viel arithemetische Ausführungseinheiten

Jupp, kann mich noch genau erinnern, als alle von 480 SP bei der HD4870 ausgegangen sind und dann 800 SP kamen. Nvidia hat gleich mal seine GTX 260 und 280 um 100-200€ im Preis gesenkt :D

[vinacis_vivids]

Nur ein paar schnell ergoogelte Werte (und eventuell nicht exakte) eingefügt. Schon sieht man, dass der Quantensprung doch keiner mehr war.

DX11 im Jahre 2009! Selbst heute werden noch 90% der Spieletests auf dieser API gemacht.
Die ganzen Nvidianer haben sich damals für DX10 ausgesprochen, weil es ja nichts bringe. Das gleiche Spielchen wird heute mit DX12 betrieben.

Navi wird noch mehr low-level-API forcieren.

Egal, es war ein (letzter) Quantensprung, weil die Sprünge danach nur noch homöpatisch im Vergleich dazu war.

https://abload.de/img/amdflopsyskeu.png

[HOT]

Na ja, die Sprünge sind immer mit erhöhter Die-Fläche und steigener TDP erkauft worden. Allein von Geforce 7 auf 8, huiuiui. Aber eben auch von Radeon 8000 auf 9000 oder Geforce 4 auf FX, oder TNT auf Geforce usw. Seit einigen Jahren geht das nur nicht mehr so, weil mehr als 300W TDP extrem unpraktisch sind und Die Größen jenseits der 500mm² bleiben riskant. Hawaii war da die Spitze des Eisberges. Mehr wirds denke ich kaum werden. NV enwickelt ja schon seit Tesla 500mm² Dies, die sind seither auch konsequent größer geworden bei gleichbleibender TDP seit Fermi (maximal 250W). GV102 wird sicherlich auch wieder 600mm² haben und bei 250W liegen.

[basix]

Ist es nicht wahrscheinlich, dass AMD bei Navi ebenfalls auf eine Single-Die-for-all Strategie wie bei Ryzen wechselt? Wesentlich geringere R&D und Validierungskosten, die für Navi angekündigte "Scalability" sowie wesentlich mehr Flexibilität beim Produktdesign. Zudem wird Infinity Fabric von Vega schon unterstützt.

Meine Idee:
Vega20 wird praktisch 1zu1 von 14nm auf 7nm geshrinkt inkl. Navi Verbesserungen. Damit kann man alle Funktionalitäten abdecken (8bit, FP16, FP32, FP64, HBCC), evtl. aber nur 1x Stack HBM3 pro Die anstatt 2x Stacks. Bei 60% geringerer Fläche würde man bei ca. 200mm2 landen, also etwa bei Ryzen Grösse (welcher ja exzellente Yields hat). Um die Kosten niedrig zu halten, wird nicht mehr zwingend ein Si-Interposer benötigt, sondern man verwendet ein mehr oder minder normales Substrat (dazu gibt es schon die nötigen Technologiestudien). Für die einzelnen Marktsegmente verwendet man nun jeweils eine beliebige Anzahl Die, ich würde auf maximal 4 wie bei EPYC tendieren. Gegen aussen sieht es aber nach einer einzigen GPU aus. Damit wären also maximal 16k Shader möglich! Und weil man so viele davon hat, kann man auch eher am Sweet Spot takten. Am Sweet Spot sind Polaris und Vega dann auch wirklich Energieeffizient.

Schlussendlich muss AMD für alle Marktsegmente nur 3x verschiedene DIE auflegen: CPU, GPU, APU / Mobile. Will AMD eine Desktop APU mit z.B. 16C und 4k Shader machen: Einfach die 4x Die-Plätze beliebig konfigurieren, IF können ja alle "schwatzen".

[Pirx]

Bis dahin dürften technologisch noch viele Probleme zu lösen sein, das realisiert man nicht einfach mal so, weil es sich gut anhört.

[Relic]

Bis dahin dürften technologisch noch viele Probleme zu lösen sein, das realisiert man nicht einfach mal so, weil es sich gut anhört.

Naja sie scheinen ja schon ein paar Jahre daran zu forschen.

[Opprobrium]

Bis dahin dürften technologisch noch viele Probleme zu lösen sein, das realisiert man nicht einfach mal so, weil es sich gut anhört.


Naja sie scheinen ja schon ein paar Jahre daran zu forschen.

Eben, wenn man nur mal zurück an die 4000er Serie denkt, Stichwort "Small Die Strategy" (http://www.anandtech.com/show/2556/2). Da ging es ja, wenn ich mich recht erinnere, schon immer irgendwie darum, mehrere kleine Dice zusammenzupacken um gegen die monolithischen Riesencores anzukämpfen.

Und auch 3dfx hat ja ähnliches probiert.

Da die X2 Boards aber nie so toll waren, SLI/Crossfire jetzt auch faktisch tot zu sein scheint etc., ist die Idee das über Interposer zu lösen nicht abwegig. Im Endeffekt sind ja die verschiedenen Ausführungen einer GPU Genereation ja auch nicht wirklich etwas anderes: Gleiche Architektur, nur mit unterschiedlich vielen Recheineinten zusammengepackt, eventuell Speicherinterface entsprechend angepasst. Wenn man das über einen Interposer o.ä. vernünftig hinkriegt, warum nicht?

[Brillus]

Ist es nicht wahrscheinlich, dass AMD bei Navi ebenfalls auf eine Single-Die-for-all Strategie wie bei Ryzen wechselt? Wesentlich geringere R&D und Validierungskosten, die für Navi angekündigte "Scalability" sowie wesentlich mehr Flexibilität beim Produktdesign. Zudem wird Infinity Fabric von Vega schon unterstützt.

Meine Idee:
Vega20 wird praktisch 1zu1 von 14nm auf 7nm geshrinkt inkl. Navi Verbesserungen. Damit kann man alle Funktionalitäten abdecken (8bit, FP16, FP32, FP64, HBCC), evtl. aber nur 1x Stack HBM3 pro Die anstatt 2x Stacks. Bei 60% geringerer Fläche würde man bei ca. 200mm2 landen, also etwa bei Ryzen Grösse (welcher ja exzellente Yields hat). Um die Kosten niedrig zu halten, wird nicht mehr zwingend ein Si-Interposer benötigt, sondern man verwendet ein mehr oder minder normales Substrat (dazu gibt es schon die nötigen Technologiestudien). Für die einzelnen Marktsegmente verwendet man nun jeweils eine beliebige Anzahl Die, ich würde auf maximal 4 wie bei EPYC tendieren. Gegen aussen sieht es aber nach einer einzigen GPU aus. Damit wären also maximal 16k Shader möglich! Und weil man so viele davon hat, kann man auch eher am Sweet Spot takten. Am Sweet Spot sind Polaris und Vega dann auch wirklich Energieeffizient.

Schlussendlich muss AMD für alle Marktsegmente nur 3x verschiedene DIE auflegen: CPU, GPU, APU / Mobile. Will AMD eine Desktop APU mit z.B. 16C und 4k Shader machen: Einfach die 4x Die-Plätze beliebig konfigurieren, IF können ja alle "schwatzen".

Wenn man sowieso interposer hat kann es auch in die andere Richtung gehen. Aktiver Interposer mit uncore Zeugs und Interfaces. Interface Treiber lassen sich schlecht schrinken und warum soll man das PCIe-Interface etc. 2 oder 4 mal mitschleppen auf teurem Silizium wenn mans auch in billigem Interposer-prozese haben kann.

[AffenJack]

Meine Idee:
Vega20 wird praktisch 1zu1 von 14nm auf 7nm geshrinkt inkl. Navi Verbesserungen. Damit kann man alle Funktionalitäten abdecken (8bit, FP16, FP32, FP64, HBCC), evtl. aber nur 1x Stack HBM3 pro Die anstatt 2x Stacks. Bei 60% geringerer Fläche würde man bei ca. 200mm2 landen, also etwa bei Ryzen Grösse (welcher ja exzellente Yields hat). Um die Kosten niedrig zu halten, wird nicht mehr zwingend ein Si-Interposer benötigt, sondern man verwendet ein mehr oder minder normales Substrat (dazu gibt es schon die nötigen Technologiestudien). Für die einzelnen Marktsegmente verwendet man nun jeweils eine beliebige Anzahl Die, ich würde auf maximal 4 wie bei EPYC tendieren. Gegen aussen sieht es aber nach einer einzigen GPU aus. Damit wären also maximal 16k Shader möglich! Und weil man so viele davon hat, kann man auch eher am Sweet Spot takten. Am Sweet Spot sind Polaris und Vega dann auch wirklich Energieeffizient.

Schlussendlich muss AMD für alle Marktsegmente nur 3x verschiedene DIE auflegen: CPU, GPU, APU / Mobile. Will AMD eine Desktop APU mit z.B. 16C und 4k Shader machen: Einfach die 4x Die-Plätze beliebig konfigurieren, IF können ja alle "schwatzen".

Alles abdecken mit Features ist schön, aber bei GPUs eher viel zu teuer und Stromverbrauchsintensiv. Einen kleinen Die schon mit 1/2DP zu haben führt eher dazu, dass du z.B. im Notebooksegment, wo es auf jedes Stück Verbrauch ankommt weiter nicht gegen Nv wirst konkurieren können. Dabei wäre gerade da auch mal wieder mehr Konkurrenz nötig. Ich preferiere deshalb die Version 1 Small Die + 2xSmall in der Einstiegsklasse, Dann darüber ein größerer Chip und dieser verdoppelt als High-End/HPC...

[BoMbY]

Ich denke das Patent könnte für Navi relevant sein: Interposer having a Pattern of Sites for Mounting Chiplets (https://patents.google.com/patent/US20170200672A1/en).

http://i.imgur.com/RbbeiURh.png

Also ein flexibel einsetzbarer Interposer, der auch aktive Elemente enthalten kann. Könnte man natürlich auch für APUs nutzen. Jedenfalls wäre eine ähnliche Strategie wie bei Ryzen/Threatripper/Epyc für GPUs sicher nicht schlecht.

[basix]

Alles abdecken mit Features ist schön, aber bei GPUs eher viel zu teuer und Stromverbrauchsintensiv. Einen kleinen Die schon mit 1/2DP zu haben führt eher dazu, dass du z.B. im Notebooksegment, wo es auf jedes Stück Verbrauch ankommt weiter nicht gegen Nv wirst konkurieren können. Dabei wäre gerade da auch mal wieder mehr Konkurrenz nötig. Ich preferiere deshalb die Version 1 Small Die + 2xSmall in der Einstiegsklasse, Dann darüber ein größerer Chip und dieser verdoppelt als High-End/HPC...

Das ist richtig. Deshalb schlage ich auch ein separates APU / Mobile Die vor mit einem CCX zwingend FP64 mit Half-Rate unterstützen. Bei Mobile ist der Footprint ebenfalls entscheidend und dort sind mehrere Die einfach grösser als ein einzelnes. Zudem wird man Mobile auch eher nicht auf 4k Shader gehen, sondern eher auf max. 2k und wahrscheinlich auch ohne HBM.

Obwohl: Eine APU mit 1x CCX, 1x 2k Shader GPU-Block und 1x 16GB HBM3 Stack wäre vom gesamten Footprint her sehr klein, da man unter Umständen keine DIMMs mehr braucht. Für ein sehr dünnes und kleines Notebook wäre dies sehr kompakt.

Edit @ Bomby:
Das würde meine Idee natürlich auf die Spitze treiben. PCIe Interface, Display Engine etc. benötigt man ja nur 1x. Vielleicht kann ich ja präzisieren: 1x Die = Shader Array + 1x Speicherinterface + alles was mit der Anzahl Shader mitwachsen soll. Ein weiteres Die = PCIe + Display Engine + XX. Das letztgenannte Die könnte man auch bei einer neuen Shader-Generation beibehalten, wenn kein Update benötigt wird. Nvidia hatte ja auch schon solche Sachen ausgelagert mit ihrem NVIO-Chip.

[Opprobrium]

Ist zwar jetzt nicht mehr strikt Navi Spekluation, aber AMD bewegt sich doch genau dahin mit ihrer Strategie die letzten Jahre (Small Die, SemiCustom etc.)

Irgendwann haben die einen Interposer auf den man dann -salopp gesagt- nach Belieben CPUs, GPUs etc. draufklatschen kann.

APU mit viel GPU Power aber wenig CPU? Kein Problem

Starke CPU mit rudimentären Grafikfunktionen? Logo

Natürlich kämen beim Konsumenten trotzdem nur ein paar Variationen an die gut ausbalanciert sind, aber für Großkunden sehr attraktiv. Und je einfach AMD ihre Custom Designs herstellen kann, desto besser. Vor allem, wenn nicht für jedes ein eigener Chip hergestellt werden muss, sondern nur die Chipzusammenstellung variiert.

[basix]

Und je einfach AMD ihre Custom Designs herstellen kann, desto besser. Vor allem, wenn nicht für jedes ein eigener Chip hergestellt werden muss, sondern nur die Chipzusammenstellung variiert.

Genau so ist es. Speziell wenn man ein begrenztes R&D Budget hat.

[AlterSack]

Wäre es sinnvoll/möglich, nur die 3D-Funktionseinheiten
in 7nm und den 2D-Teil, sowie die Speichercontroller
in einem extra Die mit 14nm-Strukturen herzustellen, auf den die
3D-Einheiten draufgepackt werden? Das ganze sitzt dann auf dem Interposer.
...könnte man z.B. ein bis vier 7nm-Dies a 150mm² mit vllt. 24-96 CUs
erreichen und bis zu 4 HBM2-Stapel auf dem Interposer unterbringen.
Ist es sinnvoll möglich die Speichercontroller von den CUs zu trennen?

[Brillus]

Wäre es sinnvoll/möglich, nur die 3D-Funktionseinheiten
in 7nm und den 2D-Teil, sowie die Speichercontroller
in einem extra Die mit 14nm-Strukturen herzustellen, auf den die
3D-Einheiten draufgepackt werden? Das ganze sitzt dann auf dem Interposer.
...könnte man z.B. ein bis vier 7nm-Dies a 150mm² mit vllt. 24-96 CUs
erreichen und bis zu 4 HBM2-Stapel auf dem Interposer unterbringen.
Ist es sinnvoll möglich die Speichercontroller von den CUs zu trennen?

Wie schon oben geschrieben würde ich den Teil sogar auf dem interposer erwarten, modulo Speicherinterface. Oder man macht was infinity factory mäßiges als unified Speichercontroller und dann kann man auf dem interposer entscheiden ob gddr hbm oder what else.

[G3cko]

Ich würde eher vermuten man erstellt kleine Blöcke inkl HBM. Sowie bei EPYC wo jeder DIE ein dualchannel-SI hat und in Summe wird dann daraus ein 8-channel Interface. Hatte den Vorteil, dass die Rechenleistung, speicherbandbreite und speichermenge immer linear mit den Blöcken mitskaliert. Man benötigt auch nur einen Block für alle Grafikkarten Varianten. = Bessere yield. 4 Blöcke = Highend. 1 Block = Einsteiger Karte.

[AlterSack]

Wie schon oben geschrieben würde ich den Teil sogar auf dem interposer erwarten, modulo Speicherinterface. Oder man macht was infinity factory mäßiges als unified Speichercontroller und dann kann man auf dem interposer entscheiden ob gddr hbm oder what else.

Das fände ich sehr flexibel. ...und für verschiedene Ausbaustufen verschieden grosse Interposer, während man nur ein Die für alle benötigt.

[davidzo]

Ich würde eher vermuten man erstellt kleine Blöcke inkl HBM. Sowie bei EPYC wo jeder DIE ein dualchannel-SI hat und in Summe wird dann daraus ein 8-channel Interface. Hatte den Vorteil, dass die Rechenleistung, speicherbandbreite und speichermenge immer linear mit den Blöcken mitskaliert. Man benötigt auch nur einen Block für alle Grafikkarten Varianten. = Bessere yield. 4 Blöcke = Highend. 1 Block = Einsteiger Karte.

Glaube ich auch eher. Erinnert mich wehmütig an den VSA-100 :biggrin:

Wenn man SI und GPU auf verschiedenen DIEs hat kostet das nur Speicherbandbreite und Latenzen gegenüber On-die. Da verschiedene Prozesse zu nutzen macht keinen Sinn da im low-end und mainstream alleine das packaging schon teurer wäre als momentan der monolitische chip kostet.

[basix]

Alles was mit der Anzahl Shader anwachsen soll, soll auch auf dem selben Die landen. Und das ist das SI, die TMUs, Cache usw. Das wäre für mich am logischsten.

[Skysnake]

Zumal es meiner Meinung nach wenig Sinn macht ein HBM Interface auf einen extra die zu packen. Da wird man wohl nicht wirklich etwas sparen. Man braucht ja dann trotzdem die PHYs zwischen SI die und GPU die.

[reaperrr]

Möglich wäre auch noch ein Zwischending:
Den Grafik-Berechnungsteil ähnlich wie bei den Zen-CCX in einen 'Slice' packen, und dann die Inter-Slice-Kommunikation über (sehr) breite IF-Verbindungen durchführen.

Ich habe jedenfalls meine Zweifel, ob sich Naples-artige MCMs bei GPUs ohne zu viel Redundanz und/oder zu hohe Latenz-Strafen umsetzen lassen, das stelle ich mir in Hinblick auf Frametimes selbst über eine breite, kurze IF-Anbindung schwierig vor.
Könnte aber sein, dass AMD zumindest für das Enthusiast-Modell zwei Chips des Performance-Chips als MCM verwendet, weil speziell die Yield-Rate in neueren/komplexeren Prozessen für die großen Chips oft ein Problem darstellt, von den benötigten Chip-Design-Ressourcen und Masken mal ganz abgesehen.
Vermutlich ließen sich so auch mehr Ausführungseinheiten auf einem MCM unterbringen, als man vernünftigerweise auf einen einzelnen Die packen würde (z.B. 2x64CUs statt 1x96, womit man auch Performance-Verluste durch IF-Latenzen teilweise oder gar mehr als kompensieren könnte, solange man 99th percentile und MinFPS im Griff hat).

An den "1 Chip Mainstream, 2 Chips Performance, 4 Chips HighEnd"-Ansatz glaube ich noch nicht so recht.

Der schwammige Stichpunkt "Scalability", den AMD auf den Roadmaps für Navi genannt hatte kann sich auch einfach auf eine Überarbeitung der Architektur dahingehend beziehen, dass endlich mehr als 4 Shader-Engines und asymmetrischere CU-Zahlen möglich werden, Nvidia steht hier mit seinen GPCs und SMs aktuell besser da.

[basix]

An den "1 Chip Mainstream, 2 Chips Performance, 4 Chips HighEnd"-Ansatz glaube ich noch nicht so recht.

Ryzen, Threadripper und EPYC machen genau das vor ;)

[Complicated]

Also GPUs können Latenzen deutlich besser kaschieren als CPUs. Das schwierige ist, dass man die GPU-Cluster am selben Frame arbeiten lassen muss um eben die Microruckler wie bei CF/SLI zu vermeiden. SFR wie bei Civ VI hat diese Probleme nicht. Es wäre möglich, dass einfach die Software/API bis Navi soweit ist.

[basix]

Muss es wirklich SFR etc. sein? z.B. Vega 10 hat auch 4x Rasterizer, welche gleichzeitig laufen.

[Brillus]

Zumal es meiner Meinung nach wenig Sinn macht ein HBM Interface auf einen extra die zu packen. Da wird man wohl nicht wirklich etwas sparen. Man braucht ja dann trotzdem die PHYs zwischen SI die und GPU die.

Das man sich auf dem Die nicht viel spart im Vergleich zu HBM ist mir klar, meine Idee ging in eine etwas andere Richtung. Der Interposer muss ja mindestens die Größe des Dies haben, somit hat man wohl etwas Platz for free. Damit bekommt man aber bei einem Die mehr Freiheit ob man billigen GDDR speicher oder teuren HBM speicher verbauen will, oder etwas weiter gedacht in in eine APU bauen und das CPU speicherinterface verwenden. Auserdem wie ich es verstanden habe spart HBM im Vergleich zu GDDR ja Platz, die Ersparniss könnte man in den kleinen mitholen.

Die Frage ist halt lohnt sich der Interposer für die Ersparniss bzw. die Ersparniss in eigener Maske wo die kleinen insbesondere das größte Volumen haben, bzw. man sowieso einen 1:2 DP und einen 1:16(?) Chip haben will.

EDIT: @Basix soweit ich es verstanden haben liegt das Problem darin, das hinter den Rasterizern ein Load-Balancing nötig ist, das wohl viel Bandbreite (im Vergleich zum Memory-bandbreite) benötigt.

[Skysnake]

Es ist egal ob du dir da Flexibilität erkaufst oder nicht. Das Endresultat wäre viel zu ineffizient. Da kann man es auch gleich lassen.

[cat]

MCM sind flexibler, richtig, haben aber auf inter Die-Latenz und ich bezweifle ob wir in näherer ZeitMCM Grafiklösungen sehen werden,
AMD wird Gründe haben bei Vega nicht einfach 2x 2048 Cores + HBM2 auf den sowieso schon vorhandenen Interposer zu "klatschen".

Bei der Gelegenheit könnte man auch 1x Zeppelin mit 2048 Cores + 16GB/24GB HBM2 paaren, ist aber wohl zu teuer oder so, wäre eine PS4pro auf Steroiden als SOC+Graphic-on-MCM.

Viel interessanter finde ich die Frage: "Welche Dies werden gebaut?"
Weil das deutlich unflexibler ist aber trotzdem auf der Infinity-Fabric beruht, z.B: 1xCCX + 11CU (704 Cores) soll RavenRidge sein, quasi 11CU statt der weitern 4 Kerne zum Zeppelin-Die.

Die Entscheidung das Zeppelin-Die und RavenRidge-Die nur bis zu gewählter Größe zu bauen wird auch für die Die-Größen von Navi bzw. dessen APU gelten, allerdings dann in 7nm deutlich mehr Transistoren/Kerne etc. fassen können.
Bei einer 7nm APU deren CCX bei 4 Kernen bleibt, und somit stark in der Größe schrumpft, sollten spätesten bei 40%-Shrink 16 NCU danaben passen, und das im selben Die versteht sich.
Ob dann die SpeicherController des GPU-Teils zum HBM3 vom Interposer aber der CPU-Teil über den Sockel zu den DDR-DIMMs spricht wird man sehen, möglich ist da viel.

Navi wird das von AMD (ich glaub es war CTO Mark Papermaster im oft falsch verstandenen Interview) erwähnte Quad-Patterning ohne EUV 7nm Verfahren verwenden.
Im Interview wird EUV nur erwähnt und gesagt, dass AMD sich davon verspricht viel weniger Masken und somit Arbeitsschritte zu benötigen und EUV bitte schnellstmöglich Marktreife erlangen soll.

[Complicated]

Die Latenz ist bei GPUs ein viel geringeres Problem als bei CPUs. GPUs müssen sowieso viel höhere Latenzen kaschieren. Je mehr Durchsatz bei parallelen Workloads so eine GPU bringt, desto höher wird auch die Latenz. Zudem sind ja GPU-MCMs ein alter Hut, sprich Dual-GPUs. Nur die Anbindung war noch nie so eng und so schnell möglich wie jetzt.

[cat]

Da hast du mit dem Verstecken der Latenz durch Parallelität natürlich recht, genau das macht eine moderne GPU ja aus.
Ich wollte eher auf die Geschwindigkeit der Synchonisation zwischen den Dies hinaus.

Als vernünftige MCM-GPU bezeichne ich natürlich nur Lösungen die komplett ruckelfrei arbeiten und ich meine nicht die üblichen FPS.
Die Not zur Verwendung von Alternate-Frame-Rendering oder Split-Frame-Rendering sollte komplett unnötig sein, wenn möglich sollte die Synchonisierung zwischen den L2-Caches der Dies spätesten abgeschlossen sein.
Welches Die dann zum Bildschirm telefoniert ist dann auch egal weil es von einem Die alleine gemacht wird = keine Mikroruckler.

Eine MCM-GPU bekommt wahrscheinlich Probleme weil die Command-Prozessoren, ACE, HWS, Global-Data-Share, L2-Cache etc. alles wie eine große GPU laufen müssten.
Da sind teilweise mehrere Terabytes pro Sekunde unterwegs, da müsste sehr viel synchonisiert werden, keinen Schimmer ob schon der bloße Gedanke an eine echte MCM-GPU als Utopie zu sehen ist.

[Dino-Fossil]

Ich denke, dass da auf jeden Fall noch einige Unwägbarkeiten sind.
Sicherlich sollte so eine GPU sich deutlich von allem Unterscheiden, was wir bisher als SLI/Crossfire oder auch (DX12) mGPU haben.

Im optimalen Fall sollte sich so ein GPU-Komplex dem System als eine monolithische GPU präsentieren und auch entsprechend (oder wenigstens annähernd) performen.
Je mehr softwareseitige Anpassungen nötig werden um so eine GPU gut auslasten zu können, desto schwieriger wird sich das Konzept wohl durchsetzen.

[HOT]

Also GPUs können Latenzen deutlich besser kaschieren als CPUs. Das schwierige ist, dass man die GPU-Cluster am selben Frame arbeiten lassen muss um eben die Microruckler wie bei CF/SLI zu vermeiden. SFR wie bei Civ VI hat diese Probleme nicht. Es wäre möglich, dass einfach die Software/API bis Navi soweit ist.

Die Kunst wird hier ja wohl sein, dass man das Teil wie eine GPU abbilden kann, sonst würde der ganze Ansatz wohl wenig Sinn ergeben.
Du kannst 4 Chips über GMI(2?) koppeln und einen weiteren Chip für die Displayengine und Videoprozessor extern halten. Anders macht die ganze Geschichte für mich keinen Sinn. Dann brauchst du auch noch 2 verschiedene Größen, einen mit 200mm² und einen mit 100mm². Der Größere hat halt einen HBM (3. Generation?)-Stack und der kleinere einen billig-HBM-Stack mit halber Bandbreite. Daraus kann man dann ein ganzes Portfolio erzeugen.

Seh ich das richtig, dass im Multichipansatz vor allem ein großes Problem existiert und das ist der Rasterizer?

[unl34shed]

Könnte mir auch 2048 Shader + 1 HBM stack auf einem Interposer vorstellen und davon dann bis zu 3 neben einander. Damit könnte man den kompletten Grafikmarkt mit einem Chip abdecken. Evtl sehen wir dann auch 2 Varianten, eine für Gamer und eine für Pros.

Sehe da aber noch ein anderes Problem. Die Verbindung zwischen den Chips. Wenn wir uns Threadripper oder Epic anschauen, bräuchte man wohl 250GB/s zwischen den Chips um keine Nachteile zu haben.
Ob das so einfach möglich ist? Und wie viel Platz das unter den Clustern braucht...

[basix]

AMD erwähnt bei EPYC ca. 2pJ/bit über IF bei Die-to-Die Interconnects. Bei gleichen Interconnect-Taktraten entspricht 1W also 62.5GB/s. So ein 250GB/s Interconnect wäre also denkbar bei ca. 4W. Nimmt man den EPYC Aufbau für 4x Die benötigt man total 6x Links und man wäre bei ca. 25W. Will man es bidrektional (was es sinnvollerweise sein sollte) landet man bei 50W. Das ist aus meiner Sicht machbar auch wenn doch ein ziemlicher Brocken der TDP, wären ca. 20% TDP einer High End Karte. Die Karte an sich benötigt aber nicht mal unbedingt mehr Strom als mit einem monolithischen Die, da man auch sonst die Daten hin und her schieben müsste. On-Die sollte aber tendenzeill schon sparsamer sein. Mit einzelnen kleinen Die gewinnt man auf der anderen Seite aber evtl. wieder was, keine Ahnung. Die Lösung an sich wäre relativ sexy, da man nun einen gemeinsamen Speicherpool mit mehr oder minder voller Bandbreite zu jedem Chip zur Verfügung hätte.

Das ganze würde am Schluss aber nicht sehr gut nach oben skalieren mit stärkeren Chips / schnellerem HBM, ausser es gibt eine sparsamere IF Gen2 oder die Bandbreiten müssen nicht zwingend so hoch sein.

Noch ein Hinweis: IF ist laut AMD auf max. 512GB/s ausgelegt (Vega).

@ SFR:
Wie schwierig ist ein HW SFR? Ich nehme an, eine heutige GPU mit mehreren Rasterizern funktioniert schon so? Wie gross ist hier der Synchronisationsaufwand / Bandbreitenaufwand?

[Der_Korken]

AMD erwähnt bei EPYC ca. 2pJ/bit über IF bei Die-to-Die Interconnects. Bei gleichen Interconnect-Taktraten entspricht 1W also 62.5GB/s. So ein 250GB/s Interconnect wäre also denkbar bei ca. 4W. Nimmt man den EPYC Aufbau für 4x Die benötigt man total 6x Links und man wäre bei ca. 25W. Will man es bidrektional (was es sinnvollerweise sein sollte) landet man bei 50W.

Wird es über einen Interposer eventuell nochmal sparsamer? Die Dies sind viel dichter zusammen als bei EPYC und man bekommt extrem breite Verbindungen hin. HBM2 schafft ja auch 500GB/s und verbraucht ganz sicher keine 50W oder gar 100W nur für die Übertragung der Daten (exklusive des Verbrauchs der DRAM-Chips). Ist natürlich per Interposer wieder etwas teurer.

[Skysnake]

Ja man bekäme das sparsamer. Daher war ich auch ernsthaft überrascht, dass man auf ein normales organisches Package setzt bei EPYC.

Alternativ zum Interposer könnte man auch ein keramisches Package verwenden.

In Anbetracht von HBM und APUs wäre ein Interposer aber wohl geschickter.

Keine Ahnung warum die das nicht gemacht haben.

[basix]

Ich glaube HBM2 sollte bei ca. 25-30W liegen für 500GB/s (Vega ein wenig mehr da anscheinend erhöhte Spannungen benötigt werden). Wirklich sparsamer ist das nicht, weil 6x Links @ 250GB/s + bidirektional total 3TB/s an Daten umherschaufeln können. Aber IF @ Interposer sollte eigentlich weniger Energie benötigen und man kann es breiter machen und somit niedrigere Taktraten verwenden. Wie du sagst wird es dann halt teurer.

@ Skysnake: Der Interposer wäre verdammt gross geworden und die Yields schlechter. Solange man es technisch nicht benötigt, wird man es auch nicht verwenden.

[Skysnake]

Naja, man hätte auch einen zusätzlichen Metall layer nehmen können der jeweils 4 Dies miteinander verbindet. Aber dann hätten yield und pin density Probleme bekommen...

Also wenn dann wirklich nen Interposer. An sich sollte das auch nicht sooooo teuer sein. Das Package kostet ja auch was. Und wenn man effizienter ist kann man a7ch mehr absetzten und/oder mehr verlangen.

[Der_Korken]

Ich glaube HBM2 sollte bei ca. 25-30W liegen für 500GB/s (Vega ein wenig mehr da anscheinend erhöhte Spannungen benötigt werden). Wirklich sparsamer ist das nicht, weil 6x Links @ 250GB/s + bidirektional total 3TB/s an Daten umherschaufeln können. Aber IF @ Interposer sollte eigentlich weniger Energie benötigen und man kann es breiter machen und somit niedrigere Taktraten verwenden. Wie du sagst wird es dann halt teurer.

Sorry, habe irgendwie total überlesen, dass das schon der Verbrauch für 6 Links war. Das sieht natürlich gleich wesentlich besser aus, denn 3TB/s sollten erstmal mehr als reichen.

Wäre es eigentlich denkbar, eine µ-Architektur für eine GPU zu designen, dass im Betrieb die Kommunikation zwischen zwei Blöcken/Shader Engines/o.ä. möglichst gering ist? Im Gegensatz zu CPUs hat man über den Treiber mehr Möglichkeiten zu beeinflussen, was wo ausgeführt wird. Denn wenn man mal in die Zukunft denkt, wird die Kommunikation bei Multi-Die-Lösungen immer kritischer werden, weil die Dies selbst zwar durch die Fertigung immer sparsamer werden bzw. immer mehr Leistung bekommen, aber bei der Kommunikation stößt man dadurch, dass die Übertragungsdistanz nicht geringer wird, sicherlich an physikalische Grenzen.

[basix]

Und wenn man effizienter ist kann man auch mehr absetzten und/oder mehr verlangen.

Das ist völlig richtig. Nur sind es bei EPYC nur 42GB/s und nicht 250GB/s und somit gerade mal 8W für die 6x bidirektionalen Links. Da lohnt es sich bei 180W TDP einfach nicht, hier sagen wir mal 5W einzusparen.


@ Korken:
Wie du sehr richtig bemerkt hast, sind heutige Chipdesigns komplett Memorybound, d.h. die Performance wird durch den Energieverbrauch des Datenschaufelns begrenzt. Hier eine zigfach bessere Lösung zu finden (am besten mit möglichst geringem Bandbreitenbedarf) ist wohl der heilige Gral. AFR bei Crossfire stellt so eine Lösung dar, allerdings mit allen bekannten Problemen wie Latenz für den Spieler, Mikroruckeln etc.

Edit:
Ich habe nochmal ein wenig rumjongliert. Der Shrink auf GF 7nm soll >50% ausfallen, nehmen wir mal an ein Vega 10 kann von 484mm2 auf 200mm2 geshrinkt werden. GF 7nm soll zudem >60% Stromverbrauchsreduktion bringen oder >2.5x höhere Effizienz. Ob TSMC oder GF spielt mal keine Rolle. Nun fehlen noch ca. Faktor 1.5x an Effizienz, um 4 Stk. Navi + 4 Stacks HBM3 im selben Power Budget wie Vega unterzubringen. Weitere Architekturverbesserungen können nochmals 20% bringen. Sweet Spot Taktraten @ z.B. 1.5GHz die anderen 30%. Somit hätte man einen riesigen Perf/W Sprung hingelegt mit nur einer Generation. Da Navi je nach dem nur kleinere Änderungen an der Vega Architektur beinhaltet, sollte sich der R&D Aufwand auf HW Seite in Grenzen halten. IF, Multi-Die Packaging, HBM usw. wurde alles schon mit den Vorgänger-Produkten und Ryzen erprobt. Die höheren Latenzen durch IF + Multi-Die anstatt Single Die sollte bei GPUs ebenfalls weniger einschenken wie bei den CPUs. Der Preis für die Energieeffizienz wäre aber ein grosses Package und total 800mm2 Silizium. Aufgrund der wahrscheinlich guten Yields und geringerer R&D Kosten wäre der Stückpreis evtl. sogar niedriger als ein einzelnes 500-600mm2 Die, trotz des aufwändigeren Packaging.

Das alles hört sich nach Best Case an. Ganz unrealistisch ist es aber auch nicht. Ich bin einfach hoffnungsloser Optimist :D

Und vielleicht war wer voreilig mit Folien erstellen ;D

[iuno]

fudzilla (http://www.fudzilla.com/news/graphics/44277-navi-to-have-ai-specific-circuits?cid=dlvr.it) behauptet, Navi wuerde etwas vergleichbares wie Tensor-Cores bekommen.
Da waere ich aber mal skeptisch. Nachdem man aktuell eh schon deutlich groessere Chips braucht, um mit Nvidia GPUs mitzuhalten soll man auch noch fixed-function Bloecke fuer NN verbauen? Nvidia ist mit der Software schon laenger im Geschaeft und hat dafuer jetzt einen riesengrossen Chip. Google baut schon in zweiter Generation ASICs und MIOpen ist fuer Vega auch nicht fertig geworden.
Ob man sich da nicht auf was anderes konzentrieren sollte?

[Screemer]

Eher kleben die da noch nen zweiten ff-kern auf nen interposer.

[basix]

Ich habe hier noch eine Folie gefunden zum Stromverbrauch von HBM und GDDR5. Infinity Fabric benötigt mit 2 pJ/Bit ca. 1/10 der Energie von GDDR5 pro Bit und ca. 1/3 von HBM.

NVIDIA vergleicht die Leistungsaufnahme zwischen DRAM und HBM und kommt auf etwa 18-22 pJ/Bit bei DRAM und 6-7 pJ/Bit bei HBM.

https://www.hardwareluxx.de/index.php/artikel/hardware/grafikkarten/35308-warum-hbm-mehr-als-nur-eine-erhoehung-der-speicherbandbreite-ist.html

[HOT]

fudzilla (http://www.fudzilla.com/news/graphics/44277-navi-to-have-ai-specific-circuits?cid=dlvr.it) behauptet, Navi wuerde etwas vergleichbares wie Tensor-Cores bekommen.
Da waere ich aber mal skeptisch. Nachdem man aktuell eh schon deutlich groessere Chips braucht, um mit Nvidia GPUs mitzuhalten soll man auch noch fixed-function Bloecke fuer NN verbauen? Nvidia ist mit der Software schon laenger im Geschaeft und hat dafuer jetzt einen riesengrossen Chip. Google baut schon in zweiter Generation ASICs und MIOpen ist fuer Vega auch nicht fertig geworden.
Ob man sich da nicht auf was anderes konzentrieren sollte?

Das geht. Angenommen man bastelt eh nur 3 kleinere Dies, dann könnte eines davon für die kleinen Produkte, eines für bis zu HighEnd und eines für Professionell sein, inclusive AI-Optimierung. Die laufen eben alle mit je einem HBM-Stack und können per IF gekoppelt werden.

[Kriton]

fudzilla (http://www.fudzilla.com/news/graphics/44277-navi-to-have-ai-specific-circuits?cid=dlvr.it) behauptet, Navi wuerde etwas vergleichbares wie Tensor-Cores bekommen.
Da waere ich aber mal skeptisch. Nachdem man aktuell eh schon deutlich groessere Chips braucht, um mit Nvidia GPUs mitzuhalten soll man auch noch fixed-function Bloecke fuer NN verbauen? Nvidia ist mit der Software schon laenger im Geschaeft und hat dafuer jetzt einen riesengrossen Chip. Google baut schon in zweiter Generation ASICs und MIOpen ist fuer Vega auch nicht fertig geworden.
Ob man sich da nicht auf was anderes konzentrieren sollte?

Ich denke mal, dass ist nur eine Vermutung, damit man hinterher sagen kann man hat es ja gewusst. Und wenn es nicht so kommt, dann verschwindet das halt in der Versenkung.

[prinz_valium]

sollte man nicht mal das Datum in der Überschrift anpassen?
2019/2020

[basix]

7nm ist schon für 2018 geplant und AMD will laut Lisa Su "aggressiv und früh auf 7nm setzen".

[HOT]

7nm ist sogar erst Mal AMD exclusiv bei GloFo. Wenn die GPUs dieses Jahr noch Tapeout haben, könnte man tatsächlich 2018 noch was sehen.

[BoMbY]

Die Crossfire/XDMA-Zukunft (vermutlich), AMD-Patentanmeldung: Peripheral component (http://www.freshpatents.com/-dt20170817ptan20170235700.php)

Zwei Karten in zwei PCIe x16 Slots: 8 Lanes verbinden jede Karte mit dem Host-System, jeweils 8 Lanes verbinden die Karten fest untereinander (ohne Kontakt zum Rest des Systems), Daten welche an jede Karte geschickt werden, werden an die jeweils andere weiter geschickt und ggfls. auch dort verarbeitet, und das System sieht nur ein PCIe x16 Device, anstelle von zwei GPUs.

[tm0975]

nett. ggf. resultiert das in einer effizienteren multi-gpu-nutzung.

[unl34shed]

Ist dann aber eher was für MCM oder spezielle Server. Normale Desktop Hardware ist so zur Zeit ja nicht aufgebaut.

PS: Hab's noch nicht gelesen

[BoMbY]

Möglicherweise könnte das mit AM4-Mainboards mit den Haupt-PCIe x16 Slots schon entsprechend so ausgelegt sein - müsste man mal prüfen.

Edit: Ne, sehe gerade: Ist wohl nicht der Fall - keine Kontakte hinter x8 beim zweiten Slot.

[basix]

Die Crossfire/XDMA-Zukunft (vermutlich), AMD-Patentanmeldung: Peripheral component (http://www.freshpatents.com/-dt20170817ptan20170235700.php)

Zwei Karten in zwei PCIe x16 Slots: 8 Lanes verbinden jede Karte mit dem Host-System, jeweils 8 Lanes verbinden die Karten fest untereinander (ohne Kontakt zum Rest des Systems), Daten welche an jede Karte geschickt werden, werden an die jeweils andere weiter geschickt und ggfls. auch dort verarbeitet, und das System sieht nur ein PCIe x16 Device, anstelle von zwei GPUs.

Da IF auch über PCIe Slots laufen kann gar nicht mal so unwahrscheinlich. Wie sieht das denn bei anderen non-AMD Karten aus? Wäre der Slot immer noch auf x8 beschränkt? Oder ist die Anwendung eher im Profi / HPC Bereich zu suchen, wo es eh Custom-Systeme gibt.

[Pirx]

Navi in 07-08/2018 (?)

https://www.tweaktown.com/news/59428/amds-next-gen-navi-gpu-launching-august-2018/index.html

[Hübie]

Aha. Genau genommen steht da nix was ein Fundament hat. Irgendwo was aufgeschnappt und in eine News verwurstet. "Well informed industry sources" (irgendein Forenmitglied etc.) fehlt da noch. ;D

[Kriton]

Nach den bisherigen Infos passt das genau zu Vega 20 - insbesondere auch, dass es sich um eine professionelle Lösung handeln soll. Eine falsche Zuordnung?

[robbitop]

08/2018 passt nicht zu 7nm. 7 nm Massenprodukte sind iirc nicht vor 2019 zu erwarten.

[HOT]

Nope, TSMC fängt ab Q2 mit 7 DUV an, GloFo ab Q3. Massenproduktion wohlgemerkt. V20 kommt ja offenbar in N7FF bei TSMC, könnte für Navi evtl. auch gelten.
Bei Navi geht man ja außerdem davon aus, dass ab Q3 ausschließlich Profiprodukte zur Verfügung stellen, V20 dürfte das ebenfalls betreffen. Erst ab 2019 wird man sicherlich Consumerprodukte in 7nm sehen. Zuerst wird man den Consumermarkt mit Vega in 12LP bedienen.

[Kriton]

Aber es gibt doch 2018 nicht zwei professionelle Chips von AMD. Das wäre unsinnig.
Und V20 war immer als Profi-Chip angekündigt in dem Zeitraum wo jetzt plötzlich Navi für den Profimarkt kommen soll?
Da sieht keiner einen (wahrscheinlichen) Fehler bei der (Codenamen)Zuordnung? :freak:

6Qr5VFPYezo

Zeit: 4:00.

Hier als Standbild:

https://www.3dcenter.org/dateien/abbildungen/AMD-Server-Profi-Roadmap-2017-2018.vorschau2.jpg

Die News mit der Grafik ist vom 26.09.!

[HOT]

V20 wird ja der HPC-Chip. Das schließt doch nicht aus, dass Navi dann in kleiner Produktion als Radeon Pro und/oder Instinct kommt?

[Hübie]

Navi kommt doch erst 2019...

[dargo]

Diese ganzen Zielsetzungen sind eh meistens viel zu optimistisch gesetzt. Legt 6-12 Monate drauf dann passt es schon eher.

[HOT]

Des Rätsels Lösung könnte auch sein, dass man einen Navi-Mainstreamchip als Pipecleaner nutzt, immerhin läuft 7 DUV bei GloFo ja erst mal exklusiv für AMD. Wäre also sehr sinnvoll zur Prozessoptimierung.

[robbitop]

Wenn Navi wirklich skalierbar ist, braucht es doch eigentlich nur noch einen Chip für ein ganzes Lineup. Entsprechend hast du 1, 2 oder 4 Chips auf dem Interposer.

Ich tippe aber auch eher auf 2019.

[Dino-Fossil]

Ich frage mich mittlerweile, ob AMD mit "Skalierbarkeit" am Ende etwas anderes meint.
Oder zumindest die Zielsetzung geändert hat.

Sehe ich mir den eher, naja, suboptimalen Vega-Launch an, mache ich mir eigentlich keinerlei Hoffnung, dass AMD etwas ambitioniertes wie multi-Chip GPUs auf Interposer-Basis in diesem Zeitrahmen ordentlich hin bekommt. Ordentlich im Sinne von: Eine solche GPU "funktioniert einfach", anstatt jedesmal händische Anpassungen zu erfordern, wenn man Software/Spiele darauf los lässt.

Andererseits kann "Skalierbarkeit" auch einfach nur bedeuten: Wir wollen unsere GPU-Architektur dahingehend optimieren, dass eine ordentliche Auslastung und Effizienz vom kleinsten bis zum größten Chip gewährleistet ist. Damit hatte GCN ja teils gewisse Probleme.

[HOT]

Jo das Multichip-Getöse halte ich auch für einen falschen Ansatz, das machen die eh nicht mit Navi. Und neue Speichertechnologie wird einfach GDDR6 heißen. Die HPC-Profiprodukte bekommen halt HBM. Es wird sicherlich V20 als HPC-Chip erscheinen, welcher ja bekanntlich bei TSMC vom Band laufen wird. Vielleicht schafft der es sogar in den Consumermarkt, vielleicht aber auch nicht.
Man wird einfach einen 300mm²+ Navi-Chip fertigstellen, der den 7LP-Prozess bei GloFo einfahren wird. Erst in kleiner Serie, also ausschließlich als Pro/Instinct und später dann, wenn der Prozess zuverlässig ist, kommt der dann als neues Consumer-Produkt auf den Markt. Ich fänd so ein Vorgehen sehr sinnvoll.

[tm0975]

vielleicht ist das mäßige arrangement von amd bei der aktuellen generation auch so zu erklären, dass das ganze eine aussterbende art ist und intern schon längst die multi-chip ära begonnen hat und diese deutlich überlegen ist.

[Der_Korken]

Wenn AMD wirklich mit Multichips anfangen will, dann vielleicht eher so, dass man den Highend-Chip weglässt und stattdessen die Performance-Chips so entwirft, dass auch zwei davon auf einem Interposer zusammenarbeiten können, ohne dass es große Probleme bei der Skalierung gibt (und natürlich auch ohne AFR).

Dass man wiklich mit einem Die wie bei Ryzen von Midrange bis Server alles abdeckt, erscheint viel zu ambitioniert. Man hätte vor allem das Problem, dass alle Karten dann den gleichen Speicher nutzen müssten und auch die gleichen Features haben müssten. Setzt man auf HBM, so muss auch die kleinste Karte HBM nutzen, obwohl GDDR6 vielleicht günstiger wäre, weil man ja schlecht PHYs für HBM und GDDR verbauen kann, ohne jede Menge Chipfläche wegzuwerfen. Außerdem müssten, wenn man 1:2 DP bei den Compute-Karten anbieten will, auch alle anderen Karten 1:2 DP mit sich rumschleppen, was auch nicht kostenlos ist.

[Dino-Fossil]

vielleicht ist das mäßige arrangement von amd bei der aktuellen generation auch so zu erklären, dass das ganze eine aussterbende art ist und intern schon längst die multi-chip ära begonnen hat und diese deutlich überlegen ist.

Und vielleicht kündigt Intel morgen Bankrott an oder der Papst erlaubt die Homo-Ehe.
Nene, AMD fehlen einfach die Ressourcen aktuell. Vermutlich wurde fast alles in Zen gesteckt, das Resultat war entsprechend gut. Für Vega hat es vermutlich schon nicht mehr ganz gereicht.
Der Treiber z.B. ist ja immer noch nicht da wo er hin soll.

Ich kann mir schon gut vorstellen, dass man intern an multi-Chip GPUs forscht, allein mir fehlt der Glaube, dass die bis Navi Marktreife haben.

[BoMbY]

Wenn AMD wirklich mit Multichips anfangen will, dann vielleicht eher so, dass man den Highend-Chip weglässt und stattdessen die Performance-Chips so entwirft, dass auch zwei davon auf einem Interposer zusammenarbeiten können, ohne dass es große Probleme bei der Skalierung gibt (und natürlich auch ohne AFR).

Dass man wiklich mit einem Die wie bei Ryzen von Midrange bis Server alles abdeckt, erscheint viel zu ambitioniert. Man hätte vor allem das Problem, dass alle Karten dann den gleichen Speicher nutzen müssten und auch die gleichen Features haben müssten. Setzt man auf HBM, so muss auch die kleinste Karte HBM nutzen, obwohl GDDR6 vielleicht günstiger wäre, weil man ja schlecht PHYs für HBM und GDDR verbauen kann, ohne jede Menge Chipfläche wegzuwerfen. Außerdem müssten, wenn man 1:2 DP bei den Compute-Karten anbieten will, auch alle anderen Karten 1:2 DP mit sich rumschleppen, was auch nicht kostenlos ist.

Man kann den Memory Controller auch wieder auf einen Extra-Chip packen, oder gleich in einen aktiven Interposer integrieren. Das Chiplet-Patent von AMD deutet darauf schon hin, wenn ich mich richtig erinnere. Der Memory Controller von Ryzen und Vega ist ja schon jetzt per Infinity Fabric mit dem Chip verbunden, und somit prinzipiell austauschbar.

[BoMbY]

Ohh, übrigens eventuell relevantes Patent: Methods and apparatus for processing in a network on chip (noc) (http://www.freshpatents.com/-dt20171012ptan20170295111.php)

[Skysnake]

Ich habe mal angefangen das du geschrieben zu lesen aber nach 1/4 wieder aufgehört. Das ist ja mal ein mega blabla.

Wenn sich jemand den ganzen Text antun will und was interessantes findet kann er sich ja melden. Ich sehe da nur prior art zu stink normalen Netzwerken bzw nocs

[Kriton]

AMD hat bereits mit der 48XX Generation den Gedanken formuliert hatte, dass es keinen single chip im high end geben soll, sondern nur noch multi chips (damals sicher eher in der bisherigen Form).
Vermutlich sind sie also an der Thematik nicht erst seit gestern dran.

Aber bezüglich Navi und 2018: Mal Ockhams Rasiermesser benutzen?

Ich verweise noch einmal auf das Datum der Folie. Wenn sie Navi planen würden (für 2018) Warum sollten sie das vor nicht einmal 1 Monat nicht auf der Folie zeigen?

[BoMbY]

Ich habe mal angefangen das du geschrieben zu lesen aber nach 1/4 wieder aufgehört. Das ist ja mal ein mega blabla.

Wenn sich jemand den ganzen Text antun will und was interessantes findet kann er sich ja melden. Ich sehe da nur prior art zu stink normalen Netzwerken bzw nocs

Das heißt Du hast beim "Background" aufgehört, welcher den "Background" erklärt? :rolleyes:

Na, egal ob patentierbar oder nicht: Hier wird recht eindeutig eine GPU beschrieben, welche ihre CUs und den Speicher über ein flexibles NOC vernetzt. In dem Chiplet-Patent (https://patents.google.com/patent/US20170200672A1/en) wird ein flexibler Interposer beschrieben, über welchen ein Netzwerk zwischen Chips aufgebaut werden soll.

Und wenn eine GPU intern wie ein Netzwerk arbeitet, spricht nichts mehr dagegen zwei GPUs mittels dieses Netzwerks zu verbinden, und dass diese dann wie eine GPU funktionieren können ...

[Hübie]

Haben die AMD-Designs etwa kein OCN? Bei NV kenne ich das schon einige Jahre (innerhalb des GPC flexibel, darüber eher nicht). Oder ist da nun wirklich was neues bei, was mir jetzt beim Überfliegen nicht aufgefallen ist?

[BoMbY]

Ich bezweifle doch ernsthaft, dass NVidia jede einzelne CU, oder überhaupt irgendwas, mittels eines Paketorientieren Netzwerks angebunden hat? Das was die als on-chip network bezeichnen sind allerhöchstens die Fabric-Verbindungen zwischen GPU und gekaufter Memory Controller IP.

[BoMbY]

Ich hab noch mal ein bisschen gestöbert und eventuell interessante Dinge zu AMD's NOC gefunden:

AMD-Research-Paper (2017): An asynchronous NoC router in a 14nm FinFET library: Comparison to an industrial synchronous counterpart (https://www.semanticscholar.org/paper/An-asynchronous-NoC-router-in-a-14nm-FinFET-librar-Jiang-Bertozzi/cab03a47d1d9be74153d9876a1aa231db5582c08)

AMD-Research-Präsentation (PDF, 2017): Variable Bandwidth Links for self-timed on-chip communication (http://www.tauworkshop.com/2018/slides/TAU17_Variable_Bandwidth_links_Shomit_AMD.pdf)

AMD-Research-Paper (PDF, 2014): Design and Implementation of Novel Source Synchronous Interconnection in Modern GPU Chips (https://pdfs.semanticscholar.org/21cb/b54b2c89f6ec5bfd520e18676e5544a0c41a.pdf)

Edit: Noch ein älteres AMD-Patent von Greg Sadowski:


Method and apparatus for multi-chip processing (https://patents.google.com/patent/US20130141442A1/en)

Various methods, computer-readable mediums and apparatus are disclosed. In one aspect, a method of generating a graphical image on a display device is provided that includes splitting geometry level processing of the image between plural processors coupled to an interposer. Primitives are created using each of the plural processors. Any primitives not needed to render the image are discarded. The image is rasterized using each of the plural processors. A portion of the image is rendered using one of the plural processors and any remaining portion of the image using one or more of the other plural processors.

[HOT]

http://www.pcgameshardware.de/Radeon-RX-Vega-64-Grafikkarte-266623/News/Vega-Nachfolger-Navi-TSMC-7-nm-1241930/
Der Vollständigkeit halber.

[BoMbY]

Ja, nicht unmöglich, aber sehr sehr unwahrscheinlich. Vermutlich genauso eine Ente wie das Summit Ridge in TSMC 16nm gefertigt wird, während in Wirklichkeit das einzige derzeit wohl die XBone oder Paystation APUs sind welche da laufen. Vermutlich kommt das Gerücht aus einer ähnlichen Richtung.

[HOT]

Nein, absolut nicht. Denn V20 wird ja auch auf TSMC setzen wie es aussieht. Das das alle Enten sind ist doch arg unwahrscheinlich.
TSMC ist einfach früher dran als GloFo und die Prozesse sind recht gleichwertig. Es macht Sinn sich für TSMC zu entscheiden.
Kleinere GPUs können übrigens auch noch bei Samsung in 8LPP vom Band laufen, wie jetzt Polaris 20 und GP107/8.

Ich denke, dass im Moment die Kapazität auch problematisch ist. Immerhin ist Ryzen ein großer Erfolg, die APUs werden sicherlich auch gut gehen. Es macht einfach Sinn, die Produkte bei verschiedenen Foundries zu fertigen.

[BoMbY]

Sorry, aber das ist zu 99% Bullshit. GloFo muss jedes Outsourcing genehmigen, und AMD zahlt für jeden outgesourcesten Wafer Straf-/Ausgleichszahlungen an GloFo - auch mit der neuen Extension des WSA. Und GloFo hat gerade erst eine Untersuchung der EU-Kommission gegen TSMC gefordert. Abgesehen davon scheint der Aufbau der Kapazitäten bei der Fab von GloFo gut zu laufen, und AMD hätte zusätzliche Kosten mit dem komplett anderen Prozess von TSMC, welcher auch eher auf Mobile optimiert zu sein scheint, im Gegensatz zu 7LP.

Edit: Wie gesagt, möglich wäre es, aber das dürfte immer nur die allerletzte Möglichkeit sein:


The sixth amendment also provides us a limited waiver with rights to contract with another wafer foundry with
respect to certain products in the 14nm and 7nm technology nodes and gives us greater flexibility in sourcing foundry
services across our product portfolio. In consideration for these rights, we agreed to pay GF $100 million, which will be
paid in installments starting in the fourth fiscal quarter of 2016 through the third fiscal quarter of 2017. Starting in 2017
and continuing through 2020, we also agreed to make quarterly payments to GF based on the volume of certain wafers
purchased from another wafer foundry.

Further, for each calendar year during the term of the sixth amendment, we agreed to annual wafer purchase
targets that increase from 2016 through 2020. If we do not meet the annual wafer purchase target for any calendar
year, we will be required to pay to GF a portion of the difference between our actual wafer purchases and the wafer
purchase target for that year.

[Kriton]

Quelle bitte verlinken...:rolleyes:

Dein Text gibt das ansonsten her, aber ohne den eigentlichen Vertragstext kann man nicht sagen, ob es nicht weitere (zugunsten von AMD) Abhängigkeiten für die Zahlungen gibt.
Ich kann mir schwer vorstellen, dass das nicht der Fall wäre - ansonsten würde ich mir Gedanken über den Verhandlungsführer machen (oder es müsste die Preise echt sehr stark beeinflusst haben).

[LadyWhirlwind]

Quelle bitte verlinken...:rolleyes:

Dein Text gibt das ansonsten her, aber ohne den eigentlichen Vertragstext kann man nicht sagen, ob es nicht weitere (zugunsten von AMD) Abhängigkeiten für die Zahlungen gibt.
Ich kann mir schwer vorstellen, dass das nicht der Fall wäre - ansonsten würde ich mir Gedanken über den Verhandlungsführer machen (oder es müsste die Preise echt sehr stark beeinflusst haben).


Die gibt es bestimmt. GF wird sich im Gegenzug auch verpflichtet haben, die Wafer in einem passenden Prozess produzieren zu können. Ich bezweifle das AMD bezahlen muss, wenn GF die Wafer gar nocht produzieren kann oder es zu massiven verschiebungen in der Roadmap kommt. Ok, vielleicht eine „Grundgebühr“.
Ausserdem könnten die Konditionen bereits vereinbart worden sein. Auch denkbar das AMD auf gewisse über das Agreement hinausgehende Kapazitäten anspruch hat zu gesetzten Preisen.

Solche Verträge werden abgeschlossen, damit alle beteiliegten Planen können.

[Nightspider]

Wann sind denn eigentlich die ersten neuen Grafikkarten von AMD zu erwarten?

In 12nm soll es keine Refresh-Chips geben oder?

Also warten auf 7nm? Das wird doch frühestens was gegen Nov.-Dezember 2018 oder?

[tm0975]

es wird sicherlich mitte des jahres was neues geben. 7 nm halte ich aber für ausgeschlossen. wahrscheinlich vega mit paar (kleinen) verbesserungen und in 12 nm

[TGKlaus]

denke auch, das AMD nicht bis zum 7nm Prozess warten wird/kann.

[Hübie]

Wäre zumindest unlogisch, da Vega dann ins Performance-Segment rutschen würde und man oben wieder nix anbieten könnte. V11 ist ja nun klar, was das ist. V20 dann wohl der große Ausbau für APUs - ODER?? Da müsste also noch etwas zwischen Navi und Vega sitzen, was mehr als nur ein Refresh wie Hawaii->Grenada oder Polaris10->Polaris20 ist.

[tm0975]

es wird sicherlich mitte des jahres was neues geben. 7 nm halte ich aber für ausgeschlossen. wahrscheinlich vega mit paar (kleinen) verbesserungen und in 12 nm

[TGKlaus]

Für Polaris muss ein preiswerter Nachfolger her, der min 15-20% mehr Leistung bringt. Und das nicht erst im nächsten Herbst.

Also kein HBM und kein 7nm.

[BoMbY]

Navi ist immer noch 2019. 2018 gibt es Vega 11 und Vega 20, und nein, das wurde nicht dementiert, die Leute raffen nur nicht die Chips und die SKU-Bezeichnungen zu differenzieren.

[TGKlaus]

Wo willst du denn VEGA 11 einordnen, besonders bei den Fertigungskosten?

[Pick]

Navi treiber
https://forum.beyond3d.com/posts/2014718/

[Hübie]

Wo willst du denn VEGA 11 einordnen, besonders bei den Fertigungskosten?

Na es wurde doch schon mehr oder weniger bestätigt, dass es die Grafikeinheit von den APUs ist. Ob V20 dann eine größere Stufe oder ein Codename für einen Chip ist muss sich noch zeigen (analog zu V56/64).

[robbitop]

Ich tippe auf einen 12nm Refresh mit ein paar Optimierungen/Fehlerbereinigungen und etwas mehr Takt.

[HOT]

Eher nicht. Der wird schon in 7nm kommen, was bislang jede Speku ausmachte, mit knapp 300mm² wird er auch Profigedöns mitbringen - das Ding muss schließlich Hawaii ablösen. 2 davon mit je 2 HBM-Stacks auf einem Interposer ergeben dann die Profivariante. Einer ist auch als Profi-APU nutzbar zusammen mit 1 oder 2 Zen2-Dies. Und er kommt eben in Q4 auch als V10-Ablöse in den Customer-Markt als Performance-GPU. Das Ganze wird dann von Navi10 in Q1 2019 nach oben hin abgerundet. Da gehe ich jede Wette ein, dass das so laufen wird. Vielleicht gibts noch mal eine 12LP oder 14LPU-Variante von V10 zwischenzeitlich, vielleicht aber auch nicht. Angeblich soll man zumindest bei GloFo ja keine neue Maske benötigen für 12LP, damit wäre ein on-the-fly-Produktionswechsel durchaus drin.
Dass es diesen Treibereintrag schon gibt, sagt mir, dass es alle 7nm-Produkte schon in Silizium gibt, da Navi von allen das letzte Tapeout gewesen sein dürfte - erst V20, dann Zen2 und als letztes Navi10.

[lowkres]

Basiert eigentlich Navi noch auf die GCN Architektur. Wenn ja, wann würdet ihr einschätzen, dass AMD endlich mal eine neue Arch rausbringt??

[iuno]

vermute ich schon. Was heisst hier "endlich mal"?

[lowkres]

AMD hat es geschafft mit Ryzen ein sehr solides Produkt zu entwickeln. Die CPUs sind günstig und bieten für ihren Preis eine gute Leistung und sind auch noch ziemlich effizient. So eine gelungene Grundbasis benötigt AMD auch bei ihren Grafikkarten. Ob das mit Navi möglich sein wird, weden wir sehen.

[dildo4u]

Die High-End AMD Chips werden immer doppelte Arbeit erledigen müssen,daher wird das fürs Gameing nie ideal sein.Siehe die Titan V die taktet deutlich langsamer als die Titan XP,die FP 64 und Tensor Core Hardware kann NV dann wieder für die Gameing Version raus nehmen.

[iuno]

AMD hat es geschafft mit Ryzen ein sehr solides Produkt zu entwickeln. Die CPUs sind günstig und bieten für ihren Preis eine gute Leistung und sind auch noch ziemlich effizient. So eine gelungene Grundbasis benötigt AMD auch bei ihren Grafikkarten.

2011: AMD hat es geschafft mit GCN ein sehr solides Produkt zu entwickeln...
2011(?): Intel hat es geschafft mit Core ein sehr solides Produkt zu entwickeln...
2017: Intel Core muss weg und eine solide Grundbasis her?

[Pick]

Basiert eigentlich Navi noch auf die GCN Architektur. Wenn ja, wann würdet ihr einschätzen, dass AMD endlich mal eine neue Arch rausbringt??

GCN -- ist eine Architektur wie x86. Es kann alt und neu sein.

[robbitop]

Du meinst eine ISA?

[|MatMan|]

@HOT:
Ich würde fast jede Wette eingehen, dass es es nicht so laufen wird. Wenn man sich P20 und Grenada anschaut, kann man konservativ erstmal ähnlich viel von V20 erwarten. Mehr ist natürlich gern gesehen.
Ich hab dich schonmal nach einer Quelle gefragt, dass der 12nm Prozess keine neuen Masken benötigt - wie soll das gehen, wenn es eine Flächenersparnis gibt?
Zu deiner Interposer-Theorie: ich hoffe inständig, dass AMD das nicht tut. Sie haben nichtmal die Basics von Vega richtig im Griff, da braucht man beim Refresh nicht schonwieder mit einer experimentellen und potentiell problematischen sowie teuren Technologie um die Ecke kommen. Von einem Refresh erwarte ich in erster Linie Bugfixing und Optimierungen, d.h. dass die Vega-Features mehr Effekt zeigen (bzw. überhaupt einen).

GCN -- ist eine Architektur wie x86. Es kann alt und neu sein.
x86 ist eine ISA (https://de.m.wikipedia.org/wiki/Befehlssatzarchitektur), keine Architektur. Zen oder Haswell sind z.B. Architekturen.
Man könnte sicherlich eine neue GPU Architektur entwickeln, die zur GCN ISA kompatibel ist. Wie sinnvoll das ist, ist eine andere Frage...

[fondness]

https://jobs.amd.com/job/Shanghai-Sr_-ASIC-Layout-Design-Engineer/444762400/

Hm, Navi kommt also wie Vega wieder vom Shanghai-Team. Bleibt die Frage, was Orlando die ganze Zeit macht. Graphics Core Next Next? :D

[Opprobrium]

Da AMD auf absehbare Zeit bei Custom Chips (Konsolen, Intel "APU" etc.), eigenen CPUs/APUs und überhaupt auf GCN zu bauen scheint glaube ich nicht, daß wir dieses Jahrzehnt noch eine komplett neue ISA von denen sehen werden. Eventuell irgendwann mal eine mittelfristige Ankündigung, aber vermutlich nicht vor Zen2/Navi/der nächsten Konsole.

Kann mich natürlich täuschen, aber so lang ist das Jahrzehnt auch nicht mehr :biggrin:

[HOT]

https://jobs.amd.com/job/Shanghai-Sr_-ASIC-Layout-Design-Engineer/444762400/

Hm, Navi kommt also wie Vega wieder vom Shanghai-Team. Bleibt die Frage, was Orlando die ganze Zeit macht. Graphics Core Next Next? :D
V20. Irgendjemand muss den Profichip ja designen.

[Tru]

Na es wurde doch schon mehr oder weniger bestätigt, dass es die Grafikeinheit von den APUs ist. Ob V20 dann eine größere Stufe oder ein Codename für einen Chip ist muss sich noch zeigen (analog zu V56/64).
IMHO hat VC James Priors Aussage maximal falsch interpretiert.

[Locuza]

V20. Irgendjemand muss den Profichip ja designen.
Das kleine Detail in der Jobbeschreibung hast du vielleicht übersehen:
Job Responsibilities: Specific for GFX10 projects (OSS/MMHUB BFM, RSMU GCDV)

[Hübie]

IMHO hat VC James Priors Aussage maximal falsch interpretiert.

Scheint mir entgangen zu sein. Wie wurde es denn neu und richtig interpretiert? :|

[HOT]

Das kleine Detail in der Jobbeschreibung hast du vielleicht übersehen:
Ist schon richtig :D. V20 ist ja auch quasi fertig. Dafür sucht man ja keine neuen Leute mehr.
Aber interessant, dann scheint die Navi-Generation ja auch ne ziemlich große Sache zu sein.

[BoMbY]

Navi treiber
https://forum.beyond3d.com/posts/2014718/

Das ist eine Beispieldatei mit Beispielwerten für die Funktion zum Nachladen von ASIC-Definitionen aus einer Datei. Das hat nichts mit einem konkreten Produkt zu tun.

[Nakai]

Die Treiberentwicklung geht ja vor einer funktionsfähigen Hardware voraus. Ergo kann man das nur als Indiz ansehen, dass eine gfx10-Architektur auf dem Vormarsch ist. Ich wäre mir nicht sicher, dass das Navi ist. Das kann genauso gut Vega20 sein.

[horn 12]

Dann ist bei Vega 10 (XT) so vieles (Alles) schief gelaufen was schief laufen kann...
oder wie sollte man dies verstehen.
Kommen bei Vega die Prim. Shader noch bis Weihnachten als Treiber Update nach dem ganzen Fiasko?

[BoMbY]

Ja, es wird irgendwann GFX10 in den Treibern geben, aber diese Beispieldatei ist nur ein verdammter Witz, und der der Typ lacht sich vermutlich gerade einen ab. Die echten Treiber-Patches wird es vermutlich in einem Jahr geben.

[Dino-Fossil]

Phoronix hat auch noch was dazu:
https://www.phoronix.com/scan.php?page=news_item&px=AMD-Linux-Drivers-Not-Yet-Navi

tl;dr:
Platzhalter/Witz-Einträge aus einem Debugger-Patch ohne besondere Relevanz.

Dazu auch PCGHW:
Die auf Linux fokussierte Webseite phoronix.com merkt an, dass der Eintrag zu Navi nicht aus einem Treiber-, sondern einem Debugger-Patch stammt. Die wenigen Zeilen Code sollen dazu dienen, den Debugger mit beliebigen Informationen zu den GPUs zu füttern, und stellten keine Unterstützung für Navi dar. Die Windows-Welt, einschließlich PCGH, war an dieser Stelle zu voreilig. Trotzdem könnte AMD bereits erste Testchips im Labor haben, die initialen Tape-Outs sollten wie im Originalartikel angesprochen 2017 stattfinden.

[lowkres]

Dann ist bei Vega 10 (XT) so vieles (Alles) schief gelaufen was schief laufen kann...
oder wie sollte man dies verstehen.
Kommen bei Vega die Prim. Shader noch bis Weihnachten als Treiber Update nach dem ganzen Fiasko?

Ich bin auch wirklich enttäuscht. Man hat Features versprochen und angekündigt und am Ende fehlen diese einfach.

Ich hoffe das jetzt mit der Leitung von Lisa Su alles besser wird.

[HOT]

Hm? Welche denn?

[BoMbY]

Er meint sicher den DSBR, zu welchem es immer noch keine ausführliche Auskunft seitens AMD gibt.

[Dino-Fossil]

Oder auch die primitive shaders, an denen sich gerade ein kleiner Shitstorm im AMD reddit abarbeitet.
Immerhin gibt's zum DSBR mehr Infos, er hat wohl nur bislang kaum Auswirkungen in Spielen.

Die wenigen Infos zu den PS sind allerdings widersprüchlich und AMD sagt aktuell gar nichts mehr dazu.

Eventuell wäre es schon ein ordentlicher Fortschritt, wenn Navi sich nur als gefixter Vega entpuppt.

[Complicated]

Also eigentlich finde ich die Infos von AMD zu Primitive Shaders recht eindeutig. Siehe Vega Whitepaper: https://radeon.com/_downloads/vega-whitepaper-11.6.17.pdf

“Vega’s” new primitive shader support allows some parts of the geometry processing pipeline to be combined and replaced with a new, highly effcient shader type. These flexible, general-purpose shaders can be launched very quickly, enabling more than four times the peak primitive cull rate per clock cycle. In a typical scene, around half of the geometry will be
discarded through various techniques such as frustum culling, back-face culling, and small-primitive culling. The faster these primitives are discarded, the faster the GPU can start rendering the visible geometry. Furthermore, traditional geometry pipelines discard primitives after vertex processing is completed, which can waste computing resources and create bottlenecks when storing a large batch of unnecessary attributes. Primitive shaders enable early culling to save those resources.

The “Vega” 10 GPU includes four geometry engines which would normally be limited to a maximum throughput of four primitives per clock, but this limit increases to more than 17 primitives per clock when primitive shaders are employed.⁷

Primitive shaders can operate on a variety of different geometric primitives, including individual vertices, polygons, and patch surfaces. When tessellation is enabled, a surface shader is generated to process patches and control points before the surface is tessellated, and the resulting polygons are sent to the primitive shader. In this case, the surface shader combines the vertex shading and hull shading stages of the Direct3D graphics pipeline, while the primitive shader replaces the domain shading and geometry shading stages.

Primitive shaders have many potential uses beyond high-performance geometry culling. Shadow-map rendering is another ubiquitous process in modern engines that could benefit greatly from the reduced processing overhead of primitive shaders. We can envision even more uses for this technology in the future, including deferred vertex attribute computation, multi-view/multi-resolution rendering, depth pre-passes, particle systems, and full-scene graph processing and traversal on the GPU. Primitive shaders will coexist with the standard hardware geometry pipeline rather than replacing it. In keeping with “Vega’s” new cache hierarchy, the geometry engine can now use the on-chip L2 cache to store vertex parameter data.

This arrangement complements the dedicated parameter cache, which has doubled in size relative to the prior-generation “Polaris” architecture. This caching setup makes the system highly tunable and allows the graphics driver to choose the optimal path for any use case. Combined with high-speed HBM2 memory, these improvements help to reduce the potential for memory bandwidth to act as a bottleneck for geometry throughput.

⁷ Peak discard rate: Data based on AMD Internal testing of a prototype RX Vega sample with a prototype branch of driver 17.320. Results may vary for final product, and performance may vary based on use of latest available drivers.
62061 62062

Also zum einem geht aus diesem Whitepaper hervor, dass die Primitive Shader in Hardware funktionieren und erfolgreich getestet wurden. Was aber auch daraus hervor geht ist, dass dies eben nicht einfach durch Treiber aktiviert wird, sondern definitiv von den Programmierern implementiert werden muss. Es ist nicht davon auszugehen, dass es schon Software geben kann die das nutzt, da man ja den doppelten Aufwand hätte mit der klassischen Render-Pipline. Zumindest konnte wohl AMD keinen Entwickler davon überzeugen diesen zusätzlichen Aufwand zu betreiben. Es ist auch etwas fraglich welcher Entwickler sich das antun will. Es läuft ja nur auf AMD Hardware.

Ich bin gespannt wie es weiter geht damit und ob AMD nun so etwas wie Nvidias Gameworks auflegen muss um all die zusätzliche Arbeit in DX12, mit Intrinsics und den Primitive Shadern für die Entwickler zugänglicher zu machen. Denn ganz offensichtlich stagniert die Verbreitung von DX12 und Vulkan und verliert an Dynamik.

[Dino-Fossil]

Klar, wenn man nur eine Quelle nutzt ist es nicht widersprüchlich. ;)
Den Stein ins Rollen brachten Aussagen seitens AMD auf Twitter, dass die PS nicht durch die Entwickler gezielt angesprochen werden müssten, sondern per Treiber automatisiert werden.
Was bisher entweder gar nicht geschehen ist, oder eben nur auf Basis eines "Fallbacks" auf die alte Pipeline.

Das es gezielt angesprochen werden müsse wurde, wenn ich mich richtig erinnere, u.a. auf dem Vega Architektur-Preview gesagt (sicher bin ich mir aber nicht).
Das sowas dann kaum genutzt werden würde wäre absehbar, zumal es wohl relativ komplex ist.

Sei es wie es sei, aktuell beschweren sich einige darüber, dass Vega nicht alle versprochenen Features hätte und die USA-typischen Drohungen mit Sammelklagen stehen im Raum.

[HOT]

Na ja, das kann man eben auch falsch verstehen. Die Native-Pipeline wird eben über PS realisiert. Dann ist es auch logisch, dass man nur bei manueller Programmierung von dessen Vorteilen profitieren kann. Man wollte wohl einfach betonen, dass diese "Emulation" effizienter ist als bisherige Implementationen.
Dann kann man sowas ja auch implementieren und hat für später evtl. noch ein Ass im Ärmel. Jetzt aber eben nicht.

[Complicated]

AMD hatte wohl gesagt, dass sie so etwas wie eine Default Implementierung zur Verfügung stellen würden, die in allen Spielen funktioniert. Die einzelne Entwickler können aber auch ihre eigenen schreiben. Nur das muss ja auch erst einmal in den Code Einzug halten. Und so wie die Entwickler dazu übergegangen sind DX12 per Update erst nachzureichen, so wird wohl ein solches Feature ganz unten auf der Liste der Patches stehen, da eben nur Vega das derzeit nutzt.

Das ändert sich mit der Verbreitung von Vega in Raven Ridge, nur fraglich ob das die Entwickler als relevante Hardwarebasis sehen. Sollte eine Konsole mit Vega Hardware erscheinen könnte sich das auf einen Schlag ändern, da eine Portierung dann auch sicherlich der PC-Hardware zugute kommen würde.

IMHO ist dieser Unsinn mit angeblich nicht vorhandenen Features chancenlos bei einer Klage. Ansonsten könnte man nun AMD auch dafür verantwortlich machen wenn ein Entwickler DX11 anstatt DX12 nutzt. Oder wenn bei DX12 kein Asynch Compute genutzt würde. Das war ja schon immer ein Kern-Problem bei allen DX Versionen oder neuen Hardware-Features. Tesselation wurde 4 Generationen lang in Hardware mit geschleppt und erst mit DX11 fingen die Entwickler an das Feature zu nutzen, weil Nvidia es dann auch in Hardware anbot.

Wo fängt das an und wo hört das dann auf, dass der Hardware Hersteller nun dafür gerade stehen muss, dass Software-Entwickler auch die Features nutzen?

[Dino-Fossil]

Das ist, was auf Twitter geschrieben wurde und alles ins Rollen gebracht hat:


Rys Sommefeldt: "No plans to expose them programatically today, but we do review the state of play periodically so that might change. No plans rn though"

"So there's no way for a game developer to use them right now? Or am I mistaken?"

Rys Sommefeldt: "The driver takes care of it for you. Just render as normal."

"What about the NGG Fast Path culling? To my understanding it needs primitive shaders, do the devs have control to use it instead of native?"

Rys Sommefeldt: "No control, it's all transparent"

"So, basically, devs can think of it as 'vertex shaders + rasterization is faster' and get on with their lives, at least right now, yeah? "

Rys Sommefeldt: "Yep. From your perspective we made a more efficient GPU and you don't do anything different. Might change later but no promises."

"Is it still culling primitives this way, or you have to redesign the pipeline to fully utilize this feature?"

Rys Sommefeldt: "You don't have to redesign anything. The idea is that you just draw as normal"

"Wait so primitive shaders just work automatically from a developer's point of view? It's done in driver?"

Rys Sommefeldt: "Yup!"

https://twitter.com/ryszu/status/896304786307469313 (https://twitter.com/ryszu/status/896304786307469313)

Sicherlich ein Stück weit offen für Interpretationen.

Angeblich sind die PS übrigens mittlerweile in den neuen Vega-iMac Pros aktiv - was klar gegen die These spräche, dass sie fehlen oder defekt sind.

[G3cko]

Auch bei Intel setzt man auf AMD GPUs zb in dem kommenden NUC. Vega10 ist einfach sehr früh auf dem Markt gekommen. Das die aktuellen Konsolen noch keine PS nutzen ist ebenso logisch. Das sehe ich als größeren Schritt für die kommenden wirklichen Next-Gen-Konsolen.

Das Feature wird sicherlich nachgereicht, aber aktuell hat man ganz andere Baustellen. Bzw die Miner kaufen die Karten auch so.

[Complicated]

https://twitter.com/ryszu/status/896304786307469313

Sicherlich ein Stück weit offen für Interpretationen.

Ist halt die Frage wie Kompetent der Herr da war. Noch im März bei Imagination gewesen und im August Aussagen auf Twitter über noch nicht erschienene Produkte verkündet:
https://www.imgtec.com/blog/author/rys/
I'm an Engineering Manager at Imagination, working primarily on competitive and performance analysis of graphics technology. My job is figure out how fast and efficient everything is and understand exactly why, so we're as competitive as possible.
Wenn er damit versorgt wurde:
AMD hatte wohl gesagt, dass sie so etwas wie eine Default Implementierung zur Verfügung stellen würden, die in allen Spielen funktioniert.
Mag das für ihn sogar so ausgesehen haben als neuer Senior Game Engineer bei AMD.

[gravitationsfeld]

Rys weiss von was er redet. Die Diskreditierung ist laecherlich.

[reaperrr]

Ist halt die Frage wie Kompetent der Herr da war. Noch im März bei Imagination gewesen und im August Aussagen auf Twitter über noch nicht erschienene Produkte verkündet:
https://www.imgtec.com/blog/author/rys/.

Die FE war da schon draußen, und zumindest paper-launched waren die RX und Primitive Shaders zu dem Zeitpunkt auch schon, dass Produktion und (R)etail-Launch wegen nicht so toller Yields ziemlich schleppend anliefen lag nicht an ihm.

[HOT]

Ich bezweifle dass der yield schlecht war. Das hatte andere Gründe.

[Complicated]

Rys weiss von was er redet. Die Diskreditierung ist laecherlich.
Das war absolut nicht als Diskreditieren gemeint. Es ist mir lediglich aufgefallen, dass er kurz zuvor gewechselt ist und somit vielleicht noch nicht in alle internen Details der neuen Hardware eingeweiht war. Ich kenne Rys nicht und habe lediglich eine Vermutung ausgesprochen wie es zu der Diskrepanz kommem konnte.

Lächerlich ist einzig deine Interpretationen von dem was ich schrieb.

[horn 12]

Navi soll bereits MAI - Juni 2018 kommen und Vega komplett ersetzen
In Vega wird kaum noch investiert, AMD soll sich des "Flops" bewusst sein.

AMD Sitzt den Vega Launch einfach aus und hofft auf Navi und alles wird da reingesteckt... Aber diese Version kennen wir ja zur Genüge bereits... Dies hieß es bei Vega ebenfalls.

[Linmoum]

Du verwechselst 2018 mit 2019.

[MadPenguin]

Du verwechselst 2018 mit 2019.

Einfach nur trollen und lästig sein, oder hast du auch etwas Mehr als spöttelnde Kommentare?

[Linmoum]

Die Realität hat nichts mit trollen zu tun. Und die Realität ist nicht Navi Mitte 2018.

[MadPenguin]

Die Realität hat nichts mit trollen zu tun. Und die Realität ist nicht Navi Mitte 2018.

Weil du...
es einfach im Kaffeesatz gelesen hast?
es in der Glaskugel gesehen hast?
es von deinem Onkel, der bei Nvidia arbeitet, erfahren hast?
konkrete Beweise für deine Vermutung hast?

Vielleicht kann Leonidas einen Poll daraus machen...

Edit: Ich hasse es mobil Texte zu verfassen!

[BoMbY]

Wo wir gerade bei Treibern waren - in der amdocl.dll vom 17.12.1 Treiber:

https://i.imgur.com/6816mSg.png

Edit: Und:

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

[Linmoum]

konkrete Beweise für deine Vermutung hast?

Das ist Fakt, keine Vermutung. Beschäftige dich doch einfach mal mit dem Thema.

Navi kommt in 7nm, das ist offiziell. 7nm Tape-Outs soll(te) es laut Lisa Su noch in diesem Jahr geben. Frage ist damit geklärt, dass das Mitte 2018 nichts werden kann.

[Dino-Fossil]

Navi soll bereits MAI - Juni 2018 kommen und Vega komplett ersetzen
In Vega wird kaum noch investiert, AMD soll sich des "Flops" bewusst sein.

AMD Sitzt den Vega Launch einfach aus und hofft auf Navi und alles wird da reingesteckt... Aber diese Version kennen wir ja zur Genüge bereits... Dies hieß es bei Vega ebenfalls.

AMD sagt halt einfach gar nix dazu und es wird dann jede Menge interpretiert bzw Gerüchte gesponnen.
Gegenwärtig gibt es mMn keinerlei Hinweise für irgendwas in die Richtung "Vega wird aufgegeben" oder "Navi vorgezogen" (als ob das überhaupt ginge) - und ich bin durchaus der Meinung das Vega relativ entäuschend war.

Eher schon würde ich 2018 einen "gefixten" Vega in 12nm erwarten - aber auch nur dann, wenn da überhaupt ein richtiger Defekt vorliegt und nicht einfach nur das Design ein Griff ins Klo war, bzw eben nicht so effektiv wie erhofft.

[MadPenguin]

Das ist Fakt, keine Vermutung. Beschäftige dich doch einfach mal mit dem Thema.

Navi kommt in 7nm, das ist offiziell. 7nm Tape-Outs soll(te) es laut Lisa Su noch in diesem Jahr geben. Frage ist damit geklärt, dass das Mitte 2018 nichts werden kann.

Mitte 2018 habe ich nie erwähnt: Dein "mach 2019 anstatt 2018" habe ich angezweifelt. Tapeout soll laut verschiedenen Medien noch 2017 stattfinden. 1 Jahr danach sollte der Chip fertig sein.

Momentan stehen Gerüchte gegen deine erfundenen "Fakten". Würde sagen 1:1 aktuell. ;D

[Iruwen]

Zwischen "fertig" und "lieferbar" kann einige Zeit vergehen wie man gerade sieht.

[Complicated]

Das ist Fakt, keine Vermutung. Beschäftige dich doch einfach mal mit dem Thema.

Navi kommt in 7nm, das ist offiziell. 7nm Tape-Outs soll(te) es laut Lisa Su noch in diesem Jahr geben. Frage ist damit geklärt, dass das Mitte 2018 nichts werden kann.
Wie wäre es wenn du das mal überprüfst?
Hier eine offizielle Quelle die 7nm GF in 2018 bestätigt.

https://www.extremetech.com/computing/250936-globalfoundries-announces-early-7nm-availability-40-improved-performance-14nm-finfet
The first customer launches on 7nm LP are expected 12-18 months from now, and GF is promising that it can deliver up to 40 percent improved performance compared with 14nm.
Juni 2017+12-18 Monate für "volume production". Davor schon "risc production", wofür Navi ein Kandidat ist.
Ein weiteres Indiz zusätzlich ist, dass TSMC ebenfalls schon 2018 Snapdragons 855 in 7nm produzieren wird obwohl GF erster bei 7nm Design sein wird.

Quelle für "risc production" in 1H/2018
https://www.golem.de/news/auftragsfertiger-globalfoundries-kuendigt-7-nm-technik-fuer-2018-an-1609-123286.html
Erste Testchips mit 7-nm-FinFET-Technik laufen in der Fab 8 Malta bereits vom Band, die Vorabfertigung (Risk Production) soll im ersten Halbjahr 2018 starten - die Serienfertigung ergo einige Monate später.
7nm GF kommt in 2018. Das ist mehrfach bestätigt.

[robbitop]

Ich tippe auch eher auf Ende 2018 wenn nicht eher Anfang 2019. 2018 würde ich eher 12nm sehen.

Kenne auch keine Serien GPU die (außer vieleicht den ursprünglichen nv30 @130nm ulk - der kam übrigens mit 0% yield zurück) jemals im Zeitfenster der risk production hergestellt wurde. Da laufen idr eher mobile SoCs oder kleinere asics vom Band.

Im Ausnahmefall auch mal ein Pipecleaner ala rv740.

Dazu kommt idr dass man erstmal eine ganze Menge Chips sammelt. Idr sind selbst beim Release einer Seriengraka die Chips oftmals schon vor Monaten produziert worden. Sicherlich sind da noch etliche andere Dinge in der Kette der Gesamt Durchlaufzeit.

[Complicated]

Das eine schließt das andere nicht aus. GPU wird es aus Kostengründen nicht in 12nm geben IMHO. Die selben Gründe sprechen dagegen wie sie gegen 10nm gesprochen haben. Navi wird in 7nm kommen. Ryzen im 12nm Refresh. AMD wird verhindern, dass ihnen in der nächsten Generation die selben Engpässe in der Fertigung eine Umsatzbremse sind wie nun in 14nm.

Navi ist ein möglicher Kandidat für Risc production wenn man die Strategie der kleinen Dies wie bei Zeppelin zu Grundelegt. Das ist natürlich noch nicht bestätigt, könnte aber eben die entscheidenden Monate Vorsprung bedeuten was die Yields angeht.

[robbitop]

Navi ist 7nm. Kommt IMO aber erst 2019. Vorher kommt imo ein 12nm Vega Refresh. Oder aber man sitzt 12nm aus und hat 2018 halt keine neue high end gpu... kann auch sein. Und man refresht Polaris.

[AffenJack]

GPUs kommen genauso wie CPUs in 12nm. Hat man beides doch angekündigt. Sowohl Vega als auch Zen waren auf AMDs Folien auf 14+, welches auch nur in 12nm umbenannt wurde.

Ich sehe Navi auch nicht vor 2019. Gf ist ein halbes Jahr hinter TSMC bei 7nm und Gf Versprechungen kann man noch weniger als TSMCs glauben.

[robbitop]

Sehe ich auch so. Wobei 12nm Vega durchaus auch ein Midgrange Produkt sein kann (aber nichmuss).

War gf @7nm noneuv nicht vor tsmc?

Edit:
https://www.extremetech.com/computing/249075-foundry-futures-tsmc-samsung-globalfoundries-intel-gear-7nm-beyond

GF ist h2 2018 dran (7nm duv), samsung und tsmc in h2 2019 (7lpp und cnl7ff+)

Edit TSMCs cnl7ff kommt eher.

[AffenJack]

War gf @7nm noneuv nicht vor tsmc?

Edit:
https://www.extremetech.com/computing/249075-foundry-futures-tsmc-samsung-globalfoundries-intel-gear-7nm-beyond

GF ist h2 2018 dran (7nm duv), samsung und tsmc in h2 2019 (7lpp und cnl7ff+)

TSMC non EUV ist CLN7FF ab H1 2018. Du vergleichst gerade Gfs non-EUV mit TSMCs EUV Prozess. TSMC 7nm ist seit April 17 in risk production und geht in H1 18 in Massenproduktion für Apple. GF sagt dagegen risk production H1 18 und Massenproduktion H2 18.

[robbitop]

Du hast Recht.

[AffenJack]

Aber trotzdem hat AMD mit GF bei 7nm zumindest zeitlich gute Karten. Wenn man Navi anfang 2019 bringt, könnte das bis zu 6 Monate Vorsprung gegenüber Nv bei 7nm bedeuten. Mit der heutigen Meldung, dass Qualcomm bei 7nm auch zu TSMC zurückkehrt setzen nun beide Schwergewichte (Apple, QC) auf TSMC. Ich kann mir nicht vorstellen, dass Nvidia da schnell an Wafer kommen wird. Ist wohl die Chance für AMD, die man nutzen muss.

[lowkres]

Hoffen wir das AMD Navi noch 2018 rausbringt. Ein Vega in 12nm wird kein Land gegen Nvidias Ampere sehen.

Edit: http://www.pcgameshardware.de/RAM-Hardware-154108/News/Nvidia-Ampere-AMD-Navi-Micron-GDDR6-Sampling-1246539/

Navi wird eventuell mit GDDR6 kommen. Ob das für die High-End Modelle auch gilt ist natürlich fraglich, aber ein RX 680 mit GDDR6 auf Navi Basis wäre echt nice.

[Hübie]

Lasst euch mal nicht von den Marketingnamen blenden. 7 nm ist nicht gleich 7 nm. ;)

[fondness]

GPUs kommen genauso wie CPUs in 12nm. Hat man beides doch angekündigt. Sowohl Vega als auch Zen waren auf AMDs Folien auf 14+, welches auch nur in 12nm umbenannt wurde.

Ich sehe Navi auch nicht vor 2019. Gf ist ein halbes Jahr hinter TSMC bei 7nm und Gf Versprechungen kann man noch weniger als TSMCs glauben.

Hieß es nicht vor kurzem, Navi kommt von tsmc?

[Complicated]

Es bezeichnet den Performance Level. 14nm von Intel hat auch keinen nenenswerten Mehrwert mehr gehabt gegenüber GF mit Zen Architektur.

Navi könnte sogar von TSMC kommen. Einen entsprechenden Pasus hat AMD für 7nm ja im WSA verankert.

Was man nicht vergessen sollte ist auch, dass AMD beim Transit 14nm zu 7nm die selben Tools nutzen will für Ryzen. Hier könnte erneut ein Engpass für die Fertigung entstehen wenn 14 und 7 nm die selben Linien nutzen würden. Da wäre TSMC eine sinnvolle Erweiterung der Kapazität.

[Hübie]

Iirc nutzt Gf weiterhin dual pattering für 7 nm während TSMC quad pattering erfordert. Das ist immenser Aufwand.

[robbitop]

Ich könnte mir auch gut vorstellen, dass man 2018 analog zu 2016 sich auf Mainstream konzentrieren. Polaris war relativ erfolgreich. Ein Konkurrent zu GA106 wäre nicht gerade dumm. GA106 hat vermutlich wieder 1/3 des Flaggschiffs (GA102 - hier tippe ich auf 5120 sps). Also liegt man irgendwo bei ~1700 sps.
Ein Vega mit 40 CUs und 256bit gddr6 wäre hier kein schlechter Kontahent. In 12nm mit leicht höheren Taktraten. Und wer weiß, vielleicht bringen ein paar bugfixes ggü V10 noch etwas mehr taktnormierte Leistung oder Bandbreiteneffizienz. Sich auf den Massenmarkt zu konzentrieren ist sicherlich nicht dumm...

[tm0975]

Hoffen wir das AMD Navi noch 2018 rausbringt. Ein Vega in 12nm wird kein Land gegen Nvidias Ampere sehen.

vega scheint ein paar bugs zu haben, die per treiber nicht zu umschiffen sind. ich kann mir nicht vorstellen, dass vega so geplant war, wie die architektur auf dem markt gekommen ist.

[Pirx]

die könnten sie ja dann mit "12 nm" beheben, sonst sehe ich auch nicht, wie man damit konkurrenzfähig sein will.

[Hübie]

Ich könnte mir auch gut vorstellen, dass man 2018 analog zu 2016 sich auf Mainstream konzentrieren. Polaris war relativ erfolgreich. Ein Konkurrent zu GA106 wäre nicht gerade dumm. GA106 hat vermutlich wieder 1/3 des Flaggschiffs (GA102 - hier tippe ich auf 5120 sps). Also liegt man irgendwo bei ~1700 sps.
Ein Vega mit 40 CUs und 256bit gddr6 wäre hier kein schlechter Kontahent. In 12nm mit leicht höheren Taktraten. Und wer weiß, vielleicht bringen ein paar bugfixes ggü V10 noch etwas mehr taktnormierte Leistung oder Bandbreiteneffizienz. Sich auf den Massenmarkt zu konzentrieren ist sicherlich nicht dumm...

Da hat man aber marketing-technisch nicht den Mitnahme-Effekt. Dumm ist es nicht, aber auch nicht optimal. Hier wird man aber zumindest nicht die hohen Kosten mit HBM haben. Ich erwarte aber nicht weniger als 64, da Polaris ne mittlerweile ziemliche Gurke ist. Da würde die Vega Architektur nicht signifikant was ändern.

[Piefkee]

Iirc nutzt Gf weiterhin dual pattering für 7 nm während TSMC quad pattering erfordert. Das ist immenser Aufwand.

Der 7nm GF ist ein quad patterning process, zuminderst der für HP.
Der SoC(Mobile) ist ein dual patterning process.



This process features a very aggressive fin pitch of 30nm which uses quad-patterning with a gate pitch of 56 nanometers which uses SADP. However, in order to maintain higher flexibility for their customers, GlobalFoundries restricted their BEOL to double patterning and a more relaxed metal pitch of 40nm.

https://fuse.wikichip.org/news/641/iedm-2017-globalfoundries-7nm-process-cobalt-euv/5/

[HOT]

Der 7nm GF ist ein quad patterning process, zuminderst der für HP.
Der SoC(Mobile) ist ein dual patterning process.

https://fuse.wikichip.org/news/641/iedm-2017-globalfoundries-7nm-process-cobalt-euv/5/
Bisherigen Infos zufolge sollte Glofo ne Mischung aus triple und dual patterning nutzen. Vielleicht gibts jetzt auch quad patterning, die info ist aber neu.

[cat]

https://www.eetimes.com/document.asp?doc_id=1332049

EE Times
AMD’s CTO on 7nm, Chip Stacks
Papermaster calls for EUV ASAP
(Rick Merritt) 7/24/2017 00:31 AM EDT

Zitat:
In 7nm it requires even deeper cooperation [because] we have quad patterning on certain critical levels

Papermaster expects foundries will begin to use extreme ultraviolet (EUV) lithography starting in 2019 to reduce the need for quad patterning.

[reaperrr]

Findet es außer mir eigentlich sonst noch jemand beunruhigend, dass AMD ab Ampere-Launch mindestens bis Navi wahrscheinlich nicht mal mehr von der Performance her mit dem aktuellen Gx104-Chip von Nvidia mithalten können wird?

Hawaii war wenigstens von der Perf und Chipgröße noch nah an GM204, Fiji von der Perf noch relativ nah an GM200 und dem 16nm GP104 salvage (1070), aber V10 brauchte jetzt schon Wakü um die Performance von GP104-Full zu erreichen.

Selbst wenn V20 wirklich 7nm und nicht 12nm ist und noch in Q3 kommt, wird der maximal vielleicht 15% Spieleperformance auf V10 draufpacken (höherer Takt und mehr Speicherbandbreite), vor allem aber durch die 4 HBM2-Stacks und teuren 7nm-Wafer zu teuer herzustellen sein, um ihn preislich gegen GA104-Salvage antreten zu lassen, und an GA104-Full wird er kaum rankommen. Könnte also u.U. HPC/Pro/Mining-exklusiv sein und gar nicht für Gamer kommen, bzw. nur als Frontier Edition (also P/L-mäßig nicht für Gaming geeignet, jedenfalls verglichen mit den Geforces).

Dass Navi noch 2018 kommt glaube ich nicht, einerseits wegen 7nm (muss für Gaming-Karten bessere Yields und niedrigere Wafer-Preise haben, als das in Q3/Q4 2018 vermutlich noch der Fall sein wird), andererseits weil AMD's Grafiksparte die letzten Jahre eigentlich immer etwas hinter dem idealen Zeitplan herhinkte.
Von daher muss zusätzlich zu 7nm der Architektur-Sprung nochmal größer als bei Vega ausfallen, wenn AMD nicht völlig den Anschluss verlieren bzw. diesen idealerweise wieder herstellen will.

[HOT]

Na ja, das ist ein halbes Jahr, dann steht es NVs 12FFN vs. AMDs 7FF...

[MadPenguin]

Im Frühjahr steht ja noch Vega refresh vs. 1-2 Monate später Ampere an. Wieso wissen bereits alle wie dieser Kampf ausgehen wird?

[Bucklew]

Warum sollte VegaRefresh plötzlich so viel schneller werden, dass man gegen Pascal geschweige denn Ampere eine Chance hat?

[basix]

Secret Sauce ;)

Momentan ist nicht ganz klar, wie viel Potential noch im TBR und vor allem den Primitive Shadern stecken. Gibt es noch Potential oder war das schon alles? Rein gefühlt sollte dort noch sehr viel möglich sein.

[MadPenguin]

Secret Sauce ;)

Momentan ist nicht ganz klar, wie viel Potential noch im TBR und vor allem den Primitive Shadern stecken. Gibt es noch Potential oder war das schon alles? Rein gefühlt sollte dort noch sehr viel möglich sein.

Genau das meine ich. Kann auch sein dass es eine wieder zu hohe Erwartungs-Haltung ist, aber Vega kann nicht das sein, was gelaunched wurde. Das ist ziemlich viel schief gelaufen. Deshalb abwarten :)

[|MatMan|]

Im Frühjahr steht ja noch Vega refresh vs. 1-2 Monate später Ampere an. Wieso wissen bereits alle wie dieser Kampf ausgehen wird?
Vetsteh ich dich richtig, dass du meinst ein Vega Refresh (V20) kommt noch vor Ampere? Wo ist das zugehörige Tamtam? Wenigstens ne Ankündigung? Die Vorbereitung zur Produktion müsste ja zumindest bei einem Hersteller laufen, wodurch es dann in der Regel irgendwelche Leaks gäbe. Außer V20 wird analog zu P10 -> P20, also nur etwas mehr Taktrate. Das ginge instant, allerdings ist der Spieleaum eher klein, da V10 schon mit der Brechstange verhauen wurde.
Für wahrscheinlicher halte ich, dass V20 tatsächlich ein im Detail überarbeiteter V10 ist + FP64 (und ggf. andere Profianpassungen) und erscheint dann grob 1 Jahr nach V10.
Navi wird wohl kaum vor Zen2 im neuen 7nm Prozess erscheinen. Zen ist wichtiger und hatte schon vor Vega Priorität. Auch wird AMD nicht 2 Topmodelle in einem Jahr rausbringen. Daher imho Navi nächstes Jahr. Überraschen lass ich mich natürlich gern :-)

[basix]

Navi wird wohl kaum vor Zen2 im neuen 7nm Prozess erscheinen. Zen ist wichtiger und hatte schon vor Vega Priorität. Auch wird AMD nicht 2 Topmodelle in einem Jahr rausbringen. Daher imho Navi nächstes Jahr. Überraschen lass ich mich natürlich gern :-)

Lisa Su hat mal erklärt, man wolle agressiv auf 7nm setzen, d.h. früh wechseln. Siehe Meldungen zu 7nm Tapeouts 2017. Ich nehme an, dass die EPYC Nachfolger im Sommer / Herbst bereits auf 7nm basieren, da dies den grössten Business Impact haben sollte und die Margen hoch sind. Consumer wird ein paar Monate später folgen, evtl. Frühjahr. Navi wird im Optimalfall ebenfalls gegen Ende 2018 erscheinen. Ich hoffe zumindest, dass so früh etwas kommt.

[MadPenguin]

Vetsteh ich dich richtig, dass du meinst ein Vega Refresh (V20) kommt noch vor Ampere? Wo ist das zugehörige Tamtam? Wenigstens ne Ankündigung? Die Vorbereitung zur Produktion müsste ja zumindest bei einem Hersteller laufen, wodurch es dann in der Regel irgendwelche Leaks gäbe. Außer V20 wird analog zu P10 -> P20, also nur etwas mehr Taktrate. Das ginge instant, allerdings ist der Spieleaum eher klein, da V10 schon mit der Brechstange verhauen wurde.
Für wahrscheinlicher halte ich, dass V20 tatsächlich ein im Detail überarbeiteter V10 ist + FP64 (und ggf. andere Profianpassungen) und erscheint dann grob 1 Jahr nach V10.
Navi wird wohl kaum vor Zen2 im neuen 7nm Prozess erscheinen. Zen ist wichtiger und hatte schon vor Vega Priorität. Auch wird AMD nicht 2 Topmodelle in einem Jahr rausbringen. Daher imho Navi nächstes Jahr. Überraschen lass ich mich natürlich gern :-)

Hmm. AMD hat doch schon angekündigt, dass Vega und Ryzen Frühjahr 2018 einen 12nm Refresh kriegen. Hab ich was verpasst in der Zwischenzeit?

[HOT]

Wenn es einen Refresh gibt, ist das nicht V20, da V20 wohl der Hawaii-Nachfolger mit hoher DP-Leistung wird und in 7nm TSMC gefertigt werden soll.
Eine 12LP-Variante von V10 könnte es dennoch ebenfalls geben, dieser wird sich aber 0 vom bisherigen V10 unterscheiden, sondern dürfte ausschließlich höhere Takte ermöglichen.
Vom Zeitplan her kann man denke ich einen potenziellen 12nm V10 wohl ca. Mai erwarten, V20 wohl ab Q4, da aber zuerst im Profibereich und Navi10 denke ich Anfang 2019.

[dargo]

Eine 12LP-Variante von V10 könnte es dennoch ebenfalls geben, dieser wird sich aber 0 vom bisherigen V10 unterscheiden, sondern dürfte ausschließlich höhere Takte ermöglichen.

Nur höhere Taktraten werden einem Vega Refresh nichts nenneswertes bringen. Dafür müsste gleichzeitig der Takt von HBM2 Richtung ~1,2Ghz (Default versteht sich). Und danach sieht es aktuell nicht aus. 4 Stacks wären totaler Overkill, 3 Stacks eigentlich auch.

Findet es außer mir eigentlich sonst noch jemand beunruhigend, dass AMD ab Ampere-Launch mindestens bis Navi wahrscheinlich nicht mal mehr von der Performance her mit dem aktuellen Gx104-Chip von Nvidia mithalten können wird?

Hawaii war wenigstens von der Perf und Chipgröße noch nah an GM204, Fiji von der Perf noch relativ nah an GM200 und dem 16nm GP104 salvage (1070), aber V10 brauchte jetzt schon Wakü um die Performance von GP104-Full zu erreichen.

Auf welchen Fakten basieren diese absurden Annahmen?
https://www.computerbase.de/2017-12/grafikkarten-round-up-2018/2/#diagramm-performancerating-fps-2560-1440

Edit:
Mal zum Vergleich Release vs. aktueller Stand bei RX Vega64 vs. GTX1080.

https://abload.de/img/cb_15gs75.jpg https://abload.de/img/cb_231sit.jpg

Quelle (https://www.computerbase.de/2017-08/radeon-rx-vega-64-56-test/4/#diagramm-doom-2560-1440)

Neuere Games im Parcour, neuere Treiber, neuere Game-Patches, neuere Systembasis... da kommt was zusammen. Lasse noch paar neuere Games mehr kommen wo die Entwickler genau so viel Hirnschmalz investieren wie Machine Games (wobei Async Compute auf GCN immer noch kaputt ist und bremst, ohne Async Compute gibts nur schwarzen Bildschirm)...

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

schon verschiebt sich das Rating noch stärker Richtung Vega. Und bevor mir wieder einer mit Cherry Picking kommt... auch in einigen anderen Games sieht es trotz DX11 für Vega keineswegs schlecht aus im Vergleich zur Konkurrenz.

https://abload.de/img/cb_4yqsf2.jpg https://abload.de/img/cb_56ms65.jpg https://abload.de/img/cb_6kzsnz.jpg

Die Leistung ist da, man muss sie nur abrufen. Wenn man schon was kritisieren möchte dann eher die Verfügbarkeit von Vega.

[BoMbY]

Hmm. AMD hat doch schon angekündigt, dass Vega und Ryzen Frühjahr 2018 einen 12nm Refresh kriegen. Hab ich was verpasst in der Zwischenzeit?

Nein, sie haben keinen Refresh angekündigt - folgendes wurde gesagt (http://www.tomshardware.com/news/amd-ryzen-vega-12nm-lp-2018,35502.html):

Mark Papermaster announced that the company will be transitioning “graphics and client products” from the Global Foundries 14nm LPP FinFET process it uses today to the new 12nm LP process in 2018.

Und nichts davon bedeutet "Refresh".

[reaperrr]

Auf welchen Fakten basieren diese absurden Annahmen?
https://www.computerbase.de/2017-12/grafikkarten-round-up-2018/2/#diagramm-performancerating-fps-2560-1440
http://www.pcgameshardware.de/Radeon-RX-Vega-64-Grafikkarte-266623/Tests/Benchmark-Preis-Release-1235445/3/

Ich sehe da mehrere klare Niederlagen und nur den einen klaren Sieg in Doom und ein paar Gleichstände.

Gut, computerbase hat wesentlich mehr Spiele getestet, aber daran, dass die V64Air mehr klare Niederlagen als die 1080FE erleidet ändert das nichts, und daran, dass es von der 1080 viele flächendeckend verfügbare OC-Modelle ohne großen Aufpreis gibt, die selbst der V64LQ Probleme bereiten dürften, auch nicht.

Also ein bisschen selektiv vielleicht, aber absurd? Wohl kaum.
Ich bin übrigens nach wie vor eher AMDler und hoffe, dass sich die Situation schnellstens bessert.

[MadPenguin]

Nein, sie haben keinen Refresh angekündigt - folgendes wurde gesagt (http://www.tomshardware.com/news/amd-ryzen-vega-12nm-lp-2018,35502.html):



Und nichts davon bedeutet "Refresh".

Da sagen "Profis" etwas Anderes:
http://www.tomshardware.com/news/amd-ryzen-vega-12nm-lp-2018,35502.html

Hat jetzt mit Navi wenig zu tun. Also sollten wir es jetzt lassen :)

[dargo]

http://www.pcgameshardware.de/Radeon-RX-Vega-64-Grafikkarte-266623/Tests/Benchmark-Preis-Release-1235445/3/

Ich sehe da mehrere klare Niederlagen und nur den einen klaren Sieg in Doom und ein paar Gleichstände.

Siehe mein Edit. Und übrigens... am Beispiel von Wolfenstein 2 sieht man, dass die Entscheidung von AMD RX Vega64 mit einer Asicpower von 220W im Defaultsetting Bios 1 zu releasen langfristig eher kontraproduktiv war. Jetzt muss AMD damit leben, dass alle Redaktionen eben mit diesem Setting benchen und natürlich dann auch den Stromverbrauch messen. Bzw. die ~300W sich in die Köpfe eingebrannt haben. Das Ding wäre selbst mit 165W ASIC auf GTX 1080TI Niveau sobald Asyc Compute richtig funktioniert. Selbst AC Off würde dafür schon reichen.

Edit:
Nur damit du ein Gefühl dafür bekommst von welchen Relationen ich hier überhaupt spreche (kein Undervolting!).


https://abload.de/img/20180103080849_1l7syl.jpg

https://abload.de/img/20180103081243_1vas5k.jpg

https://abload.de/img/20180103082148_14osm1.jpg

https://abload.de/img/20180103082357_1vtsb9.jpg

Spätestens bei 185W ASIC hätte ich einen Cut gemacht. Wen sollen 4% weniger Leistung denn jucken? Das merkt kein Schwein. Aber offenbar dachte sich AMD global gesehen zählt nur der Balken, egal was es kostet. Noch besser, einen Cut bei 175W ASIC. Dann sind es immer noch nur lächerliche 6% Leistung weniger. Dafür aber 58W weniger Verbrauch (ganze Karte, bei den ganzen Vergleichen beziehe ich mich auf die 286W von Igor bei 220W ASIC einer wassergekühlten Vega!). Das Ding würde einfach mit ~245W einen besseren Gesamteindruck hinterlassen als mit ~300W, meine bescheidenen Meinung nach und wäre immer noch sehr schnell.

Die 264W ASIC der Liquid setzt dem ganzen noch die Krone auf. Damit habe ich 145fps. Wahnsinn... 1% mehr gegenüber 220W. :uup:

Ich persönlich hätte die Air-Version mit 175-185W ASIC released und die Liquid von mir aus mit 220W. Den HBM2 dann mit 1Ghz, das hätte noch minimal (ca. 1%, in den Taktregionen von 1,4Ghz bis 1,5Ghz hängt Vega kaum an der Bandbreite) was aufgefangen. Beim letzteren kann AMD natürlich nichts machen wenn der Hersteller sagt wir können "nur" 945Mhz unter allen Bedingungen garantieren. Dem muss sich AMD natürlich beugen.

[Bucklew]

Mal zum Vergleich Release vs. aktueller Stand bei RX Vega64 vs. GTX1080.
Wahnsinn. Die RX Vega 64 ist ganze DREI (!) Prozent schneller als die GTX1080. Drei Prozent. Also 51,5 statt 50 fps. Der Wahnsinn.

Nun betrachten wir mal die technischen Daten:

Diefläche: +54%
Transistoren: +75%
Shaderleistung: +42%
Leistungsaufnahme: +63%

Echt der Wahnsinn, wie effizient AMD da doch agiert. Brauchen nur 50% mehr Diefläche und mehr als 50% mehr Leistungsaufnahme, um dann anschließend von jedem Custommodell mit 10% Übertaktung (also fast jedem) doch wieder überholt zu werden ;D

schon verschiebt sich das Rating noch stärker Richtung Vega. Und bevor mir wieder einer mit Cherry Picking kommt... auch in einigen anderen Games sieht es trotz DX11 für Vega keineswegs schlecht aus im Vergleich zur Konkurrenz.
Was ist CherryPicking denn sonst, als nach einem Rating mit einem marginalen Vorsprung plötzlich ein, zwei Spiele raus zu kramen, wo es mal mehr sind? ;D

Man sollte mal ein Best-of-Vega-Speku-Thread-vor-Release machen. Was wurde da nicht Stunk gegen alle gemacht, die auch nur ansatzweise mal die damals kursierenden Leaks mit Vega~GTX1080 erwähnt haben. Was wird Vega die GTX1080Ti platt machen. Und heute ist man froh, wenn es tatsächlich mal 3% schneller als eine 1080 FE ist ;D

Echt großes Kino, großes Kino! Ich brauch mehr Popcorn, mehr davon dargo, mehr davon! ;D

[tm0975]

das sagt doch nur, dass amd zur darstellung eines bildes mehr berechnet als nvidia. der rest paßt doch. und der "software"-nachteil wird auch irgendwann mal verschwinden...

[|MatMan|]

Wenn es einen Refresh gibt, ist das nicht V20, da V20 wohl der Hawaii-Nachfolger mit hoher DP-Leistung wird und in 7nm TSMC gefertigt werden soll.
Eine 12LP-Variante von V10 könnte es dennoch ebenfalls geben, dieser wird sich aber 0 vom bisherigen V10 unterscheiden, sondern dürfte ausschließlich höhere Takte ermöglichen.
Vom Zeitplan her kann man denke ich einen potenziellen 12nm V10 wohl ca. Mai erwarten, V20 wohl ab Q4, da aber zuerst im Profibereich und Navi10 denke ich Anfang 2019.
Also gleich 3 große neue Chips innerhalb eines Jahres? Das halte ich für extrem unwahrscheinlich. Wenn V20 etwas wie Hawaii wird, also neues Topmodell mit hoher DP-Leistung, und in Q4 2018 kommt, dann kommt ein noch schnellerer Navi nicht schon in Q1 2019. Außer Navi wird ein Polaris 10 Nachfolger mit vielleicht 250mm2. Das wäre dann von der Performance her reichlich unspektakulär.

[dargo]

Was ist eigentlich aus V11 geworden? Kommt da nichts mehr? Ich dachte V11 kommt als Nachfolger für Polaris in 2018. Oder wartet AMD bei V11 nur noch auf GDDR6?

[AffenJack]

Was ist eigentlich aus V11 geworden? Kommt da nichts mehr? Ich dachte V11 kommt als Nachfolger für Polaris in 2018. Oder wartet AMD bei V11 nur noch auf GDDR6?

Ist einerseits gut möglich, dass er erst mit GDDR6 kommt und andererseits kann es sein, dass er direkt in 12nm kommt und auch deshalb noch etwas länger braucht. Klingt für mich zumindest wahrscheinlicher, als dass man Vega10 noch mal in 12nm refresht.

[dargo]

Stimmt... wenn man eh auf GDDR6 warten muss dann kann man auch gleich den 12nm Fertigungsprozess mitnehmen.

[Dino-Fossil]

Vermutlich wurde der ursprünglich geplante V11 verworfen.
Ausgehend von V10 wäre es wohl ein Chip geworden, der sich in der Performance nur wenig von Polaris unterscheidet, dafür aber deutlich teurer wäre.
Damit hätte man abgesehen von einer gewisse Harmonisierung des GPU-Portfolios kaum Vorteile, aber handfeste Nachteile.
Daher denke ich auch, dass wir ihn wohl nur mit gewissen Überarbeitungen (z.B. 12nm, Bugfixes?, GDDR6) sehen dürften.

[|MatMan|]

Ich tippe darauf, dass V11 auf dem Package der Intel CPU sitzt. Das ist eine stinknormale GPU mit einem HBM Stack. Die Entwicklung wäre viel zu teuer um die GPU nur in so einem Nischenprodukt zu verwenden. Allerdings hat sich AMD scheinbar verschätzt wie wirtschaftlich die HBM-Kombo zu fertigen ist...

[tm0975]

mit dem semi-custom von intel wird die verkaufte und benötigte hmb menge endlich steigen und damit deren preis sinken. das sollte den weg aus der niesche beschleunigen, denn technologisch ist das ganze ja deutlich überlegen. ich denke nicht, dass amd für vega nachfolger ohne hbm planen sollte.

[Dino-Fossil]

Ich tippe darauf, dass V11 auf dem Package der Intel CPU sitzt. Das ist eine stinknormale GPU mit einem HBM Stack.

Wäre evtl. auch möglich, vielleicht kam der Intel-Deal sogar erst nachdem V11 bereits (weitestgehend) in trockenen Tüchern war und damit eine willkommene Gelegenheit, die darauf aufgewendeten Ressourcen doch noch (oder jedenfalls mit überschaubarem Mehraufwand) nutzen zu können.

Obwohl ich da vielleicht ein wenig optimistisch bin, sicherlich hat so eine Lösung dann doch gewisse Mehranforderungen ggü. einer dGPU.

[robbitop]

AMD tut gut daran, sich ihre knappen Ressourcen einzuteilen. Das Massenprodukt ist die 2xx € Klasse. Da war Polaris ein guter Griff. Gegen GA106 wird man braucht dort was passendes brauchen. Ich vermute, dass V10 gar nicht so viel Umsatz brachte. Fijii vermutlich auch nicht.
Bei V10 scheint auch etwas kaputt zu sein. 12,5 Mrd Transistoren. 2,2x so viel wie P20. Performance aber nur ~1,6x. Ein doppelter P20 wäre wohl schneller gewesen.
Das kann ja nicht Anspruch einer neuen mArch sein.

Ich tippe mal darauf, dass Nachfolgeprodukte hier eher wieder besser als Polaris und nicht schlechter werden was perf/Transistor angeht..


Ein Vega mit 40 CUs @~1,5 GHz sollte hier für GA106 reichen. Mit 12LP sollte man unter 300 sqmm bleiben können. >=10GT/s sollten dann für 256 bit Memory reichen. GDDR5X oder GDDR6.

[dargo]

Bei V10 scheint auch etwas kaputt zu sein. 12,5 Mrd Transistoren. 2,2x so viel wie P20. Performance aber nur ~1,6x. Ein doppelter P20 wäre wohl schneller gewesen.

Ach komm... ich kann diesen Unsinn echt nicht mehr hören.

Es stehen immer noch die primitiven Shader im Raum. Dann hat FP16 nicht ganz die Erwartungen bei Wolfenstein 2 geliefert was Performancevorteile angeht wenn ich gravitationsfeld richtig verstanden habe. In Wolf 2 sehe ich +68% wo eine Vega Air ins TT-Limit läuft. Die RX580 läuft afaik nur ins PT-Limit. Ich würde das aber gerne erst richtig bewerten wenn Async Compute richtig implementiert ist. Ich habe keinen blassen Schimmer wie stark sich das aktuell negativ auf Polaris auswirkt und ob ein richtig funktionierendes AC auf Polaris und Vega prozentual gleich viel Mehrleistung bringt oder ob es da auch Unterschiede gibt. Immerhin reden wir hier von 2304 vs. 4096 Shadern.

Mal was zum nachdenken... was ist bei GP102 kaputt? 50% größere Die Size und nur 29% schneller als GP104 @1440p oder 32% @4K beim neuesten Performanceranking der CB.

PS: ich finde es einfach befremdlich sich auf Vergleiche zu stürzen wo mehr als offensichtlich ist, dass die Software und nicht die Hardware limitiert.

PPS: einige Transistoren (weil du diese gerade verglichen hast) sind auch für die wesentlich höheren Frequenzen drauf gegangen gegenüber Polaris.

Mich erinnert die ganze Diskussion unheimlich an Tahiti damals. Was wurde da alles nicht über ein limitierendes Frontend spekuliert. Heute muss man sich nur mal anschauen wo Tahiti gegenüber Kepler in Games steht die auch für GCN optimiert sind.

[Dino-Fossil]

Ach komm... ich kann diesen Unsinn echt nicht mehr hören.

Es stehen immer noch die primitiven Shader im Raum. Dann hat FP16 nicht ganz die Erwartungen bei Wolfenstein 2 geliefert was Performancevorteile angeht wenn ich gravitationsfeld richtig verstanden habe.

Kein neues Feature (HBCC mal außen vor gelassen, weil bei 8GB+ aktuell schwer zu bewerten) hat bei Vega die Erwartungen bisher wirklich erfüllen können.
Das kann ein Treiberproblem sein, aber mittlerweile (aufgrund der verstrichenen Zeit) glaube ich auch eher, dass da auch die Hardware nicht ganz so läuft, wie man mal wollte.
Auf die PS sollte man auch nicht zu viel Hoffnung setzen, da ist ebenfalls zu vieles unklar - vor allem wann wir überhaupt Software sehen, die die effektiv nutzen kann.

Und auch im Vergleich zu Polaris ist Vega ein wenig enttäuschend - schaut man sich z.B. Wolfenstein 2 an, dann kann da auch Polaris einiges reißen. Ebenfalls aufgrund ordentlicher Optimierung auf (neuere) GCN-Architektur.
Aber abgesehen vom Mehr an CUs und Takt kann sich Vega trotzdem nicht klar absetzen.

Von daher - das ist meiner Meinung nach kein Unsinn, dass ist eine gerechtfertigte Betrachtungsweise von Vega zum jetzigen Zeitpunkt.

Wobei ich ebenfalls der Meinung bin - wie du ja auch, siehe oben - dass Vega besser angekommen wäre, hätte man das PT @default sinnvoller gesetzt.


PS: ich finde es einfach befremdlich sich auf Vergleiche zu stürzen wo mehr als offensichtlich ist, dass die Software und nicht die Hardware limitiert.

Ich finde es befremdlich einen Großteil der aktuellen Spielelandschaft - die nunmal noch nicht aus optimierten low-level Titeln besteht - auszublenden und so zu tun als wäre das irrelevant, nur weil es der eigenen Wunschvorstellung zuwiderläuft. :freak: :tongue:

[dargo]

Ich finde es befremdlich einen Großteil der aktuellen Spielelandschaft - die nunmal noch nicht aus optimierten low-level Titeln besteht - auszublenden und so zu tun als wäre das irrelevant, nur weil es der eigenen Wunschvorstellung zuwiderläuft. :freak: :tongue:
Ich empfehle mal genauer zu lesen was ich schreibe. Robbitop spekuliert auf einen kaputten V10 und leitet die Spekulation aus größtenteils unoptimierten Software. Ich rieche hier ganz klar ein deja vu zu Tahiti.

Kein neues Feature (HBCC mal außen vor gelassen, weil bei 8GB+ aktuell schwer zu bewerten) hat bei Vega die Erwartungen bisher wirklich erfüllen können.

Auf welchen Fakten basiert das? Zeig mir mal bitte die Benchmarks mit und ohne deiner genannten Features von Vega. Oh wait...

[Bucklew]

Ich vermute, dass V10 gar nicht so viel Umsatz brachte. Fijii vermutlich auch nicht.
Sieh dir die Verfügbarkeit an: AMD hat Vega schon lange abgeschrieben. Die produzieren nur noch ein paar Karten auf Sparflamme, um sich nicht die Blöße zu geben das ganze Projekt einzustampfen und halten so wenigstens den Straßenpreis hoch und ein paar Fanboys glauben, das läge an der Nachfrage.

Vega ist für AMD ein wahrscheinlich noch größerer Flop als Fiji - und das will etwas heißen.

Ach komm... ich kann diesen Unsinn echt nicht mehr hören.
:facepalm:

Mal was zum nachdenken... was ist bei GP102 kaputt? 50% größere Die Size und nur 29% schneller als GP104 @1440p oder 32% @4K beim neuesten Performanceranking der CB.
:facepalm: :facepalm:

GP102 hat nur 38% höheres PT ggü GP104. Ich wette, wenn du jeden Benchmark im CPU-Limit raus nimmst, kommst du genau auf diese 38% Vorsprung auf GP104.

Es ist sicherlich was kaputt, aber das ist nicht GP102. Wenn ich schreibe was, wäre das aber eine Beleidigung, spare ich mir also :ugly:

[|MatMan|]

Wäre evtl. auch möglich, vielleicht kam der Intel-Deal sogar erst nachdem V11 bereits (weitestgehend) in trockenen Tüchern war und damit eine willkommene Gelegenheit, die darauf aufgewendeten Ressourcen doch noch (oder jedenfalls mit überschaubarem Mehraufwand) nutzen zu können.

Obwohl ich da vielleicht ein wenig optimistisch bin, sicherlich hat so eine Lösung dann doch gewisse Mehranforderungen ggü. einer dGPU.
Nachdem jetzt bestätigt wurde, dass in der Intel CPU die Grafikeinheit vorhanden und aktiv ist, sehe ich nicht was da an der AMD semi-custom sein muss. Die wird normal über PCIe auf dem Package angebunden. Statt Interposer wird halt EMIB benutzt wofür man wahrscheinlich nicht einmal etwas an der GPU ändern musste. Wenn also Intel nicht unbedingt bestimmte Features in der GPU haben wollte, dann ist das ne stinknormale dGPU.

[robbitop]

Ach komm... ich kann diesen Unsinn echt nicht mehr hören.

Es stehen immer noch die primitiven Shader im Raum. Dann hat FP16 nicht ganz die Erwartungen bei Wolfenstein 2 geliefert was Performancevorteile angeht wenn ich gravitationsfeld richtig verstanden habe. In Wolf 2 sehe ich +68% wo eine Vega Air ins TT-Limit läuft. Die RX580 läuft afaik nur ins PT-Limit. Ich würde das aber gerne erst richtig bewerten wenn Async Compute richtig implementiert ist. Ich habe keinen blassen Schimmer wie stark sich das aktuell negativ auf Polaris auswirkt und ob ein richtig funktionierendes AC auf Polaris und Vega prozentual gleich viel Mehrleistung bringt oder ob es da auch Unterschiede gibt. Immerhin reden wir hier von 2304 vs. 4096 Shadern.

Polaris profitiert auch von AC. Die CUs sollen ja sehr ähnlich sein. Nur von FP16 nicht. Und die primitive shader werden ja nicht eingesetzt und man hört auch nichts mehr davon. Könnte wohl sein, dass an der HW was kaputt ist. Auch die Bandbreiteneffizienz sollte dank DSBR besser sein. Auch da hakt irgendwas.
Ich tippe aber mal darauf, dass AMD das mit der nächsten Gen in Ordnung bringt.

In Wolfenstein 2 (das ist momentan das optimierteste Stück SW) liegt Vega auch nicht annähernd Faktor 2,2 von RX580.

[dargo]

Polaris profitiert auch von AC.

Ich habe nichts anderes behauptet. In welchem Verhältnis zu Vega wissen wir aber noch nicht.


In Wolfenstein 2 (das ist momentan das optimierteste Stück SW) liegt Vega auch nicht annähernd Faktor 2,2 von RX580.
Dein Faktor von 2,2 nur anhand von Transistoren zu bewerten ist imo ziemlich daneben. Das wirst du kaum erreichen. So ein Feature wie HBCC frisst auch Transistoren, bringt aber solange der Vram ausreicht kaum Vorteile. Zudem gingen wie ich schon sagte einige Transistoren bei Vega für die höheren Frequenzen drauf. Bei Pascal war es genau so gegenüber Maxwell. +80-90% halte ich noch für realistisch. Faktor 2 vielleicht, aber dann eher nur in Ausnahmefällen.

Auch die Bandbreiteneffizienz sollte dank DSBR besser sein. Auch da hakt irgendwas.

Ob da was hackt oder nicht kann ich nicht beurteilen. Ich kann dir aber sagen, dass die 484GB/s nirgendwo bei den üblichen Frequenzen einer luftgekühlten Vega limitieren. Wenn ich die Bandbreite um 6% anhebe und 1-2% mehr Leistung bekomme dann sehe ich hier keine Bandbreitenprobleme. So ab 1,6-1,7Ghz wirds dann schon etwas interessanter mit 1,0-1,1Ghz beim Speicher.

[robbitop]

Perf/W und Perf/mm² sind übliche Kennzahlen. Perf/W ist schwer zu sagen. Vega liegt im Auslieferungszustand in keinem besonders tollen Betriebspunkt. RX580 sicherlich auch nicht.
V56 und RX570 sind sicherlich ein besserer Vergleich (handoptimiert wie bei dir, lässt sich aus P20 und V10 sicherlich noch viel mehr rauskitzeln - das gilt aber für jede GPU ein Stück weit).
Hier liegt V56 nur ~30% höher als RX570. Hat aber eher 60% mehr Leistung.

Perf/mm² ist das gleiche wie Perf/Transistor (wenn Fertigungsprozess der gleiche ist). Das Thema hatten wir ja durch.

Das Problem ist IMO nicht V10s Leistung in Relation zu seinem Konkurrent (GP104). Sondern, dass V10 wahrscheinlich eine höhere BOM hat als GP104. Bedeutet, dass die Marge viel geringer für AMD ist. V10 liegt wahrscheinlich vergleichbar zu GP102 von der BOM. Wenn man vergleichbare Margen holen will, muss entweder mehr Performance her oder die Kosten gesenkt werden. Für letzteres muss die Chipgröße runter und ein günstigerer Speicher her. Damit das nicht die Performance senkt, muss man mehr Perf/mm² und mehr Bandbreiteneffizienz realisieren. In beidem ist ausgehend von V10 noch eine ganze Menge Luft, wenn man Pascal als Vergleich annimmt.

Deshalb tippe ich darauf, dass sie einen kostenoptimierten 40CU Vega @12LP bringen, der gegen GA106 auf gleicher Ebene ist. Das wäre in < 300 sqmm möglich. 256 bit SI würde auch reichen. Wenn sie die Bandbreiteneffizienz noch etwas erhöhen, ginge ggf. auch 192 bit und gddr6.

[Daredevil]

Die 3870 war ja auch in jedem Belangen das deutlich bessere Produkt als die 2900XT.
Wenn sie Vega ein wenig optimieren und verkleinern, kann das schon echt was sehr feines werden, vor allem mit dem modernen Feature Set.

[robbitop]

Na vor allem ist die 2xx € Preisrange einer der umsatzstärksten Bereiche. Polaris hat AMD da sehr gut getan. Um das so zu halten wird man etwas gegen GA106 brauchen.

Um ökonomisch sinnvoll mit der 104 Reihe konkurrieren zu können, ohne sich aufzureiben, muss AMD Bandbreiteneffizienz und Perf/mm² erhöhen. Das sollte sicherlich mit spätestens Navi das Ziel sein. Ggf. auch schon vorher?

[Dino-Fossil]

Auf welchen Fakten basiert das? Zeig mir mal bitte die Benchmarks mit und ohne deiner genannten Features von Vega. Oh wait...

Wir haben genug Hinweise dafür:
Launchtreiber der FE - Features offiziell inaktiv und taktnormiert praktisch kein Unterschied zu Fiji, im Vergleich mit heute sicherlich ein Plus, aber kein übermäßig deutliches.
AMDs eigene Benchmarks sehen z.B. im Mittel gerade mal ~7% Verbesserung durch den DSBR - bei AMDs selbst ausgewählten Best-case Titeln, d.h. über ein breites Feld dürfte der DSBR noch weniger bringen.
Bedenkt man, das der mal als eines DER Features mit dem größten Potential galt ist das mMn eher mager.

Nun sollten einige der verbesserten Features mit Vega ja gerade helfen die Auslastung der Hardware und Ausnutzung der Rechenpower schon hardwareseitig zu verbessern - also die Notwendigkeit für aufwendige Optimierungen seitens der Entwickler reduzieren - das ist aber bisher nicht eingetreten.

[BoMbY]

Navi könnte möglicherweise deutlich weniger Transistoren brauchen:

System and method for using virtual vector register files (http://www.freshpatents.com/-dt20171228ptan20170371654.php)

File Date: 06/23/2016

Inventors: Ljubisa Bajic, Michael Mantor, Syed Zohaib M. Gilani, Rajabali M. Koduri

Described is a system and method for using virtual vector register files that may address all of the bottlenecks presented by current register file architecture by yielding lower die area, lower power and faster SIMT units while balancing low latency and register usage. The virtual vector register file architecture can include a two level, non-homogenous hardware vector register file structure that can yield considerable power benefits by avoiding the access of large structures in favor of small structures whenever possible. Management of vector register allocation between the two levels is provided in order to minimize the number of accesses to a larger vector register file. In particular, the virtual vector register file architecture provides more efficient management of vector register file storage by avoid having a large percentage of vector registers that are unusable at any given time and reducing vector register file size. For example, for the “super pixel shaders,” the virtual vector register file neatly avoids spending costly physical vector register storage on unused (or used once twice—then dead) vector registers.

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

[dargo]

Perf/W und Perf/mm² sind übliche Kennzahlen.
Für wen? Für das 3DC? Und vor allem wo? In einer PC-Umgebung? Wo eine fette Schicht Bremsklotz immer noch zum Großteil zwischen Applikation und Hardware liegt? Ich bitte dich.

Wir haben genug Hinweise dafür:
Launchtreiber der FE - Features offiziell inaktiv und taktnormiert praktisch kein Unterschied zu Fiji, im Vergleich mit heute sicherlich ein Plus, aber kein übermäßig deutliches.

Keine Ahnung was du mit der FE willst, die war nie für die Gamer vorgesehen.


AMDs eigene Benchmarks sehen z.B. im Mittel gerade mal ~7% Verbesserung durch den DSBR - bei AMDs selbst ausgewählten Best-case Titeln, d.h. über ein breites Feld dürfte der DSBR noch weniger bringen.
Bedenkt man, das der mal als eines DER Features mit dem größten Potential galt ist das mMn eher mager.

Dürfte, hätte, könnte. Liefere endlich mal Fakten und keine wilden Vermutungen. Bisher gibt es nur das...
https://progame.tv/wp-content/uploads/2017/07/arch-35.jpg

Und laut CB sprach AMD auch von bis zu 33% eingesparter Bandbreite.

Laut AMD kann durch die neue Technik massiv Bandbreite zum „Off-Chip-Speicher“ (HBM2) gespart werden, da die tatsächlich benötigten Daten öfter auch in einem kleineren On-Chip-Speicher (L2-Cache) gespeichert werden können und von Kachel zu Kachel „weitergegeben“ werden. Durch weniger Kommunikation mit dem Off-Chip-Speicher reduziere sich zudem die Leistungsaufnahme. AMD spricht von bis zu 33 Prozent gesparter Bandbreite und bis zu zehn Prozent mehr Performance durch den DSBR.

https://www.computerbase.de/2017-08/radeon-rx-vega-64-56-test/


Nun sollten einige der verbesserten Features mit Vega ja gerade helfen die Auslastung der Hardware und Ausnutzung der Rechenpower schon hardwareseitig zu verbessern - also die Notwendigkeit für aufwendige Optimierungen seitens der Entwickler reduzieren - das ist aber bisher nicht eingetreten.
Nehmen wir nochmal den DSBR. Statt bis zu 33% bringt er bis zu 50% mehr Einsparung. Was soll das großartig bei V10 bringen wenn das Teil jetzt schon kaum an der Bandbreite hängt (wofür auch eben der DSBR beigetragen hat)? Glaubst du wirklich dadurch könnte V10 mit nur einem Stack und der Hälfte der Bandbreite kommen?

[N0Thing]

Für AMD und Nvidia, aber auch für die weiteren Hersteller sind diese Kennzahlen relevant.
Für den Endkunden ist das Endergebnis samt Preis wichtig, aber der setzt sich ja aus Produktionskosten und Leistung zusammen. Größere Fläche --> mehr Kosten. Höherer Verbrauch --> mehr Kosten für Kühler und Bauteile. Höherer Verbrauch --> u.U. weniger Leistung/Takt.

[Bucklew]

Für wen? Für das 3DC? Und vor allem wo? In einer PC-Umgebung? Wo eine fette Schicht Bremsklotz immer noch zum Großteil zwischen Applikation und Hardware liegt? Ich bitte dich.
:facepalm:

Wohl für jeden, außer für AMD-Fanboys, die beharrlich den Vega-Fail schön reden müssen.

Dürfte, hätte, könnte. Liefere endlich mal Fakten und keine wilden Vermutungen. Bisher gibt es nur das...
:facepalm:

Oh ja, wo ja Folien von AMD bekanntlich die reinste und purste Wahrheit liefern!

Oh! Wait! Wie war das nochmal mit der 2,5fach besseren Perf/Watt von Polaris, die nie erreicht wurde? :rolleyes:

[MadPenguin]

Solltest du endlich fertig haben, hier alle(s) zuzumüllen, würde ich dich gerne bitten euren Kindergartenkrieg per PN auszuführen...

[Screemer]

Für wen? Für das 3DC? Und vor allem wo? In einer PC-Umgebung? Wo eine fette Schicht Bremsklotz immer noch zum Großteil zwischen Applikation und Hardware liegt? Ich bitte dich.

:uponder:

Am effiziententen (Perf/W) ist nach wie vor beim UV die Methode von Igor! Schön wäre es halt wenn ich noch irgendwie unter die 1,0V kommen könnte. Denn es deutet alles darauf hin, dass ich die 1,6Ghz noch mit 220W Asicpower erreichen kann.

Das ist schon wieder kompletter Unfug. Am Freitag kommt Wolfenstein 2 dann sehen wir wie die Perf/W bei beiden aussieht.
In Games die auch Vega Features nutzen wird sich die Perf/W schlagartig ändern.

Nein... war schon bei Grenada nicht anders. Am Beispiel von Doom @Vulkan... Takt sankt bei meiner R9 390 um 1-2% bei 40-50% mehr Leistung. Ergo steigt die Perf/W deutlich.
Sorry, aber die Effizienzmessung von igor ist unbrauchbar. In einer Effizienzmessung geht es immer um Perf/W. Und da kann man nicht einfach mit einer Uraltsoftware kommen bei der selbst eine GTX1060 bei avg. 1850Mhz gerade mal 95W zieht wo sie in der Regel bei neuen Spielen mit diesem Takt 120W (bei CB sind es in Anno übrigens 1.810-1.823 MHz (https://www.computerbase.de/2016-07/geforce-gtx-1060-test/2/)) verbraucht.
Man achte mal auf Tahiti vs. Kepler. X-D Perf/W schlägt hier in ganz andere Dimensionen. Die R9 280X zersägt sogar die Titan und 780TI. Tonga XT schneidet imho etwas schwach ab.

[Flusher]

Ah komm, das macht doch kein Sinn mit dem zu diskutieren. Dargo wird gleich mit einem Post um die Ecke kommen, dass das ja aus dem Kontext gerissen sei, und er ja gar nicht vom 3DC spricht sondern dem Markt und das die Performance unter LL-APIs doch hervorragend sei.

Dummerweise ist ausgerechnet Perf/W für den Markt die interessanteste Kennzahl, da sich schliesslich davon alle anderen Kosten ableiten. Und am Markt sind nunmal hauptsächlich Spiele ohne LL-APIs.


Im übrigen Frage ich mich wie durchschlagskräftig Navi überhaupt noch sein kann. Fiji & Vega müssen AMDs R&D Budgets ordentlich gebeutelt haben, ohne dass dahinter der nötige Umsatz generiert wurde.

Ich befürchte, dass da von AMD längere Zeit keine Highend/Enthusiasten GPUs mehr kommen werden.

[dargo]

:uponder:
Schön, dass du dir paar Sachen ausgesucht hast. Wenn du mir jetzt nur sagen könntest was das mit dem Thema zu tun hat was du zuerst von mir zitiert hast könnte man vielleicht darauf eingehen.

Nochmal extra für dich da die Botschaft offenbar nicht angekommen ist. Eine aussagekräftige Perf/W Beurteilung zwischen zwei GPUs bekommst du erst in einer Konsolenumgebung wo du nah an der Hardware bist und nicht bei dem PC. Selbst mit DX12/Vulkan erreicht man nicht die Effizienz der Konsole. Man ist aber schon mal deutlich näher dran als mit den Steinzeit-APIs.

[nalye]

Und wir kriegen uns bitte alle wieder ein, danke. Gibt nur wieder Karten, die beide Seiten nicht wollen

[robbitop]

Wenn ich eine normierte Leistung 1 haben will:

- Perf/W resultiert in der Dimensionierung des Kühlkörpers und der Stromversorgung im PCB -> mehr Leistungsaufnahme schlägt auf die BOM
- Perf/mm² resultiert in der Größe des Kerns und auf den Yield -> größerer Kern schlägt auf die BOM
- Bandbreiteneffizienz resultiert im Preis des Arbeitsspeichers -> mehr GT/s oder breiteres SI schlägt auf die BOM

Ist die BOM teurer, bleibt weniger übrig (Gewinnspanne). Damit ein IHV langfristig konkurrenzfähig ist braucht er Kapital um in R&D investieren zu können. Mit weniger Gewinnspanne ist auch weniger R&D möglich was darin resultiert, dass man in obigen Kennzahlen in Relation zum Wettbewerb immer schlechter wird.
Es ist nicht nur in AMDs eigenen Interesse hier wettbewerbsfähiger zu werden (also möglichst geringe Kosten für Performance X in der BOM) sondern auch im Interesse des Kunden (ohne Konkurrenz leidet P/L und Fortschritt).

Dass Vega, auch unter Berücksichtigung best optimiertester Titel (W2), da deutlich mehr Geld für die BOM ausgeben muss, liegt leider auf der Hand.
Vega müsste für die BOM vermutlich GP102 Leistung bringen um entsprechend höhere Preise (und somit Gewinnspanne) abrufen zu können. Das schafft er aber nichtmal in W2.

Für NAVI wird man sicher an obigen Aspekten arbeiten.
Auch sollte es hoffentlich zum Ziel gemacht werden, schnellst möglich in allen Spielen sofort zum Launch möglichst gute Performance abzurufen. Zum Launch gibt es die Reviews und die bleiben stehen. Wenn die SW (Treiber/Spiele) gereift wird, ist der "Buzz" für diese Produkte (und somit der Kaufanreiz) ungleich geringer.

V56 ist für einen potenziellen Kunden eine gute Wahl. Das will ich nicht bestreiten. Für AMDs langfristige Strategie (Gewinnspanne -> Kapital -> R&D) aber eine schlechte Karte. Wenn AMD langfristig konkurrenzfähig bleiben will, muss man hier besser werden.
Es ist aber wahrscheinlich unheimlich schwiergig gegen NV anzukommen, weil man schon sehr stark ausgeblutet ist in den letzten Jahren und immer weniger investieren konnte. NV hat schon ein ziemlich hohes Level erreicht was HW und Treiberarbeit angeht. Für uns Kunden wäre es wichtig, dass AMD mittelfristig überall aufschließt und möglichst 50% des Umsatzes bei dGPUs macht. Wir wollen ja langfristig ein gutes P/L. :)

[Dino-Fossil]

Keine Ahnung was du mit der FE willst, die war nie für die Gamer vorgesehen.

Stell dich nicht dumm, das hast du nicht nötig.

Dürfte, hätte, könnte. Liefere endlich mal Fakten und keine wilden Vermutungen.

Keine Vermutungen, AMDs eigene Folien.
Sowohl die "bytes per frame savings (da sind die "up to 33%" ein Idealfall, der auf AMDs eigener Folie nur selten erreicht wird - man hat im Mittel eher <15%), als auch die zum Effekt des DSBR auf Perf/Watt und fps in Vega. Das was hinten raus kommt.
Und da die letzten Endes Marketingmaterial sind kann sich jeder mit ein bisschen Hirnschmalz zusammenreimen, dass es schon der best-case sein dürfte.
Der Nutzen könnte natürlich stärker sein, wenn ein echtes Bandbreitenlimit vorliegt, aber der DSBR soll wohl noch ein wenig mehr machen als "nur" Bandbreite einzusparen.

Aber um das klarzustellen: Ich sage nicht, dass Vega Elektronikschrott oder ein Rohrkrepierer sei.
Vega kann für unterschiedliche Anforderungen durchaus ein brauchbares Produkt liefern.
Ich bin aber der Überzeugung, dass Vega mit hoher Wahrscheinlichkeit nicht so effizient/performant/gewinnträchtig geworden ist, wie AMD das ursprünglich geplant hatte.
Und hier nur auf optimierte Titel mit ll-APIs zu verweisen sind Nebelkerzen, die aktuelle Marktrealitäten verschleiern.

[scully1234]

Im übrigen Frage ich mich wie durchschlagskräftig Navi überhaupt noch sein kann. Fiji & Vega müssen AMDs R&D Budgets ordentlich gebeutelt haben, ohne dass dahinter der nötige Umsatz generiert wurde.


Hast du dir damit die Frage nicht schon selber beantwortet?

[Bucklew]

Ich finde man darf den Unsinn, den dargo hier postet so einfach nicht unkommentiert lassen.

AMD baut GPUs für den PC-Einsatz. Und wenn man mal ehrlich ist, dann müsste sogar dargo eingestehen, dass sie GPUs *primär* für den PC-Einsatz bauen. Die Verwendung in den Konsolen ist eher Resteverwertung der IP, die man durch die Chips für den PC hat.

Also ist es völlig legitim die Perf/Watt verschiedenen Chips in dieser Umgebung zu vergleichen.

Auch sehe ich kein Problem damit, unter Nicht-DX12/Vulkan-APIs diese Metrik zu vergleichen. Sei es nach Zahl der Spiele, noch nach Verbreitung hat irgendeine dieser "neuen" APIs einen nennenswerten Verbreitungsanteil, die eine Bewertung nur anhand dieser APIs rechtfertigen würde. Im Gegenteil, gerade die am meisten gespielte Spiele haben häufig noch ältere APIs als DX11. Was hat Dota 2? DX9? Oder CS:Go?

Es steht AMD gern frei, den von dir skizzierten Weg zu gehen: Ihre GPUs nur noch in den Konsolen zu verkaufen. Keine PC-Version mehr. Oder aber auch die Nutzung der "Steinzeit"-APIs zu unterbinden und nur noch DX12 + Vulkan zu unterstützen. Ich bin mir sicher, wenn AMD diesen Weg einschlägt, wird der Vega-Nachfolger der Knaller und Verkaufsschlager :up:

"The worlds first and only GPU with only DX12 and Vulkan Support!" - das doch mal knackig!

Aber du darfst deine Vegakarte auch gern in der Konsolenumgebung nutzen. Vielleicht erschlafft dann auch dein Interesse an diesem Forum....? :wave2:

[HOT]

Ah komm, das macht doch kein Sinn mit dem zu diskutieren. Dargo wird gleich mit einem Post um die Ecke kommen, dass das ja aus dem Kontext gerissen sei, und er ja gar nicht vom 3DC spricht sondern dem Markt und das die Performance unter LL-APIs doch hervorragend sei.

Dummerweise ist ausgerechnet Perf/W für den Markt die interessanteste Kennzahl, da sich schliesslich davon alle anderen Kosten ableiten. Und am Markt sind nunmal hauptsächlich Spiele ohne LL-APIs.


Im übrigen Frage ich mich wie durchschlagskräftig Navi überhaupt noch sein kann. Fiji & Vega müssen AMDs R&D Budgets ordentlich gebeutelt haben, ohne dass dahinter der nötige Umsatz generiert wurde.

Ich befürchte, dass da von AMD längere Zeit keine Highend/Enthusiasten GPUs mehr kommen werden.
Das ist einfach nur Quatsch. Der Markt interessiert sich kaum für W. Die Marke ist viel, viel wichtiger. Danach kommt Verfügbarkeit und was hinten an Leistung rauskommt. Dann ist noch relevant wie leise das Produkt ist. Der Stromverbrauch interessiert hingegen kaum einen, das ist nett, das wars dann aber auch.

Der Schwachsinn geht ja weiter, Fiji hat kaum R&D gekostet, man hat ja nur die damals neuesten GCN-Bausteine genommen und deren Maximalausprägung in eine Marke gepresst. HBM ist keine große Sache gewesen, das einzige, was daran eben schwer ist, ist das billig in ein Package zu packen und billig zu produzieren. Das hat aber weder mit Fiji noch mit Vega als solches was zu tun. Mit Vega hat man wieder einige Entwicklungen mitgenommen, die erst später durchschlagen werden, von daher ist da 0,0 "verschwendet" am R&D-Budget für den Chip. Lasst doch mal diesen polemischen Schwachsinn sein.

Und wenn 12nm Ampere gegen 7nm Navi antreten muss würd ich da nicht die Hand für ins Feuer legen, dass NV das gewinnen kann, die Prozesse sind doch sehr weit auseinander.

Bucklew
Das ist genau so ein Schwachsinn. Die IP eignet sich hervorragend für Konsolen. Sie hat lediglich einige Entwicklungen nicht, die NV gemacht hat, das ist alles. GCN ist ne gute IP, auch Vegas GCN ist ne gute IP. Es gibt jedoch noch Nachteile, die beseitigt werden müssen, worauf man sich offenbar bei Navi fokussiert hat (endlich). GCN braucht halt mehr Saft als NVs Architekturen. Das wars dann aber im Prinzip auch schon.
Zudem ist klar, dass der Markt eben immernoch an vorsintflutlicher Software festhält. Anders kann man DX11 nunmal nicht bezeichnen, das ist genauso veraltet wie DX9 oder 10.

[dargo]

Stell dich nicht dumm, das hast du nicht nötig.

Das sagt der richtige der immer noch nicht verstanden hat, dass für den Gamer die RX Reihe und nicht die FE von AMD vorgesehen ist. :rolleyes:


Keine Vermutungen, AMDs eigene Folien.
Sowohl die "bytes per frame savings (da sind die "up to 33%" ein Idealfall, der auf AMDs eigener Folie nur selten erreicht wird - man hat im Mittel eher <15%), als auch die zum Effekt des DSBR auf Perf/Watt und fps in Vega. Das was hinten raus kommt.
Und da die letzten Endes Marketingmaterial sind kann sich jeder mit ein bisschen Hirnschmalz zusammenreimen, dass es schon der best-case sein dürfte.

Jetzt sind es also schon <15%? Vor kurzem waren es noch ~7%, was denn nun?

Bezüglich Marketingmaterial... wenn man immer nur den Best Case zeigen möchte dann läuft da im Marketing von AMD ganz schön was quer. Wie kann man sich für eine Marketingfolie Spiele bzw. Szenen aus Spielen aussuchen die nur 3-5% Vorteil bringen?

[N0Thing]

Das ist einfach nur Quatsch. Der Markt interessiert sich kaum für W. Die Marke ist viel, viel wichtiger. Danach kommt Verfügbarkeit und was hinten an Leistung rauskommt. Dann ist noch relevant wie leise das Produkt ist. Der Stromverbrauch interessiert hingegen kaum einen, das ist nett, das wars dann aber auch.

Weniger Leistungsaufnahme resultiert in einem besseren Image und dazu entweder in einer leiseren Karte, oder einem günstigeren Kühler und Platinendesign und damit einem potentiellen Preisvorteil und höherer Akzeptanz bei OEMs.

Mehr Verbrauch wird sicherlich vom Markt akzeptiert, aber meiner Meinung nach nur dann, wenn auch die Leistung höher ist.

[Dino-Fossil]

Das sagt der richtige der immer noch nicht verstanden hat, dass für den Gamer die RX Reihe und nicht die FE von AMD vorgesehen ist. :rolleyes:

Es geht um die Auswirkung diverser Features. Lässt sich Anhand der Treiberversionen der FE leichter nachverfolgen. Die Hardware ist abgesehen vom HBM identisch.
Kannst ja mal Raff mit seiner FE fragen, vielleicht kann der noch was beisteuern.


Jetzt sind es also schon <15%? Vor kurzem waren es noch ~7%, was denn nun?
Wer lesen kann ist klar im Vorteil. Schau dir AMDs Folien an und du verstehst worauf ich mich beziehe - es gibt nämlich zwei Folien, die insgesammt drei Metriken zeigen. Hab ich alles geschrieben. Du erwartest doch nicht plötzlich, dass ich mich hier endlos wiederhole? :tongue:

[dargo]

Es geht um die Auswirkung diverser Features. Lässt sich Anhand der Treiberversionen der FE leichter nachverfolgen. Die Hardware ist abgesehen vom HBM identisch.
Kannst ja mal Raff mit seiner FE fragen, vielleicht kann der noch was beisteuern.

Ich brauche Raff gar nichts fragen da die FE fürs Gaming komplett uninteressant ist. Auch wenn die gleiche Hardware verbaut ist bekommen beide nicht den gleichen Treiber.

[Bucklew]

Das ist einfach nur Quatsch. Der Markt interessiert sich kaum für W. Die Marke ist viel, viel wichtiger. Danach kommt Verfügbarkeit und was hinten an Leistung rauskommt.
Dann erkläre mal den markierten Anstieg mit der Marke und nicht mit dem massiven Vorteil von NVIDIA in Sachen Perf/Watt.
62240

Der Schwachsinn geht ja weiter, Fiji hat kaum R&D gekostet
Ach so, gut zu wissen. Ich dachte Fiji wäre ein riesiges Projekt von AMD gewesen, bei dem sie richtig viel Geld und Man-Power investiert haben, um HBM in den Massenmarkt zu kriegen. Gut, dass du das mal klar stellst.

Bezüglich Ampere/Navi:
12nm Ampere ist Q2/18, während 7nm Navi 2019 wird. Woher weißt du, ob die jemals gegeneinander antreten werden?

[Screemer]

Ich brauche Raff gar nichts fragen da die FE fürs Gaming komplett uninteressant ist. Auch wenn die gleiche Hardware verbaut ist bekommen beide nicht den gleichen Treiber.

Man kann auf der fe den Gaming Treiber installieren, ja sogar parallel zum pro und diese on the fly wechseln :eek:

Es soll sogar Leute geben, die sich die Karte nur für Gaming gekauft habe und schlicht die 8gb mehr vram mitnehmen wollten. Sie war auch mal für wenig mehr Geld als die lc kostet verfügbar.

Bei dir ist grad alles schwarz oder weis. Du warst echt mal zugänglicher und vor allem umgänglicher.

@bucklew: Blick mal ein bisschen weiter zurück. Der anstieg bei amd kurz nach Einführung der 400er Generation bei nv, lag hauptsächlich am imageverlust durch die schlechte Perf/w. Gleiches gilt für den von die markierten Anstieg bei nv nach Einführung der 900er Generation. Hawaii war durchweg als zu heis zu laut und zu stromhungrig verschriehen.

[dargo]

Man kann auf der fe den Gaming Treiber installieren, ja sogar parallel zum pro und diese on the fly wechseln :eek:

Und dennoch stößt man auf diverse Probleme wie zb. kein Wattman. Zumindest hatte ich das mal von Raff gelesen. Ob das heute immer noch so ist weiß ich nicht. Auch hatte ich gelesen, dass Igor für einen Gamer keine FE empfehlen würde. Es wird schon Gründe geben warum man sowas tut. Ich habe ja nicht grundsätzlich was gegen die FE. Man sollte sich nur im klaren sein worauf man sich da einlässt. Für den "08/15" Spieler ist das sicherlich nichts.

[Daredevil]

Und dennoch stößt man auf diverse Probleme wie zb. kein Wattman.
Das "Problem" habe ich auch mit der Vega56 und der Vega64.
Liegts an AMD oder an dem Wattman? :)

[dargo]

Vielleicht daran? :tongue:
GeForce GTX1080 WaKü + Vega56 Ref + Vega64 Ref

Etwas unübliche Konfiguration.