> > > > Vega-Architektur mit HBM2 und neuer Compute-Engine vorgestellt

Vega-Architektur mit HBM2 und neuer Compute-Engine vorgestellt

DruckenE-Mail
Erstellt am: von

Kurz nachdem man sich bei AMD dazu entschlossen hatte, mit der Polaris-Architektur auf den Mittelklasse- und Mobile-Markt abzuzielen, folgte die Entscheidung mit einer parallelen Architektur-Entwicklung andere Märkte in den Fokus zu nehmen. Auch wenn AMD in den vergangenen Monaten immer wieder neue FirePro-Grafikkarten auf den Markt brachte, so schien man den Trend zum Machine Learning, Deep Learning, Artificial Intelligence etwas verschlafen zu haben – auch weil die verfügbaren GPUs aufgrund ihrer Architektur in diesem Bereich nicht ihre Stärken hatte. Mit der Vega-Architektur soll diese Lücke nun geschlossen werden. Heute gibt AMD einen ersten Einblick auf das, was uns 2017 erwartet.

Zum jetzigen Zeitpunkt dürfen wir etwas genauer über das sprechen, was wir schon Mitte Dezember im Rahmen der Vorstellung von Radeon Instinct zumindest an der Oberfläche ankratzen konnten. Schon damals wurden einige Details zu Vega bekannt, wenngleich AMD offiziell noch nichts sagen wollte.

Bei der Entwicklung der Vega-Architektur wollte AMD diese auf die aktuellen Anforderungen auslegen und das nicht nur hinsichtlich der Rohleistung der Shadereinheiten, sondern auch die dazugehörige (Speicher)-Infrastruktur. Dass der Speicher ein immer wichtigerer Faktor wird, zeigt die Entwicklung von High Bandwidth Memory, GDDR5X und weiteren Stapelspeichertechnologien wie 3D XPoint bei Intel und HMC bei Micron. In Spielen werden inzwischen einige Gigabyte an Daten in den Speicher geschrieben und wieder von dort gelesen. Bei der Verarbeitung von Video-Inhalten sind wir inzwischen bei mehreren Petabyte angekommen. Schaut man aber in den Compute-Bereich und diesen will AMD mit der Vega-Architektur ansprechen, sind mehrere Exabyte keine Seltenheit mehr. Das auseinanderlaufende Verhältnis zwischen Rechenleistung und der zur Verfügung stehenden Speichermenge sowie dessen Anbindung will AMD wieder in ein sinnvolles Verhältnis rücken.

Neue Speicherarchitektur

Im Rahmen der ersten Vorstellung der Vega-Architektur wollen wir auch mit der Betrachtung der neuen Speicherarchitektur beginnen. Ein wichtiger Bestandteil ist dabei der High-Bandwidth Cache. So bezeichnet AMD den für die GPU verfügbaren Speicher. Dabei handelt es sich nicht nur um den Grafikspeicher, sondern um allen der GPU zur Verfügung stehenden Speicher, einschließlich Caches. Dabei spielt es auch keine Rolle, ob es sich beim Speicher um GDDR5, GDDR5X oder HBM der 1. oder 2. Generation handelt.

Der Vorteil der neuen Speichertechnologien wie HBM2 liegt auf der Hand. Die Speicherbandbreit kann auf bis zu 1.024 GB/s und damit verdoppelt werden. Die zur Verfügung stehende Kapazität kann bis zu 32 GB in vier Stacks zu jeweils 8 GB betragen.

HBM2 ermöglicht flexible Speicherausstattung

Bisher kennen wir den High Bandwidth Memory im Desktop-Bereich nur von der Radeon R9 Fury X. Dort kommt dieser Speicher jedoch in seiner ersten Generation zum Einsatz. AMD verwendet im GPU-Package vier HBM-Speicherstacks mit einer Kapazität von jeweils 1 GB und einer Speicherbandbreite von jeweils 128 GB/s. Der Takt des Speichers liegt bei 500 MHz und somit ergeben sich daraus die insgesamt 4 GB Grafikspeicher und 512 GB/s.

NVIDIA präsentierte im letzten Frühjahr den GPU-Beschleuniger Tesla P100 und dieser ist nach wie vor der einzige seiner Art, der HBM der zweiten Generation verwendet. Auch hier werden vier Speicherstacks verwendet, die allerdings auf jeweils 4 GB Speicherkapazität und auf 180 GB/s kommen. Insgesamt ergeben sich daraus die 16 GB Gesamtspeicher auf der Tesla P100, der mit 720 GB/s angebunden ist. bei HBM2 kann der Takt theoretisch verdoppelt werden, sodass 256 GB/s pro Speicherstack erreicht werden, allerdings verwendet NVIDIA für die Tesla P100 vermutlich noch Speicher aus der Risikoproduktion von Samsung, der diese Taktraten noch nicht erreichen konnte.

Doch HBM2 soll im Unterschied zu HBM1 deutlich flexibler sein, was den Speicherausbau betrifft. Spezifiziert ist HBM2 in Speicherstacks zu 2 (2Hi HBM2), 4 (4Hi HBM2), 8 GB (8Hi HBM2) sowie 16 GB (16Hi HBM2). Bisher haben SK Hynix und Samsung als Hersteller von HBM2 aber nur bis zu 8Hi HBM2 in der Produktion vorgesehen. 16Hi HBM2 sind allerdings bereits spezifiziert und damit theoretisch umsetzbar. Je nachdem, wie viele Speicherstacks nun zum Einsatz kommen, kann der Speicherausbau und dessen Anbindung unterschiedlich ausgeführt werden.

Einige Vorteile des High Bandwidth Memory kennen wir bereits von der 1. Generation, die auf der Radeon R9 Fury X zum Einsatz kommt. Hier liegt die Speicherbandbreite mit 512 GB/s zwar auch schon auf einem recht hohen Niveau, schon damals war es aber wichtig festzuhalten, dass der HBM1 um den Faktor zwei effizienter weil sparsamer bei der Leistungsaufnahme ist. Hinzu kommt, dass der High Bandwidth Memory auf einem Interposer direkt neben der GPU und damit im GPU-Package platziert wird. Damit nimmt der Speicher auch deutlich weniger Platz auf dem PCB sein.

Immer mehr DRAM zu verwenden konnte die aktuellen Limitierungen also nicht mehr aufheben. Außerdem steigen der PCB Footprint und die Leistungsaufnahme. Ein heterogenes Speichermanagement soll die notwendige Flexibilität bieten. Dazu hat AMD den HBCC (High-Bandwidth Cache Controller) entwickelt. Dieser kümmert sich um die Ansteuerung und Verwaltung der verschiedenen Speichertechnologien.

Neben der reinen Größe und Geschwindigkeit des Speichers gibt es noch viele andere Punkte, an denen die Effizienz des Gesamtsystems verbessert werden kann. So ist es nicht notwendig alle Daten im schnellsten Speicher vorzuhalten, denn die GPU kann nur einen bestimmten Datensatz gleichzeitig verarbeiten. Das Datamanagement verschiebt sich von den Spieleentwicklern hin zu AMD bzw. der Architektur selbst. Bisher verwenden die Entwickler allen Speicher, den sie zur Verfügung gestellt bekommen. Die Kontrolle darüber haben sie selbst. Allerdings kostet eine gute und effiziente Anpassung viel Zeit und damit auch Geld.

Die Radeon Pro SSC mit einer SSD war in diesem Segment ein erster Schritt in die Richtung, der mit der Vega-Architektur nun vollständig vollzogen wird. Verschiedene Speicher werden kombiniert, die Hardware übernimmt weitestgehend die Zuteilung und sorgt für eine effiziente Nutzung.

Im Rahmen dieser Umstellung werden wir uns aber auch an neue Begriffe und Funktionsprinzipien gewöhnen müssen. Der Grafikspeicher oder richtiger Frame Buffer wird von AMD nur noch als High-Bandwidth Cache bezeichnet. Angesprochen wird dieser vom neuen High Bandwidth Cache Controller (HBCC), der neben dem HB Cache auch angebundenen Network Storage und System DRAM verwalten kann. Insgesamt kann der HBCC 512 TB an virtuellem Adressraum verwalten. 49 Bit können als Shared Memory auf alle GPUs in einem System verteilt werden. Dazu werden Speicherpools angelegt. 256 TB kann ein einzelner physikalischer Speicher theoretisch groß werden. Der HBCC entscheidet, welche Daten im schnellen Speicher und welche Daten im langsamen Speicher landen. Gesteuert wird dies über den Treiber (siehe Speichermanagement bei Fiji). Zugriffe auf die Daten im Speicher sollen optimiert werden, denn nur etwa die Hälfte der Daten, die sich im Frame Buffer befinden, werden überhaupt verwendet.

Wie ineffizient ein Speicher trotz vieler Optimierungen verwendet wird, zeigt folgendes Beispiel: In einer beispielhaft ausgesuchten Spielszene in Deus Ex: Mankind Devided sind 210 Millionen Polygonevorhanden, davon aber nur 2 Millionen davon sind sichtbar.

Unklar ist noch, wie das neue Speichermanagement genauer aussieht. Ab wann der Treiber die Kontroller übernimmt und wie viel Einfluss die Programmierer darauf haben. Mit DirectX 12 sollte die Kontrolle des Speichers eigentlich weiter in die Hände der Entwickler überführt werden. AMD und NVIDIA übernehmen über die Treiber aber weiterhin eigene Optimierungen, die auf die Hardware angepasst sind.

Neue Geometry Pipeline

Neben dem Speicher hat AMD in der Vega-Architektur aber noch weitere Änderungen vorgenommen und diese betreffen die Geometry Pipeline. Diese soll einen doppelt so hohen Pixeldurchsatz pro Takt im Vergleich zu den bisherigen Architektur aus dem Hause AMD ermöglichen.

An dieser Stelle ein kleiner Exkurs durch die GPU-Architekturen bei AMD. AMD bezeichnet seine Architekturen und Instruction Sets in den vergangenen Jahren mit dem Namen Graphics Core Next (GCN). Den Anfang machte AMD mit der 1. Generation in der Radeon-HD-7700-Serie. Intern wurde diese Architektur auch als GFX7 bezeichnet. Allerdings gibt es Überschneidungen zwischen den GCN-Generationen und den Architekturbezeichnungen bei AMD. Mit GCN 2.0 und GCN 3.0 bzw. GFX8 wurden die darauffolgenden Generationen bezeichnet – bis hin zu den im letzten Sommer vorgestellten Polaris-Karten, die mit GCN 4.0 bezeichnet werden.

Die weitgehenden Änderungen bei der Vega-Architektur rechtfertigen wohl auch eine neue interne Bezeichnung bei den Architekturen. Die Vega-Architektur wird daher auch mit GFX9 benannt. Vega 10 und Vega 11 bleiben dem grundsätzlichen Design der GCN-Architekturen treu.

Neu innerhalb der Geometry Pipeline ist, dass Vertex Shader und Geometry Shader nicht mehr getrennt voneinander behandelt werden. Stattdessen können sogenannte Primitive Shader eingesetzt werden. Diese beinhalten Vertex- und Geometry-Berechnungen, lassen sich über einen verbesserten Load Balancer aber besser auf die zur Verfügung stehenden Hardware-Ressourcen verteilen. Damit sollen die Shadereinheiten auch besser ausgelastet werden. Die GPU überwacht sich bzw. die Auslastung ständig selbst und versucht die ideale Verteilung zu erreichen.

Neue Compute Engine

Dritter wichtiger Bestandteil der neuen Architektur ist die neue Compute Engine und auch hier gibt es weitgehende Änderungen im Vergleich zur bisherigen Architektur. Im Rahmen der neuen Compute Engine wird auch der bereits im Dezember gefallene Begriff NCU genauer erläutert. NCU steht wie von uns vermutet für Next-Generation Compute Engine.

Diese neue Compute Engine kann 512 8-Bit Operationen pro Takt, 256 16-Bit Operationen pro Takt und 128 32-Bit Operationen pro Takt ausführen. Damit kommt die Vega-Architktur auf ein 4:2:1-Verhältnis für diese Datentypen und liegt wieder auf Niveau der Hawaii-GPUs. Das Double-Precision-Verhältnis ist anpassbar. AMD setzt dabei auch auf eine Technologie, die wir von NVIDIA als Mixed Precision kennen. Dabei können 32 Bit Register mit den dazugehörigen 32 Bit Operationen in 2x 16 Bit Register mit 2x 16 Bit Operationen aufgeteilt werden. Dies ist der wesentliche Schritt, um hinsichtlich der Leistung für Machine-Learning-Anwendungen wieder mithalten zu können. Durch andere Optimierunge sollen die NCU auch eine höhere Single-Threaded-Leistung vorzuweisen haben.

Neue Pixel Engine

Änderungen hat es auch bei der Pixel Engine gegeben. Diese kann nun neue sogenannte Draw Stream Binning Rasterizer ausführen, die für eine bessere Kompression der vorhandenen Daten sorgen. Damit soll der Speicherbedarf reduziert werden, was bei der Übertragung dieser Daten aus und in den Speicher auch Vorteile bei der Geschwindigkeit birgt. In einer Szene wird jedes Objekt nacheinander berechnet, dies alles muss durch den Rasterizer – ob sichtbar oder nicht spielt dabei zunächst einmal keine Rolle. Durch den Draw Stream Binning Rasterizer können Pixel entfernt werden, die nicht sichtbar sind. Ein Shading ist in diesem Fall nicht mehr notwendig. Dadurch wird Speicherkapazität und Speicherbandbreite eingespart. In bisherigen GPU-Architekturen von AMD ist der Pixel- und Texturspeicher nicht coherent ausgelegt und musste daher teilweise doppelt verwendet werden. Mit der Vega-Architektur nutzen die Geometry Pipeline, die Compute Engine und die Pixel Engine den zur Verfügung stehenden L1- und L2-Cache parallel. Dies gilt auch für die Render Backends.

Die immer komplexere Fertigung mit mehr und mehr Transistoren stellt für AMD natürlich auch eine Herausforderung dar. Die Leistung muss ebenso steigen wie die Effizienz. Einiges davon kann durch eine verbesserte Fertigung erreicht werden, ein Großteil der aber über eine verbesserte Architektur. Dazu trägt bei Vega unter anderem die neue Speicherhierarchie bei, aber auch die neuen Entwicklungen bei der Compute und Pixel Engine. Ein Ergebnis dieser Entwicklung, die vor vier Jahren startete, ist der Infinity Fabric.

Infinity Fabric

Bei den Zen- bzw. RYZEN-Prozessoren tauchte immer wieder der Begriff Infinity Fabric oder Infinity Control Fabric auf. Doch was steckt dahinter? Eben diese Frage versuchen wir nun einmal zu klären.

Mit der Zen- und Vega-Architektur führt AMD einen neuen Interconnect ein. An diesem Infinity Fabric hat AMD seit 4 Jahren gearbeitet. Der Name Fabric legt im Grunde schon nahe, um welche Struktur es sich handelt, denn Fabric heißt übersetzt Stoff und eben so ist auch dieser Interconnect aufgebaut. Laut AMD ist der Infinity Fabric modular aufgebaut und kann beliebig komplex ausgeführt werden. Eben diese Skalierbarkeit soll den Infinity Fabric in allen neuen Prozessoren und GPUs einsetzbar machen.

Der Infinity Fabric teilt sich auf in einen Control Fabric und Data Fabric. Der Control Fabric ist für die Ansteuerung der verschiedenen Engine-HUBs verantwortlich. Auf Basis des Control Fabric können Technologien wie das Power Management, Sicherheitsfunktionen, Reset&Initialization und das Testing durchgeführt werden. Der Data Fabric hingegen ist ein extrem schneller Interconnect, der dafür verantwortlich ist, dass die Daten schnellstmöglich innerhalb einer Architektur bewegt werden können. Über den Data Fabric wird auch die Verbindung zum Speicher sichergestellt. Im Falle der Vega-GPU bedeutet dies, dass der Interconnect bis zu 512 GB/s zur Anbindung des HBM2 bereitstellen muss. Im Falle eines Mobile-Prozessors mit DDR4-Arbeitsspeicher sind aber auch nur 40-50 GB/s notwendig. Eben dies soll zeigen, wie flexibel der Infinity Fabric ist.

Der Infinity Fabric ist Bestandteil der Vega-Architektur bei den Grafikkarten, aber auch von Summit Ridge bzw. den RYZEN-Prozessoren sowie den für das 2. Halbjahr geplanten Mobile-Prozessoren Raven Ridge, die ebenfalls unter der Marke RYZEN vermarktet werden sollen. Im Falle der Vega-Architektur soll der Infinity Fabric als Mesh, also in einer Gitterstruktur ausgeführt werden. Dies liegt vor allem daran, dass in einer GPU tausende von Shadereinheiten mit Daten gefüttert werden müssen und eine effiziente Verteilung der Daten ist über ein Mesh am besten möglich. Bei den Prozessoren sollen weniger komplexe Topologien für den Infinity Fabric zum Einsatz kommen. AMD wollte keine weiteren Details verraten, eine Ringstruktur wäre hier aber denkbar und wird beispielsweise auch von Intel so umgesetzt.

Der Infinity Fabric ist aber kein reiner Interconnect innerhalb einer CPU oder einer GPU. Laut AMD soll der Infinity Fabric auch in Multi-Socket-Verbindungen zum Einsatz kommen. Dort dient er als technische Basis für AMDs HyperTransport. Mehr zum Infinity Fabric werden wir sicherlich erfahren, wenn AMD den Vorhang zu Zen und Vega vollständig lüftet.

Bis zur ersten Hardware wird es noch etwas dauern

Im Verlaufe der Demos zu Radeon Instict erwähnte Raja Koduri, Chef der Radeon Technologies Group, dass die gezeigte Hardware erst wenige Wochen alt gewesen sei. Der erste Tape Out von Vega 10 soll im Sommer stattgefunden haben. Dies deckt sich in etwa mit dem Zeitrahmen, den AMD zur Polaris-Architektur nannte. Auch hier soll das sogenannte Final Silicon Ende November bzw. Anfang Dezember 2015 vorhanden gewesen sein, wie wir alle wissen erschien die Radeon RX 480 Ende Juni 2016, also rund ein halbes Jahr später. Diesen Zeitplan auf Vega angewendet sehen wir die erste Desktop-Hardware auch nicht viel früher als Mai oder Juni 2017.

Dennoch können wir neben den theortischen Details zur Vega-Architektur auch noch ein paar weitere Details aus den Fotos des Events gewinnen. So hielt Raja Koduri die GPU mehrfach in die Kameras. Im GPU-Package zu erkennen sind zwei HBM-Speicherstacks. Damit könnte die GPU auf 8 oder 16 GB an HBM2 kommen. Das ausgestellte Demo-Systeme zeigte allerdings nur 8 GB an.

Derzeit wissen wir auch noch nicht, um welchen Ausbau der Vega-Architektur es sich bei der gezeigten Hardware handelt. Wir gehen davon aus, dass AMD bisher nur Vega 10 und damit die kleinere Ausbaustufe gezeigt hat. Kommen wir nun wieder zurück zum Demo-System mit Vega und den besagten 8 GB Speicherausbau. Mit HBM2 bestückt wäre es für AMD am logischsten, hier zwei Speicherstacks zu verwenden. Bei 4Hi HBM2 ergäbe dies die 8 GB Gesamtspeicherausbau und bei einem Takt von 1.000 MHz werden hier 256 GB/s pro Speicherstack und insgesamt 512 GB/s erreicht.

Aus der Vorstelltung der Radeon Instinct MI25, die ebenfalls eine Vega-GPU verwendet und zu der AMD eine Rechenleistung von 25 TFLOPS (FP16) angibt, ergibt sich aus angenommenen 4.096 Shadereinheiten ein GPU-Takt von 1.520 MHz. Ob dies letztendlich auch für die Desktop-Version zutrifft, wird sich noch zeigen müssen. Aufgrund der FPS in DOOM bei 3.840 x 2.160 Pixel und dem Ultra-Preset kann aktuell davon ausgegangen werden, dass die erste Vega-Grafikkarte etwas schneller als eine GeForce GTX 1080 sein wird. Genaueres lässt sich derzeit aber noch nicht abschätzen.

Da sich AMD mit der Angabe von technischen Daten noch etwas zurückhält, haben wir versucht aus den Bildern noch ein paar weitere Erkenntnisse zu gewinnen. Gefertigt wird diese wohl in 14 nm. Aus den Bildern der GPU sowie der bekannten Größe der HBM2-Speicherstacks (7,75 mm × 11,87 mm und 91,99 mm²) ergibt sich eine Die-Größe von etwa 520 bis 540 mm². Die Polaris-10-GPU kommt bei 232 mm² auf 5,7 Milliarden Transistoren. Vega 10 mit 520 mm² besäße damit in etwa 12,8 Milliarden Transistoren und wäre ähnlich komplex wie die GP102-GPU von NVIDIA auf der Titan X. Sollte die Größe über 500 mm² tatsächlich zutreffen sein, wäre die erste Vega-GPU deutlich komplexer, als zunächst vermutet. Die daraus zu erwartende Rohleistung müsste deutlich über dem liegen, was NVIDIA mit der GeForce GTX 1080 bieten kann.

Nun heißt es aber zunächst einmal zurücklehnen, denn so schnell werden wir noch keine Grafikkarte mit Vega-GPU sehen. Bis dahin wird AMD sicherlich auch noch einige Informationen veröffentlichen und spätestens mit dem finalen Release und der Verfügbarkeit werden dann auch die letzten Fragen zum Takt und Leistung beantwortet.

Social Links

Ihre Bewertung

Ø Bewertungen: 5

Tags

Kommentare (363)

#354
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
Weinböhla (Sachsen)
Moderator
Beiträge: 32340
Es ist halt deine Entscheidung...

Wir wissen die Preise von Vega oder GP102 nicht
Wir wissen nicht vollends, was bei rum kommen wird
Wir wissen nicht, ob dein bevorzugtes Custom Modell gleich zum Start kommt

Es ist halt vieles offen... Je nach Budget kann es sein, das du nicht so viel ausgeben willst, wie die Dinger kosten werden. Dann wäre die 480er als solide Mittelklasse wohl nicht schlecht.
Für einen reinen Übergang mit dem definitiven Drang, so oder so was fixes zu kaufen, wäre es mir aber zu teuer. Deswegen vote4 290er nach Wahl in Gebraucht. Günstig + viel Leistung... Und bis in einem halben Jahr ca. dürfte sich der 4GB VRAM auch nicht extrem viel problematischer als heute erweisen. Außer dem Verbrauch und der Flexibilität in der Modellvielfalt spricht nicht so viel für die 480er als reiner Übergang zum großen Modell. Eine 470er wäre ggf. aber auch nicht unsinnig ;) Etwas langsamer, aber eben auch günstiger.
#355
customavatars/avatar213165_1.gif
Registriert seit: 02.12.2014

Kapitänleutnant
Beiträge: 1742
Diese Heimlichtuerei ist zum kotzen. Statt die Leute schon auf etwas fixieren zu lassen und Gewissheit zu haben, immer diese Quatsch. Ich bete jeden Tag das eine dritte Firm aus dem Boden emporsteigt, was bessere für wenig Geld rausbringt, viele Marktanteile erobert und rot und grün dumm aussehen läßt.
#356
Registriert seit: 24.08.2009
D
Obergefreiter
Beiträge: 95
Zitat fdsonne;25320782
Einheiteneffizienz ist nicht Stromverbrauch... Einheiteneffizienz meint pro Takt Performance.

Wer hat irgendetwas von Stromverbrauch gesagt? Jedenfalls gehört die Effizienz nicht zur Rohleistung, sondern beschreibt wieviel von der Rohleistung am Ende in effektive Leistung (Anwendungs-/Spiele-Leistung) umgesetzt wird.

Zitat fdsonne;25320782
An welche Stelle kommt dort die Rohleistung ins Spiel? Oder anders gefragt, woran sieht man eine Optimierung auf die Rohleistung?

Anhand von bestimmten Design-Entscheidungen kann man abschätzen worauf die Entwickler besonders Wert gelegt haben. Wird auf Kosten optimiert, wählt man z.B. gerne kleine Einheiten und versucht diese hoch zu takten, denn je kleiner die Einheiten und je höher der Takt desto weniger Fläche braucht man um eine bestimmte Leistung zu erreichen.
Optimiert man auf Energieeffizienz versucht man die Auslastung zu maximieren und nimmt dafür auch größere Einheiten in Kauf (größere Buffer/Caches, aufwendigere Sprungvorhersage, ...). Tendenziell wählt man auch eher moderate Taktraten.
Eine Optimierung auf Rohleistung erkennt man an sehr vielen, aber relativ kleinen, Einheiten bei gleichzeitig möglichst hohen Taktraten. Dieses Schema erkennt man bis Kepler bzw. Fiji und teilweise Polaris. nVidia setzte dabei mehr auf Takt und AMD auf mehr Einheiten.

Zitat fdsonne;25320782
Und natürlich ist die Aussage meinerseits so als Begründung tragbar. Denn ich benannte doch etwas, aus so nicht stattfindet. Und nicht, das findet so nicht statt, weil es nicht stattfindet. Eine Begründung, warum das so ist, habe ich doch gar nicht angestrebt, sondern rein den Umstand erwähnt, dass es so eben nicht ist.

Muss man das verstehen? Deine Aussage ist weder eine allgemeingültige Erkenntnis noch eine reine Beobachtung und bedarf damit auf jeden Fall einer Begründung.

Zitat fdsonne;25320782
Warum reist du den Satz aus dem Zusammenhang? Es ging um den Verbrauch in dem Fall... Kannst du Gegenteilige Aussage wenigstens mit Indizien belegen, warum der Verbrauch einer 4096 ALU breiten GPU nicht in etwa dem doppelten einer Polaris GPU entsprechen sollte?

Ganz einfach, die Shadereinheiten wurden deutlich verändert. Hätte man einfach leicht veränderte Einheiten von Polaris genommen, würde man bei der Fläche und dem kleineren SI problemlos auf >5000, evtl sogar auf >6000 Einheiten kommen. Für eine deutlich geänderte Architektur spricht auch, dass AMD der ISA eine neue Versionsnummer gegeben hat (nicht der Fall bei Polaris), die Notwendigkeit von umfangreichen Treiberanpassungen und die Gerüchte über deutlich höhere Taktraten. Warum sollte man also die Energieeffizienz der alten Architektur so einfach auf die neue übertragen können, denn nur dann würde deine Rechnung Sinn ergeben. Dass eine neue Architektur viele verändern kann hat man bei Kepler zu Maxwell gesehen.


Gesendet von meinem LG-V500 mit Tapatalk
#357
customavatars/avatar179024_1.gif
Registriert seit: 29.08.2012

Kapitän zur See
Beiträge: 3627
Zitat fdsonne;25320782
Einheiteneffizienz meint pro Takt Performance. Vergleichbar mit dem, was AMD für Polaris aussagte (up to 15%) oder NV mit Maxwell (up to 35%)
Oder vergleichbar mit CPUs. Ein Sandy Bridge ist nicht gleich schnell pro Takt und Anzahl der Cores wie ein aktueller Kaby Lake Prozessor. Beide basieren im Grunde aber auf der P6 Microarchitektur. Oder AMDs Bulldozer, der als Bulldozer, Vishera, Steamroller, Excavator als Verbesserungen hat, welche ebenso nicht gleich schnell sind -> dabei spricht man von Einheiteneffizienz, nämlich wie schnell die Einheit bei gleicher Zeit ist.

Ähm, Du hast da aber einen Denkfehler. Bei CPUs kann man auch FLOP/Zyklus berechnen, das heißt mit mehr IPC steigen die FLOPS logischerweise auch an. Mehr Befehle = mehr Operationen pro Sekunde. Du kannst aber eine 32 Bit FPU nicht 1,2 32 Bit- Zahlen gleichzeitig berechnen lassen - sie steckt aber im Produkt der FLOPS, somit sind FLOPS nicht unterschiedlich viel wert, sondern gleichwertig.
Der Rest ist dann durch Limitierungen im Datenfluss, wie effizient komplexere Instruktionen durch elementare umgesetzt sind, etc. begründbar. Da hatte die Fury X offensichtlich eine ziemliche Schwäche, aber das ist eine Ausnahme gewesen und man kann damit rechnen, dass es bei der Vega - Architektur bereinigt wurde. Und je näher die Spiele an den reinen elementaren Float- Operationen mit Vulkan/DX12 sind, umso ausschlaggebender sind auch die reinen FLOPS statt dem Overhead durch Abstraktionsschichten.
#358
Registriert seit: 08.11.2015

Oberleutnant zur See
Beiträge: 1298
Zitat koffeinjunkie;25321052
Ich bete jeden Tag das eine dritte Firm aus dem Boden emporsteigt, was bessere für wenig Geld rausbringt, viele Marktanteile erobert und rot und grün dumm aussehen läßt.


Jensen ist ein Urgestein im GPU Segment; die NV1 kam 1995 heraus. Außer ATI hat sich niemand weiter gehalten im Business. PowerVR lebt noch ein wenig weiter mit ihren Tile Based Rendering approach (siehe Nvidia Maxwell/Pascal Series und AMD Vega) und vielleicht kommt ja auch nochmal Glaze3D zurück samt Bitboys Marketing :D aber das ist eher unwahrscheinlich atm.

Was immer bleiben wird ist Team Green, was aus Team Red mal wird bleibt abzuwarten...
#359
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
Weinböhla (Sachsen)
Moderator
Beiträge: 32340
Zitat Limit64;25321617
Wer hat irgendetwas von Stromverbrauch gesagt? Jedenfalls gehört die Effizienz nicht zur Rohleistung, sondern beschreibt wieviel von der Rohleistung am Ende in effektive Leistung (Anwendungs-/Spiele-Leistung) umgesetzt wird.

Ich ging davon aus, du dachtest ich würde Effizienz den Stromverbrauch/die Energieeffizienz meinen -> wenn dem nicht so war, um so besser ;)
Dennoch benötigt es einen Dritten Faktor in der Rechnung und wenn du dich noch so sehr dagegen stellst, es macht es nicht richtiger diesen wegzulassen. Auch bitte ich dich dir den genauen Themenbezug auf die Aussagen von oooverclocker (abermals) anzusehen. Ich habe nämlich keine Lust, Aussagen die in einem Bezug standen mit irgendwas zu erklären, was mit dem Ursprungsbezug nichts mehr am Hut haben.
Für dich zusammengefasst, es ging um die Behauptung: "Optimierung auf Rohleistung" und im späteren Verlauf auf die Frage, wie man das denn anstellen sollte "so viele wie möglich Einheiten auf so wenig wie möglich Fläche bei so hohem Takt wie möglich". So oder so ähnlich...

Es viel definitiv allerdings im Zusammenhang Rohleistung die Maßeinheit GFlop/sec. Schau bitte selbst oben nach, dass ich dir da keinen Mist erzähle!
-> wenn du dir nun die Formel zur Bildung der "Rohleistung" in GFlop/sec ansiehst wirst du sehr schnell merken, dass da exakt 3, in Worten DREI Faktoren vor dem Gleichheitszeichen stehen. Schimpf den dritten Faktor von mir aus wie du willst. Für mich ist das eine Art Einheiteneffizienzfaktor. Nämlich im Falle der aktuellen AMD Umsetzungen die 2, stellvertretend für ein "MADD". Es gab in der Vergangenheit, wie du vielleicht weist auch andere GPUs aus dem Hause AMD, wo dort eine 10 oder 8 stand. (VLIW5, VLIW4), bei NV stand dort sogar mal eine 3 (MADD + MUL) beim G80/G200.

Also erkläre mir bitte, wie du ohne einen dritten Faktor bei der Formel:
"ALU count" x "clockrate in GHz" = "performance in GFlop/sec kommen willst. Das geht schlicht und ergreifend nicht auf. FAKT!

Die Rechnung im konkreten Beispiel einer RX-480 lautet richtigerweise:
2304 x 1,266 x 2 = 5833,728 GFlop/sec

Der Spaß wird übrigens auch aus einem anderen Blickwinkel rund, nämlich unter dem, dass in den Faktor Rohleistung ebenso einfließen _kann_, wie schnell Einheit überhaupt ist. Wie du vielleicht ebenso weist, gibt es neben ALUs noch andere Einheiten auf der GPU. Und auch diese Besitzen eine Rohleistung. Das, was die ROPs durchschubsen oder das, was die TMUs durchschubsen kann von Generation zu Generation bspw. unterschiedlich sein. Auch hier benötigt es also einen Faktor, der das Ergebnis in die richtige Region lenkt.

Ein weiterer Umstand, der gegen eine ausschließlich "Takt x Anzahl" Rechnung spricht ist bspw. die Ermittlung der jeweiligen Rohleistung auf eine gewisse Prezision, denn es fehlt zusätzlich ein Faktor, der benennt, was überhaupt gleichzeitig geht.
Hawaii hat bekanntermaßen ein SP/DP Verhältnis von 2/1. GK110 hat 3/1.
Nur verwendet Hawaii 4x11x64=2818 ALUs bei SP und 4x11x64/2 = 2818/2 ALUs bei DP. Denn in DP rechnen jeweils zwei ALUs an einem FP64 Wert.
Beim GK110 ist das völlig anders. GK110 hat 5x3x192=2880 ALUs für FP32. UND dazu 5x1x192=960 ALUs für FP64!
Die Rechnung auf Rohleistung ist beim GK110 aber defakto NICHT! (2880+960) x 0,928 x 2 = 4661,76 GFlop/sec. Sondern man man trennt FP32 und FP64. Es arbeiten also NICHT alle Einheiten zur gleichen Zeit bzw. können dies wohl auch gar nicht. Schubst du FP64 durch, liegen die FP32er ALUs brach und andersrum. Eigentlich bedingt das sogar noch einem vierten Faktor -> nämlich dem, der angibt, was überhaupt alles gleichzeitig laufen _kann_... Auch der fehlt in deiner Rohleistungsformel!

Bitte tue mir den Gefallen und erkläre mir auf technisch sachlicher Ebene, wo und an welcher Stelle es richtig wäre, diesen dritten Faktor aus der Rechnung auszuklammern!? Und was das mit der Ursprungspauschalisierung, man würde auf Rohleistung optimieren zu tun hat!?

Zitat Limit64;25321617
Anhand von bestimmten Design-Entscheidungen kann man abschätzen worauf die Entwickler besonders Wert gelegt haben. Wird auf Kosten optimiert, wählt man z.B. gerne kleine Einheiten und versucht diese hoch zu takten, denn je kleiner die Einheiten und je höher der Takt desto weniger Fläche braucht man um eine bestimmte Leistung zu erreichen.
Optimiert man auf Energieeffizienz versucht man die Auslastung zu maximieren und nimmt dafür auch größere Einheiten in Kauf (größere Buffer/Caches, aufwendigere Sprungvorhersage, ...). Tendenziell wählt man auch eher moderate Taktraten.
Eine Optimierung auf Rohleistung erkennt man an sehr vielen, aber relativ kleinen, Einheiten bei gleichzeitig möglichst hohen Taktraten. Dieses Schema erkennt man bis Kepler bzw. Fiji und teilweise Polaris. nVidia setzte dabei mehr auf Takt und AMD auf mehr Einheiten.

Das sind aber nur Indizien, keinesfalls Fakten... Die Behauptung, man (stellvertretend für AMD) optimiert auf Rohleistung und NV optimiert auf Takt ist und bleibt quatsch, vor allem da sich die Aussage insich widerspricht. Deswegen sagte ich eingans auch, dass Rohleistung eben nicht aus nur der Einheitenanzahl besteht. Denn wenn Rohleistung (laut deiner eigenen Aussage) aus Takt x Anzahl besteht, wie kann dann eine Ausrichtung auf Takt x Anzahl eine Rohleistungsoptimierung sein und eine Ausrichtung auf Takt eben nicht? Die Faktoren in der Formel sind gleichgewichtig. Eine Ausrichtung auf Takt _oder_ auf Anzahl _oder_ auf beides -> wäre IMMER eine Rohleistungsoptimierung. Denn bei jeder GPU wird man möglichst das optimale Verhältnis aus Takt und Anzahl anstreben. Unter gewissen Bedingungen, wie der Gesamtfläche, dem Energieverbrauch, der Kosten und vor allem im technisch möglichen Rahmen -> die GPU besteht halt nicht ausschließlich aus ALUs, mal eben da welche dran klatschen ist also nicht. Im Umkehrschluss bedeutet das aber auch, eine Optimierung durch Erhöhung des ALU Counts zieht gleichbedeutend eine Erhöung von Teilen anderer Einheiten nachsich. Damit skaliert man also nicht die Rohleistung der ALUs, sondern man skaliert die komplette GPU. So kann eben ein GP104 x Faktor 1,5 ein GP102 sein. Indem man stupide anstatt 4x vollwertigen GPCs einfach deren 6x verbaut. Man baut aber schlicht nicht 4x GPCs und erhöht dort einfach mal den ALU Count um 1,5 auf 3840 ohne den Rest zu skalieren. Weder bei NV noch bei AMD!
Wobei sich AMD dort in der Vergangenheit recht schwer getan hat, das korrekte Verhältnis aus CUs und Frontend zu finden. Im Moment sieht es so aus (bis einschließlich Polaris) dass 8-10 CUs pro Stück FrontEnd am besten skalieren und Modelle mit bis 16 CUs einfach nicht die Power auf die Straße bringen...

Schau dir dazu vllt einfach den Aufbau gängier Modelle an. AMD verwendet eine Skalierung (jeweils der Vollausbauten) von 8-16 CUs pro Teil am FrontEnd. Bei NV ist das starrer und weniger Flexibel. NV nutzt eine Anzahl von GPCs, je nach Generation (Kepler, Maxwell, Pascal) sind pro GPC eine Anzahl an Shaderblocken mit einem fixen Einheitencount vorhanden. Auch dort siehst du ein Verhältnis, was als Designentscheidung vorgegeben ist und eine Erhöhung ohne weiteres nicht möglich macht!

Zitat Limit64;25321617
Muss man das verstehen? Deine Aussage ist weder eine allgemeingültige Erkenntnis noch eine reine Beobachtung und bedarf damit auf jeden Fall einer Begründung.

Die Aussage, dass eine Optimierung auf Rohleistung unwar ist bedarf doch keiner Begründung... Das ist eben der Vorteil in dieser Gesprächsposition, es ist äußerst einfach Aussagen zu widerlegen während die Belegung der Aussage in anderer Richtung schwer bis unmöglich ist. Ich sehe weiterhin keine Belege für eine Rohleistungsoptimierung, habe dir aber eine ganze Menge Aussagen gebraucht, warum das eben nicht der Fall ist.

Zitat Limit64;25321617
Ganz einfach, die Shadereinheiten wurden deutlich verändert. Hätte man einfach leicht veränderte Einheiten von Polaris genommen, würde man bei der Fläche und dem kleineren SI problemlos auf >5000, evtl sogar auf >6000 Einheiten kommen. Für eine deutlich geänderte Architektur spricht auch, dass AMD der ISA eine neue Versionsnummer gegeben hat (nicht der Fall bei Polaris), die Notwendigkeit von umfangreichen Treiberanpassungen und die Gerüchte über deutlich höhere Taktraten. Warum sollte man also die Energieeffizienz der alten Architektur so einfach auf die neue übertragen können, denn nur dann würde deine Rechnung Sinn ergeben. Dass eine neue Architektur viele verändern kann hat man bei Kepler zu Maxwell gesehen.


Nunja, nenn es Intuition ;) Ich sprach ja auch nicht davon, dass es so ist. Sondern ich sprach, dass ich davon ausgehe, Polaris gibt die Reise vor... Schimpf es von mir aus auch Spekulation. Kann richtig sein oder kann auch falsch sein... Wir werden es sehen. Dennoch deckt sich meine Annahme dahingehend mit den Spekulationen, dass der große Vega im Moment mit bis 300W gehandelt wird. Die Rechnung Polaris x 2 im Verbrauch erzeugt das selbe Ergebnis, wie ich oben vorrechnete.
Mit Kepler/Maxwell hat das einfach wenig zu tun... Kepler krankt an anderer Baustelle bzw. Maxwell macht es bedeutend besser. :wink:

Zitat oooverclocker;25321672
Ähm, Du hast da aber einen Denkfehler. Bei CPUs kann man auch FLOP/Zyklus berechnen, das heißt mit mehr IPC steigen die FLOPS logischerweise auch an. Mehr Befehle = mehr Operationen pro Sekunde. Du kannst aber eine 32 Bit FPU nicht 1,2 32 Bit- Zahlen gleichzeitig berechnen lassen - sie steckt aber im Produkt der FLOPS, somit sind FLOPS nicht unterschiedlich viel wert, sondern gleichwertig.


Du denkst wieder zu kurz... Schau dir bspw. die Prozessoren an, Sandy hat 3x ALUs, Haswell und jünger haben 4x ALUs. Die Rechnung auf die Rohleistung steigt... In dem Fall ist der Faktor zur Benennung (siehe oben die Erklärung, WARUM dieser Faktor da drin ist) der Einheitenleistung also gleich. Anders schaut das auf der FPU aus. 256Bit vs. 128Bit -> wie ermittelst du den Speed als reinen Rohwert, wenn es derartige Unterschied gibt? Auch siehe dazu oben die Aussage bzgl. Kepler FP32/FP64 vs. Hawaii FP32/FP64. :wink:
#360
customavatars/avatar179024_1.gif
Registriert seit: 29.08.2012

Kapitän zur See
Beiträge: 3627
Bei GPUs ist aber schon die Komplexität pro ALU mit dem drumherum viel schwächer und es gibt vom Grundaufbau fast nur geteilte 64 Bit- FPUs, die im Consumer- Segment zum größten Teil 2x 32bit- Zahlen berechnen dürfen. Im Prinzip kann man es fast schon darauf beschränken, ob die ALU ihre Daten vom Drumherum rechtzeitig bekommt oder ob sie verhungern gelassen wird. Während man bei der GPU eigentlich pro ALU auch von Kernen spricht, sind bei der CPU schon in einem Kern mehrere. So eine einfache Rechnung wie bei den GPUs ist dadurch überhaupt nicht möglich, besonders nicht, dass in einem Takt auch genau eine Zahl(oder zwei halbe) berechnet werden könnte.
Das ist eigentlich das, worauf ich hinaus wollte - dass eben der Vergleich GPU vs. CPU einfach hinkt, weil so große Ängerungen durch einzelne Parameter da eher nicht möglich sind, wenn es nicht vorher jemand verbockt hat(wie wahrscheinlich bei Fiji).
#361
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
Weinböhla (Sachsen)
Moderator
Beiträge: 32340
Zitat oooverclocker;25322517
Bei GPUs ist aber schon die Komplexität pro ALU mit dem drumherum viel schwächer und es gibt vom Grundaufbau fast nur geteilte 64 Bit- FPUs, die im Consumer- Segment zum größten Teil 2x 32bit- Zahlen berechnen dürfen.

Auch das halte ich für völlig aus der Luft gegriffen... Über die Komplexität der Einheiten wurde doch gar nicht gesprochen... Aber wenn du das gern tun möchtest, bitte... Die notwendige Logik, die es eben braucht damit ein FP64 Wert aus zwei Einheiten rauspurzeln kann (AMD Hawaii bspw.) erhöht die Komplexität der Einheiten. Sprich der Transistorcount erhöht sich für diesen Umstand. Hier gilt es wohl eher designtechnisch abzuwegen zwischen Flächeneffizienz einer Mixed Precision Einheit und dem Anbringen von Einheiten für die jeweilige Prezision im Vergleich dazu. GK110/GK210 verwendet dedicated Einheiten für FP64. Auf drei Einheiten für FP32 kommt eine Einheit für FP64. Gilt aber NUR für den GK110/GK210 in diesem Beispiel. Der GK104 verwendet weit weniger dedicated FP64 Einheiten und kommt damit auf ein deutlich niedrigeres Verhältnis. AMDs Hawaii in dem Fall ist anders gestrickt. Im Profiprodukt wird voller FP64 Support freigeschalten. Im Gamerprodukt wird es Softwareseitig eingekürzt. Ggf. weggelasert (Spekulation meinerseits)
Andere GPUs aus dem Portfolio bei AMD können aber auch von Haus aus kein 2/1 Verhältnis. Es liegt die Vermutung also nahe, dass man die oben genannte notwendige Logik erst gar nicht einbaut, was sinnig ist, wo es doch überhaupt kein Endprodukt gibt, die es auf 2/1 schafft abseits der Hawaii GPU, die genau dafür exakt in diesem Maße designt ist/wurde. Polaris bspw. KANN es einfach nicht.
EDIT: kleine Anmerkung dazu, interessant sind bspw. die APUs bei AMD -> wenn mich nicht alles täuscht, der A12-9800 kann glaube ich 2/1 ;)

Aber kommen wir zurück zur deiner ursprünglichen Behauptung. Wenn du dir mal die CUs bei AMD ansiehst, wirst du schnell feststellen, dass da pro CU 64 ALUs vorhanden sind, die in jeweils 16er Blocken zusammen gegliedert sind. Und, wenn du aufmerksam weiter das Blockschaltbild anschaust, findest du dort eine Scalar Unit! -> wo taucht die denn in deiner Rechnung auf ALU Anzahl und Takt auf? Und in der Behauptung auf eine Rohleistungsoptmierung?
Die Einheit ist essenziell wichtig! für das Konstrukt. Und die ist dort drin, weil man sie offenbar braucht bzw. das Design so ausgelegt hat, dass diese unter gewissen Umständen eben angesprochen wird. -> in KEINER! Rohleistungsrechnung findet sie sich aber.

PS: Spekulieren wir weiter. Alle Modelle bei AMD skalieren in einem gewissen Verhältnis von SP/DP, außer die auf den Profimarkt ausgelegten Hawaii GPUs und Tahiti, was eine Sonderlocke in dem Fall ist.
Das SP/DP Verhältnis von Polaris ist 16/1, das von Fiji ebenso. -> vllt kommt dir die gleiche Frage mir wie -> was rechnet die FP64 Values?
Sind es die ALUs, die man mit einer Logik versehen MUSS, damit aus 2xALUs ein FP64 Wert rauskommt? Oder hat vllt die Scalar Unit damit was zu tun? Oder gar dedicated Einheiten für FP64? -> rein vom Verhältnis würde es exakt passen... 16/1 lässt sich exakt bis auf den CU runterbrechen!
Nur wieder die Frage, ist das nun Rohleistung-Optimiert? Und wenn ja, warum? Man gibt offenbar wenig bis gar keinen Wert auf Rohleistung für FP64 bei AMD abseits der Modelle, die explizit für diese Form der Prezision ausgelegt sein sollen. Wäre Fiji also Rohleistungsoptimiert, wenn es um FP64 geht? -> definitiv NEIN, wäre es Hawaii? -> möglicherweise ja. Wie passt das dann aber im Vergleich zu GK110? Ist GK110 mit extra dedicated Einheiten Rohleistungsoptmiert?

Vllt fällt dir ja selbst auf, das die Pauschale einer Rohleistungsoptmierten GPU irgendwie völliger Quark ist... Es sind einfach viel zu viele Faktoren, auf die Rohleistung passt und es gibt viel zu viele Möglichkeiten, diese Rohleistung in verschiedenen Produkten zu skalieren. Eins haben sie aber alle gemein, ein gewisses Maß von Designentscheidungen in der Basis gibt vor, wie der Spaß skalierbar ist -> genau das führt die Aussage einer auf Rohleistung optmierten GPU im Vergleich zu einem anderen Produkt aber auch ad absurdum. Denn es fehlen schlicht und einfach Faktoren, die man im Vorfeld festgesetzt hat und an die sich die Ausbauten schlicht richten (müssen).

Wenn du nun mal an Vega oder GP100 denkst... Wo dort 4/2/1 für ein FP16/32/64 Verhältnis stehen sollen... Nunja, gleiches Argument wie oben, Logik, die notwendig ist, damit die Einheiten genau das können... Macht den Spaß komplexer, bläht den Transistorcount auf, hemmt möglicherweise die Fähigkeit, hohe Taktraten zu fahren -> hier zählen auch andere Faktoren rein! spart aber möglicherweise Fläche im Vergleich zu dedicated Einheiten, kostet möglicherweise aber Energieeffizienz (das war mal NVs Argument pro dedicated Units) usw. usf. Auch dort bleibt es aus der Luft gegriffen, dass es eine Rohleistungsoptmierung wäre. Warum haben sie nicht stattdessen einfach 6144 ALUs drauf gezimmert und den Rest so belassen? Oder Polaris mit 3072 ALUs gebracht? -> das wären dann 12 CUs pro Shaderengine und Teil vom Frontend. Ging es nicht? Wollte man es nicht? Gaben andere Einheitencounts es vor ohne günstige Verhältnisse von ALU zu TMU, ALU zu ROP, ALU zu whatever zuweit auseinander zu fahren?? Oder was? Fragen, die sich stellen, wenn man eine Pauschale in den Raum wirfst... Und die diese Pauschale einfach nichtmal im Ansatz bedienen kann. :wink:

Nix für ungut, aber ich habe kategorisch eine Abneigung gegen Pauschalen, die sich derart einfach abschmettern lassen und wo es schlicht viel zu viele Einflussfaktoren gibt, die die gebrachten Modelle einfach beeinflussen können/würden. :wink:
Ist doch OK, wenn du dich besser fühlst mit einer AMD GPU im Vergleich zu einer ALU-Leistungsärmeren NV GPU. Nur muss man da aus meiner Sicht nix erfinden ;)


Zitat oooverclocker;25322517
Im Prinzip kann man es fast schon darauf beschränken, ob die ALU ihre Daten vom Drumherum rechtzeitig bekommt oder ob sie verhungern gelassen wird. Während man bei der GPU eigentlich pro ALU auch von Kernen spricht, sind bei der CPU schon in einem Kern mehrere. So eine einfache Rechnung wie bei den GPUs ist dadurch überhaupt nicht möglich, besonders nicht, dass in einem Takt auch genau eine Zahl(oder zwei halbe) berechnet werden könnte.
Das ist eigentlich das, worauf ich hinaus wollte - dass eben der Vergleich GPU vs. CPU einfach hinkt, weil so große Ängerungen durch einzelne Parameter da eher nicht möglich sind, wenn es nicht vorher jemand verbockt hat(wie wahrscheinlich bei Fiji).


Nein, weder spricht von bei der GPU von "Kernen" für die ALUs noch ist ein Vergleich dahingehend zur CPU sinnig... Häng dich bitte nicht an dem Prozessoren auf, die dienten doch nur als Mittel zum Zweck dir ein Beispiel zu geben, dass Einheitenanzal und Takt nicht die Rohleistung machen... Aber auch darum ging es ursprünglich nicht :wink:
#362
customavatars/avatar179024_1.gif
Registriert seit: 29.08.2012

Kapitän zur See
Beiträge: 3627
OK - ich kann vieles nachvollziehen, ist ja auch mindestens überwiegend alles richtig, aber jetzt mal ganz bildlich: Wenn die Architektur von Nvidia, aus welchen Gründen auch immer, trotz weniger FLOPS, leistungsfähiger wäre, warum zeigt sie es dann in DX12 und Vulkan nicht mehr, wenn für beide Hersteller ans Limit optimiert wurde, sondern bildet im Durchschnitt wie AMD- Karten auch, und wie auch im OpenCL, einfach nur ihre Rohleistung ab? :)
Schlussfolgerung: Die Architektur ist wohl eben nicht besser. Sondern geht wegen der höheren Taktrate einfach nur Overhead aus dem Weg, dem man mit Gameworks etc. möglicherweise noch selbst ein bisschen nachhilft...;)
#363
Registriert seit: 24.08.2009
D
Obergefreiter
Beiträge: 95
Zitat fdsonne;25322443
Es viel definitiv allerdings im Zusammenhang Rohleistung die Maßeinheit GFlop/sec. Schau bitte selbst oben nach, dass ich dir da keinen Mist erzähle!
-> wenn du dir nun die Formel zur Bildung der "Rohleistung" in GFlop/sec ansiehst wirst du sehr schnell merken, dass da exakt 3, in Worten DREI Faktoren vor dem Gleichheitszeichen stehen. Schimpf den dritten Faktor von mir aus wie du willst. Für mich ist das eine Art Einheiteneffizienzfaktor.

Das was du als Einheiteneffizienzfaktor bezeichnest wird für gewöhnlich als Breite oder auch Durchsatz einer Einheit bezeichnet und hat mit Effizienz nichts zu tun. Sehr breite Einheit sind sogar häufig ineffizienter, da es schwerer ist sie auszulasten. Wenn du wirklich die Einheiten zählst, reichen auch zwei Faktoren, denn eine MADD-Einheit ist z.B. in der Regel nämlich nur eine MUL und eine ADD Einheit, die seriell hintereinandergeschaltet sind. Das macht man einfach, weil diese Kombination extrem häufig vorkommt und man so im Vergleich zu separat arbeitenden Einheiten ein paar Transistoren sparen kann.

Zitat fdsonne;25322443
"ALU count" x "clockrate in GHz" = "performance in GFlop/sec kommen willst. Das geht schlicht und ergreifend nicht auf. FAKT!

Jo, wenn du diese "Kombi-Einheiten" als eine Einheit zählst, passen die drei Faktoren. Mit Effizienz hat das aber nichts zu tun, denn sonst wäre z.B. auch Itanium eine extrem effiziente Architektur, denn deren "Einheiteneffizienzfaktor" wäre nach deiner Definition 128 im Vergleich zu 3/4 bei der Core-Architektur.

Zitat fdsonne;25322443
Der Spaß wird übrigens auch aus einem anderen Blickwinkel rund, nämlich unter dem, dass in den Faktor Rohleistung ebenso einfließen _kann_, wie schnell Einheit überhaupt ist. Wie du vielleicht ebenso weist, gibt es neben ALUs noch andere Einheiten auf der GPU. Und auch diese Besitzen eine Rohleistung. Das, was die ROPs durchschubsen oder das, was die TMUs durchschubsen kann von Generation zu Generation bspw. unterschiedlich sein. Auch hier benötigt es also einen Faktor, der das Ergebnis in die richtige Region lenkt.

Natürlich hat jede Einheit ein gewisses Leistungspotential und man könnte auch jedes davon als Rohleistung bezeichnen (selbst die Speicherbandbreite). Bei der ganzen Sache geht es aber darum das Leistungspotential einer Architektur auf möglichst einen einzelnen Wert zu reduzieren (den man dann Rohleistung bezeichnet) und bei GPUs ist die Wahl eben auf die Compute-Leistung gefallen.

Zitat fdsonne;25322443
Ein weiterer Umstand, der gegen eine ausschließlich "Takt x Anzahl" Rechnung spricht ist bspw. die Ermittlung der jeweiligen Rohleistung auf eine gewisse Prezision, denn es fehlt zusätzlich ein Faktor, der benennt, was überhaupt gleichzeitig geht.

Was hat das damit zu tun? Du gibst die Leistung bei einer bestimmten Prezision an. Das gleiche tust du bei der Rohleistung. Alles andere macht keinen Sinn oder willst du die SP und DP-Leistung irgendwie miteinander verrechnen?

Zitat fdsonne;25322443
Eigentlich bedingt das sogar noch einem vierten Faktor -> nämlich dem, der angibt, was überhaupt alles gleichzeitig laufen _kann_... Auch der fehlt in deiner Rohleistungsformel!

Die Rohleistung ist eine Abstraktion um eine komplexe Architektur mit sehr vielen Leistungsparametern auf einen einzelnen Wert zu reduzieren und Abstraktionen haben es an sich, dass man viele Details einfach weglässt.

Zitat fdsonne;25322443
Das sind aber nur Indizien, keinesfalls Fakten... Die Behauptung, man (stellvertretend für AMD) optimiert auf Rohleistung und NV optimiert auf Takt ist und bleibt quatsch

Wenn du nicht mal ein einziges vernünftiges Argument für deine Position bringen kannst würde ich deine Aussage als Quatsch bezeichnen.

Zitat fdsonne;25322443
Deswegen sagte ich eingans auch, dass Rohleistung eben nicht aus nur der Einheitenanzahl besteht. Denn wenn Rohleistung (laut deiner eigenen Aussage) aus Takt x Anzahl besteht, wie kann dann eine Ausrichtung auf Takt x Anzahl eine Rohleistungsoptimierung sein und eine Ausrichtung auf Takt eben nicht?

Hoher Takt und viele Einheiten sind beides Möglichkeiten die Leistung zu steigern. Etwas anderes habe ich nie behauptet.

Zitat fdsonne;25322443
Die Faktoren in der Formel sind gleichgewichtig. Eine Ausrichtung auf Takt _oder_ auf Anzahl _oder_ auf beides -> wäre IMMER eine Rohleistungsoptimierung.

Rein theoretisch ja, denn du maximierst die Rohleistung indem du Einheitenzahl und Takt maximierst. In der Realität gibt es aber Randbedingungen, die erfüllt werden müssen, einige davon sind durch die Fertigung vorgegeben, andere sind Designentscheidungen. Da diese Designentscheidungen wesentlich für die Architektur sind, kann man grob die Ziele der Entwickler daran erkennen. Solche Randbedingungen sind z.B. Größe des Chips oder max. Leistungsaufnahme. So erreichst du bei fester Leistungsaufnahme durch mehr Einheiten mit niedrigeren Taktraten eine höhere Rohleistung, da hohe Taktraten in der Regel mit Spannungserhöhungen verbunden sind und diese quadratisch in die Leistungsaufnahme mit eingehen. Andererseits gibt es auch eine Flächenbegrenzung. Sobald du in deren Nähe kommst, ist eine Takterhöhung die einzige Möglichkeit die Rohleistung weiter zu steigern. Wie bereits schon einmal gesagt sind nVidia Architekturen bis Kepler und AMD Architekturen bis min. Polaris offensichtlich Rohleistungsoptimiert, bei AMD stärker über die Einheitenzahl, bei nVidia stärker über die Taktrate. Bei nVidia gab es allerdings mit der Maxwell-Generation eine grundlegende Änderung des Designs. Man machte die einzelnen Einheiten sehr viel effizienter, aber auch deutlich größer. So ist Maxwell bei vergleichbarer Rohleistung deutlich schneller als Kepler. Nach AMD-Angaben scheint Vega in die gleiche Richtung zu gehen, nämlich wenigere, dafür aber effizientere Einheiten. Deswegen ist der Vergleich Kepler->Maxwell zu Polaris->Vega durchaus angebracht. Ob die Umsetzung genau so gut wie bei nVidia funktioniert, weiß zur Zeit wohl nur AMD, aber die Zielrichtung ist klar.


Zitat fdsonne;25322443
Die Aussage, dass eine Optimierung auf Rohleistung unwar ist bedarf doch keiner Begründung... Das ist eben der Vorteil in dieser Gesprächsposition, es ist äußerst einfach Aussagen zu widerlegen während die Belegung der Aussage in anderer Richtung schwer bis unmöglich ist.

Wenn es so einfach ist, dann widerlege sie doch bitte mal. Die Behauptung kein Argument zu brauchen ist nämlich kein Argument.

Zitat fdsonne;25322443
Mit Kepler/Maxwell hat das einfach wenig zu tun... Kepler krankt an anderer Baustelle bzw. Maxwell macht es bedeutend besser. :wink:

Und Polaris ist so gut, dass keine bedeutenden Verbesserungen mehr möglich sind?!?!?
Um Kommentare schreiben zu können, musst Du eingeloggt sein!

Das könnte Sie auch interessieren:

Roundup: 5x GeForce GTX 1070 mit Custom-Design im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/5X-GTX1070/GTX1070_CUSTOM_ROUNDUP-TEASER

Nachdem wir bereits eine Reihe von Boardpartner-Karten der NVIDIA GeForce GTX 1080 ausführlich getestet haben, holen wir gleiches nun für das kleinere Schwestermodell nach, denn auch von der NVIDIA GeForce GTX 1070 gibt es viele Custom-Modelle mit höheren Taktraten, eigenen Kühlsystemen und... [mehr]

Drei Custom-Modelle der GeForce GTX 1060 im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/3X-GTX1060/GTX1060_ROUNDUP_TEST-TEASER

Anders als bei der GeForce GTX 1080 und GeForce GTX 1070 trudelten wenige Stunden nach unserem Test zur Founders Edition der NVIDIA GeForce GTX 1060 schon die ersten Boardpartner-Karten mit teils höheren Taktraten, eigenem Kühlsystem und überarbeitetem Platinenlayout ein. Sie dürften... [mehr]

NVIDIA GeForce GTX 1080 mit Pascal-Architektur im XXL-Test

Logo von IMAGES/STORIES/LOGOS-2016/GEFORCE-GTX-1080

Heute ist es soweit: NVIDIA läutet mit der GeForce GTX 1080 und GTX 1070 auf Basis der Pascal-Architektur den diesjährigen Neustart bei den Grafikkarten ein. In Kürze wird wohl auch AMD seinen Beitrag zu diesem Thema leisten. Vor zehn Tagen lud NVIDIA die gesammelte Fachpresse nach Austin ein... [mehr]

Roundup: 5x GeForce GTX 1080 im Custom-Design im Test

Logo von IMAGES/STORIES/LOGOS-2016/GEFORCE-GTX-1080

Nachdem wir uns die Founders Edition der GeForce GTX 1080 und GeForce GTX 1070 bereits angeschaut haben, folgen nun fünf Retail-Modelle, die wir in aller Ausführlichkeit unter die Lupe nehmen wollen. Aus den vielen Boardpartnern und unterschiedlichen Modellen haben wir uns solche von ASUS, EVGA,... [mehr]

AMD Radeon RX 480 im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/RADEON-RX480/RADEON-RX480-REFERENCE-LOGO

Es ist also soweit: AMD startet die großangelegte Zurückeroberung des Grafikkartenmarktes mit der Radeon RX 480, die als erste Grafikkarte der Polaris-Generation mit gleichnamiger Architektur erscheint und die wir uns genauer anschauen können. Dabei versucht sich AMD an einem anderen Ansatz im... [mehr]

PowerColor Radeon RX 480 Red Devil im Test

Logo von IMAGES/STORIES/GALLERIES/REVIEWS/2016/POWERCOLOR-RX480/POWERCOLOR-RX480REDDEVIL-LOGO

Mit der Radeon RX 480 will AMD zurück zu alter Stärke und hat daher über Monate hinweg die PR-Trommel geschlagen. Letztendlich dabei herausgekommen ist eine sehr gute Karte für einen niedrigen Preis, die aber nicht in allen Bereichen zu überzeugen weiß. Wohl größtes Manko der Karte sollte... [mehr]