VEGA (Vega10, Vega11, Vega12, Vega20) - 2017

[Isen]

Oder Throttled weil AMD zuviel Kleber bestellte und nicht wussten wohin damit, außer dort :D

[Blediator16]

Hoffen wir mal für Vega das Doom im CPU-Limit war. XD

Welcher Vega war das denn?

[Isen]

Vega *Zugeklebt* Edition.

[derF]

Hoffen wir mal für Vega das Doom im CPU-Limit war. XD
Versteh ich nicht.
"Hoffen wir mal für Ryzen, dass Doom im GPU-Limit war."

[KORE]

Welcher Vega war das denn?

Na der kleine ;)

[Unicous]

Wie oft denn noch. Bei der "Demo" ist VSync an.:facepalm:


(btw. bei dem HBC habe ich mich ja dann doch deutlich geirrt. Also "neuer" Cache mit hoher Bandbreite und extra Controller... hört sich ja schon mal interessant an.)

Ok, doch nur HBM umbenannt....:freak:

[Isen]

Nein, Unicous. Eben nicht. ;-) schwankt zwischen 60-75fps - Zu Beginn bei den fetten Energiebällen kurz auf 58 und sogar einmal auf 43 rum.
Bei dem Star Wars Video hingegen schon.

[TheGood]

http://www.forbes.com/sites/patrickmoorhead/2017/01/05/amd-provides-vega-graphics-architecture-details-and-it-looks-very-promising/#2807b83c7c5c

das scheint schon auf den nachher zu erhaltenden Infos zu basieren

Edit: Na wohl eher auf den von videocardz basierten Folien.

[Unicous]

Ah ok, sorry. Dann muss ich das zurücknehmen. Ich dachte das war die gleiche Demo zum zigsten Mal hier verlinkt.:freak:

[KORE]

Versteh ich nicht.
"Hoffen wir mal für Ryzen, dass Doom im GPU-Limit war."

Dann aber in den anderen Thread. ;)

[dargo]

Also bei dem von Isen verlinkten Video sehe ich kein Vsync On. ;)

[BlacKi]

ca doppelt so schnell wie p10 mit oc

CPDkpTUXgQc

[Complicated]

Wäre aus meiner Sicht zu unflexibel. Man möchte ja nicht eine Wavefront von einem SIMD zu einem anderen transferieren (Overhead zu groß dafür). Das wird (falls es so kommt) vermutlich eher wie bei den alten Vektorrechnern laufen (auf die hat sich AMD ja schon bei der GCN-Vorstellung explizit bezogen), wo eine relativ schmale Einheit einfach mehrere Takte lang an einem variabel langen Vektor gearbeitet hat. Je länger der Vektor, desto mehr Takte.

Beispiel:
Unter vec4 macht es meiner Meinung nach zu wenig Sinn (eventuell nimmt man vec8 oder bleibt gar bei vec16, da bei kleinen Vektoren der Overhead für instruction issue recht groß wird), da die Pixelshader immer noch in Quads abgearbeitet werden. Lass eine CU also z.B. aus 16 vec4 Vektoreinheiten bestehen (statt vier mal vec16 bisher). Für eine Wavefront aus althergebrachten 64 Elementen benötigt so ein Ding dann 16 Takte. Werden mehrere Quads ausgeblendet, wird es entsprechend schneller (12 Takte bei 48 Elementen, 9 Takte bei 36, 3 Takte bei 12 usw.). Mit nur vier gültigen Elementen (1 Quad) kann jeden Takt ein neuer Befehl (aber für eine andere Wavefront, wegen Latenz) abgesetzt werden. Hierfür benötigt man dann aber viele Wavefronts, die zur Ausführung bereit sind, um die Latenzen zu verstecken. Mit ein wenig Aufwand kann man so auch Branching innerhalb einer Wavefront recht effizient handhaben (über Splitten der Wavefront in zwei kleinere, Rekonvergenz muß man halt hinkriegen, damit das wirklich gut funktioniert). Und so ein Umbau erlaubt es eventuell auch, die Latenz der Einheiten etwas zu erhöhen (hilft der Taktfähigkeit), wenn man flexibler mit dem Scheduling wird (was aber mehr Aufwand bedeutet, auch mit der Synchronisierung mit der Skalareinheit, wovon man dann eventuell eher zwei einbaut, um dem erhöhten Durchsatz kleinerer Wavefronts gerecht zu werden).
Als Mittelweg bieten sich vielleicht acht vec8 Einheiten (mit einer Latenz von 8 Takten statt bisher 4?) an. Oder man bleibt gar bei vier mal vec16, kann aber die Vektorlänge dynamisch auf bis zu 16 Elemente reduzieren (in Stufen von 64, 48, 32 oder 16). Für herkömmliche Wavefronts mit 64 Elementen ändert sich dann praktisch kaum etwas. Aber kleinere Wavefronts werden schneller, solange man genügend Occupancy (Füllgrad der CU mit Wavefronts) hat.
Zunächst einmal Sorry für den Fullquote, doch der ist mit Grund.

Zuerst einmal bezugnehmend auf den von mir fett markierten Teil möchte ich dich und die anderen Experten hier auf folgenden Artikel bei GPUOpen hinweisen, der nach meiner begrenzten Kenntnis auf dieser Detailebene, sich exakt mit diesem Problem des Overhead schon für die aktuelle GCN Architektur beschäftigt:
http://gpuopen.com/concurrent-execution-asynchronous-queues/

Nur um zu verifizieren, dass ich den fetten Teil richtig verstanden habe.
Dies würde genau das beschreiben nach meinem Verständnis, was du oben als problematisch beschrieben hast und wie es auf Vectorrechnern laufen würde:
http://developer.amd.com/community/blog/2014/05/16/codexl-game-developers-analyze-hlsl-gcn/
If more waves per SIMD is better for latency hiding, and this is often achieved through lower VGPR usage, a question arises: Why doesn’t the AMD driver’s shader compiler just schedule instructions such that VGPR usage is minimized? Consider the following simple pseudo-code example of two possible ways to schedule instructions:

Schedule 1
-----------
Load v1
Load v2
Load v3
VALU use v1
VALU use v2
VALU use v3

Schedule 2
-----------
Load v1
VALU use v1
Load v1
VALU use v1
Load v1
VALU use v1

Schedule 1 requires 3 VGPRs, whereas Schedule 2 uses only a single VGPR to do the same work. However, although Schedule 2 uses fewer registers, it is not necessarily better, because you have to wait for each load to complete before the data is available for use by the VALU.
Grouping loads together as in Schedule 1 is better for latency hiding within a particular wavefront, but Schedule 2 is better for GPR pressure, which could mean more waves per SIMD, which also hides latency (by switching between wavefronts). So basically, it’s complicated.
So wird es unter CodeXL für bestehende GCN Architekturen verwendet.

Der oben verlinkte Artikel bei GPUOpen zeigt hier neue Instruktionen die schon auf GCN gewisse, soweit ich verstanden habe eingeschränkte, Möglichkeiten des "shifting" von Wavefronts. Mich würde interessieren ob dieser Code tatsächlich der erste Schritt in diese Richtung mit unterschiedlich großen Einheiten ist und schon dafür bereit steht um diese Möglichkeiten noch mehr zu nutzen.

Terminology

We’ll be optimizing communication between work-items, so it is important to start with a consistent set of terminology:


The basic execution unit of an AMD GCN GPU is called a wavefront, which is basically a SIMD vector.
A wavefront comprises 64 parallel elements, called lanes, that each represent a separate work item.
A lane index is a coordinate of the work item in a wavefront, with a value ranging from 0 to 63.
Because a wavefront is the lowest level that flow control can affect, groups of 64 work items execute in lockstep. The actual GCN hardware implements 16-wide SIMD, so wavefronts decompose into groups of 16 lanes called wavefront rows that are executed on 4 consecutive cycles.

This hardware organization affects cross-lane operations – some operations work at the wavefront level and some only at the row level. We’ll discuss the details below.
Why Not Just Use LDS?

Local data share (LDS) was introduced exactly for that reason: to allow efficient communication and data sharing between threads in the same compute unit. LDS is a low-latency RAM physically located on chip in each compute unit (CU). Still, most actual compute instructions operate on data in registers. Now, let’s look at the peak-performance numbers. The memory bandwidth of AMD’s Radeon R9 Fury X is an amazing 512 GB/s. Its LDS implementation has a total memory bandwidth of (1,050 GHz) * (64 CUs) * (32 LDS banks) * (4 bytes per read per lane) = 8.6 TB/s. Just imagine reading all the content of a high-capacity 8 TB HDD in one second! Moreover, the LDS latency is an order of magnitude less than that of global memory, helping feed all 4,096 insatiable ALUs. LDS is only available on a workgroup level.
At the same time, the register bandwidth is (1,050 GHz) * (64 CUs) * (64 lanes) * (12 bytes per lane) = 51.6 TB/s. That’s another order of magnitude, so communication between threads is much slower than just crunching data in the thread registers.
But can we do better by sharing? The answer is yes, if we further reduce our scope from a workgroup to a single wavefront.


Ich habe den Eindruck, dass mit den dort beschriebenen "permute" und "swizzle" Instruktionen genau das schon praktiziert wird in geringerem Umfang. Den nächsten Step scheint nun Vega in Hardware zu machen, doch Code dafür ist schon vorhanden. Speziell dieser Code sollte demnach auf Vega deutlich schneller laufen. Er ist auf Github schon verfügbar zum testen.

Ich bitte um Korrektur oder Anpassung, falls ich da etwas falsch verstanden habe.

[Linmoum]

Doom läuft ohne V-Sync, Battlefront mit.

[MechWOLLIer]

Ein wenig mehr Details dürfen es dann doch sein.
Das ist eine Vega-Preview. Schraubt eure Erwartungen bitte herunter :)

[Gipsel]

Was ist Binning Rasterizer, klärt mich auf.Ein Ausführung des Rasterizers, die man für Tile based Renderer (egal ob immediate oder deferred) benötigt. NVidia verbaut seit Maxwell auch etwas in der Art (sehr abgespeckt).

Was im Prinzip passiert, ist, das die Geometrie nach der Transformation in Bildschirmkoordinaten nicht sofort gerastert und in die Pixelshader gejagt wird. Vielmehr wird nur festgestellt, in welchen Bereich des Bildschirms ein Dreieck fällt (dazu wird der Screen in mehrere Kacheln [Tiles] unterteilt) und für jeden Tile wird eine Liste der Geometrie angelegt, bis der komplette Frame durch ist. Danach wird dann Tile für Tile gerendert (Rasterizer + Pixelshader). Ein TBDR stellt vorher noch fest, welche Pixel von welchen Dreiecken genau verdeckt bzw. sichtbar sind, führt also die Pixelshader nur für jeden Pixel genau einmal aus, Overdraw wird eliminiert. Weiterhin läuft das ganze in einem On-Chip-Speicher ab. Erst wenn ein Tile fertig ist, wird es final in den Speicher geschrieben. Man benötigt also deutlich weniger externe Bandbreite. Ein TBIMR macht keine (vollständige) hidden surface removal sondern vertraut nur auf den schnellen on-chip Zwischenspeicher für den Overdraw. Die externe Bandbreitenanforderung wird aber ebenfalls reduziert.
Bestimmte Rendertechniken können aber Probleme machen und die Renderer praktisch in einen Fallback zum Immediate Mode zwingen (was für TBIMRs trivial ist, die Adrenos können z.B. sogar vom Programmierer umgeschaltet werden).

Für Desktop-GPUs setzt nV auf eine Art Minimalimplementation (Details sind aber nicht bekannt, es ist also schwierig einzuschätzen). In den Tilebins wird nur Geometrie eines einzigen Drawcalls gesammelt (also nicht über Drawcalls hinweg) und die Menge an gesammelte Geometrie ist überschaubar (maximal wohl 64kB an Daten, was ein paar tausend Dreiecke entspricht, je nachdem wie viel Parameter man hat). Trotzdem bringt dies bereits Vorteile und Bandbreitenersparnis, da viele Drawcalls eben lokal begrenzte Objekte zeichnen und man diese räumliche Lokalität nutzen kann, um die Caches besser zu nutzen und so die Bandbreitenanforderungen zu senken.
AMD erwähnt nun explizit auch hidden surface removal und "fetch once"/"shade once", was darauf hindeuten könnte, daß mehr gesammelt wird (oder es sind einfach Schlagworte, die man so raushaut) als bei nV. Es ist aber auch weiterhin ein immediate mode renderer, er pflückt nur ein paar der niedrig hängenden Früchte mit Anleihen von den Tile based Renderern. Wie gut das umgesetzt ist, werden wir sehen müssen.

[deekey777]

Das ist eine Vega-Preview. Schraubt eure Erwartungen bitte herunter :)
Spielverderber. Die ganze Vorfreude genommen, bist noch schlimmer als der Leaker. :P

[pest]

Ich will jetzt Benches :mad:

http://www.gifbin.com/bin/2074yu4sw2.gif

[Gipsel]

Zunächst einmal Sorry für den Fullquote, doch der ist mit Grund.

Zuerst einmal bezugnehmend auf den von mir fett markierten Teil möchte ich dich und die anderen Experten hier auf folgenden Artikel bei GPUOpen hinweisen, der nach meiner begrenzten Kenntnis auf dieser Detailebene, sich exakt mit diesem Problem des Overhead schon für die aktuelle GCN Architektur beschäftigt:
http://gpuopen.com/concurrent-execution-asynchronous-queues/

Nur um zu verifizieren, dass ich den fetten Teil richtig verstanden habe.
Dies würde genau das beschreiben nach meinem Verständnis, was du oben als problematisch beschrieben hast und wie es auf Vectorrechnern laufen würde:
http://developer.amd.com/community/blog/2014/05/16/codexl-game-developers-analyze-hlsl-gcn/

So wird es unter CodeXL für bestehende GCN Architekturen verwendet.

Der oben verlinkte Artikel bei GPUOpen zeigt hier neue Instruktionen die schon auf GCN gewisse, soweit ich verstanden habe eingeschränkte, Möglichkeiten des "shifting" von Wavefronts. Mich würde interessieren ob dieser Code tatsächlich der erste Schritt in diese Richtung mit unterschiedlich großen Einheiten ist und schon dafür bereit steht um diese Möglichkeiten noch mehr zu nutzen.

Ich habe den Eindruck, dass mit den dort beschriebenen "permute" und "swizzle" Instruktionen genau das schon praktiziert wird in geringerem Umfang. Den nächsten Step scheint nun Vega in Hardware zu machen, doch Code dafür ist schon vorhanden. Speziell dieser Code sollte demnach auf Vega deutlich schneller laufen. Er ist auf Github schon verfügbar zum testen.

Ich bitte um Korrektur oder Anpassung, falls ich da etwas falsch verstanden habe.Mit den Permute- und Swizzle-Geschichten verschiebt man nur Daten innerhalb einer Wavefront (zwischen verschiedenen Lanes) also innerhalb eines Registerfiles. Der größere Overhead beim Verschieben einer Wavefront kommt daher, daß man etliche kB an Daten von einem Registerfile in ein anderes schieben müßte, also den kompletten Kontext der Wavefront. Das ist nicht unmöglich (und der LDS bietet sich dafür an), aber eben fraglich, ob sich das lohnt.

[robbitop]

Vieleicht funktioniert in Vega ja auch die DCC besser. Laut Foobar ist diese bis inklusive Polaris ziemlich "ghetto" und bringt zumindest in DOOM praktisch nichts.

[Tru]

Ich will jetzt Benches :mad:

http://www.gifbin.com/bin/2074yu4sw2.gif
Hast du eine mechanische Tastatur? Ein paar Monate F5 in dem Tempo drücken könnte hart werden.

[Complicated]

Mit den Permute- und Swizzle-Geschichten verschiebt man nur Daten innerhalb einer Wavefront (zwischen verschiedenen Lanes) also innerhalb eines Registerfiles. Der größere Overhead beim Verschieben einer Wavefront kommt daher, daß man etliche kB an Daten von einem Registerfile in ein anderes schieben müßte, also den kompletten Kontext der Wavefront. Das ist nicht unmöglich (und der LDS bietet sich dafür an), aber eben fraglich, ob sich das lohnt.
Danke dir. Würde dies demnach bedeuten, dass beim verschieben von Lanes hier Daten von den Lanes am Ende des Blocks einfach verloren gehen oder werden diese erhalten und können durch eine andere Wavefront genutzt werden im weiteren Verlauf. Sozusagen innerhalb der 4 Takte beim abarbeiten der Wavefront.
Siehe auch hier:
http://gpuopen.com/amd-gcn-assembly-cross-lane-operations/
Den Link hatte ich oben vergessen, Sorry

ds_swizzle_b32

Full crossbar in a group of four
Limited sharing in a group of 32, such as the following:

Swap groups of 1, 2, 4, 8 or 16
Reverse in groups of 2, 4, 8, 16 or 32
Broadcast any lane in a group of 2, 4, 8, 16 or 32
Any other shuffle that can be expressed using bit masks




DPP Modifier


Full crossbar in a group of four
Wavefront shift/rotate by one lane
Row shift/rotate by 1–15 lanes
Reverse inside a row or half-row
Broadcast 15th lane of each row to the next row
Broadcast lane 31 to rows 2 and 3

[iuno]

Eine NCU besteht nun wohl aus 128 SPs, die 256 16 bit Ops und 512 8 bit Ops raus hauen können, double precision konfigurierbar
bzgl. fp64 war gcn ja bisher auch schon "konfigurierbar". Hawaii hat die beste Konfiguration bekommen, Fiji nicht :freak:
Oder wie soll man das verstehen?

[fondness]

Das ist eine Vega-Preview. Schraubt eure Erwartungen bitte herunter :)

Was, keine Benchmarks? ;(

bzgl. fp64 war gcn ja bisher auch schon "konfigurierbar". Hawaii hat die beste Konfiguration bekommen, Fiji nicht :freak:
Oder wie soll man das verstehen?

Wohl genau so. Je nach Chip. Mit 128 SPs pro CU könnte man auf 1/32 DP-Leistung runter gehen bei der "kleinsten" Config.

[MechWOLLIer]

Was, keine Benchmarks? ;(

Falls AMD nicht Sachen auspackt, die es auf dem Tech Summit nicht zu sehen gab - nein.

Wie sagte Raja so schön am Anfang: Das ist kein Techday, das ist eine Preview.

[fondness]

ve.ga ist down ;(

https://s27.postimg.org/9yjt4abvn/logo_1260x709_707b7ad8.jpg (https://postimg.org/image/c3465ddi7/)

https://www.computerbase.de/2017-01/amd-vega-preview/

[MR2]

ve.ga ist down ;(

https://s27.postimg.org/9yjt4abvn/logo_1260x709_707b7ad8.jpg (https://postimg.org/image/c3465ddi7/)
Lies halt erstmal das:-)
https://www.computerbase.de/2017-01/amd-vega-preview/

[Linmoum]

Auch wenn AMD nie explizit davon gesprochen hat, dass die gezeigte GPU das zukünftige Flaggschiff wird, deutet die Größe des Die darauf hin: der vermutlich Vega 10 genannte Chip ist groß – überraschend groß. Die Perspektive und die nicht perfekt sichtbaren Konturen macht eine exakte Analyse zwar unmöglich, ComputerBase geht aber von einer Fläche zwischen 520 bis 530 mm² aus.

https://www.computerbase.de/2017-01/amd-vega-preview/

[fondness]

Here we go:
https://www.computerbase.de/2017-01/amd-vega-preview/
http://www.pcgameshardware.de/Vega-Codename-265481/Specials/Architektur-NCU-HBCC-Vorstellung-1217460/
http://www.anandtech.com/show/11002/the-amd-vega-gpu-architecture-teaser-packed-instructions-more-coming-in-h12017

[Troyan]

Mehr als 500mm^2?! Dann ist die Karte wohl wirklich noch fast 6 Monate entfernt. Sind wohl viele Transistoren in die neuen Features geflossen, wodurch der Rechenleistungsvorteil sich deutlich negiert hat zu nVidia.

[Blediator16]

Mehr als 500mm^2?! Dann ist die Karte wohl wirklich noch fast 6 Monate entfernt. Sind wohl viele Transistoren in die neuen Features geflossen, wodurch der Rechenleistungsvorteil sich deutlich negiert hat zu nVidia.

Gib uns mehr von deinem Wissen über die Architektur bitte

[dargo]

ve.ga ist down ;(

https://s27.postimg.org/9yjt4abvn/logo_1260x709_707b7ad8.jpg (https://postimg.org/image/c3465ddi7/)
Alter Schwede, das Ding ist ja riesig. Das können doch niemals nur 4096 SPs sein. :confused:

[fondness]

Wenn die IPC und der Takt entsprechend steigt sind 4096 SPs nicht so wenig. Dazu 2xFP16 und 4x8-bit Leistung. P100 hat 610mm² bei "nur" 3864 SPs. Abwarten, könnten natürlich auch mehr SPs sein, aber ich würde nicht mehr mit den anderen AMD-Chips vergleichen.

[Skysnake]

Gibt es denn keinen Stream der laeuft?

[fondness]

t6CrvyXeT9Q

[Unicous]

Ich dachte eigentlich auch, dass es einen Stream gibt, aber AMD hat das ja nie wirklich angekündigt.

Schon sehr peinlich, dass die ve.ga Seite down ist kann mir nicht vorstellen, dass es am Ansturm liegt.

[BlacKi]

geht bei mir http://ve.ga/

[Botcruscher]

Wenn die IPC und der Takt entsprechend steigt sind 4096 SPs nicht so wenig. Dazu 2xFP16 und 4x8-bit Leistung. P100 hat 610mm² bei "nur" 3864 SPs. Abwarten, könnten natürlich auch mehr SPs sein, aber ich würde nicht mehr mit den anderen AMD-Chips vergleichen.

P100 ist aber nun mal ganz anders aufgebaut. Womöglich sehen wir doch was in die Richtung 6000.

[Blediator16]

Wirds überhaupt eine Präsentation geben? Es sieht so aus, als ob es bereits eine gab?

[Unicous]

geht bei mir http://ve.ga/

Ja, aber erst seit ein oder zwei Minuten wieder.


... und es gibt nur das alte Uprising Video. :rolleyes:


Ach AMD, das kann doch nicht euer Ernst sein.

[Blediator16]

Typisch AMD das kann doch einfach nicht wahr sein...wann lernen die es endlich:facepalm:

[Skysnake]

hmm... "nur" Zwei HBM2 stacks. Das empfinde ich jetzt als etwas wenig. Da sollte noch ein Chip mit 4 Stueck kommen, damit man gegen P100 richtig anstinken kann.

[Linmoum]

Wurde denn überhaupt ein Livestream angekündigt?

[qu3x^]

Gibt es denn keinen Stream der laeuft?
Den Drummerboy hat AMD zu Hause gelassen. Offenbar gibts wieder nur hypothetische Slides die beweisen sollen wie überlegen eine Architektur sein könnte. Da es weder Slides zur Leistung gibt noch genau Details zur Karten selbst gibt wird es bis März nichts neues geben.

[Flusher]

Ich dachte die zeigen was auf der CES, stattdessen ist einfach nur ein NDA von einem Folienpaket gefallen, dass bereits im Dezember der Presse gezeigt wurde.

meeh...:|

[BlacKi]

Wurde denn überhaupt ein Livestream angekündigt?
wofür war denn der timer? nur das ende des NDA??? lame...

€dit: auf dem amd twitch channel hatte ich den eindruck, das man statt einem live stream, nun als ersatz die werbevideos laufen lässt https://www.twitch.tv/amd

[qu3x^]

Ich dachte die zeigen was auf der CES, stattdessen ist einfach nur ein NDA von einem Folienpaket gefallen, dass bereits im Dezember der Presse gezeigt wurde.

meeh...:|
Das leidige an der Geschichte ist das AMD nach so einem Brimborium wieder nicht liefern konnte. Bei der Vorstellung von Ryzen hatte ich echt schon Hoffnungstränen das zu CES etwas lauffähiges in Form von einer Top Tier Lösung gezeigt wird.

[[MK2]Mythos]

Eins muss man AMD lassen, sie schaffen es immer wieder, uns zu trollen. :D

[Troyan]

Äh, wieso habt ihr mehr erwartet? In Vegas geht gerade die Sonne auf. Da stellt sich niemand hin und hält eine Pressekonferenz...

AMD hat auch nichts zu verlieren. Polaris hat man gerade geosbornt. Viel erwartet man wohl von der alten Architektur nicht mehr. Dann kann man den Endkunden schonmal mitteilen, dass ein neuer, moderner Chip mit über 200 neuen Features in den nächsten 6 Monaten erscheinen wird.

[Linmoum]

Es wurde das "geliefert", was angekündigt war. Nämlich eine Preview auf die Vega Architektur. Von mehr war nie die Rede.

[Blediator16]

Es wurde das "geliefert", was angekündigt war. Nämlich eine Preview auf die Vega Architektur. Von mehr war nie die Rede.

Diese Art von Marketing ist einfach nur schlecht und das ist Fakt. So etwas bringt AMD nicht weiter.

[Kartenlehrling]

Das schicksal vom Ei und Henne, warscheinlich warten beide Hersteller sogar auf Microsoft März-Update.

[Axe Homeless]

Mal ungeachtet des suboptimalen Marketings und PR.

Gibt es denn jetzt endlich mehr ordentliche Infos, ETA Termine, Leistungsversprechen, wichtige Features?

[Setsul]

Wenn HBM2 Stacks nicht auf einmal kleiner geworden sind (oder es HBM1 ist), dann stimmt die Größe schon.
Es müsste mal jemand unauffällig Raja Koduris Finger vermessen, damit man immer einen Vergleichswert hat.

Ohne 1/2 DP wäre die Konkurrenz GP102, 3840 SPs bei 471mm² gegen 4096 SPs bei 500-550mm² sind jetzt nicht fürchterlich unrealistisch.

Egal worauf es letztendlich genau herausläuft, 32 NCUs oder 36 NCUs oder was auch immer, bei der Größe muss sich das Ding eigentlich zwingend auch mit einem GP102 im Vollausbau anlegen können. Alles andere wäre ein peinlicher Fehlschlag.

Natürlich alles unter der Annahme DP <1/2 SP. Aber selbst mit DP wären 1080 +10% für einen fast doppelt so großen Chip mit HBM, sprich schlimmstenfalls wirklich doppelt so große genutzte Fläche, wirklich erbärmlich.

[BlacKi]

Mal ungeachtet des suboptimalen Marketings und PR.

Gibt es denn jetzt endlich mehr ordentliche Infos, ETA Termine, Leistungsversprechen, wichtige Features?
mhh, zu vega?^^

vl hilft dir das um einzuschätzen wie weit vega noch weg ist:

"Ein Fragezeichen beim Fertigungsprozess

Angefangen hat die Entwicklung von Vega schon vor langer Zeit. Die ersten Gedanken über Vega habe man sich vor fünf Jahren gemacht, so Koduri. Offen bleibt noch die Frage, auf welche Fertigung Vega setzt. Denkbar sind entweder wie bei Polaris 14-nm-FinFET bei Globalfoundries oder das konkurrierende 16-nm-FinFET von TSMC." https://www.computerbase.de/2017-01/amd-vega-preview/

[iuno]

Das Ding ist ja echt riesig, geht mMn. sogar eher an die 550 statt 500 mm². Der Chip kommt doch sicher auch noch mit 4 Stacks. Sofern alles was hier so schoen dargelegt wird klappt macht ein kleinerer Vega Chip mit 1 Stack halt doch noch Sinn.

[Screemer]

geosbornt

Wow, du hast ein neues wort gelernt und musst es nun in jeden zweiten post verwenden. :up:

[Sunrise]

Diese Art von Marketing ist einfach nur schlecht und das ist Fakt. So etwas bringt AMD nicht weiter.
Diese Art von Marketing hat die Mitglieder und GPU-Interessenten in den Tech-Foren dazu verleitet die F5-Tasten zu hämmern und das Interesse an Vega ist jetzt (mit den neuen Infos) größer denn je.

Sprich: Du hast keine Ahnung von Marketing, genausowenig wie die meisten in den Foren.

Da weder die Treiber fertig sind, noch irgendwelche Karten final sind, keine Taktraten festgelegt wurden (das ist so ziemlich der letzte Schritt), braucht AMD hier keine Ergebnisse zu veröffentlichen, wenn man jetzt mit ein paar Preview-Videos schon sieht, dass man mit einer Titan X Pascal min. mithalten kann.

Einfach mal weniger Kaffee trinken und sich beruhigt zurücklehnen. Da kommt schon noch mehr, nur eben nicht jetzt.

Es ist genau das was AMD benötigt, permanent im Gespräch zu bleiben und Vega genau dann zu liefern, wenn das Paket fertig ist und keine Sekunde vorher. Ich leg mich dann mal wieder hin.

Achja, bei PCPerspective kommt demnächst wohl noch was, AMD hat da einiges in der Pipeline.

[dildo4u]

PCPER:AMD Vega GPU Architecture Preview: Redesigned Memory Architecture

https://youtu.be/jVHFRtKy_iE

[fondness]

Dieses Standardmäßig rauzen, egal was AMD macht ist nur noch lächerlich. Es wurde eine Architekur-Preview angekündigt und das würde geliefert. Das es jetzt noch keine Benchs gibt, sollte klar sein. Aber egal was AMD macht, es wird eben grundsätzlich geraunzt.

[BoMbY]

Wenn HBM2 Stacks nicht auf einmal kleiner geworden sind (oder es HBM1 ist), dann stimmt die Größe schon.
Es müsste mal jemand unauffällig Raja Koduris Finger vermessen, damit man immer einen Vergleichswert hat.

Ohne 1/2 DP wäre die Konkurrenz GP102, 3840 SPs bei 471mm² gegen 4096 SPs bei 500-550mm² sind jetzt nicht fürchterlich unrealistisch.

Egal worauf es letztendlich genau herausläuft, 32 NCUs oder 36 NCUs oder was auch immer, bei der Größe muss sich das Ding eigentlich zwingend auch mit einem GP102 im Vollausbau anlegen können. Alles andere wäre ein peinlicher Fehlschlag.

Natürlich alles unter der Annahme DP <1/2 SP. Aber selbst mit DP wären 1080 +10% für einen fast doppelt so großen Chip mit HBM, sprich schlimmstenfalls wirklich doppelt so große genutzte Fläche, wirklich erbärmlich.

Ich denke die Fläche könnte sich sich durch die doppelten ALUs per NCU im Vergleich zu alter CU ergeben? Also würde 64 NCUs quasi etwa der Fläche von 128 CUs entsprechen?

[Unicous]

Es wurde das "geliefert", was angekündigt war. Nämlich eine Preview auf die Vega Architektur. Von mehr war nie die Rede.

Es war von nichts die Rede. Es gab einen Countdown und dann... ein "altes" Video ohne neue Informationen. Es wurde auf der Seite nichts geliefert. Nicht einmal Links zu den Previews auf den Tech Sites.

Das ist hochgradige Dummheit und man fragt sich wieder und wieder, wer so etwas veranlasst. Sie haben ja noch nicht einmal die neuen Videos verlinkt.

Ich frage mich langsam, ob das Online-Marketing-Team seit Jahren das Gleiche ist und nichts auf die Reihe bekommt und die Trailer lediglich outsourced werden.
Es ist ja nicht so, als hätten sie nur schlechte Marketing-Leute. Das Technical Marketing Team ist kompetent und zugänglich. Der Rest scheint aber einfach nur unfähig zu sein. Es sollte doch nicht so schwer sein, ein paar Slides auf die Seite zu klatschen und/oder olle Raja (mit Untertiteln :freak:) ein paar Sätze sprechen zu lassen.

Stattdessen gibt es einen nichtssagenden Trailer der nicht einmal erklärt was Vega überhaupt ist.


@Sunrise

Nicht jeder steht auf Tease&Denial (https://de.wikipedia.org/wiki/Tease_and_Denial)
Und nein, es ist kein gutes Marketing.
Es wurde auf der Seite nichts geliefert, als potentiell Interessierter muss man jetzt selbst auf die Suche nach Informationen gehen, nachdem auf der Countdown ein schwarzes Nichts präsentiert wird (und lustigerweise das Video wohl nur über die Countdownseite gelegt wurde, die Typen, die die Seite gebaut haben sind also auch noch zu faul wenigstens die frontpage zu ersetzen).
Die Leute ragen gerade bei Twitch, bei Reddit und wahrscheinlich in allen Foren, dass AMD nichts geliefert hat, nachdem nVidia heute früh schon so hart gefailed hat.
Die Kundschaft ist erregt, also sie regen sich auf.:rolleyes: Das ist kein gutes Marketing.

[qu3x^]

Es wurde das "geliefert", was angekündigt war. Nämlich eine Preview auf die Vega Architektur. Von mehr war nie die Rede.
Bei einer Preview will ich erste Balkendiagramme sehen. Solche Infohappen, die mir die Presse erst aufarbeiten muss um die theoretische Leistung dieses Produkts zu erahnen ist doch absolut lächerlich. AMD hätte die omninöse "Blackbox" in der ein Prototyp steckt aufdröseln können. Ich hab eher den Eindruck das mit dieser Taktik versucht noch im Gespräch zu bleiben.

[Linmoum]

Bei einer Preview will ich erste Balkendiagramme sehen.
Dann hast du den Sinn hinter dieser ARCHITEKTUR (soll man das noch fetter hervorheben?) Preview nicht verstanden.

[iuno]

Einfach mal cool bleiben und http://ve.ga aktualisieren.
Habt ihr dort wirklich mehr erwartet?

[fondness]

Es sind einige neue Videos online:

M3chULm4glM
TLM3LNpEYXA
FUktXMzUMVw
vGffngWEX78
Ku5OMWYVKSs

[Dino-Fossil]

Als Preview der Architektur interessant, wenn auch noch viele Fragen offen bleiben.
Man könnte darüber streiten, ob AMD derart Dinge groß ankündigen sollte, da offenbar nicht wenige Leute einen falschen Eindruck davon bekommen, was sie geliefert kriegen.

Für mich stellen sich, abseits des eigentlichen Release-Dates von Vega nun vor allem zwei Fragen:
1. Wieviel kommt von den diversen Änderungen/Neuerungen/Verbesserungen in der Praxis an und
2. Wie schaut es auf der Treiberseite aus? Wieviel muss AMD am Treiber mit Vega ändern, schaffen sie es rechtzeitig und bedeutet das dann automatisch auch einen verringerten Fokus auf GCN4 und darunter?

[Unicous]

@iuno

Es wird nicht besser. Da steht nur Gelaber. Wenn ich mir Gelaber anhören will, schaue ich mir Jensens Keynote an.:freak:

[Grundkurs]

Habt ihr dort wirklich mehr erwartet?
Jetzt wo wir langsam auf Mitte Januar zusteuern: Ja.
Diese Salami-Taktik von AMD bekommt mittlerweile fast Christian Wulff'sche Züge vor seinem Abtritt als B-Präsident :biggrin:

[dildo4u]

Ist es nicht normal das die GPU so ein Monster ist,da AMD nicht wie Nvidia ein extra HPC Chip baut?

[Digidi]

All die Grünen die hier stänkern, geht doch Mal in eueren eignen Thread und fragt euch wo die große Ankündigung von Nvidia bleibt!

Ich glaube nachdem Nvidia nicht die 1080ti präsentiert hat hält sich AmD zurück um nicht zu viel zu verraten! Wenn AMD jetzt vorlegt und Nvidia mit höherem Takt kommt ist AMD der Dumme so sieht es aus!

[Menace]

Einfach mal cool bleiben und http://ve.ga aktualisieren.
Habt ihr dort wirklich mehr erwartet?

Habt ihr von unseren ewig gleichen nölenden Jungs wirklich mehr erwartet? :biggrin: Ich weiß nicht, was mich trauriger macht, deren gespielte "Enttäuschung" gegenüber einer Marketing Webseite oder die postfaktischen (ich habe auch ein Wort gelernt :biggrin: ) Unterstellungen, dass AMD mehr "versprochen" hätte.

So wie Computerbase annimmt (sofern ich das richtig verstanden habe) geht es dann von der größten Karte (Vega 10) runter bis zu einer möglichen Vega 20. Letztere ist dann der Polaris Ersatz?

[Sunrise]

...Die Kundschaft ist erregt, also sie regen sich auf.:rolleyes: Das ist kein gutes Marketing.
Alles, was die Leute anheizt und Aufmerksamkeit verursacht, egal in welcher Form, ist gutes Marketing. Ich möchte mich eigentlich nicht wiederholen.

Dass hingegen Erwartungen nicht erfüllt werden (es ist eine Architektur-Preview), ist einzig und allein ein Fehler, der vor dem Bildschirm zu suchen ist. Es ist ja nicht so, als hätte es keine neuen Informationen gegeben. Dann wäre so ein Einwand auch eher berechtigt.

Vega ist noch ein gutes Stück weiter weg, es wird je näher wir zum Release kommen auch mehr gezeigt werden, das ist genau das, was AMD machen muss.

[qu3x^]

Dieses Standardmäßig rauzen, egal was AMD macht ist nur noch lächerlich. Es wurde eine Architekur-Preview angekündigt und das würde geliefert.
Das liegt schlicht daran dass sowohl das "grüne Lager" als auch das "blaue Lager" sich auch nach Konkurenz sehnen, die der jetzige Markt dringenst notwendig hat. Selbst wenn es bedeutet im gleichen Lager wieder ein zu kaufen. Den Preisen würde es gut tun. Die Verdroßenheit in den unterschiedlichen Lagern macht es im Moment nicht leicht emotionslos zu sein wenn der Hoffnungsträger für einen belebten Markt wie unseren, es nicht schaft zeitgerecht zu überzeugen.

Meine größte Sorge, und ich hoffe es entpuppt sich nicht als Deja vu Erlebnis wäre, wenn es ein Rohrkrepierer wie die damlige R600 GPU wird. Viel Bla Bla zur unheimlichen Rohleistung während es unzählige Probleme mit dieser GPU gab, sowohl treiberseitig als auch der thermische Standpunkt. Ich hatte mich damalig noch für 2 dieser GPUs entschieden und auch noch den Wechsel auf eine 4860 vollzogen ehe ich ins "grüne Lager" gewechselt habe...

[Setsul]

@BoMbY:
Hab ich doch geschrieben.:wink:
Aber das könnten 1024 SPs pro NCU sein und man bekäme trotzdem keinen Preis wenn man deswegen dann die 16-fache Fläche für die gleiche Leistung braucht.
Ob das 32 NCUs oder 64 CUs sind, ist völlig egal, 4096 SPs bei 1525 MHz geben 12,5 TFlops. Mehr SPs mit niedrigerem Takt oder umgekehrt ändern auch nicht viel.

Mehr SPs pro (N)CU = weniger (N)CUs pro SP. Nach der Logik bräuchte man weniger Fläche. Aber die SPs werden größer sein, wenn sie höher takten sollen und der Overhead dürfte auch gestiegen sein. Ist es alles wert wenn am Ende mehr Leistung / Watt oder mehr Leistung / Fläche rauskommt.

Mehr Leistung / Watt bei viel größere Fläche oder kleinerer Leistung ist keine Kunst, Takt und Spannung runter und dann hat man das, also läuft alles auf Leistung / Fläche raus.
Und ein >500mm² Chip sollte eher bei vollem GP102 (471mm²) +10% rauskommen als bei einer 1080 (314mm²) +10%, das wäre erbärmlich.


Wie gesagt, wenn DP mit dabei ist, dann sieht es etwas anders aus, aber den GP104 muss AMD mit >500mm² und HBM schon locker schnupfen können.

[TheGood]

Es ist wie immer. Solange die "grünen" nicht hier waren, gabs ne ordentliche Diskussion und nun "den grünen sei dank" gleitet es in absolute Belanglosigkeit und dummen Gelaber aus.

Entweder tragt etwas ordentliches und sinnvolles zum Thread bei, dem auch andere interessierte wie ich, gerne lesen oder lasst Eure Kommentare einfach stecken.

[Gipsel]

Sicher wären mehr Detailinformationen nett, aber erwarten konnte man die nun nicht gerade.
Mal zum Vergleich: Ein gutes halbes Jahr vor der Einführung der HD7970 hat AMD auf einem Entwicklertreffen eine Präsentation zur GCN Architektur gegeben. In ziemlichem Detail, was die CUs anging (sogar das Schema des Instruktionsencodings wurde gezeigt und ISA-Code im Vergleich zu den VLIW-Architekturen usw.), mit weniger Details für den Rest und überhaupt gar nichts zu konkreten Produkten (wie CU-Zahl, Anzahl der verschiedenen Engines usw.) und natürlich auch keinen einzigen Benchmark.
Jetzt sind wir wieder noch einige Monate (vermutlich 5) vom Launch entfernt und wir hatten ein Architektur-Preview (nicht für Entwickler und ausdrücklich keine Präsentation) und jemand erwartet Informationen wie bei einer Produktvorstellung? Kann ich nicht nachvollziehen.

[rentex]

Ob die Theorie so stimmt, das beide Hersteller aufeinander warten? Wohl nicht ganz...Nvidia wartet auf AMD! Bis dahin wird der Pascal Refresh vorbereitet und beim VEGA Release losgelassen...vielleicht!
Ich hoffe VEGA's Releasetreiber, bringen die Leistung auf die Straße.

[Korvaun]

Mein aktuelles Fazit:

- VEGA10 ist groß und viele Sachen sind stark überarbeitet (endlich). Leistung erwarte ich auf GP102-Niveau. Salvage entsprechend darunter.

- Das Silikon selbst ist noch sehr jung, erst ein paar Wochen alt. Die Treiber sind eher noch im Alpha-Stadium.

--> VEGA10 wird wohl erst gegen Ende Q2 kaufbar werden und nicht gerade billig, bestimmt mindestens so teuer wie die Fury anfänglich (>700€). Ein echtes Performance-Preview kommt sicherlich noch im Frühjahr, wenn die Treiber gereift sind und die Produktion läuft. Aktuell wäre das echt sinnlos.


VEGA11 sollte dann wohl auf 1070/1080 Niveau sein und noch später erscheinen (Herbst)?

[Nakai]

Mhh, hat Vega nun nativen Support für NVRAM und anderem Speicher?
Das könnte die Größe der gezeigten Vega-Instict-Karte erklären. Da ist nicht nur eine GPU drauf.

Die Neuentwicklungen am Speichersystem verdeutlichen ja auch, dass Vega wohl nicht nur HBM2 als "Haupt"Speicher verwenden könnte.
Vielleicht sind noch PHYs für DDR4 und NAND-Flash verbaut? Das würde die Diesize auch etwas aufblähen.

[deekey777]

Die AMD-Präsentation ist so schlimm wie die von Apple, wo jede so kleine Farbweichung eine Revolution verspricht.

Was genau versteckt sich in der Folie "CU vs. NCU"? In der *-Beschreibung steht nur, dass eine CU 64 Shaders ("Stream Processors") enthält. Verdoppung der SPs an sich? Auf welche Art 128 SPs oder (1+1)*64 SPs? Was soll die Andeutung des doppelt so hohen Taktes? Oder sagt diese Folie gar nichts aus, sondern soll nur zeigen, dass die neuen NCUs einfach flexibel sind: doppelt so hoher Takt oder 128 SPs.

[Sunrise]

...Und ein >500mm² Chip sollte eher bei vollem GP102 (471mm²) +10% rauskommen als bei einer 1080 (314mm²) +10%, das wäre erbärmlich.
Anders, AMD benötigt bei dieser Chipgröße und HBM2 in etwa >= Titan X Pascal (GP102)-Leistung, was aber durch die Bank sicher nicht einfach wird. Zumindest out-of-the-box sind die Taktraten ja erwartbar schonmal recht ähnlich zur Titan X. Nur hatte AMD ja bisher das Problem, die GPU nicht annähernd so gut auslasten zu können, das bedarf sicher einiges an Treiberarbeit, aber evtl. wurden nun auch endlich mal eine paar Flaschenhälse beseitigt. Von außen ohne weitere Daten schwer zu sagen, anhand von Marketing-Folien sieht es erstmal nüchtern betrachtet gut aus, aber was das in Zahlen bedeutet wissen wir aktuell nur anhand von Spiele-Videos (das reicht bei weitem nicht)

Wenn sie einen 1080Ti-Killer bzw. Konkurrent spätestens im Sommer liefern, warum nicht. Alles andere darf kein Ziel sein.

[Nakai]

Die AMD-Präsentation ist so schlimm wie die von Apple, wo jede so kleine Farbweichung eine Revolution verspricht.

Was genau versteckt sich in der Folie "CU vs. NCU"? In der *-Beschreibung steht nur, dass eine CU 64 Shaders ("Stream Processors") enthält. Verdoppung der SPs an sich? Auf welche Art 128 SPs oder (1+1)*64 SPs? Was soll die Andeutung des doppelt so hohen Taktes? Oder sagt diese Folie gar nichts aus, sondern soll nur zeigen, dass die neuen NCUs einfach flexibel sind: doppelt so hoher Takt oder 128 SPs.

Ja, das stimmt. Das ist mehr Verwirrung und Pseudohype als Klarheit.

Ich würde diese Folien nicht ernst nehmen.

Im Endeffekt verdeutlicht es nur zwei Sachen:
- höhere Frequenz der Rechteckkurve => mehr Takt
- zwei OP pro Zyklus => doppelt SP-Anzahl

[redlock]

Die Artikel Heise und Golem klingen auf den ersten Blick sehr spannend.

Die Leistungssteigerungen der letzten Jahre waren ja eher auf mehr Shader und Architektur-Kosmetik zurückzuführen. Die Effizienz der Architektur stieg dabei nur marginal. Im Gegensatz bei NVidia, wo fast die gleiche Shaderanzahl auf einmal 30 Prozent mehr Leistung brachte.

Wenn AMD es diesmal hinbekommt, endlich die Effizienz zu steigern und sei es nur durch mehr GPU-Takt, so wäre es ein echter Hoffnungsschimmer.

Aber ! Wenn ich mal eine kleinen simplen Vergleich der Performance auf Basis der DOOM-Ultra-4K-Vulkan-Benchnmarks mache, so sieht das alles andere als nach Hoffnung aus:

AMD
Vega = 70 Fps bei 4.096 Shadern = pro Frame sind 58 Shader notwendig = Keine Verbesserung zu Polaris
Fury X = 55 Fps 4.096 Shadern = pro Frame sind 74 Shader notwendig
RX 480 = 39 Fps bei 2.304 Shadern = pro Frame sind 59 Shader notwendig
380X = 29 Fps bei 2.048 Shadern = pro Frame sind 70 Shader notwendig

NVIDIA
GTX 1080 = 63 Fps bei 2.560 Shadern = pro Frame sind 41 Shader notwendig
GTX 1070 = 50 Fps bei 1.820 Shadern = pro Frame sind 36 Shader notwendig
GTI 980 = 47 Fps bei 2048 Shadern = pro Frame sind 43 Shader notwendig

[robbitop]

Alter Schwede, das Ding ist ja riesig. Das können doch niemals nur 4096 SPs sein. :confused:
Es ist eine Frage, wie diese aussehen. NV bekommt IPC und Takt auch nicht geschenkt. Deren SPs sind viel größer. Wenn die SPs auf ähnliche Ergebnisse kommen wie Maxwell/Pascal, dann darf der Chip auch größer werden.
GP102 @4096SPs wäre nach Milchmädchen übrigens 502 sqmm groß.

[mboeller]

http://cdn.videocardz.com/1/2017/01/AMD-VEGA-VIDEOCARDZ-28.jpg
HOTCLOCK CONFIRMED ;D
Spaß beiseite, ein oder zwei Pipelinestufen mehr wären echt mal angebracht. Das Scheduling dürfte bei 128 SPs auch etwas aufgeblasen werden.

sind das 4 32bit FP-Ops bei den alten CU's und 14 16bit FP-Ops (bzw. 7 32bit FP-Ops) bei den neuen NCUs? ... oder interpretiere ich zu viel in das Bild hinein? ;D

[BoMbY]

sind das 4 32bit FP-Ops bei den alten CU's und 14 16bit FP-Ops (bzw. 7 32bit FP-Ops) bei den neuen NCUs? ... oder interpretiere ich zu viel in das Bild hinein? ;D

Ja, ungefähr das. Man könnte daraus auf jeden Fall auf fast eine Taktverdoppelung schließen, wobei man da die Erwartungen eher realistisch halten sollte. Im besten Fall wären das doppelte Fiji Flops.

[Troyan]

Es ist eine Frage, wie diese aussehen. NV bekommt IPC und Takt auch nicht geschenkt. Deren SPs sind viel größer. Wenn die SPs auf ähnliche Ergebnisse kommen wie Maxwell/Pascal, dann darf der Chip auch größer werden.
GP102 @4096SPs wäre nach Milchmädchen übrigens 502 sqmm groß.

Nö. Den größten Anteil an Fläche nehmen die Speicherkontroller und der L2 Cache ein. GP104 ist 57,5% größer als GP106, hat aber 100% mehr Ausführungseinheiten.

[robbitop]

Man darf die Ergebnisse in Doom nicht überinterpretieren. Man kennt vermutlich die Settings nicht und da es eine neue mArch ist, muss auch Treiber samt Shadercompiler neu geschrieben werden.
Kein Mensch kennt die Taktfrequenz - das sind die ersten lauffähigen Chips. Ggf. erreichen die noch gar nicht ihren Zieltakt.

Wenn es finale Chips wären, bräuchte man nicht erst in 5 Monaten (stimmt das?) launchen. Dann könnte man wohl eher Ende Februar launchen.

AMD wird sicher nicht aus Spaß 520 sqmm investieren, wenn nur die doppelte Leistung von P10 herauskommt. Dann wäre es billiger und einfacher gewesen, P10 zu verdoppeln. Das wären dann maximal 460 sqmm. Das Ergebnis muss im Endeffekt schon besser sein - sonst wäre das idiotisch.

Die neuen CUs, der höhere Takt und der neue Rasterizer sollten schon im Endeffekt deutliche Konsequenzen haben.

[Digidi]

Ob die Theorie so stimmt, das beide Hersteller aufeinander warten? Wohl nicht ganz...Nvidia wartet auf AMD! Bis dahin wird der Pascal Refresh vorbereitet und beim VEGA Release losgelassen...vielleicht!
Ich hoffe VEGA's Releasetreiber, bringen die Leistung auf die Straße.

Der Refresh von Pascal wird nicht vor 2018 fertig sein. Da wird dann wohl auch eine komplett neue Architektur kommen. Sowas dauert.

Nvidia und AMD haben zurzeit keinen Druck. Die gesamte Menge wartet auf die Performance Karten von AMD und Nvidia. Wer hier zuerst nachgebt verliert. Weil der jeweils andere dann mit höherem Takt und Bios Anpassungen davon zieht.

Das wird ein Spannendes Rennen.

[Nakai]

Man darf die Ergebnisse in Doom nicht überinterpretieren. Man kennt vermutlich die Settings nicht und da es eine neue mArch ist, muss auch Treiber samt Shadercompiler neu geschrieben werden.
Kein Mensch kennt die Taktfrequenz - das sind die ersten lauffähigen Chips. Ggf. erreichen die noch gar nicht ihren Zieltakt.

Wenn es finale Chips wären, bräuchte man nicht erst in 5 Monaten (stimmt das?) launchen. Dann könnte man wohl eher Ende Februar launchen.

AMD wird sicher nicht aus Spaß 520 sqmm investieren, wenn nur die doppelte Leistung von P10 herauskommt. Dann wäre es billiger und einfacher gewesen, P10 zu verdoppeln. Das wären dann maximal 460 sqmm. Das Ergebnis muss im Endeffekt schon besser sein - sonst wäre das idiotisch.

Die neuen CUs, der höhere Takt und der neue Rasterizer sollten schon im Endeffekt deutliche Konsequenzen haben.

Reinher vom Doom-Ergebnis sieht es eher danach aus, dass es in erster Linie mit dem Takt hochskaliert ist. Wie du gesagt hast, da muss mehr bei rumkommen.

€: V10 ist etwa oder ein bisschen größer als ein GP102.

[Schaffe89]

Ich glaube nachdem Nvidia nicht die 1080ti präsentiert hat hält sich AmD zurück um nicht zu viel zu verraten!

Was sollen sie auch präsentieren? Die verkaufen die Titan X für n Haufen Kohle und lachen sich über Amd´s elende Verzögerungen ins Fäustchen, so langsam nervt mich der Verein. Die "Preview" war noch lahmer als das was Jensen gebracht hat.

Das Marketing unterirdisch. Trommelvideo für die Fans, Countdown und dann nix konkretes.

Wenn das Ding über 500mm² hat und dann gegen eine GTX 1080/GTX 1070 antreten muss, na dann gute Nacht.:freak:
Nächster Fail incoming.

[Digidi]

Wenn du die Die Fläche + Architekturdetails nichts konkretes nennst ....

Das Teil wird zwischen einer GTX 1080 und einer GTX 1080ti / Titan XP liegen. AMD hat zudem keinen reinen GamingChip im Programm. Vega ähnelt eher GP100 als GP102

[Mancko]

Nvidia und AMD haben zurzeit keinen Druck. Die gesamte Menge wartet auf die Performance Karten von AMD und Nvidia. Wer hier zuerst nachgebt verliert. Weil der jeweils andere dann mit höherem Takt und Bios Anpassungen davon zieht.
Das wird ein Spannendes Rennen.

AMD hat derzeit sehr wohl Druck. Die GPU Abteilung wird von Nvidia derzeit ordentlich in die Mangel genommen. Man könnte es auch anders formulieren. Das was an Geld verdient werden kann unterm Strich landet zu 99% derzeit bei Nvidia. Wenn das kein Druck ist dann weiß ich auch nicht. In einer Industrie wo immer mehr R&D Gelder notwendig werden ist es elementar ordentlich Geld mit den Produkten zu verdienen. Insofern kann Nvidia tatsächlich derzeit sich das Ganze in Ruhe ansehen und abwarten. Sie haben mit 1070, 1080 und TitanX(P) die gesamte Palette oben für sich gepachtet und das schon im GPU Business in einer umgerechneten Ewigkeit.


Wenn das Ding über 500mm² hat und dann gegen eine GTX 1080/GTX 1070 antreten muss, na dann gute Nacht.
Nächster Fail incoming.


Also das wird glaube ich eher nicht passieren. Das wäre in der Tat unterirdisch und auch der Sargnagel auf die GPU Abteilung. Ich würde in diese komische Doom Messung nicht zu viel reininterpretieren. Das Teil lief niemals mit dem angepeilten Takt und Treiber sind auch noch so eine Sache. Es ist viel zu früh um da genaue Leistungsdaten abzuschätzen. Ich denke zwischen 1080 und TitanX(P) ist da alles drinn. Vielleicht auch mehr als TitanX(P). Ich würde mich da aktuell nicht aus dem Fenster lehnen. Was aber sehr schmerzhaft ist, bleibt die zeitliche Distanz bis dahin. Defakto hat man dann 12 Monate einen ganz wichtigen Teil des Marktes komplett der Konkurrenz überlassen. Das macht die Ausgangslage nicht besser. Da ist von Preisjustierung bis zu Lieferung anderer (neuer) Produkte auch alles drin und interessant wird auch wieder das Kosten / Verkaufspreisverhältnis. Da sieht AMD aktuell in Summe sehr schlecht aus. Da bin ich gespannt ob sich das mit Vega ändert, dann das ist betriebswirtschaftlich gesehen für die Firma einfach ein riesen Problem.

[Gouvernator]

Wenn du die Die Fläche + Architekturdetails nichts konkretes nennst ....

Das Teil wird zwischen einer GTX 1080 und einer GTX 1080ti / Titan XP liegen. AMD hat zudem keinen reinen GamingChip im Programm. Vega ähnelt eher GP100 als GP102
Es gibt noch die Frage zu welchen Stromkosten... diese Leistung erbracht wird.
Ich habe echt keine Lust mehr auf eine neue Inkarnation der GTX480... Gesamtverbrauch 400W+: für 20FPS mehr als mit GTX1080? Nein danke.
So ein Stromschlucker muss die GTX1080 um 60-70% schlagen können um der Anschaffung wert zu sein.

[Achim_Anders]

Ich habe gerade mal geschaut wie die Informationspolitik zu Polaris war. Die Architektur wurde vor genau 366 Tagen vorgestellt (4.1.2016). Auch mit ähnlichen Fakten zum Chip selbst. Falls sie einer ähnlichen Releasestruktur folgen sehen wir Vega gerade so in H1 2017. Auch wenn das vielleicht von langer Hand so geplant war, es wäre (für mich) etwas enttäuschend keine Karten in Q1 bei den Händlern zu sehen. Ich befürchte mittlerweile allerdings, dass es darauf hinaus läuft.
Auf der anderen Seite hoffe ich auch, dass der Launch besser wird als zu RX480 Zeiten. Einerseits war der Performancesprung im Gegensatz zur 1060 höher, es lag also mehr Leistung brach zu Release, andererseits hat AMD augenscheinlich wirklich eine komplette High-End Serie ausgelassen (bzw. Nvidia hat eine mehr aufgelegt.)
Ich bin gespannt ob AMD mit dieser Art und Weise das Ruder herumreißen können wird.


Vielleicht hat von euch ja einer gute Gründe zu glauben, warum wir Vega noch im März kaufen können werden?

[Digidi]

Es gibt noch die Frage zu welchen Stromkosten... diese Leistung erbracht wird.
Ich habe echt keine Lust mehr auf eine neue Inkarnation der GTX480... Gesamtverbrauch 400W+: für 20FPS mehr als mit GTX1080? Nein danke.

Geht's noch? Das ist doch mal wieder total übertriebener Troll versuch der Hier abläuft. Du weist noch nichts über Vega glaubst aber schon das die Stromkosten durch die Decke gehen?

[Gouvernator]

Geht's noch? Das ist doch mal wieder total übertriebener Troll versuch der Hier abläuft. Du weist noch nichts über Vega glaubst aber schon das die Stromkosten durch die Decke gehen?
Naja es gab doch schon den dubiösen Versuch von AMD, Berichte über laute Grafikkarte zu sperren... die PCGH über ihren Vega Event gemacht hat. Schwer zu kühlen = hohe Stromkosten.

[Digidi]

Ach ja dann zeig doch mal her den Bericht!

[Gouvernator]

Zweitens sollte jegliche Sicht auf die Grafikkarte verwehrt bleiben, sodass vorne, hinten, seitlich und oben alle Lüfterplätze abgeklebt wurden. Etwa Frischluft kann, wenn überhaupt, nur über die Unterseite ins Gehäuse gelangt sein. Die Grafikkarte war dadurch merklich laut und schaufelte ordentlich heiße Abluft nach hinten heraus.
http://www.pcgameshardware.de/AMD-Radeon-Grafikkarte-255597/Specials/Vega-10-HBM2-GTX-1080-1215734/

[Linmoum]

Naja es gab doch schon den dubiösen Versuch von AMD, Berichte über laute Grafikkarte zu sperren... die PCGH über ihren Vega Event gemacht hat. Schwer zu kühlen = hohe Stromkosten.
Nope, den gab es nicht. Da ging es konkret um die Erfahrungen zu der entsprechenden Doom-Demo, die auch erst heute mitveröffentlicht werden sollten/durften.

[Dino-Fossil]

Ich habe gerade mal geschaut wie die Informationspolitik zu Polaris war. Die Architektur wurde vor genau 366 Tagen vorgestellt (4.1.2016). Auch mit ähnlichen Fakten zum Chip selbst. Falls sie einer ähnlichen Releasestruktur folgen sehen wir Vega gerade so in H1 2017. Auch wenn das vielleicht von langer Hand so geplant war, es wäre (für mich) etwas enttäuschend keine Karten in Q1 bei den Händlern zu sehen. Ich befürchte mittlerweile allerdings, dass es darauf hinaus läuft.

Betrachtet man frühere Ankündigungen und die Resultierenden Launches ist in der Tat nicht mit einer Veröffentlichung vor Ende Q2 zu rechnen.

Sicherlich eher suboptimal für die Marktposition, wenn man der Konkurrenz in diesem Segment ein Jahr kaum etwas entgegen setzen kann (wenigstens haben sie mit Polaris ganz gute Karten im Mittelfeld, was absatztechnisch deutlich größer sein dürfte).
Ich kann mir aber eigentlich kaum vorstellen, dass das ursprünglich so geplant war. Ich vermute, dass da mindestens die schlechte Verfügbarkeit von HBM2 mit beigetragen hat.

Natürlich hatte nVidia auch die bessere Startposition. Dank Maxwell konnten sie es sich leisten, sich mit Pascal im wesentlichen auf einen Shrink und Detailverbesserungen zu konzentrieren und auf der Basis eine komplette Serie relativ einfach raushauen.

[Digidi]

Zweitens sollte jegliche Sicht auf die Grafikkarte verwehrt bleiben, sodass vorne, hinten, seitlich und oben alle Lüfterplätze abgeklebt wurden. Etwa Frischluft kann, wenn überhaupt, nur über die Unterseite ins Gehäuse gelangt sein. Die Grafikkarte war dadurch merklich laut und schaufelte ordentlich heiße Abluft nach hinten heraus.
http://www.pcgameshardware.de/AMD-Radeon-Grafikkarte-255597/Specials/Vega-10-HBM2-GTX-1080-1215734/
DU Troll Kontext beachten

So ein Manipulator. Endlich hab ich dich getriggert:mad:

Und wo steht das in deinem Artikel
Naja es gab doch schon den dubiösen Versuch von AMD, Berichte über laute Grafikkarte zu sperren...

[Unicous]

http://www.pcgameshardware.de/AMD-Radeon-Grafikkarte-255597/Specials/Vega-10-HBM2-GTX-1080-1215734/

Wow, du bist ja offensichtlich ein Meister im bewussten Missinterpretieren der Sachlage.:eek:

Die Schlitze wurden verklebt um eine Sicht auf die Karte zu verwehren und dadurch entstand ein Wärmestau weil keine ordentliche Luftzufuhr zustande kam, dadurch muss der Lüfter mehr arbeiten.

Aber natürlich macht das was du sagst viel mehr Sinn.:freak::freak::freak:

[Ätznatron]

Und er verfälscht auch noch das von ihm in #1350 gebrachte Zitat.

[Gouvernator]

DU Troll Kontext beachten


So ein Manipulator. Endlich hab ich dich getriggert:mad:
Hä, mich getriggert?
Wenn du als Consument einen hohen Betrag für eine neue Grafikkarte leisten musst, dann machst du dir schon im Vorfeld Gedanken, welche Eigenschaften das Produkt mitbringt.
Alles was wir jetzt wissen ist nicht "kühl und leise" sondern genau umgekehrt.

Soll ich jetzt brav etwa offizielle PR abwarten mit der Begründung warum das Produkt dennoch toll ist? Und bis dahin sich gehirntot stellen?

[Digidi]

Red dich nur raus Gouvernator. Im Endeffekt tust du mir leid das du dich so manipulieren lässt.

[Ätznatron]

Alles was wir jetzt wissen ist es nicht "kühl und leise" sondern genau umgekehrt.


Nö, das wissen wir nicht.

Was wir allerdings wissen ist, was von deinen Beiträgen dazu zu halten ist.

[Gouvernator]

Wow, du bist ja offensichtlich ein Meister im bewussten Missinterpretieren der Sachlage.:eek:

Die Schlitze wurden verklebt um eine Sicht auf die Karte zu verwehren und dadurch entstand ein Wärmestau weil keine ordentliche Luftzufuhr zustande kam, dadurch muss der Lüfter mehr arbeiten.


Ordentliche Luftzufuhr ist ungleich keine Luftzufuhr wie bei hermetischen PS4 Plastikkästen bei solchen Presentationen. Man weiß schon ganz gut Bescheid wie eine sparsame Grafikkarte Luft zu blasen hat.

[Linmoum]

Kannst bei dir zuhause ja mal das Expirement machen.
Lüfterplätze abkleben, Doom starten, der GPU ordentlich einheizen und dann schauen. Würde mich wundern, wenn die dann leise und kühl bleibt.

[BlacKi]

Kannst bei dir zuhause ja mal das Expirement machen.
Lüfterplätze abkleben, Doom starten, der GPU ordentlich einheizen und dann schauen. Würde mich wundern, wenn die dann leise und kühl bleibt.
die luft im inneren wird nicht so warm wie manche denken, wenn die grafikkarte die luft nach draussen schaufelt. das der lüfter dabei laut wird ist dabei wohl klar, heißt aber nicht das er besonders runterdrosseln muss.

[Schnoesel]

die luft im inneren wird nicht so warm wie manche denken, wenn die grafikkarte die luft nach draussen schaufelt.

Ich glaube eher du hast keine Ahnung wie warm das werden kann, wenn nur noch der Radiallüfter die Abwärme abtransportiert.

Ein guter Anhaltspunkt ist das hier:

https://www.computerbase.de/2016-12/xfx-radeon-rx-460-passiv-test/3/

Und wir reden dann von einer RX460 mit ein paar Watt. Eine "250" Watt GPU ohne Luftzufuhr und nur der Radiallüfter bläst raus...

@ Vega

Insgesamt entäuschend aber war eigentlich vorher klar. Ließt sich ja alles schön und gut aber AMD muss das mal auf die Straße bringen. Ich will Leistung dann gebe ich auch Geld aus. Keine Leistung kein Geld. Und man darf auch etwas konkreter werden imo. Also lasst euch mal nicht zu viel Zeit.
16GB wäre mir dann auch lieber als 8GB. Den "Fehler" Von Fiji mach ich nicht nochmal.

[GSXR-1000]

Das hauptproblem derer die sich hier so beschweren, balkendiagramme und benches, ETAs und dergleichen hier als einzig relevante informationen einfordern, ja auf die sie geradezu anspruch haben, ist, das sie nicht begreifen, das sie nicht die adressaten dieses previews sind. Das ist gedacht fuer experts, professionals und...enthusiasts.
Leider glauben diese genannten zu unrecht, das sie der prototyp der enthusiasten seien, da sie benchmarkexperten, waküpros und stickstoffbastler sind. Und nein. Dad zeichnet eben enthusiasten nicht aus. Auch die zugehoerigkeit zu einer potentiellen high end kaeuferschicht nicht.
Ein enthusiast zeichnet sich vor allem durch echtes interesse an der materie, inklusive eines grundsaetzlichem sachverstandes aus. Durch interesse an technischen umsetzungen und moeglichkeiten. An theoretischen sowie praktischen moeglichkeiten und grenzen. Sprich an genau dem was heute geliefert wurde: an einem technischen architektur preview.
Auch wenn jetzt viele getroffene hunde bellen werden: die die hier nöhlen sind eben exakt die, die nicht wirklich enthusiasten sind. Und sich auch nicht als solche bezeichnen sollten. Den fuer enthusiasten sind dinge wie benchmarklaengenvergleiche eher zum gaehnen denn interessant.
Ich fand die vorstellung super interessant. Obwohl ich kein enthusiast bin weil ich mich mit der materie zu wenig beschaeftige. Es wurde aber genau das geliefert was erwartet werden konnte.

[Botcruscher]

Was darf ich mir eigentlich unter Folie 36 vorstellen? NV-RAM, Network storage und System DRAM sind doch nicht ohne Grund stilistisch wie die GPU und getrennt von den anderen Einheiten dargestellt. Da wird wohl gleich der SSD noch einiges Zeug auf die Platine wandern.

[DrFreaK666]

Hä, mich getriggert?
Wenn du als Consument einen hohen Betrag für eine neue Grafikkarte leisten musst, dann machst du dir schon im Vorfeld Gedanken, welche Eigenschaften das Produkt mitbringt.
Alles was wir jetzt wissen ist nicht "kühl und leise" sondern genau umgekehrt.

Soll ich jetzt brav etwa offizielle PR abwarten mit der Begründung warum das Produkt dennoch toll ist? Und bis dahin sich gehirntot stellen?

Was wir eher wissen ist, dass du wohl lesen aber nicht verstehen kannst

[Ätznatron]

Etwa Frischluft kann, wenn überhaupt, nur über die Unterseite ins Gehäuse gelangt sein.

Das sagt doch schon alles. Die Karte steckte sozusagen in einem Konsolengehäuse, ohne große Möglichkeit, die Abwärme nach draußen zu befördern.

[ecodriver]

Oh doch, die Grakas werden laut, einfach mal selbst ausprobieren.
Bererits das runterschalten meiner Lüftersteuerung (für die Gehäuselüfter) bringt einen merklichen Lärmsteigerung mit sich.
Kannst dir auch mal die Diagramme der Lüfter mit Drehzahl/dB anschauen.

[Gouvernator]

Kannst bei dir zuhause ja mal das Expirement machen.
Lüfterplätze abkleben, Doom starten, der GPU ordentlich einheizen und dann schauen. Würde mich wundern, wenn die dann leise und kühl bleibt.
Ich sehe nicht ein warum man überhaupt für so ein Event was abkleben muss. Das Klebeband könnte einfach nur eine Attrappe sein. Um zu verschleiern das es die Grafikkarte ist die heizt. Mit oder ohne Klebeband. ;D

[BlacKi]

Ich glaube eher du hast keine Ahnung wie warm das werden kann, wenn nur noch der Radiallüfter die Abwärme abtransportiert.
die größte hitzequelle ist doch die grafikkarte...

an die skeptiker https://youtu.be/YDCMMf-_ASE?t=509

[Digidi]

Ich sehe nicht ein warum man überhaupt für so ein Event was abkleben muss. Das Klebeband könnte einfach nur eine Attrappe sein. Um zu verschleiern das es die Grafikkarte ist die heizt, und nicht das Klebeband. ;D
Also damit bist wirklich der Toll König hier.

@BlacKi

natürlich ist die Grafikkarte die größte Hitzequelle. Nur ist es im Gehäuse durch CPU nun mal keine 20 Grad sondern 30°C warm und damit nimmt die Luft weniger Wärme auf. Was auch hinzu kommt das durch das Abkleben nicht genug Frischluft nachströmt und somit der GPU Lüfter einen abstrampelt aber kaum Luft umsetzt.

[Gouvernator]

Also damit bist wirklich der Toll König hier.
Lifehack um eine wirklich laute/heiße Grafikkarte der gierigen Presse zu presentieren um hinterher PR-mäßig nicht zerfleisht zu werden?
Dafür muss man ja auch zum PR-Mann im Unternehmen ein Studierter sein.:biggrin:

[Digidi]

die größte hitzequelle ist doch die grafikkarte...

an die skeptiker https://youtu.be/YDCMMf-_ASE?t=509
Bei deinem Video hätten mich die Taktraten interessiert. Wenn meine 290x runtertaktet wird die auf einmal auch nur noch 60° warm. Man kann es im Video nur erahnen, aber furmark ruckelt da ganz schön. Der Typ hat einfahc keine Ahnung was der da tut.

Als ich damals vom Silent Base auf mein Corsair Gehäuse gewechselt bin, hatte meine 290x keine Probleme den Takt zu halten.

[DrFreaK666]

Lifehack um eine wirklich laute/heiße Grafikkarte der gierigen Presse zu presentieren um hinterher PR-mäßig nicht zerfleisht zu werden?
Dafür muss man ja auch zum PR-Mann im Unternehmen ein Studierter sein.:biggrin:

Dann wäre es schlauer einen PC im Hintergrund die Sache rendern zu lassen.
Bei dem Vorführ-PC könnte man dann eine Karte ohne jeglichen Inhalt einbauen... *hust*

[Gipsel]

Zurück zum Thema!

[Digidi]

@Gipsel
Total vergessen. Danke noch mal deine Ausführungen zum Rasterizer. Ich kann mir jetzt wage vorstellen was du damit meinst :D würde mich freuen wenn du das dass nächste mal nochmals für noobs wie mich vereinfachen könntest.

Was ich aber nicht verstehe ist die bekommen 11 Polygonen pro Takt raus. Selbst wenn sie Culling bzw Binding verwenden kommen am Ende 11 Polygonen pro Takt raus mit nur 4 Engines. Wie geht das?

Und noch eine Frage. Wie viele Polygonen packt denn eigentlich GP102 von Nvidia und GP100 um das mal einschätzen zu können.

[Gipsel]

Was ich aber nicht verstehe ist die bekommen 11 Polygonen pro Takt raus. Selbst wenn sie Culling bzw Binding verwenden kommen am Ende 11 Polygonen pro Takt raus mit nur 4 Engines. Wie geht das?Wie schafft es nV?
http://www.hardware.fr/getgraphimg.php?id=333&n=1
GP102: 6 Rasterengines, GP104: 4 RasterEngines, GP106: 2 Rasterengines.
Die wirklichen gezeichneten Dreiecke skalieren mit der Anzahl der Rasterengines (und Takt). Man kann aber mehr verwerfen, wenn man sich clever anstellt (nV macht das mehr oder weniger mit Hilfe der "Polymorph Engines", die in der Summe einen höheren Durchsatz haben).

[basix]

So ich habe mal auf ve.ga beim Wettbewerb mitgemacht. Vielleicht gewinne ich ja eine Vega Karte :)

[Digidi]

Intersant. Laut dem Diagramm von Gispel hat Nvidia bei GP102 nur einen Durchsatz von 8-9 Polygonen pro Takt.

[Gipsel]

Intersant. Lut dem Diagramm von Gispel hat Nvidia bei GP102 nur einen Durchsatz von 8-9 Pixel pro Takt.Das sind Dreiecke.

[Digidi]

Danke für das Verbessern. Das ist der Hustensaft :D, ich hab es oben ja schon verbessert.

Was mich wundert ist das GP102 nicht mehr durchsetzen kann als GP104 an Polygonen. Hat Nvidia hier eine Limitierung?

[Nakai]

Was darf ich mir eigentlich unter Folie 36 vorstellen? NV-RAM, Network storage und System DRAM sind doch nicht ohne Grund stilistisch wie die GPU und getrennt von den anderen Einheiten dargestellt. Da wird wohl gleich der SSD noch einiges Zeug auf die Platine wandern.

Ja, das ist auch die generelle Idee. Das lustige an der Folie ist aber, dass NVRAM, Network Storage und System-DRAM dunkel eingezeichnet ist und womöglich tatsächlich irgendwann in die GPU wandern kann. Das wird aber, denke ich, erstmal nicht passieren.

Nichtsdestotrotz könnten Vega10-Profikarten mit integriertem NAND-Flash daherkommen. Es gibt ja auch bereits DDR4-NVDIMMs mit DDR4 und NAND-Flash.
Außerdem ist es ebenfalls der erste Schritt den HBM als Cache zu nutzen, um eben auch eine weitere Stufe der Speicherhierarchie zu unterstützen.

Ein hypothetischer Vega11 mit nur einem Stack und eventuell etwas DDR4-Speicher wäre doch interessant? ;)

[Hübie]

Wenn du die Die Fläche + Architekturdetails nichts konkretes nennst ....

Welche Architekturdetails meinst du? Für mich steht da 'Blah'. Da sind nun mehr Fragen offen, als beantwortet. Hat AMD den NVIDIA-Fachmann für PowerPoint-Folien abgeworben? :confused: So ein Quark. Klingt alles toll, aber wenig hard facts und viel Interpretationsspielraum. Da hätten die auch einfach mal nix sagen brauchen.
Also weiter bangen und hoffen, dass man künftig nicht wieder alles Jensen in den Rachen werfen 'muss'.

[Digidi]

@Hübie
Man kann erkennen das AMD die schwachstellen beseitigt hat. Das Thema Frontend sind sie ja angegangen.

[GSXR-1000]

Also weiter bangen und hoffen, dass man künftig nicht wieder alles Jensen in den Rachen werfen 'muss'.
Das ist genau dein Problem. Dich interessieren die hard facts, also die technischen aspekte der architektur garnicht. dich interessieren keine technischen Feinheite, optionen, möglichkeiten, entwicklungen, technische strategiemoeglichkeiten, die technische basis.
Dich interessiert nur eins: die benchmarklänge der letztlich kaufbaren lösung. Und das ist wirklich der langweiligste aspekt für diejenigen an die diese Präsentation gerichtet war, nämlich die technisch an dieser materie interessierten. Für mich war das grundgerüst interessant auf das man nun für einige jahre verschiedene Lösungen aufbauen wird... mit unterschiedlichsten benchmarklängen im ergebnis.
Hard facts sind eher die technischen grundlagen. Und genau die wurden geliefert.
Was am ende an benchmarklängen herauskommt hängt an vielen faktoren die für mich momentan eher belanglos sind. das liegt einmal an der ausbeute des produktionsprozesses, der strategischen ausrichtung der produktplanung, marktumfeld etc etc etc.
Es ist in etwa so, als würden auf einer automesse neueste technologien die grundlage für generationen neuer Modelle sind präsentiert und du nölst rum, weil dich ausschliesslich PS und Spitzengeschwindigkeit interessiert. Was aber in diesem zusammenhang garkeine rolle spielt. Weil diese technolgien die Basis bilden fuer die modelle die darauf aufbauen. Und diese nach verschiedensten aspekten die PS eines käfers oder die eines Mclaren F1 haben koennen, je nachdem WAS man baut und wofür man es baut.
Ich weiss nicht warum das so schwer für einige zu verstehen ist?

[Digidi]

Ich finde das Technische auch interessant. Zudem zeigt es sehr gut Schwachstellen auf. Wie gesagt wenn man sich von Gipsel das Diagramm mit den Dreiecken anschaut, stellt man fest das GP102 trotz 2 Rasterengines mehr bei in etwa der gleichen Dreiecksrate festängt wie der GP104, was bei etwa 8-9 Polygonen pro Takt liegt. AMD schaft hier 11 Polygonen pro Takt und damit satte 20% mehr als Pascal. Das ist eine menge

[Gipsel]

was bei etwa 8-9 Polygonen pro Takt liegt. AMD schaft hier 11 Polygonen pro Takt und damit satte 20% mehr als Pascal. Das ist eine mengeDas bei Pascal waren Messungen, von AMD haben wir einen mehr oder weniger theoretischen Peakwert. Bevor ich die Güte der Implementation einschätze, würde ich auf entsprechende Messungen warten.

[Ravenhearth]

Eine NCU kann 512 mögliche 8-, 256 16- und 128 32-Bit-Operationen in einem 4:2:1-Verhältnis berechnen. Möglich wäre das quasi nur, wenn AMD von 64 Shader in einer CU auf 128 in einer NCU aufstockt - fast schon ironisch: AMD geht genau den anderen Weg als Nvidia, der mit GP100 erst auf 64 Shader/SM für HPC-Anwendungen heruntergegangen ist.
http://www.pcgameshardware.de/Vega-Codename-265481/Specials/Architektur-NCU-HBCC-Vorstellung-1217460/

Moving on, the second thing we can infer from AMD’s slide is that a CU on Vega is still composed of 64 ALUs, as 128 FP32 ops/clock is the same rate as a classic GCN CU. Nothing here is said about how the Vega NCU is organized – if it’s still four 16-wide vector SIMDs – but we can at least reason out that the total size hasn’t changed.
http://www.anandtech.com/show/11002/the-amd-vega-gpu-architecture-teaser/2

Wer liegt nun richtig? :confused:

So wie ich das sehe, sind die "128 32-bit ops per clock" pro NCU doch nicht neu. Fiji hat ja auch 128 pro CU x 64 CUs = 8192 per clock (also 8192 GLFOPs bei 1 GHz). Oder nicht?

[Digidi]

Das bei Pascal waren Messungen, von AMD haben wir einen mehr oder weniger theoretischen Peakwert. Bevor ich die Güte der Implementation einschätze, würde ich auf entsprechende Messungen warten.

Natürlich hast du Recht gipsel.aber die theoretischen Werte bei theoretischen Tests haben ja auch immer relative gut gepasst. Das stimmt mich optimistisch aber natürlich hast du Recht das man es mit einer gewissen Skepsis betrachten muss.

[deekey777]

http://www.pcgameshardware.de/Vega-Codename-265481/Specials/Architektur-NCU-HBCC-Vorstellung-1217460/


http://www.anandtech.com/show/11002/the-amd-vega-gpu-architecture-teaser/2

Wer liegt nun richtig? :confused:

So wie ich das sehe, sind die "128 32-bit ops per clock" pro NCU doch nicht neu. Fiji hat ja auch 128 pro CU x 64 CUs = 8192 per clock (also 8192 GLFOPs bei 1 GHz). Oder nicht?

Jetzt renne ich durch die Wand:

Eine CU kann 64 FP32-MADDs ausführen, was 128 OPs sind.

Achso, das passt nicht zur Folie.

[Rabiata]

Ein hypothetischer Vega11 mit nur einem Stack und eventuell etwas DDR4-Speicher wäre doch interessant? ;)
Oder eine Geldsparvariante mit weiterhin zwei Stacks, aber nur 4Hi => 8GB und niedrigere Taktung.
Es geisterten schon mal 700 MHz durch die Speku-Foren, das wäre immer noch gut für 350 GB/s. Würde vermutlich ganz gut passen.

[Thunder99]

Das wird ne Bombe denke ich :eek: Wie damals Hawaii :naughty:

Oder unterm Strich vermute ich sehr gute Gaming Performance, endlich ohne die GCN Schwächen, bei höherem Verbrauch als die Konkurrenz. Dafür Top Profi Chip der mit weniger Fläche den TopDog von der Konkurrenz schlagen kann. Alles bei einem Chip und damit weniger Kosten!

Vega wird wohl was richtig feines von AMD :up:

[Agent117]

http://www.pcgameshardware.de/Vega-Codename-265481/Specials/Architektur-NCU-HBCC-Vorstellung-1217460/


http://www.anandtech.com/show/11002/the-amd-vega-gpu-architecture-teaser/2

Wer liegt nun richtig? :confused:

So wie ich das sehe, sind die "128 32-bit ops per clock" pro NCU doch nicht neu. Fiji hat ja auch 128 pro CU x 64 CUs = 8192 per clock (also 8192 GLFOPs bei 1 GHz). Oder nicht?

PCGH sollte da Recht haben. Das folgende Bild aus der Präsentation sagt meiner Meinung nach eindeutig dass es doppelt so viele Ops sind, 128 Ops = 64 MADDs. Im Bild wird auf der einen Seite die höhere Frequenz angedeutet (was dann V10 mit 4096SP@~1,5 Ghz sehr wahrscheinlich macht) und es werden pro Takt doppelt soviele Ops dargestellt.

http://images.anandtech.com/doci/11002/Vega%20Final%20Presentation-29.png?_ga=1.45151651.68909847.1472047867

[basix]

Ich denke die Ops / Takt Grafik ist sinnbildlich gemeint. Die Grafik würde ja 2-fache IPC andeuten, was ich beim besten Willen nicht glauben kann. Es wird halt einfach mehr pro Takt geleistet. Aber anstatt "halbe Häuschen" zu zeichnen hat man einfach ein ganzes dazu gemalt.

[Agent117]

Nein, es sind ja dann 128 Shader pro CU statt bisher 64. Daher der doppelte Durchsatz. Der Durchsatz pro CU ist verglichen mit Fiji doppelt so hoch aber man hat nur noch 32 statt 64Cu, somit insgesammt pro Takt die gleiche Rechenleistung.
Es hieß ja auch oft, dass die vielen Register der kleinen 64er CUs mit Schuld an der höheren Leistungsaufnahme von GCN verglichen mit Maxwell mit 128er CUs sind. Vielleicht hat man dies wirklich aus diesem Grund geändert. Sollte Vega 20 ausschließlich für HPC sein, hat dieser wahrscheinlich weiterhin 64er CUs wie ja auch GP100 weil man für HPC wohl oft viele Register braucht.

[Nakai]

Das wird ne Bombe denke ich :eek: Wie damals Hawaii :naughty:


Man hat definitiv einige IPC-steigernde Features eingebaut.
Reinher von den ersten Eindrücken, hat das nichts mehr mit GCN zu tun.
Man geht einen großen Schritt Richtung TBDR und überarbeitet dabei sehr viel.

Bei Polaris und den vorherigen GCN-Iterationen konnte man einigermaßen neue Produkte abschätzen. Bei Vega ist das in der Tat sehr schwierig. Die ganzen Verbesserungen sprechen jedenfalls stark für einen IPC- und Effizienz-Anstieg.
Das Einzige was ich hoffe ist dass der Stromverbrauch sich in Grenzen hält.

Meine Prognose bleibt dementsprechend zwischen GP104 und GP102.

[bbott]

Meine Prognose bleibt dementsprechend zwischen GP104 und GP102.

Da käme man doch mit einem 2x Polaris 10 auch hin.

[Ravenhearth]

Nein, es sind ja dann 128 Shader pro CU statt bisher 64. Daher der doppelte Durchsatz. Der Durchsatz pro CU ist verglichen mit Fiji doppelt so hoch aber man hat nur noch 32 statt 64Cu, somit insgesammt pro Takt die gleiche Rechenleistung.
Es hieß ja auch oft, dass die vielen Register der kleinen 64er CUs mit Schuld an der höheren Leistungsaufnahme von GCN verglichen mit Maxwell mit 128er CUs sind. Vielleicht hat man dies wirklich aus diesem Grund geändert. Sollte Vega 20 ausschließlich für HPC sein, hat dieser wahrscheinlich weiterhin 64er CUs wie ja auch GP100 weil man für HPC wohl oft viele Register braucht.

Ja, das ist was PCGH sagt. Aber der Durchsatz pro NCU ist doch gar nicht doppelt so hoch wie vorher, sondern genauso hoch, wenn ich mich nicht versehe (siehe meine Beispielrechnung).

[y33H@]

Raja Koduris sagte grade, es sind unter 500 mm² Die-Size.

[mczak]

Was mich wundert ist das GP102 nicht mehr durchsetzen kann als GP104 an Polygonen. Hat Nvidia hier eine Limitierung?
So auf den ersten Blick ist es schwierig zu sagen woran das liegen könnte. Eigentlich müssten die verworfenen Dreiecke perfekt skalieren (es braucht ja im Gegensatz zu den nicht-verworfenen die da ziemlich gut skalieren auch keinerlei Synchronisation oder ähnliches, geschieht alles lokal in den SMM). Entweder gibt's hier irgend ein anderes Limit (irgendwo im Frontend?) oder der Test selbst skaliert nicht gut genug aus irgendwelchen Gründen.

[Agent117]

Ja, das ist was PCGH sagt. Aber der Durchsatz pro NCU ist doch gar nicht doppelt so hoch wie vorher, sondern genauso hoch, wenn ich mich nicht versehe (siehe meine Beispielrechnung).

Hmh also so eindeutig ist es wohl doch nicht, da hast du Recht.
AMD schreibt was von 128 FP32 Bit Ops per clock. Sie schreiben aber nicht ob sie Multiplikation und Addiation meinen (dann wären es weiterhin 64er Cus) oder nur eins von beiden. Das Bild was ich weiter oben verlinkt habe impliziert in meinen Augen schon, dass sich der Durchsatz pro CU verdoppelt hat. Eine andere Möglichkeit wäre dass man sich auf den Bild auf FP 16 Ops bezieht, aber dann hätte man auch gleich FP 8 Ops nehmen und als 4-fachen Durchsatz bewerben können. Also es bleibt alles fraglich. Die gesamte Präsentation enthielt ja leider auch nichts zu den NCUs leider.

[aufkrawall]

Da käme man doch mit einem 2x Polaris 10 auch hin.
Bei 300W.

[[MK2]Mythos]

Na wollen wir mal hoffen dass der Verbrauch trotz des riesigen DIE's nicht in diese Region kommt.

[Screemer]

Bei 300W.
hat vega doch auch. das haben wir doch vor ein paar seiten erfahren.

[Schaffe89]

Das hauptproblem derer die sich hier so beschweren, balkendiagramme und benches, ETAs und dergleichen hier als einzig relevante informationen einfordern, ja auf die sie geradezu anspruch haben, ist, das sie nicht begreifen, das sie nicht die adressaten dieses previews sind.


Wer waren dann die Adressaten von dem VEGA GPU TRommel Video und dem angesetzten Hype? Ingenieure?:tongue:

[aufkrawall]

hat vega doch auch. das haben wir doch vor ein paar seiten erfahren.
Woot? Das ist in dem Chaos hier an mir vorbei gegangen.

[[MK2]Mythos]

Woot? Das ist in dem Chaos hier an mir vorbei gegangen.
Das ist Troyans Prognose. Bevor das noch für voll genommen wird...

[Linmoum]

Prognose würde ich das nicht mal nennen, da er das ja sogar ernst meint und wirklich daran glaubt.
Wenn die MI25 bei <300W liegt, muss es ja auf alles andere ebenfalls zutreffen. ;)

[Setsul]

Raja Koduris sagte grade, es sind unter 500 mm² Die-Size.
Wann/wo/Link bitte?

[Screemer]

Woot? Das ist in dem Chaos hier an mir vorbei gegangen.
-> https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11254002#post11254002

[iuno]

FirePro S -> Radeon Instinct
FirePro W -> Radeon Pro
Radeon -> Radeon RX

Hawaii:
S9170: 275 W
290X: 300 W

Ich sehe keinen Grund, beim grossen Modell von deutlich weniger als 300 W auszugehen, wenn die passiv gekuehlte mi25 mit "<300" angegeben wird. Das Ding ist gross und wird hoch takten. Und AMD platziert ja bekanntlich relativ nahe am Limit.

Raja Koduris sagte grade, es sind unter 500 mm² Die-Size.
:ugly:
Und dann haben sie hbm1 drauf gepappt oder was? Das sind doch nie im Leben unter 500, wenn die Angaben von Hynix zur Groesse von HBM2 stimmen. Weiss man, ob Samsung Stacks kleiner sind? Hat die jemand bei P100 mal vermessen?

[y33H@]

Wann/wo/Link bitte?Bei AMD hier auf der CES in Vegas.

[iuno]

Also soweit ich das beurteilen kann stimmt die Groesse der Samsung Stacks bei GP100 mit den Angaben von Hynix ueberein.
imho kann das irgendwie nicht hinkommen. Die 2 HBM Stacks sollten knapp 24 mm haben, + das Stueck dazwischen und noch was am Rand, macht vielleicht 26. Um da noch unter 500 zu bleiben, stimmt das Seitenverhaeltnis nicht.
Aber was weiss ich schon.

Mich wundert uebrigens auch etwas, wie viele Pins das Package noch hat:

https://pics.computerbase.de/7/6/1/7/2/3-1080.1749082644.jpg

Aber zugegebenermassen habe ich mir glaube ich auch ueberhaupt noch nie ein GPU Package von unten angeschaut ;D

Zumindest der Prototyp nutzte 8 GByte Videospeicher, das Endprodukt soll 16 und 32 GByte verwenden.
http://www.golem.de/news/grafikchip-amd-zeigt-vega-10-und-erlaeutert-architektur-1701-125201-2.html

Wurde das wirklich genau so gesagt? Also keine Karte mit 8 GiB, nur 8 Hi Stacks?
btw: hynix kann sich wohl auch nicht entscheiden:

aus dem jeweiligen databook

Q3 2016:
http://i.imgur.com/T34eAaI.png

Q4 2016:
http://i.imgur.com/7mG8tim.png

Q1 2017:
http://i.imgur.com/3e3smbs.png


Gut, bis zum Launch geht es schon noch ein paar Monate, aber wenn 8/16 GiB und 2 Gbps bestaetigt sind, wird das wohl eher nichts mit Hynix.


Hat Raja eigentlich jetzt klipp und klar gesagt, dass er Vega 10 in die Luft haelt und auch explizit die <500 mm² auf V10 bezogen? Mir ist noch nicht ganz klar, ob da nicht gerade einiges durcheinanderkommt.

Im Artikel schreibst du auch, der chip sei in 14LPP gefertigt, anderswo ist man da noch vorsichtiger. Ist die info gesichert?

[Happo]

Ich habe ausgehend von den Angaben bei PCGH (http://www.pcgameshardware.de/Vega-Codename-265481/News/AMD-Vega-10-Chipgroesse-1217461/) das Foto von Golem mal ein wenig bearbeitet. Also so verzerrt (und ein wenig gedreht), so dass die HBM2-Stacks auf dem Bild vom Seitenverhältnis her passend zu den Angaben von PCGH sind (Ein solcher von SK Hynix gefertigter [HBM2-Stack] misst 11,87 x 7,75 mm).
58570
Sofern es sich also um HBM2 von Hynix handelt sollte das Bild zumindest grob passen und Vega 10 müsste auf Basis meiner dilettantischen Bildbearbeitung und nachfolgender Abschätzung (Vergleich des DIE mit den HBM2-Stacks) zwischen 485 mm² und 515 mm² groß sein.

[rentex]

Ach ja, dem Herrn von AMD gehört auf die Finger geklopft...die GPU ohne ESD Handschuhe zu befingern :eek::rolleyes:;D

[Skysnake]

Das ist doch heutzutage kein großes Problem mehr sobald der Wafer fertig ist. Die ESD Struckturen sind ja meines Wissens nach im Allgemeinen heutzutage onChip. Sprich wenn das Ding aufm Package ist, dann ists an sich wurscht. Zumal der Chip eh nie real verwendet wird.

[fondness]

Wenn Konduri sagt unter 500mm², dann wird das auch stimmen. Viel unter 500mm² wird es allerdings nicht sein. Damit wohl ca. GP102-Größe. Leistung zwischen Gp104 und GP102 scheint also realistisch, man darf auch nicht vergessen, dass V10 im Gegensatz zu GP102 2xFP16 und 4x INT8 Leistung bietet.

[Digidi]

Das ist doch heutzutage kein großes Problem mehr sobald der Wafer fertig ist. Die ESD Struckturen sind ja meines Wissens nach im Allgemeinen heutzutage onChip. Sprich wenn das Ding aufm Package ist, dann ists an sich wurscht. Zumal der Chip eh nie real verwendet wird.

So egal ist es nicht. Wenn du einen Kontaktpin erwischt und du dort 10000 Volt induzierst wars das. Aber ich glaube der Herr Koduri hat hier eh nur einen Toten Chip gezeigt, den sie aus der Produktion aussotiert haben :wink:

Ich glaube mich zu erinnern, das Infineon mal Schlüsselhanger an Ihre Vertragspartner verteilt hat, die bestanden aus toten Chips :D

[bbott]

Wenn die Performance "nur" zwischen Gp104 und GP102 liegen würde, dann sollte es eher Richtung 225W gehen, weil sonst wieder der Fortschritt zu zwei Polaris sehr gering wäre. Zumal viele Transistoren durch das Speicher-Interface frei werden.

Die bisherige Performance war aber doch über Titan, oder? Und das mit einem (ersten) Sample?! Ich denke Vega hat nach den aktuellen Infos das Potenzial sich im Idealfall in die Reihe von R300, G80, Tahiti, Maxwell einzureihen. Ein Worstcase einer HD2000 kann eigentlich nicht eintreten, da es keine vollständig neue Architektur ist und (laut AMD) die IPC definitiv gesteigert wurde. Damit bliebe nur nach das man das Takt ziel nicht erreicht, welches aktuell mindestens zum Patt reicht (siehe Videos).

[Skysnake]

Ja, das macht man immer wieder ;)

@ESD: Eben nicht. Wenn die ESD Struckturen onDIE sind, dann ist es praktisch egal. Klar, es kann mal immer noch etwas sein. Eventuell hat man an Power und Ground auch keine ESD-Strukturen sondern nur an den Signalpins. Bin da gerade nicht ganz sicher. Kann sein das man an GRND und VDD gar keine packen kann...

Wie dem auch sei. Selbst wenn keine ESD Struckturen da sind, haste heutzutage in der Regel genug Bulk kontakte, so das man den Latchup ziemlich stark verhindern kann.

Mir selbst ist noch nie irgendwas kaputt gegangen bei neueren Sachen und ich habe auch von keinem gehört, bei dem es passiert ist. Früher war das wirklich ein Problem. Aber heutzutage?

Vorsicht ist aber natürlich immer die Mutter der Porzellankiste ;)

[cyrusNGC_224]

Mir selbst ist noch nie irgendwas kaputt gegangen bei neueren Sachen und ich habe auch von keinem gehört, bei dem es passiert ist. Früher war das wirklich ein Problem. Aber heutzutage?Was heißt denn früher? Also ich weiß nur, wenn man mal so einen BGA/TQFP/QFN Protz unvorschriftsmäßig behandelt hatte, dann konnte sich das über die Zeit signifikant problematisch auswirken. Fakt ist: ein so behandeltes Package, wie bei solchen Präsentationen wird man nie und nimmer produktiv weiter verwenden (können). Aber Ausschuss zum zeigen gibt es ja genug.

[Skysnake]

Wie gesagt, kommt darauf an, wie lange das her ist. Früher waren die ESD Struckturen ja auf dem Package, oder sogar außerhalb. Heutzutage kannst du dir das zumindest für die Signalpins teils gar nicht mehr erlauben. Und wenn und ESD schon onChip hast für die Signalpins, kannste es theoretisch auch für den Rest nehmen. Aber das ist eine Fruchtlose Diskussion. Ich denke keiner von uns will das man einfach testen ;)

@TOPIC:
http://insidehpc.com/2017/01/vega-amds-new-graphics-architecture-for-virtually-unlimited-workloads/

Da gibt es alle (?) slides. Interessant ist vor allem die Folie 35.

Jetzt könnte ihr man mal ein bischen das Denken anfangen. Vielleicht kommt ja noch jemand auf die gleiche Idee, die ich habe. Wäre schon ziemlich cool.

1. Was ist der HighBandwidthCacheController
2. WAs ist der HighBandwidthCache
3. Was bedeutet es, das NVRAM, System ram, Network Storage und PCIe dran hängen am HBCConstroller?

[Digidi]

Was ich nicht so ganz verstehe an Vega warum man das FrontEnd so aufgebohrt hat. In DX12 konnte AMD mehr Drawcalls und mehr Polygonen absetzen als Pascal.

[Screemer]

High bandwith cache = hbm
High bandwith cache controller = coherent Fabric controller (eh gmi) und multipurpose phys

Da kann man für hpc und deep lerning sicher coole sachen basteln. Mal ein quote aus nem alten wtftech artikel:

GMI phys of Zen die will talk directly with GMI phys of Greenland HBM 2.0 graphics die and uses coherent fabric too.

[tm0975]

3. Was bedeutet es, das NVRAM, System ram, Network Storage und PCIe dran hängen am HBCConstroller?
standardisierung von speicher-erweiterung, damit ram, ssd, etc. beliebig bzw. flexibel als erweiterung der vrams verwendet werden können. bei einer tradeon pro die ssd, bei einer apu der ram auf dem board etc?

[Locuza]

Wenn Konduri sagt unter 500mm², dann wird das auch stimmen. Viel unter 500mm² wird es allerdings nicht sein. Damit wohl ca. GP102-Größe. Leistung zwischen Gp104 und GP102 scheint also realistisch, man darf auch nicht vergessen, dass V10 im Gegensatz zu GP102 2xFP16 und 4x INT8 Leistung bietet.
4x INT8 bietet auch der GP104 und GP102, aber nicht der GP100.
2xFP16 bietet nur der GP100.
https://devblogs.nvidia.com/parallelforall/new-pascal-gpus-accelerate-inference-in-the-data-center/
https://gigglehd.com/gg/files/attach/images/14103/260/397/d1a39bf946becd5d48682797404aa116.jpg

Was ich nicht so ganz verstehe an Vega warum man das FrontEnd so aufgebohrt hat. In DX12 konnte AMD mehr Drawcalls und mehr Polygonen absetzen als Pascal.
Darum:
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11256415#post11256415

AMD kann eben nicht mehr Polygone absetzen und ein stupider Drawcall-Test wird einem nicht bei der Bewertung davon helfen.

[Skysnake]

High bandwith cache = hbm
High bandwith cache controller = coherent Fabric controller (eh gmi) und multipurpose phys

Da kann man für hpc und deep lerning sicher coole sachen basteln. Mal ein quote aus nem alten wtftech artikel:
1. Check
2. Check

Wobei noch ein Punkt etwas unklar ist. Ist der HBCC der HBM+PCI-E Controller, oder ist es ein HBM+Interconnect controller? Also ist das Interface PCI-E oder ist es etwas anderes?

Wenn man an IBM denkt, dann könnte das eventuell kompatibel zu CAPI2 sein, oder CCIX. An OpenCAPI ak NVLink glaube ich eher nicht. Das sind meines Wissens nach unterschiedliche PHYs. Zumindest ist das bei IBM so.

Zu 3. check @tm0975
Da hat man wohl endlich das umgestzt, was man sich mit Fiji schon versprochen hat. Das Ding ist ja sicher HSA kompatibel. Jetzt ist die Frage, wie man damit umgeht, und wie die Cohärenz genau aussieht.

Eventuell sieht man ja Ryzen + Vega. Das wäre schon ziemlich nice.

[Digidi]

@Locuza

Der Drawcalltest ist aber etwas näher an der Realität als der reine von dir verlinkte Polygonentest und da kann AMD weit mehr Polygonen absetzen als Nvidia wo anscheinend der Commandprozessor behindert.

Was wird denn eigentlich als schnitstelle bei dem Byoned3d Suite test genutzt? DX11 oder was eigenes?

[Loeschzwerg]

3. Was bedeutet es, das NVRAM, System ram, Network Storage und PCIe dran hängen am HBCConstroller?

Es bedeutet zunächst einmal dass sämtlicher Speicher als ein gemeinsamer Speicherbereich gesehen werden kann und das bringt dir hinsichtlich der Adressierung schon mal enorme Vorteile.
Der HBM2 dient in diesem Aufbau dann wirklich als "Cache" für häufig genutzte Daten, weshalb ich den Namen "HBC" ganz passend finde.

Die Infos zu Vega sind schon sehr interessant, ich bin gespannt was uns da erwartet. Hoffentlich verspricht AMD nicht zu viel.

[Complicated]

3. Was bedeutet es, das NVRAM, System ram, Network Storage und PCIe dran hängen am HBCConstroller?

Zu 3. check @tm0975
Da hat man wohl endlich das umgestzt, was man sich mit Fiji schon versprochen hat. Das Ding ist ja sicher HSA kompatibel. Jetzt ist die Frage, wie man damit umgeht, und wie die Cohärenz genau aussieht.

Eventuell sieht man ja Ryzen + Vega. Das wäre schon ziemlich nice.
Das läuft tatsächlich auf CCIX und GenZ Interconnect und die daraus resultierenden Möglichkeiten hinaus, diese Speicher nicht mehr blockbasierend anzusprechen wie HDD/SSD sondern direkte Speicheroperationen wie im VRAM auch auf den angebundenen NVRAM auszuführen oder sogar auf angebundenem Netzwerkspeicher. Siehe:
https://www.community.arm.com/processors/b/blog/posts/how-do-amba-ccix-and-genz-address-the-needs-of-the-data-center
Today, storage requires block based accesses with complex, code intensive software stacks. Memory operations such as loads and stores allow processors to access both volatile (ie DRAM) and non-volatile storage in the same efficient manner. Emerging Storage Class Memory (SCM) and rack level disaggregatedmemory pools, are example use-cases that benefit from a memory operation interconnect.https://www.community.arm.com/cfs-file/__key/communityserver-blogs-components-weblogfiles/00-00-00-21-42/2210.Gen_2B00_Z.png


CCIX basiert auf PCIe.

[Troyan]

Es bedeutet zunächst einmal dass sämtlicher Speicher als ein gemeinsamer Speicherbereich gesehen werden kann und das bringt dir hinsichtlich der Adressierung schon mal enorme Vorteile.
Der HBM2 dient in diesem Aufbau dann wirklich als "Cache" für häufig genutzte Daten, weshalb ich den Namen "HBC" ganz passend finde.


Es ist normaler VRAM. "HBC" ist ein reiner Marketingname, um etwas normales als neu zu verkaufen.

[Complicated]

Es ist normaler VRAM. "HBC" ist ein reiner Marketingname, um etwas normales als neu zu verkaufen.
Nö
https://www.heise.de/newsticker/meldung/AMDs-Next-Gen-Grafikchip-Vega-Erste-Details-zur-High-Speed-Architektur-3577830.html
AMD spricht bei Vega von einem revolutionären High Bandwidth Cache Controller (HBCC). Er soll im Zusammenspiel mit einem speziellen High Bandwidth Cache "adaptive feinkörnige Datenbewegungen" ermöglichen. Dazu gehört insbesondere das Paging auf externe Speicher, etwa Arbeitsspeicher, SSDs, NVRAM und Netzwerkspeicher. Anwendungen lässt sich dadurch ein besonders großer Videospeicher vorgaukeln.
http://www.pcgameshardware.de/Vega-Codename-265481/Specials/Architektur-NCU-HBCC-Vorstellung-1217460/
Das kann HBM2 sein, ist jedoch nicht darauf limitiert. AMD könnte beispielsweise auch - rein theoretisch - den auf niedrige Latenzen optimierten Hybrid Memory Cube (HMC) nutzen, den Intel bei Knights Landing einsetzt. Die Rede ist von einem bis zu 512 Terabyte großen virtuellen Adressbereich. Der HBCC kann den kompletten On-Package-Speicher oder auch nur einen Teil davon als L3-Cache nutzen. Das Ganze sei variabel einstellbar und mit verschiedenen Modi, zum Beispiel inclusive oder exclusive, nutzbar. Interessant könnte die Idee bei einem Konstrukt wie der Radeon Pro SSG werden, wo die GPU auf eine SSD als Grafikspeicher zugreifen kann.
Sicherlich kann normaler VRAM derzeit so nicht verwendet werden.

[Locuza]

@Locuza

Der Drawcalltest ist aber etwas näher an der Realität als der reine von dir verlinkte Polygonentest und da kann AMD weit mehr Polygonen absetzen als Nvidia wo anscheinend der Commandprozessor behindert.

Was wird denn eigentlich als schnitstelle bei dem Byoned3d Suite test genutzt? DX11 oder was eigenes?
Das ist allerdings auch ein Drawcalltest und 3DMark rät selber davon ab, Hersteller untereinander zu vergleichen.
Der Faktor gegenüber DX11 liegt bei 10 und sogar mehr, deswegen pumpt ja auch kein Hersteller 10 mehr Polygone unter DX12 durch.
Ich würde dort gar nichts ableiten wollen.

Die Schnittstelle von der B3D Suite sollte DX11 sein, wobei ich nicht weiß ob sich an der Test-Suite jemals etwas verändert hat.
https://www.beyond3d.com/content/reviews/55/10

DICE hat auf der GDC 2016 auch ihre Culling-Mechanismen präsentiert, mit XO, PS4 und Fury X Ergebnissen:
http://www.frostbite.com/2016/03/optimizing-the-graphics-pipeline-with-compute/

Die Motivation wird dargelegt und am Ende benötigt eine XO ohne Software-Culling 14% länger, die PS4 17% und eine Fury X dagegen abartige 49%.
Es ist offensichtlich das die Hardware an der Stelle nicht gut ausbalanciert ist.

[Screemer]

1. Check
2. Check

Wobei noch ein Punkt etwas unklar ist. Ist der HBCC der HBM+PCI-E Controller, oder ist es ein HBM+Interconnect controller? Also ist das Interface PCI-E oder ist es etwas anderes?


Coherent fabric soll ja aussieht ein ht nachfolger sein, der mehr möglichkeitwn bietet. Ich denke das es ccix bzw. Amds vorarbeit als basis für ersteres ist.

http://www.forbes.com/sites/moorinsights/2016/05/23/a-cache-coherent-interconnect-for-accelerators-ccix-fantasy-or-nirvana/

[Digidi]

@Locuza
Natürlich rät 3Dmark davon ab es zu vergleichen. Weil ja der ganze Kram wie Shader noch hinten dran steht. Aber der Test beleuchtet eindeutig das Frontend.

The test is designed to make API overhead the performance bottleneck. The test scene contains a large number of geometries. Each geometry is a unique, procedurally-generated, indexed mesh containing 112 -127 triangles.

und
The scene is drawn to an internal render target before being scaled to the back buffer. There is no frustum or occlusion culling to ensure that the API draw call overhead is always greater than the application side overhead generated by the rendering engine.

http://www.anandtech.com/show/9112/exploring-dx12-3dmark-api-overhead-feature-test

[Troyan]

Es gibt kein Unterschied zwischen Polaris und Pascal im Drawcall-Test:
http://www.sweclockers.com/test/22360-nvidia-geforce-gtx-1060/8#content

GXT1080 mit 4 Rasterizer ist exakt den Taktunterschied vor der RX 480 mit 4 Rasterizern.

[Unicous]

keinEN :rolleyes:

[BoMbY]

Der High Bandwidth Cache scheint laut Vega Präsentation ein eigenständiger Bereich auf der GPU zu sein, vermutlich eine Art L3 Cache, nur, dass der über den High Bandwidth Cache Controller angebunden ist, und Daten aus allen angeschlossenen Speicherarten puffern kann.

Über z.B. Vulkan kann man ja schon jetzt gezielt unterschiedliche Speicherbereiche ansprechen, welche unterschiedliche Eigenschaften/Flags haben. Die Frage wäre: Wie flexibel kann man das bei Vega in Zukunft steuern, und kann ich selbst z.B. auch Bereiche festlegen (im RAM, oder auf einer M.2 SSD, usw.), oder läuft das alles nur über den Treiber intern.

[iuno]

Nein, das ist schon der HBM. Die Darstellung ist halt symbolisch. Schau mal auf Seite 36, ansonsten wuerde ja der Speicher komplett fehlen ;)

[BoMbY]

Okay, wenn das HBM der Cache ist, wird dann immer ein fester Bereich von Hauptspeicher als VRAM abgezweigt? Wenn eine Applikation Texturen auf die GPU laden möchte, müssen die ja erstmal irgendwo hin, von wo aus sie dann ggfls. in den Cache geladen werden. Also klar, theoretisch wäre es möglich, aber ob das praktisch sinnvoll ist, das HBM im Hauptspeicher zu verdoppeln?

[Nakai]

Mit Vega baut AMD eben das ein, was mit PIM (Processing-In-Memory) schon angedeutet wurde. Durch Heterogene-Speichersysteme will man sich auf den Usecase gut anpassen können. Im Grunde ist es nur eine Abstraktionsschicht für Speicherzugriffe. Der nächste Schritt wäre der Ausbau und die Erweiterung von APIs, um diese neuen Methoden der Speicherverwaltung auch auszunutzen.

Für Consumer-Produkte ist das eh noch zu früh. Im professionellen Sektor ist das ziemlich nett, wenn es möglich wäre koherent auf verschiedene Speichersysteme zuzugreifen.

[BoMbY]

Ja, in der Theorie ist das nett, in der Praxis bedeutet das aber 32 GB DDR4 wären für ein System mit Vega mit 16 GB HBM2 quasi das Minimum.

[Complicated]

Wie oben schon zitiert:
Der HBCC kann den kompletten On-Package-Speicher oder auch nur einen Teil davon als L3-Cache nutzen.

Es bedeutet schon mehr. Siehe ausführlich:
https://www.techpowerup.com/reviews/AMD/Radeon_Vega_GPU_Architecture/2.html
AMD feels there is a disparity between the memory allocation and actual memory access by apps. An app could load into memory resources it finds relevant to the 3D scene being rendered, but not actually access all of it all the time. This disparity eats up precious memory, hogs memory bandwidth, and wastes clock cycles in trying to move data. The graphics driver development team normally collaborates with game developers to minimize this phenomenon and rectify it both through game patches and driver updates. AMD feels something like this can be corrected at the hardware level. AMD calls this "adaptive fine-grained data movement." It is a comprehensive memory allocation pipeline that senses the relevance of data to preemptively move it to the relevant physical memory, or defers access.
Dazu auch diese Folie:
https://www.techpowerup.com/reviews/AMD/Radeon_Vega_GPU_Architecture/images/memory6.jpg

Dadurch sollen deutlich weniger Daten im VRAM liegen und sie sollen preemptiv vorgeladen werden. Das ganze auf Hardwareebene ohne dass der Programmierer optimieren muss.

[Loeschzwerg]

Die Schnittstelle von der B3D Suite sollte DX11 sein, ...

Gibt es von der irgendwo einen Download oder muss man sich da direkt an Rys wenden?

[Kriton]

Ja, in der Theorie ist das nett, in der Praxis bedeutet das aber 32 GB DDR4 wären für ein System mit Vega mit 16 GB HBM2 quasi das Minimum.

Könntest Du das erklären - ich fürchte mein technisches Verständnis ist nicht so hoch wie das einiger anderer hier.

[Loeschzwerg]

Ja, in der Theorie ist das nett, in der Praxis bedeutet das aber 32 GB DDR4 wären für ein System mit Vega mit 16 GB HBM2 quasi das Minimum.

Nein, denn wie Locuza schon schreibt ist es "Im Grunde ist es nur eine Abstraktionsschicht für Speicherzugriffe.".

[Troyan]

Okay, wenn das HBM der Cache ist, wird dann immer ein fester Bereich von Hauptspeicher als VRAM abgezweigt? Wenn eine Applikation Texturen auf die GPU laden möchte, müssen die ja erstmal irgendwo hin, von wo aus sie dann ggfls. in den Cache geladen werden. Also klar, theoretisch wäre es möglich, aber ob das praktisch sinnvoll ist, das HBM im Hauptspeicher zu verdoppeln?

Es ist kein Cache. Es ist der normale VRAM. Und alle Informationen sind im Hauptspeicher vorhanden.

[BoMbY]

Es ist kein Cache. Es ist der normale VRAM. Und alle Informationen sind im Hauptspeicher vorhanden.

Das würde aber bedeuten, dass die Applikation nachdem die GPU über die Existenz von einem Objekt im Hauptspeicher quasi nur informiert wurde, dieser nicht gelöscht werden darf, weil man nie weiß ob der jetzt im "Cache" ist, oder nicht. Oder man hat halt einen fest definierten Shared-Memory-Bereich, der dann halt nicht als Hauptspeicher zur Verfügung steht, und welcher immer größer oder gleich dem belegten HBM2 ist.

[Complicated]

Ja genau sie nennen es nur Cache aus Jux und Dollerei - gut dass du das zum zweiten mal falsch hier postulierst, trotz gegenteiliger Quellen und Zitate. Lang lebe Troyan der Ignorante....

Wieder ernsthaft:
So wie Locuza und Löschzwerg interpretiere ich es auch. Vermutlich ein write-back Cache mit MOESI-Protokoll für die Kohärenz, wie es AMD auch bei Zen nutzt. (http://www.planet3dnow.de/cms/26077-details-und-analyse-der-zen-architektur-nach-der-hot-chips-konferenz/subpage-speichersubsystem-im-detail/) Ich bin nur gespannt ob Zen CPUs auch auf diesen Cache direkt zugreifen können, wenn ein Servernode mit Zen+Vega bestückt ist.

[Kriton]

Sieht HSA denn auch einen übergreifenden Zugriff auf Cache oder nur auf Speicher vor?

[mksn7]

Ich hab mal eine Frage wegen der Folie, wo beschrieben wird das die ROPs jetzt ein Client des L2 sind. Manche Kommentare deuten an, dass Deferred Renderer hier profitieren können.

Einen Deferred Renderer versteh ich so (bin kein Graphikprogrammierer): Alle Geometrie wird in den G-Buffer gerendert, mit Eigenschaften wie diffuse color, normals, specularity usw. Danach berechnet ein Full Screen Pixel (Compute?) Shader im Lighting Pass aus den Daten den endgültigen Pixel Farbwert. So wie ich die Kommentare versteh, soll wohl der Lighting Shader beim Zugriff auf den G-Buffer im L2 hitten, weil der von den Geometrie Passes noch da ist. Ist der G-Buffer nicht viel zu groß dafür? Ein 12Byte, FHD G-Buffer hat in meiner Rechnung schon 63MByte, und weder 12B noch FHD ist eine besonders hohe Anforderung.

Wie groß ist eigentlich so ein typisches Geometriedatenvolumen in modernen Spielen? Mach ichs mir zu einfach, wenn ich mir ausrechne dass 1Mio Vertices a 32B etwa 30MByte belegen? Eine voll tile based rasterizer müsste also Größenordnung 100MByte an Geometrie zwischen Vertex Shader und Pixel Shader zwischenpuffern, wenn nicht mehrfach transformiert werden soll. Es wird also in kleineren Datenhäppchen transformiert, gebinnt, gerastert und geshadet. Wäre es so schlimm, die transformierte Geometrie im DRAM zu binnnen und die Bins dann von dort zu laden zum rastern?

[Complicated]

http://developer.amd.com/wordpress/media/2013/10/Everything_You_Always_Wanted_to_Know_About_HSA_Final.pdf
We’re using “coherent” both as Webster’s defines it (“logically or aesthetically ordered”) and as computer scientists define the term (“a technique that ensures that multiple processors see a consistent view of memory,” even when values in memory may be updated independently by any of those processors).1 , 2
Memory coherency has been taken for granted in homogeneous multiprocessor and multi-
core systems for decades, but allowing heterogeneous processors (CPUs, GPUs and DSPs) to maintain coherency in a shared memory environment is a revolutionary concept.

2 HSA gurus refer to this feature as “Cache Coherent Shared Virtual Memory" (CC-SVM)

Abhandlung:
Evaluating Cache Coherent Shared Virtual Memory for Heterogeneous Multicore Chips (http://people.ee.duke.edu/~sorin/papers/ispass13_ccsvm.pdf)

[Locuza]

Gibt es von der irgendwo einen Download oder muss man sich da direkt an Rys wenden?
Also Googel spuckt fast nichts aus.
Scheinbar muss man wirklich eine Anfrage stellen.

Nein, denn wie Locuza schon schreibt ist es "Im Grunde ist es nur eine Abstraktionsschicht für Speicherzugriffe.".
[...]
So wie Locuza und Löschzwerg interpretiere ich es auch. [...]
Ja, ich heiße Locuza hier, aber die Interpretation stammt von Nakai. ;D

[Complicated]

Ok, Ehre wem Ehre gebührt ;)

[Loeschzwerg]

Hoppla :redface: :D

[Troyan]

Das würde aber bedeuten, dass die Applikation nachdem die GPU über die Existenz von einem Objekt im Hauptspeicher quasi nur informiert wurde, dieser nicht gelöscht werden darf, weil man nie weiß ob der jetzt im "Cache" ist, oder nicht. Oder man hat halt einen fest definierten Shared-Memory-Bereich, der dann halt nicht als Hauptspeicher zur Verfügung steht, und welcher immer größer oder gleich dem belegten HBM2 ist.

Ich verstehe es nicht 100%, was du meinst. Es gibt kein Cache. Die GPU benötigt die Daten im VRAM. Der "Cache Controller" verhindert, dass die Verarbeitung abbricht, da die Informationen nicht mehr im VRAM sind. Er liest automatisiert die Daten von außerhalb ein.

nVidia unterstützt die exakt selbe Funktionalität: https://devblogs.nvidia.com/parallelforall/beyond-gpu-memory-limits-unified-memory-pascal/

[Complicated]

Schon wieder. Nun nochmal. Ich kann es ebenso oft wiederholen. Unterstützt Nvidia dies auch?
http://www.pcgameshardware.de/Vega-Codename-265481/Specials/Architektur-NCU-HBCC-Vorstellung-1217460/
. Der HBCC kann den kompletten On-Package-Speicher oder auch nur einen Teil davon als L3-Cache nutzen. Das Ganze sei variabel einstellbar und mit verschiedenen Modi, zum Beispiel inclusive oder exclusive, nutzbar. Interessant könnte die Idee bei einem Konstrukt wie der Radeon Pro SSG werden, wo die GPU auf eine SSD als Grafikspeicher zugreifen kann.Beliebig zu konfigurierender Cache, sowohl in Größe als auch in Funktionsweise?
Zeig mal einen Link. Vor allem ist Nvidia limitiert auf die Größe des System-Speichers, wie dein Link deutlich beschreibt. AMDs Speicher kann auf die SSD und auf NVRAM ausgedehnt werden bis 512 GB auch wenn nur 16 GB RAM verbaut sind. Das ist einige Generationen voraus verglichen mit Nvidia. Die haben mit Pascal überhaupt erst aufgeschlossen auf Kaveri. Und ohne NVLink kann Nvidia kein bidirektionales Unified Memory bieten. Also für Gaming nicht zu gebrauchen sondern nur in HPCs mit IBM Power Prozessoren einsetzbar. Faktisch hat Nvidia kein Unified Memory für Gaming/Desktop, es sei denn man baut sich ein IBM Power9 System. AMD hat mit Vega gerade schon die dritte Stufe gezündet, da dies in Hardware gelöst ist.

[Locuza]

Ich sehe da keinen Unterschied.
Nvidia kann ebenso bis zu 49-Bit adressieren (512 TB) und das umfasst alle Clienten vom System.
Kaveri ist darüber hinaus eine APU, dass funktioniert ja auch nur für ihren gemeinsamen Speicher.

[Nakai]

Ok, Ehre wem Ehre gebührt ;)

Ich, Ich, Ich, Ich, Ich, ... ;D


Zeig mal einen Link. Vor allem ist Nvidia limitiert auf die Größe des System-Speichers, wie dein Link deutlich beschreibt. AMDs Speicher kann auf die SSD und auf NVRAM ausgedehnt werden bis 512 GB auch wenn nur 16 GB RAM verbaut sind. Das ist einige Generationen voraus verglichen mit Nvidia. Die haben mit Pascal überhaupt erst aufgeschlossen auf Kaveri. Und ohne NVLink kann Nvidia kein bidirektionales Unified Memory bieten. Also für Gaming nicht zu gebrauchen sondern nur in HPCs mit IBM Power Prozessoren einsetzbar. Faktisch hat Nvidia kein Unified Memory für Gaming/Desktop, es sei denn man baut sich ein IBM Power9 System. AMD hat mit Vega gerade schon die dritte Stufe gezündet, da dies in Hardware gelöst ist.

Wenn es so funktioniert, wie überall beschrieben, dann ist für jegliche Speicherarchitekturen möglich.

Wir sind eh erst am Anfang angekommen. Das dauert noch einige Zeit bis wir hier deutlich etwas sehen.
Es wäre jedenfalls ziemlich cool, wenn V10 einfach 16 GB HBM2 + 32 GB DDR4 und noch einen fetten NAND-Flash (~1TB) spendiert bekommt. Einen Batzen vom HBM2 wird als Cache konfiguriert.

Das wäre schon ziemlich fett, auch zum Training von fetten DL-Netzwerken. Da müssen horrende Mengen an Trainingsdaten vorgehalten werden, welche sich sehr gut in den NV-Speicher vorhalten lassen würden. Shared Layer Informationen würden sich super im HBM2-Cache cachen lassen. Die wichtigsten Netzwerkdaten lässt man im HBM2-Speicher und Daten von konsekutiven und prezenten Layern kann man im DDR4 liegen lassen.

Unter NVs-Namen wurden auch einige Papers veröffentlicht, wie man neuronale DL-Netzwerke so sehr komprimiert, dass die wichtigsten Informationen auf der GPU vollständig liegen (alle Register, Caches, etc.). Mit einem HBM2-Cache wäre das sehr nett erweiterbar.

[BoMbY]

Ich verstehe es nicht 100%, was du meinst. Es gibt kein Cache. Die GPU benötigt die Daten im VRAM. Der "Cache Controller" verhindert, dass die Verarbeitung abbricht, da die Informationen nicht mehr im VRAM sind. Er liest automatisiert die Daten von außerhalb ein.


Hier wird behauptet das VRAM wäre kein VRAM sondern ein Cache für das VRAM, welches sich folglich irgendwo anders befinden muss, also zum Beispiel ein Teil (größer oder gleich dem Cache) welcher vom Hauptspeicher abgezwackt wird. Kein Cache ohne Speicher.

Man kann nicht einfach irgendwelche Daten welche der Anwendung gehören auf einmal als VRAM ansehen, weil die GPU nicht wissen kann, was die Anwendung mit diesem Speicher macht. Macht braucht auf jeden Fall einen Speicher welcher als VRAM klassifiziert ist.

[mboeller]

Ja genau sie nennen es nur Cache aus Jux und Dollerei - gut dass du das zum zweiten mal falsch hier postulierst, trotz gegenteiliger Quellen und Zitate. Lang lebe Troyan der Ignorante....


IMHO (als Layman):

bei Spielen dürfte der Cache genauso funktionieren wie der VRAM bisher. Erst bei Profi-Anwendungen wird es wohl einen massiven Unterschied machen weil GPUs ja, soweit ich weiß bisher daran kranken dass sie keinen direkten Zugriff auf die großen Datenmengen haben sondern erst Häppchenweise gefüttert werden müssen. Soweit ich mich erinnere erreichen unter anderem deshalb GPUs nur einen sehr kleinen Teil ihres theoretischen Vorteils im Vergleich zu CPUs. Wenn eine VEGA-GPU jetzt auf max. 512TB direkt und kohärent zugreifen kann sollte das viele Profi-Sachen massiv beschleunigen. Skysnake sollte das aber wesentlich besser erklären können, der arbeitet ja in dem Bereich.

[BoMbY]

AMD VEGA 10 and VEGA 20 slides revealed (http://videocardz.com/65521/amd-vega-10-and-vega-20-slides-revealed)

Aus dem Dezember September und beziehen sich wohl auf die Compute-Karten. Ich würde etwas mehr Rohleistung von den Gaming-Vega-Karten erwarten.

[Nakai]

AMD VEGA 10 and VEGA 20 slides revealed (http://videocardz.com/65521/amd-vega-10-and-vega-20-slides-revealed)

Aus dem Dezember September und beziehen sich wohl auf die Compute-Karten. Ich würde etwas mehr Rohleistung von den Gaming-Vega-Karten erwarten.

Also kann Vega10 mit 4 Stacks umgehen. Das ist interessant. Und Vega11 kommt noch 2017. Und es sind doch 64 CUs. Nun die Frage, was diese andere Slide mit doppelter OP-Zahl meint. 2xFP16? Mhh...

[BoMbY]

Also kann Vega10 mit 4 Stacks umgehen. Das ist interessant. Und Vega11 kommt noch 2017. Und es sind doch 64 CUs. Nun die Frage, was diese andere Slide mit doppelter OP-Zahl meint. 2xFP16? Mhh...

Ist nicht eindeutig: Das ist eine Doppel-GPU-Karte, und eventuell wurde nur mal wieder das RAM beider GPUs zusammen gezählt.

[Nakai]

Mhh, jedenfalls ist Vega20 der Kandidat für eine HPC-APU. xGMI ist da zwingend notwendig.
Es wären noch Slides für Vega11 sehr nett. Eventuell hat der auch schon den xGMI-Support. ;)

[fondness]

Naja ein MADD benötigt 2 OPs, von daher kann man zu 64 MADDs schon mit 128 Ops angeben?!

Vega20 erst 2H/2018 in 7nm?! Navi erst 2019....ich hoffe Vega wird gut^^

[Nakai]

Mhh...Vega muss gut werden. Sonst wäre dieses geplante LineUp ein Problem.
V10 also bei 225W TDP. Das ist weit unter den genannten 300W. :)

[Complicated]

Ich sehe da keinen Unterschied.
Nvidia kann ebenso bis zu 49-Bit adressieren (512 TB) und das umfasst alle Clienten vom System.
Kaveri ist darüber hinaus eine APU, dass funktioniert ja auch nur für ihren gemeinsamen Speicher.
Der Unterschied ist gravierend:

Bei Nvidia musst du 512 TB RAM/VRAM (CPU+GPU) verbauen um diese Größe zu nutzen.
Bei AMD kannst du 16GB VRAM und 16GB DDR RAM nutzen und den Rest auf der SSD/HDD/NVRAM/LAN-Storage adressieren..

Das sind erhebliche Kostenunterschiede um die selbe Speichermenge nutzen zu können. Das adressieren alleine ist noch keine Kunst.

[AnarchX]

Bis Ende 2018 Hawaii weiter das schnellste DP-HPC Angebot bei AMD? :|

[Troyan]

Der Unterschied ist gravierend:

Bei Nvidia musst du 512 TB RAM/VRAM (CPU+GPU) verbauen um diese Größe zu nutzen.
Bei AMD kannst du 16GB VRAM und 16GB DDR RAM nutzen und den Rest auf der SSD/HDD/NVRAM/LAN-Storage adressieren..

Das sind erhebliche Kostenunterschiede um die selbe Speichermenge nutzen zu können. Das adressieren alleine ist noch keine Kunst.

Du kannst auch bei nVidia auf jedes Drittsystem zugreifen: https://developer.nvidia.com/gpudirect

[Complicated]

Also ist Vega20 doch ein Refresh der Vega-Architektur auf 14nm und Navi kommt auf keinen Fall 2018. Dafür kann man bei 2019 von 7nm ausgehen. Wie es aussieht ist Navi ein Polaris Nachfolger und Vega20 wir etwas anderes nachfolgen.

[[MK2]Mythos]

Vega10 kommt also ausschließlich mit 16GB HBM. Das Ding wird sicherlich ein paar Mark kosten. :D

[dildo4u]

Mythos;11257519']Vega10 kommt also ausschließlich mit 16GB HBM. Das Ding wird sicherlich ein paar Mark kosten. :D
Das sind Server Slides.

[Screemer]

Warum sollte man salvage versionen nicht mit 8gb bringen?

[Complicated]

Du kannst auch bei nVidia auf jedes Drittsystem zugreifen: https://developer.nvidia.com/gpudirect
Nur nicht in einem gemeinsamen Adressraum. Flickwerk was du da gerade händeringend zusammensuchst. Nvidia hat diese Teile einfach noch nicht verbunden. NVLink ermöglicht einiges, doch nicht auf x86 Systemen derzeit. Diese P2P und DMA Zugriffe hat Nvidia auch erst Jahre nach AMDs Hypertransport in 2013 endlich fertig gestellt. Das ist die Grundlage für NVLink.
Wie dort zu lesen 20 Jahre nach AMD, Intel oder IBM ist Nvidia dem Club beigetreten:
Optimize communication between GPUs using NUMA-style access to memory on other GPUs from within CUDA kernels.
Du verstehst Unified Memory einfach nicht.

[Troyan]

Nur nicht in einem gemeinsamen Adressraum. Flickwerk was du da gerade händeringend zusammensuchst. Nvidia hat diese Teile einfach noch nicht verbunden. NVLink ermöglicht einiges, doch nicht auf x86 Systemen derzeit. Diese P2P und DMA Zugriffe hat Nvidia auch erst Jahre nach AMDs Hypertransport in 2013 endlich fertig gestellt. Das ist die Grundlage für NVLink.
Wie dort zu lesen 20 Jahre nach AMD, Intel oder IBM ist Nvidia dem Club beigetreten:


Ich weiß, es ist vergebens, aber trotzdem:
Du weißt schon, dass Vega per PCIe an das Subsystem angeschlossen wird? Die unterliegen den selben Beschränkungen wie nVidia.


Du verstehst Unified Memory einfach nicht.

Eher du nicht, über was AMD redet.

[danarcho]

IMHO (als Layman):

bei Spielen dürfte der Cache genauso funktionieren wie der VRAM bisher. Erst bei Profi-Anwendungen wird es wohl einen massiven Unterschied machen weil GPUs ja, soweit ich weiß bisher daran kranken dass sie keinen direkten Zugriff auf die großen Datenmengen haben sondern erst Häppchenweise gefüttert werden müssen. Soweit ich mich erinnere erreichen unter anderem deshalb GPUs nur einen sehr kleinen Teil ihres theoretischen Vorteils im Vergleich zu CPUs. Wenn eine VEGA-GPU jetzt auf max. 512TB direkt und kohärent zugreifen kann sollte das viele Profi-Sachen massiv beschleunigen. Skysnake sollte das aber wesentlich besser erklären können, der arbeitet ja in dem Bereich.

Das sehe ich auch so. Bei Spielen (oder allgemeiner Grafikanwendungen) wird HBM einfach als VRAM dienen. Der Unterschied spielt erst bei HPC eine Rolle.
Nvidia GPUs können aktuell zwar ebenfalls Speicher mappen, aber es dauert praktisch ewig neue Threads zu spawnen, weshalb kleinere (parallelisierbare) Programme dann oft doch auf der CPU gerechnet werden. Zudem ist der Speicher nicht kohärent, weshalb die CPU es nicht "mitbekommt", wenn die GPU Daten verändert. Deshalb werden die Daten dann meistens doch hin- und herkopiert. Zusammen mit HSA und der Möglichkeit die Threads einfach in eine work-queue zu packen dürfte das der feuchte Traum aller HPC-Anwender werden. Damit entwickelt AMD die GPU weiter in Richtung eines Co-Prozessors.

[Complicated]

@Troyan
Erzähl keinen Unsinn. AMD hat echtes Unified Memory in heterogenen Systemen. Nvidia hat einen gemeinsamen virtuellen Adressraum in CUDA der wiederum partitioniert wird und die verschiedenen Partitionen den verschiedenen Devices zugeteilt werden. Bei AMD gehen die gesamten 512 in einen gemeinsam adressierbaren Speicher von jedem Device aus zugänglich.

Lies mal Nvidias Dokus richtig:
http://docs.nvidia.com/cuda/gpudirect-rdma/index.html#basics-of-uva-cuda-memory-management
http://docs.nvidia.com/cuda/gpudirect-rdma/graphics/cuda-va-space-addressing.png
Subsequently, within the CUDA VA space, addresses can be subdivided into three types:

GPU
A page backed by GPU memory. This will not be accessible from the host and the VA in question will never have a physical backing on the host.Dereferencing a pointer to a GPU VA from the CPU will trigger a segfault.
CPU
A page backed by CPU memory. This will be accessible from both the host and the GPU at the same VA.
FREE
These VAs are reserved by CUDA for future allocations.

This partitioning allows the CUDA runtime to determine the physical location of a memory object by its pointer value within the reserved CUDA VA space.

Addresses are subdivided into these categories at page granularity; all memory within a page is of the same type. Note that GPU pages may not be the same size as CPU pages. The CPU pages are usually 4KB and the GPU pages on Kepler-class GPUs are 64KB. GPUDirect RDMA operates exclusively on GPU pages (created by cudaMalloc()) that are within this CUDA VA space. Die Adressen werden schön aufgeteilt unter den Devices für unterschiedliche Nutzung.

[Skysnake]

Du kannst auch bei nVidia auf jedes Drittsystem zugreifen: https://developer.nvidia.com/gpudirect
Das ist aber ein gewaltiger Unterschied...

Du musst da alles im RAM halten. Hier kannste aber auch auf nem Massstorage etwas vorhalten. Das ist bezüglich Kosten ein gewaltiger Unterschied!

IMHO (als Layman):

bei Spielen dürfte der Cache genauso funktionieren wie der VRAM bisher. Erst bei Profi-Anwendungen wird es wohl einen massiven Unterschied machen weil GPUs ja, soweit ich weiß bisher daran kranken dass sie keinen direkten Zugriff auf die großen Datenmengen haben sondern erst Häppchenweise gefüttert werden müssen. Soweit ich mich erinnere erreichen unter anderem deshalb GPUs nur einen sehr kleinen Teil ihres theoretischen Vorteils im Vergleich zu CPUs. Wenn eine VEGA-GPU jetzt auf max. 512TB direkt und kohärent zugreifen kann sollte das viele Profi-Sachen massiv beschleunigen. Skysnake sollte das aber wesentlich besser erklären können, der arbeitet ja in dem Bereich.
Danke, aber aktuell kann man dazu noch nicht sehr viel sagen. Es ist z.B. noch gar nicht klar, was nach dem Ende eines Prozesses mit den Daten passiert. Wenn die Daten noch da sind und auch von nem anderen Prozess dann zugreifbar sind, dann wäre das schon ziemlich cool. Man könnte das dann z.B. für Checkpointing oder Dantenauswertung verwenden.

Ansonsten muss man sich anschauen, auf welcher Granularität das läuft. Ich gehe mal von Pageweise aus, was nicht sooo cool ist. Damit läuft man quasi dann in die gleichen Probleme wie nVidia mit ihren virtual shared memory Ansatz. Das funktioniert und man ist schnell beim prototyping, aber wirklich performant ist es nicht. Sprich man muss oft dann doch von Hand kopieren, wenn man Performance will. Wo es halt etwas bringen kann ist, wenn man random Zugriffe hat durch mehrere GPUs, wo man zwar weiß, das jeder nur auf einen Teil zugreift, aber nicht wer auf welchen Teil. Hier könnte man dadurch insgesamt weniger Daten transferieren. Die Frage ist aber, ob das am Ende wirklich schneller ist, als einfach den ganzen Buffer zu kopieren.

Genau darüber habe ich gestern auch mit nem Kollegen geredet, das man das mal benchmarken müsste. :rolleyes: Es ist nämlich wirklich nicht klar, dass das performant ist. Die bisherige Entwicklung bei nVidia ist da nicht so der Knaller.

Und solange es PCI-E ist gehe ich auch bei AMD nicht unbedingt davon aus, dass das wirklich gut funktioniert. Bei einer APU aus CPU + GPU auf einem Träger mit GMI (oder wie man es auch immer nennen mag) könnte das aber schon sehr sehr cool funktionieren, und ich hoffe ja noch immer darauf, das man mit Vega endlich mal so eine CPU GPU Kombi bringt.

[Troyan]

"Unified Memory" gibt es seit 2013 bei nVidia: https://devblogs.nvidia.com/parallelforall/unified-memory-in-cuda-6/

Das ist aber ein gewaltiger Unterschied...
Du musst da alles im RAM halten. Hier kannste aber auch auf nem Massstorage etwas vorhalten. Das ist bezüglich Kosten ein gewaltiger Unterschied!

Wer hält Berechnungen auf langsamen Massenspeicher vor?

[fondness]

Also ist Vega20 doch ein Refresh der Vega-Architektur auf 14nm

Vega20 steht mit 7nm auf der Folie. Alles andere braucht man im H2/2018 auch nicht mehr zu bringen. Vega20 ist damit ein Vega10 in 7nm mit 1/2 DP rate.

Aber immerhin scheint Vega10 auch mit 4 HBM2 Stacks umgehen zu können, damit liegt am Desktop also das halbe SI brach, aber auch das erklärt die relativ große Die-Size.

BTW, die Folien bestätigen wohl auch weiterhin GF-Fertigung (14nm) für Vega, also nichts TSMC 16nm.

[AffenJack]

Vega20 steht mit 7nm auf der Folie. Alles andere braucht man im H2/2018 auch nicht mehr zu bringen. Vega20 ist damit ein Vega10 in 7nm mit 1/2 DP rate.

Aber immerhin scheint Vega10 auch mit 4 HBM2 Stacks umgehen zu können, damit liegt am Desktop also das halbe SI brach, aber auch das erklärt die relativ große Die-Size.

BTW, die Folien bestätigen wohl auch weiterhin GF-Fertigung (14nm) für Vega, also nichts TSMC 16nm.

Ich glaube irgendwie eher, dass das mal wieder Marketing ist und 2 x HBM einfach als 4 Stacks gezählt wird. Das wurde oft schon gemacht. Vega20 sieht sehr nach Pipecleaner aus. Man bringt das Ding sehr früh in 7 nm, unter Umständen wird es wegen schlechter Yield und damit hohen Preis erstmal für Monate nur im Servergeschäft sein, aber man hat wichtige Erfahrung für Navi.

[Nakai]

Und solange es PCI-E ist gehe ich auch bei AMD nicht unbedingt davon aus, dass das wirklich gut funktioniert. Bei einer APU aus CPU + GPU auf einem Träger mit GMI (oder wie man es auch immer nennen mag) könnte das aber schon sehr sehr cool funktionieren, und ich hoffe ja noch immer darauf, das man mit Vega endlich mal so eine CPU GPU Kombi bringt.

Laut den Folien ist es nur Vega20 mit xGMI-Support bisher. Vega10 wäre auch zu groß dafür. Vega11 wäre der erste Chip der das womöglich unterstützen könnte. Der wäre auch von der Diesize für so ein MCM-Package verwendbar.

Vega20 wird interessant. Je nachdem wie hoch die Taktraten gehen können. Im Grunde ein Refresh mit DP- und xGMI-Support.

€: Ahja, sieht in Zukunft sehr stark danach aus, dass AMD MCMs mit GPUs auch im Consumer-Markt anbieten möchte. Da wird AMD sehr bald in Richtung Skalierbarkeit, womöglich auf einem Interposer.

[Skysnake]

VIRTUAL"Unified Memory" gibt es seit 2013 bei nVidia: https://devblogs.nvidia.com/parallelforall/unified-memory-in-cuda-6/

ICh habe es mal angepasst. Zudem weiß ich nicht, was du mir damit sagen willst...


Wer hält Berechnungen auf langsamen Massenspeicher vor?
Frag mal die Leute aus der Gensequenzierung und CGI. Ansonsten kann es auch bei Chemie Codes durchaus vorkommen, dass das gemacht wird.

Aber schön, das du auch nicht weiter gelesen hast. Denn das ist ja nur ein Teilaspeckt. Wichtiger ist es, das man Checkpointing beschleunigen könnte, und das machen verdammt viele Leute...

[Skysnake]

Ich glaube irgendwie eher, dass das mal wieder Marketing ist und 2 x HBM einfach als 4 Stacks gezählt wird. Das wurde oft schon gemacht. Vega20 sieht sehr nach Pipecleaner aus. Man bringt das Ding sehr früh in 7 nm, unter Umständen wird es wegen schlechter Yield und damit hohen Preis erstmal für Monate nur im Servergeschäft sein, aber man hat wichtige Erfahrung für Navi.
Würde ich auch von ausgehen.

Laut den Folien ist es nur Vega20 mit xGMI-Support bisher. Vega10 wäre auch zu groß dafür. Vega11 wäre der erste Chip der das womöglich unterstützen könnte. Der wäre auch von der Diesize für so ein MCM-Package verwendbar.

Vega20 wird interessant. Je nachdem wie hoch die Taktraten gehen können. Im Grunde ein Refresh mit DP- und xGMI-Support.
Den neuen Link mit den Folien hatte ich erst danach gelesen.

Schon ziemlich blöd, dass das wohl erst mit Vega20 kommt. Aber DIE Size ist kein Argument. Schau dir mal KNL oder auch den neuen Server-Sockel von AMD an. Die sind wirklich groß. Und wenn du dir mal den Sockel z.B. von einer alten SX8 (?) anschaust, dann ist der Sockel so groß wie ein Essteller ;D Und für was aktuelleres schau dir einfach mal die SystemZ MCM an. Die sind auch schon ziemlich riesig.

Man hat da also durchaus Luft nach oben.

[mboeller]

Also ist Vega20 doch ein Refresh der Vega-Architektur auf 14nm und Navi kommt auf keinen Fall 2018. Dafür kann man bei 2019 von 7nm ausgehen. Wie es aussieht ist Navi ein Polaris Nachfolger und Vega20 wir etwas anderes nachfolgen.


:confused: du solltest dir die Slides noch einmal anschauen

[Botcruscher]

Was für ein Mist. Von Vega also auch wieder nur 2 Chips + X2 gay-version. Dazu aufgewärmter Polaris. Das ganze bis H2 18 wo auch gut H1 19 draus wird. Da kommt ja totale Begeisterung... bei NV... auf.
PS: V10 dafür ein "Gamerchip" und Hawaii lebt ewig weiter ?!?

[Nakai]

Würde ich auch von ausgehen.


Den neuen Link mit den Folien hatte ich erst danach gelesen.

Schon ziemlich blöd, dass das wohl erst mit Vega20 kommt. Aber DIE Size ist kein Argument. Schau dir mal KNL oder auch den neuen Server-Sockel von AMD an. Die sind wirklich groß. Und wenn du dir mal den Sockel z.B. von einer alten SX8 (?) anschaust, dann ist der Sockel so groß wie ein Essteller ;D Und für was aktuelleres schau dir einfach mal die SystemZ MCM an. Die sind auch schon ziemlich riesig.

Man hat da also durchaus Luft nach oben.

Luft, ja. Aber der GPGPU-Teil einer HPC-APU wird nicht so fett sein dürfen. Auch reinher von der TDP. Klar, wenn man einen speziellen Sockel anbieten möchte, wieso nicht? Wenn AMDs RnD das zulässt, ist es in Ordnung.

[Troyan]

Frag mal die Leute aus der Gensequenzierung und CGI. Ansonsten kann es auch bei Chemie Codes durchaus vorkommen, dass das gemacht wird.

Und die verwenden nur 16GB Hauptspeicher? I dont think so.
Wer mit massiven Daten arbeitet, der hat auch sein Hauptspeicher bis zu Grenze gefüllt.


Aber schön, das du auch nicht weiter gelesen hast. Denn das ist ja nur ein Teilaspeckt. Wichtiger ist es, das man Checkpointing beschleunigen könnte, und das machen verdammt viele Leute...

Die Daten liegen wohl kaum auf langsamen "Massenspeicher" vor und werden erst zur Laufzeit von der CPU über das langsame Bussystem angefragt.

Und Checkpointing? Ich habe gerade 2 Minuten Zeit investiert, um zu sehen, was es ist. Nope, das wird wohl kaum vom erweiterten Adressraum profitieren, da der gespeicherte Zustand auf dem langsamen Massenspeicher liegt.

[mboeller]

...

Und solange es PCI-E ist gehe ich auch bei AMD nicht unbedingt davon aus, dass das wirklich gut funktioniert. Bei einer APU aus CPU + GPU auf einem Träger mit GMI (oder wie man es auch immer nennen mag) könnte das aber schon sehr sehr cool funktionieren, und ich hoffe ja noch immer darauf, das man mit Vega endlich mal so eine CPU GPU Kombi bringt.

Danke.

Bzgl. der HPC-APU. Dafür eignet sich ja anscheinend erst Vega20. Also frühestens 2019. :(

[Nakai]

Danke.

Bzgl. der HPC-APU. Dafür eignet sich ja anscheinend erst Vega20. Also frühestens 2019. :(

Ich würde erstmal V11 abwarten. Vielleicht sehen wir da mehr dann.

[cyrusNGC_224]

Und die verwenden nur 16GB Hauptspeicher? I dont think so.
Wer mit massiven Daten arbeitet, der hat auch sein Hauptspeicher bis zu Grenze gefüllt.Und wenn die nun beispielsweise 2 TB überschreiten? Oder einfach nicht so viel Hauptspeicher vorhanden ist, aus Kosten-Nutzen Gründen?


Und Checkpointing? Ich habe gerade 2 Minuten Zeit investiert, um zu sehen, was es ist. Nope, das wird wohl kaum vom erweiterten Adressraum profitieren, da der gespeicherte Zustand auf dem langsamen Massenspeicher liegt.Soll das jetzt echt aussagen, dass jemand, der nur 2 Minuten oberflächlich recherchiert mehr über spezifische technische Aspekte sagen kann, als jene, die täglich damit arbeiten?

[BlacKi]

wird vega 11 nun kleiner oder größer als vega 10?

[mboeller]

Ich würde erstmal V11 abwarten. Vielleicht sehen wir da mehr dann.

V11 wird aber der Nachfolger von Polaris 10/11. Da erwarte ich keine 1/2 DP und für eine HPC-APU sind die IMHO erforderlich.

Eine andere Möglichkeit wäre natürlich, dass RR genauso wie BR 1/2 DP unterstützt. Da RR hoffentlich auch infinity Fabric unterstützt könnte man damit dann Mainboards mit bis zu 4 APUs und bis zu 2-3 TF DP auf den Markt bringen.

[Isen]

wird vega 11 nun kleiner oder größer als vega 10?

11 Klein, 10 Groß für mich jedenfalls.

[Complicated]

Vega20 steht mit 7nm auf der Folie. Alles andere braucht man im H2/2018 auch nicht mehr zu bringen. Vega20 ist damit ein Vega10 in 7nm mit 1/2 DP rate.
:confused: du solltest dir die Slides noch einmal anschauen
Jetzt habe ich mir die Folien noch dreimal anschauen müssen bevor mir der Prozess dort ins Auge gesprungen ist. Danke :)
Dann hatte ich also doch Recht mit den 7nm Non-EUV in 2018. Ich war schon sehr enttäuscht über 2019 :D
Ich hatte 7nm für Navi auf dem Schirm. Aber Vega20 schon zuvor im neuen Prozess ist natürlich nochmal unerwartet, da kann Navi auch gerne 1 Jahr später raus kommen.

Allerdings macht mich bei der Folie eines stutzig:
Warum schreiben die Hawaii drauf? Der S9170 ist mit Grenada ausgestattet. Ich weiss die meisten sagen es sei der selbe Chip, doch warum sollte AMD seine eigenen Codenamen nicht benutzen? Ich bin gerade skeptisch geworden bzgl. der Echtheit.

[Achill]

Bis Ende 2018 Hawaii weiter das schnellste DP-HPC Angebot bei AMD? :|

Es gibt doch bisher keine Konkurrenz zur AMD FirePro S9170 mit 32GB und 2,62 TFLOPS bei DP oder?

[cyrusNGC_224]

Es gibt doch bisher keine Konkurrenz zur AMD FirePro S9170 mit 32GB und 2,62 TFLOPS bei DP oder?Außer eventuell Xeon Phi von Intel scheint das noch so zu sein.
Das er aber diese Position bis 2018 noch halten soll, das überrascht mich. Am Ende segelt noch so eine HPC APU dran vorbei ;)

[AffenJack]

Es gibt doch bisher keine Konkurrenz zur AMD FirePro S9170 mit 32GB und 2,62 TFLOPS bei DP oder?

Mit 32GB nicht, aber bei den Tflops ist P100 nunmal klar überlegen oder worum gehts dir? Allerdings ist DP mittlerweile nur noch für einen Bruchteil der Serverkunden interessant. Deap Learning Tauglichkeit hat einen viel größeren Markt und da ist Vega ja top.

[Digidi]

@Locuza
Natürlich rät 3Dmark davon ab es zu vergleichen. Weil ja der ganze Kram wie Shader noch hinten dran steht. Aber der Test beleuchtet eindeutig das Frontend.



und


http://www.anandtech.com/show/9112/exploring-dx12-3dmark-api-overhead-feature-test

Mal eine Frage wie viele Polygonen hat den Durchschnittlich ein Drawcalls? Und was mich auch mal interessiet, kann AMD nun 11 Polygonen entgegen nehmen und dann verarbeiten und es kommen dann nur 4 aus dem Rasterizer raus, oder kommen wirklich 11 Polygonen aus dem Rasterizer raus und die 11 werden dann an die Shader übergeben?

[Nakai]

Wie wird der NVRAM eigentlich angesprochen? Gibt es einen integrierten nativen NVRAM(NAND-Flash)-Controller. IP-Cores gibts dafür. Und gibt es native PHYs?
Falls, ja. Wieviele Speicherbausteine will man gleichzeitig ansprechen?
Die HBM2-PHYs werden winzig sein. Da ist genug Platz für zusätzliche Anschlusse. Aber leider kein xGMI-Link...

€:
V11 wird aber der Nachfolger von Polaris 10/11. Da erwarte ich keine 1/2 DP und für eine HPC-APU sind die IMHO erforderlich.

Eine andere Möglichkeit wäre natürlich, dass RR genauso wie BR 1/2 DP unterstützt. Da RR hoffentlich auch infinity Fabric unterstützt könnte man damit dann Mainboards mit bis zu 4 APUs und bis zu 2-3 TF DP auf den Markt bringen.

Zu V11 wissen wir erstmal gar nichts. Ansonsten klingt V11 nach einer Interessanten Karte. Ich würde schon 25% mindestens auf P10 draufrechnen.