3DCenter Forum - Diskussion zu: Hardware- und Nachrichten-Links der Osterfeiertage 2018

Leonidas · 2018-04-03, 12:02:58

Link zur News:
https://www.3dcenter.org/news/hardwa...feiertage-2018

2018-04-03, 12:31:36

Das ist doch mal eine interessante News zu Vega 20. Ich bin gespannt, wann der Chip auf den Markt kommt und ob vielleicht nicht doch auch Gaming-Ableger davon produziert werden. Vielleicht ändert sich die geplante (und spekuliert?) Roadmap durch den starken Einbruch im Mining - die Kurse halten sich auf niedrigem Niveau und auf ebay/ebay-kleinanzeigen kommen viele Grafikkarten und Netzteile der Miner gerade auf den Markt.

Zitat:

vmtl. 4-6 Raster-Engines

Leonidas, meinst Du wirklich, dass AMD hier noch GCN auf möglicherweise 6 Raster-Engines aufbohrt? Ich hatte Deine News vom Januar 2018 Link so verstanden, dass mit Fiji und Vega quasi das maximal Mögliche aus GCN herausgeholt wurde und damit auch die Zahl der Raster-Engines (--> 4 Stück) fix ist.

Zitat:

Schließlich kann Vega 10 durchaus hoch takten, säuft dann aber auch Strom wie andere Bier, wird also auf hohem Takt maßgeblich ineffizient wie umso schwerer zu kühlen. Dasselbe in der 7nm-Fertigung dürfte sich nochmals etwas höher takten lassen, ohne aber die ganzen Seiteneffekte aufzuweisen – sprich, Vega 10 in effizient.

In Sachen Lithographie habe ich Nachholbedarf. Vega wurde von AMD mit einem Hochtaktdesign versehen, d.h. bestimmte Funktionen sind mit mehr Transistoren vermutlich mit hoher Lokalität auf dem Chip (redundant?) aufgebaut und lassen sich so hoch takten, richtig? Wenn nun der Prozess einen Shrink auf 7nm erfährt, dann kann man die Taktfrequenz noch höher schrauben und dabei sogar weniger Abwärme erzeugen? Kann mir das bitte mal jemand erklären - gerne auch mit mehr als nur 2 Sätzen, danke

Kulasko · 2018-04-03, 16:31:58

Zu Gigabyte gab es doch die externen Grafikkarten, wo die AMD-Version nicht unter AORUS angeboten wird. Auch wenn Gigabyte behauptet, das halte man so, weil die Karten dafür nicht High End genug sein, sollte man das trotzdem mit einbeziehen.

2018-04-03, 21:27:20

Beitrag anzeigen — Zitat von **AMDoderNvidia**

Mehr Transen für mehr Takt? Wie funktioniert das? Gibt es jemanden der das für jemanden mit guten Grundkenntnissen in E-Technik/Elektronik erläutern kann?

vinacis_vivids · 2018-04-03, 23:18:33

https://radeon.com/_downloads/vega-w...er-11.6.17.pdf
Built for higher clock speeds
One of the key goals for the “Vega” architecture was
achieving higher operating clock speeds than any prior
Radeon™ GPU. Put simply, this effort required the design
teams to close on higher frequency targets. The simplicity
of that statement belies the scope of the task, though.
Meeting “Vega’s” substantially tighter timing targets
required some level of design effort for virtually every
portion of the chip.
In some units—for instance, in the texture decompression
data path of the L1 cache—the teams added more stages to
the pipeline, reducing the amount of work done in each
clock cycle in order to meet “Vega’s” tighter timing targets.
Adding stages is a common means of improving the
frequency tolerance of a design, but those additional stages
can contribute more latency to the pipeline, potentially
impacting performance. In many cases, these impacts can
be minor. In our texture decompression example, the
additional latency might add up to two clock cycles out of
the hundreds required for a typical texture fetch—a
negligible effect.
In other instances, on more performance-critical paths, the
“Vega” project required creative design solutions to better
balance frequency tolerance with per-clock performance.
Take, for example, the case of the “Vega” NCU. The design
team made major changes to the compute unit in order to
improve its frequency tolerance without compromising its
core performance.
First, team changed the fundamental floorplan of the
compute unit. In prior GCN architectures with less
aggressive frequency targets, the presence of wired
connections of a certain length was acceptable because
signals could travel the full distance in a single clock cycle.
For this architecture, some of those wire lengths had to be
reduced so signals could traverse them within the span of
“Vega’s” much shorter clock cycles. This change required a
new physical layout for the “Vega” NCU with a floorplan
optimized to enable shorter wire lengths.
This layout change alone wasn't suffcient, though. Key
internal units, like the instruction fetch and decode logic,
were rebuilt with the express goal of meeting “Vega’s”
tighter timing targets. At the same time, the team worked
very hard to avoid adding stages to the most
performance-critical paths. Ultimately, they were able to
close on a design that maintains the four-stage depth of the
main ALU pipeline and still meets “Vega’s” timing targets.
“Vega” 10 also leverages high-performance custom SRAMs
originally developed by the “Zen” CPU team. These SRAMs,
modified for use in the in general-purpose registers of the
Vega NCU, other improvements on multiple fronts, with 8%
less delay, an 18% savings in die area, and a 43% reduction
in power use versus standard compiled memories.
¹⁰

basix · 2018-04-03, 23:46:29

Mehr Takt durch mehr Transistoren sind oftmals zwei Dinge:

Mehr Gates für die selbe Distanz (Repeater). Dadurch werden Signallaufzeiten zwischen den Gates verkürzt. Gleichzeitig nimmt die Kapazität pro Streckenabschnitt ab (bessere Signalqualität am Eingang des nächsten Gates, dadurch können Signalströme veringert werden und dadurch geringerer Verbrauch pro Streckenabschnitt), der maximal mögliche Takt steigt. Geringere Ströme = Weniger Verlustleistung an diesen Stellen. Ausserdem ist bei so kleinen Strukturen der ohmsche Widerstand nicht proportial zum Leiterquerschnitt, sondern sehr stark überproportional. Höhere Widerstände = Mehr Verlustleistung = weniger Takt möglich. Noch extremer wird es für "lange" Leitungen (weiss nicht genau, wo die Grenze ist), hier steigt die Signalverzögerung (Delay) um Länge² und nicht linear. Hier ein Design zu kreieren, wo die Daten zur richtigen Zeit am richtigen Ort sind wird dann immer schwieriger. Kommen die Daten zu stark versetzt zueinander an, crashed das ganze irgendwann mal.
Mehr GND (& Speisungs) Transistoren. Verbessern die lokale Spannungsversorgung und Signalqualität. Bessere Signale = höherer möglicher Takt, bevor es zu Fehlern kommt. Mit mehr GND Transistoren ist evtl. auch die lokale Hitzeentwicklung (Hotspots) ein wenig entschärft. Geringere Temperatur = geringerer Widerstand = geringere Leistungsaufnahme = mehr Eneergiebudget = höherer Takt möglich.

Es gibt sicher noch andere Tricks und Kniffe, diese zwei sind aber meines Wissens nach die wichtigsten.

Bei 7nm vs. 14nm ist es einfach so, dass die Transistoren näher zusammenliegen etc. und allein dadurch würde ein 14nm auf 7nm skaliertes Design auch ohne mehr Transistoren mehr Takt mitmachen (ausser man macht was falsch, und da gibt es viele Möglichkeiten

) Grundsätzlich dreht sich alles darum, die parasitären Kapazitäten und Widerstände so klein wie möglich und die Signal-Delays minim zu halten. Dadurch werden die Ströme und Spannungen geringer und dadurch steigt bei entsprechendem Chipdesign automatisch die Taktbarkeit bei selbem Energiebudget, was ein kleinerer Prozess im Regelfall mitbringt. Nur geht das leider nicht mehr so einfach wie früher, da immer mehr Nebeneffekte wie Leakage, Tunneleffekt, Elektromigration etc. das Design erschweren. Falls es aber interessiert: Dennard Scaling ist das Zauberwort. Das allgemein bekannte Mooresche Gesetz ist nur die logische Konsequenz davon. Bis etwa 65nm hat dies sehr gut gepasst. Und seit dies nicht mehr passt, hat sich auch die Leistungsexplosion bei Computerchips verlangsamt

https://en.wikipedia.org/wiki/Dennard_scaling

2018-04-04, 01:37:21

Basix, ich glaube du vermischt zwei Dinge: Maximale Taktfrequenz durch Timing und maximale Taktfrequenz wegen Leistungsaufnahme.

Weißt du das alles, weil du in dem Bereich arbeitest oder sind das Vermutungen? Bisher hatte ich den Eindruck, dass einzig skysnake auf dem Gebiet Erfahrung hat...

Von den Masse-Transistoren lese ich hier im Forum immer wieder, aber mir könnte noch keiner an Hand eines Schaltplans erklären, wo in einem Gatter die zum Einsatz kommen sollen. Zusammenhang mit Hotspot? Siehe oben: hier vermischt du dir Dinge imho.

Zu repeater: ist es echt so, dass die signalisiert durch repeater verringert wird? Kommt mir sehr komisch vor. Das propagation delay eines gatters ist doch immer höher als die reine Laufzeit.

Gibt es für deine Behauptungen Literatur?

2018-04-04, 07:17:51

Danke für Eure Erklärungen, das hilft mir erstmal weiter.

Offen ist noch der Punkt der Skalierung von GCN, gerade was die Anzahl der Raster-Engines betrifft. Hat da jemand noch ein paar Infos dazu, wieso, weshalb, warum, ...?

2018-04-04, 07:56:28

Sind damit Pull-down Stufen gemeint? Oder was anderes?

Leonidas · 2018-04-04, 08:12:45

Die Tabelle ist aus einer alten News kopiert. Ich habe überlegt, das "4-6" zu "4" zu ändern, es aber vorerst gelassen. Letztlich liegen zu diesem Punkt keine Infos vor, also ist eine spekulative Angabe okay. Aber es ist definitiv unwahrscheinlicher geworden. Eigentlich sind mehr als 4 RE ein Thema von Navi.

Vega 20 könnte sich hier natürlich drumherumschummeln und einfach 4 RE mit doppelter Raster-Power auflegen. Deswegen hab ich die Angabe mal so stehenlassen. Die Angabe weist darauf hin, das dieser Punkt noch unklar ist. 4096 SE und 4096 Bit SI sind dagegen sichere Infos.

2018-04-04, 13:09:07

Das Problem daran ist, dass die wesentliche Info fehlt.
http://cdn.wccftech.com/wp-content/u...ns-740x279.jpg

Vega10 hat Infinity Fabric eingeführt, aber erst mal ohne Wirkung. Mit Vega20 will AMD per Infinity Fabric mGPU Setups ermöglichen. Der xGMI Support ist bei Ryzen das Pendent zu den Sockel Interkonnektionen, der Global Memory Interconnect. Und das ist eigentlich alles was an Vega20 wirklich zählt.

Die Frage wird sein, ob Vega20 als mGPU bereits nach Aussen als eine single GPU transparent ansprechbar wird.

Ganz spekulativ könnte es z.B. möglich sein die FP64 Leistung wird durch zwei verbundene Vega10 erreicht, die nach aussen jedoch immer nur 64 CUs darstellen. Die CUs von Vega20 wurden IMHO aber noch nie weiter erläutert als in der verlinkten Grafik.
Genausogut möglich ist, dass man nur für dieses Pro-Design die CUs auf FP64 Leistung hin optimiert weil man seit Hawaii keinen guten Compute-Chip mehr in diesem Bereich hatte - Navi könnte dann wieder mit den Erfahrungen im mGPU Link auf Effizienz und Fläche hin ohne DoublePrecision optimiert werden.

Wie bereits geschrieben, entscheidend allein wird sein ob die xGMI aka Infiniy Fabric Interconnects eine transparente mGPU ermöglichen oder nicht. Bei nVidias nVlink2 wurde das bislang leider auch noch nicht geklärt.

2018-04-04, 17:45:42

Die Sache mit nVLink, nvLink2, Infinity Fabric und xGMI ist interessant für mGPU Setups. Ich frag mich dabei, ob es wirklich ausreichend ist, über diese Technik vollwertige GPUs (wie wir sie bisher kennen) zusammenzuschalten und damit die Performance entsprechend zu skalieren. Bei reinen Compute-Anwendungen mag das ja funktionieren, wie es zuletzt Nvidia auf der Hausmesse angekündigt/demonstriert hat.

Etwas anderes ist es jedoch im Bereich Computergrafik. Wenn ich mir die ganzen Schritte bei der klassischen Rasterizer-based Renderpipeline ansehe, dann gibt es doch immer wieder Schritte, bei denen die (Zwischen)Ergebnisse eingesammelt werden und dann wieder zur Berechnung verteilt. Mein Szenario (ganz simpel):

Vertexdaten -> verteilt auf verschiedene Chips und dort per Vertex-Shader berechnet (tlw. mit Geometry-Shader und/oder Tessellation-Shader) -> Daten wieder zusammengeholt, damit sie gerastert werden können -> Daten wieder verteilt auf verschiedene Chips, damit die Pixel-Shader die Farbe berechnen (und Zugriff auf die Texture-Units) -> Schlussendlich alle Daten wieder an eine Stelle zusammen, damit die ROPs das Blending, den Tiefentest und das Schreiben in den Framebuffer durchführen.

Die Engpässe sehe ich beim Rasterizer und bei den ROPs (allerdings kann ich hier auch völlig falsch liegen - bin nur jemand, der sich manchmal seine Freizeit mit der OpenGL-/DirectX-Programmierung um die Ohren schlägt und ein bisschen sich die Hardware-Architekturen dazu ansieht). Wie skaliert man sowas? Kann man da einfach mehrere Vega10-Chips innerhalb eines "Mega-Chips" zusammenschalten (per xGMI) und voilà, die Performance vervielfacht sich?

Mr.Smith · 2018-04-04, 23:20:25

Mining macht AMD kaputt..
Vega 56 ist eigtl. ne ziemlich gute Karte (mit leichtem UV), es wird aber nVidida für Gaming gekauft wegen dem günstigeren Preis (eigtl. falschrum, das war immer AMD's starker Punkt)

580 muss man gut UV und optimieren, sonst ist der Verbrauch einfach zu hoch im Vergleich zur 1060, und der Preis ist auch hier höher.

560 mit 4GB könnte ganz nett sein, wenn der Preis bei 100-120€ liegen würde, die 1050ti ist schon merklich schneller.

AMD verliert seine Kunden im Gaming Markt und wenn die ne neue kaufen irgendwann, ist die Wahrscheinlichkeit beim gleichen Hersteller zu bleiben doch etwas höher.

2018-04-05, 01:18:26

Ehrlicherweise muss man sagen, dass Vega 20 eben kein Vega 10 in effizient ist, denn der kommt als 12nm für die Instinct und Pro Serie.

Vermutlich löst Vega 20 Polaris 20 ab. Dann machen auch die 7nm Sinn, ohne dabei viel Ausschuss zu produzieren, denn Vega ist immer noch komplex. Das AMD dabei einfach nur shrinkt fürs Jahr 2019, davon würde ich nicht ausgehen. Ergo ist es ein Chip der Polaris ablöst, der ungefähr so schnell wie Vega10 wird, wobei dieser dann von Navi Consumer abgelöst wird.

Vega auf 12nm und dann nochmal auf 7nm zu shrinken, wäre völliger Bullshit. Mehr Takt macht Vega nicht schnell. Reine Rohpower hat der Chip schon jetzt genug.

Leonidas · 2018-04-05, 05:53:37

Von AMD kam aber die klare Aussage, das der für HPC bestimmte Vega in 7nm kommt. Wurde genauso auch auf alten Roadmaps notiert, die bislang immer noch als korrekt gelten. Insofern verstehe ich die Ausführungen zu 12nm nicht.

2018-04-03, 12:02:58	#1 (im Thread / einzeln)
Leonidas 3DCenter, Administrator Registriert: 2001-03-26 Beiträge: 48.508	Diskussion zu: Hardware- und Nachrichten-Links der Osterfeiertage 2018 Link zur News: https://www.3dcenter.org/news/hardwa...feiertage-2018

2018-04-03, 12:31:36	#2 (im Thread / einzeln)
AMDoderNvidia Gast Beiträge: n/a	Re: Diskussion zu: Hardware- und Nachrichten-Links der Osterfeiertage 2018 Das ist doch mal eine interessante News zu Vega 20. Ich bin gespannt, wann der Chip auf den Markt kommt und ob vielleicht nicht doch auch Gaming-Ableger davon produziert werden. Vielleicht ändert sich die geplante (und spekuliert?) Roadmap durch den starken Einbruch im Mining - die Kurse halten sich auf niedrigem Niveau und auf ebay/ebay-kleinanzeigen kommen viele Grafikkarten und Netzteile der Miner gerade auf den Markt. Zitat: vmtl. 4-6 Raster-Engines Leonidas, meinst Du wirklich, dass AMD hier noch GCN auf möglicherweise 6 Raster-Engines aufbohrt? Ich hatte Deine News vom Januar 2018 Link so verstanden, dass mit Fiji und Vega quasi das maximal Mögliche aus GCN herausgeholt wurde und damit auch die Zahl der Raster-Engines (--> 4 Stück) fix ist. Zitat: Schließlich kann Vega 10 durchaus hoch takten, säuft dann aber auch Strom wie andere Bier, wird also auf hohem Takt maßgeblich ineffizient wie umso schwerer zu kühlen. Dasselbe in der 7nm-Fertigung dürfte sich nochmals etwas höher takten lassen, ohne aber die ganzen Seiteneffekte aufzuweisen – sprich, Vega 10 in effizient. In Sachen Lithographie habe ich Nachholbedarf. Vega wurde von AMD mit einem Hochtaktdesign versehen, d.h. bestimmte Funktionen sind mit mehr Transistoren vermutlich mit hoher Lokalität auf dem Chip (redundant?) aufgebaut und lassen sich so hoch takten, richtig? Wenn nun der Prozess einen Shrink auf 7nm erfährt, dann kann man die Taktfrequenz noch höher schrauben und dabei sogar weniger Abwärme erzeugen? Kann mir das bitte mal jemand erklären - gerne auch mit mehr als nur 2 Sätzen, danke

2018-04-03, 16:31:58	#3 (im Thread / einzeln)
Kulasko Full Member Registriert: 2015-07-16 Beiträge: 79	Re: Diskussion zu: Hardware- und Nachrichten-Links der Osterfeiertage 2018 Zu Gigabyte gab es doch die externen Grafikkarten, wo die AMD-Version nicht unter AORUS angeboten wird. Auch wenn Gigabyte behauptet, das halte man so, weil die Karten dafür nicht High End genug sein, sollte man das trotzdem mit einbeziehen.

2018-04-03, 21:27:20	#4 (im Thread / einzeln)
Gast Gast Beiträge: n/a	Re: Diskussion zu: Hardware- und Nachrichten-Links der Osterfeiertage 2018 Zitat von AMDoderNvidia In Sachen Lithographie habe ich Nachholbedarf. Vega wurde von AMD mit einem Hochtaktdesign versehen, d.h. bestimmte Funktionen sind mit mehr Transistoren vermutlich mit hoher Lokalität auf dem Chip (redundant?) aufgebaut und lassen sich so hoch takten, richtig? Wenn nun der Prozess einen Shrink auf 7nm erfährt, dann kann man die Taktfrequenz noch höher schrauben und dabei sogar weniger Abwärme erzeugen? Kann mir das bitte mal jemand erklären - gerne auch mit mehr als nur 2 Sätzen, danke Mehr Transen für mehr Takt? Wie funktioniert das? Gibt es jemanden der das für jemanden mit guten Grundkenntnissen in E-Technik/Elektronik erläutern kann?

2018-04-03, 23:18:33	#5 (im Thread / einzeln)
vinacis_vivids Avantgarde Member Registriert: 2004-09-08 Ort: Leipzig Beiträge: 6.326	Re: Diskussion zu: Hardware- und Nachrichten-Links der Osterfeiertage 2018 https://radeon.com/_downloads/vega-w...er-11.6.17.pdf Built for higher clock speeds One of the key goals for the “Vega” architecture was achieving higher operating clock speeds than any prior Radeon™ GPU. Put simply, this effort required the design teams to close on higher frequency targets. The simplicity of that statement belies the scope of the task, though. Meeting “Vega’s” substantially tighter timing targets required some level of design effort for virtually every portion of the chip. In some units—for instance, in the texture decompression data path of the L1 cache—the teams added more stages to the pipeline, reducing the amount of work done in each clock cycle in order to meet “Vega’s” tighter timing targets. Adding stages is a common means of improving the frequency tolerance of a design, but those additional stages can contribute more latency to the pipeline, potentially impacting performance. In many cases, these impacts can be minor. In our texture decompression example, the additional latency might add up to two clock cycles out of the hundreds required for a typical texture fetch—a negligible effect. In other instances, on more performance-critical paths, the “Vega” project required creative design solutions to better balance frequency tolerance with per-clock performance. Take, for example, the case of the “Vega” NCU. The design team made major changes to the compute unit in order to improve its frequency tolerance without compromising its core performance. First, team changed the fundamental floorplan of the compute unit. In prior GCN architectures with less aggressive frequency targets, the presence of wired connections of a certain length was acceptable because signals could travel the full distance in a single clock cycle. For this architecture, some of those wire lengths had to be reduced so signals could traverse them within the span of “Vega’s” much shorter clock cycles. This change required a new physical layout for the “Vega” NCU with a floorplan optimized to enable shorter wire lengths. This layout change alone wasn't suffcient, though. Key internal units, like the instruction fetch and decode logic, were rebuilt with the express goal of meeting “Vega’s” tighter timing targets. At the same time, the team worked very hard to avoid adding stages to the most performance-critical paths. Ultimately, they were able to close on a design that maintains the four-stage depth of the main ALU pipeline and still meets “Vega’s” timing targets. “Vega” 10 also leverages high-performance custom SRAMs originally developed by the “Zen” CPU team. These SRAMs, modified for use in the in general-purpose registers of the Vega NCU, other improvements on multiple fronts, with 8% less delay, an 18% savings in die area, and a 43% reduction in power use versus standard compiled memories. ¹⁰ Vega 64 Fine Wine? RDNA3 Radeon Path Tracing (RPT) CP2077!