Vega-Architektur mit HBM2 und neuer Compute-Engine vorgestellt

[oooverclocker]

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).

 

[fdsonne]

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.

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.
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

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

 

[oooverclocker]

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...

 

[Limit64]

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.

"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.

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.

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?

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.

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.

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.

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.

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.

Mit Kepler/Maxwell hat das einfach wenig zu tun... Kepler krankt an anderer Baustelle bzw. Maxwell macht es bedeutend besser.

Und Polaris ist so gut, dass keine bedeutenden Verbesserungen mehr möglich sind?!?!?