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

[iuno]

Ich empfinde es als verwirrend, denn Rys Tweets und die Umschreibungen kann man auch so interpretieren, dass etwas automatisch läuft und nicht direkt von einem Entwickler eingepflegt werden muss.
Rys hat auch gesagt, dass vorerst keine Pläne existieren, dass ganze direkt in die Hand von Entwicklern zu geben.

Dann stellt sich natürlich die Frage, was macht dann der Treiber im Hintergrund und wann?
Irgendwie hat ja AMD einen Fall konstruiert, wo bis zu 17 Primitives geculled werden
verwirrend finde ich es mit den ganzen Aussagen durchaus auch. Aber ich kann es mir nicht anders erklaeren, wie oben beschrieben:
- Neue Pipeline mit anderem API-zu-HW Mapping, natuerlich automatisch vom Treiber (shader compiler) gemacht und ggf. noch deaktiviert
- Neue Pipeline beschleunigt bestimmte Vorgaenge, z.B. cluster culling, was aber trotzdem nach wie vor im Shader implementiert werden muss

Das Beispiel mit den 17 Dreiecken wird einfach einen compute "primitive" shader nutzen, der das entsprechend macht, ganz aehnlich wie bisher auch (http://gpuopen.com/gaming-product/geometryfx/). Eine Art Referenzimplementierung/Techdemo wie GeometryFX oder die Implementierung von Culling ueber compute Shader in diversen Engines.

[Isen]

Wie war das damals, bei BF3 oder wars 4?
da knallte NV ja einige Zeit nach Mantle den Wundertreiber raus, der gab ja fast generell (in vielen Games) mehr Leistung raus... vlt. bei AMD möglich... ?
Oder verrenne ich mich hier gerade in falschen Erinnerungen :D?

Das schlimme ist doch eh, wenn überhaupt, das jene Treiber dann auch die möglichen Miner auf den Schirm bringen können, da damit auch dort die Leistung steigt oder was auch immer.

Einfach nur noch ätzend das ganze, Preise sind völlig verkorkst. Zum Schwallartigen Gübeln der ganze PC-Gaming Markt.

[dildo4u]

Das hatte mit Win 8.1 und DX11.1 zu tun,Dice nutzt das seit BF4.

https://www.hardocp.com/article/2013/11/24/battlefield_4_windows_7_vs_81_performance_review/1

[Isen]

Das betraf doch aber auch andere Games, oder nicht?
Ich kann mich da echt nur noch Vage Vega (hehe) daran erinnern... :-/

[-=Popeye=-]

Das betraf doch aber auch andere Games, oder nicht?
Ich kann mich da echt nur noch Vage Vega (hehe) daran erinnern... :-/

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=10170731&postcount=24

[Isen]

Besten dank!

[Cyphermaster]

Die Frage ist, ist das alles einfach zu neu oder funktioniert es tatsächlcih nicht wie gedacht.Beides, weil es wohl zusammenhängt. Es sieht so aus, als würde Vega nur wirklich gut laufen, wenn alle Features miteinander laufen, und damit der Chip auch optimal "gefüttert" wird. Bei den aktuellen Treibern ist davon noch nichts zu sehen, man hat erst taufrisch überhaupt den DSBR drin. Wie übel die sind (und, daß wohl nicht die Hardware per se defekt ist), mag man nicht nur an den Windows, sondern auch an den Linux-Treibern sehen: Da laufen die open-source-Treiber für die RX sogar performanter als die aktuellen Hersteller-eigenen.

"RadeonSI OpenGL is outperforming the closed-source AMDGPU-PRO OpenGL driver for Vega 64 and Vega 56. Yes, you read that right; the open-source driver stack on launch-day is faster than the hybrid driver for OpenGL! This is something that has never been seen before in the history of AMD's open-source driver stack for new hardware on launch day! And is not something ever seen on the NVIDIA side either where the open-source, unofficial Nouveau driver lags behind the official NVIDIA Linux (proprietary) driver."

Wie viel da aber realistisch mit Treibern und BIOS-Optimierungen (da scheint auch noch Einiges drin, was man an Leistung liegen gelassen hat) wirklich rauszuholen sein könnte, ist bei den riesigen Streubreiten an Ergebnissen in den Launch-Reviews (von 1070-Niveau rauf bis zur 1080 Ti!) kaum einzuschätzen.

[iuno]

Der freie OpenGL Treiber ist genauso "herstellereigen" und schon seit längerem die bevorzugte Implementierung für Spieler. Ist also völlig normal dass der schneller ist.

[uweskw]

.....Wie viel da aber realistisch mit Treibern und BIOS-Optimierungen (da scheint auch noch Einiges drin, was man an Leistung liegen gelassen hat) wirklich rauszuholen sein könnte, ist bei den riesigen Streubreiten an Ergebnissen in den Launch-Reviews (von 1070-Niveau rauf bis zur 1080 Ti!) kaum einzuschätzen.

Wie ich das sehe hat sich seit Dezember performancemäßig eigentlich nichts getan. Nicht mal bei den üblichen verdächtigen AAA-Standard-Benchmark-Titeln.
Wenn da noch so viel herauszuholen wäre, hätten wir das schon bei dem ein oder anderem Spiel gesehen.
Ich hoffe AMD hat die Zeit vor Markteinführung genutzt und wenigstens kräftig Bitcoins geschürft. Dann bleibt zu hoffen, dass wenigstens die nächste Generation die nötigen Recourcen bekommt.

greetz
US

[HOT]

Dass der DSBR erst jetzt erstmals lauffähig wurde spricht mMn Bände. Auch dass es noch einige Features gibt, die immer noch deaktiviert sind. Das Ding hat die Softwareabteilung einfach massiv überfordert. Die haben sich erst mal um die Pro-Treiber gekümmert und sich die Zertifikate geholt, damit man im Pro-Bereich direkt alles am Laufen hat. Spiele hatten einfach keine Priorität bis jetzt, so seh ich das. MMn war erst mal vor allem OpenGL, aber auch DX11 auf der Agenda, DX12 und Vulkan laufen mMn nur und da wurde nix weiter dran gemacht.
Sicherlich wird die V64 ohne Hilfe von GCN-eigenen Eigentschaften wie RPM und SI kaum erreichen, aber man kann dem sicherlich letztendlich doch recht nahe kommen, wenn softwaremäßig alles läuft wie es soll, davon bin ich überzeugt. Nur bis es soweit ist, spricht keiner mehr von der 1080 ti, sondern nur noch von der 2080.

[Cyphermaster]

Der freie OpenGL Treiber ist genauso "herstellereigen" und schon seit längerem die bevorzugte Implementierung für Spieler. Ist also völlig normal dass der schneller ist.Dann mea culpa, vergessen wir das. :redface:
Wie ich das sehe hat sich seit Dezember performancemäßig eigentlich nichts getan. Nicht mal bei den üblichen verdächtigen AAA-Standard-Benchmark-Titeln.
Wenn da noch so viel herauszuholen wäre, hätten wir das schon bei dem ein oder anderem Spiel gesehen.Mich wundert es nicht, daß bei Titeln wie Doom, in denen die Auslastung des Chips von Beginn an gut war, nicht groß besser geworden sind (mehr als 100% ist halt nicht ;)); wenn, dann ist Potential vorrangig dort, wo der Chip nicht richtig gefüttert wird - und da, wo die neuen Features was reißen könnten. Da die noch nicht drin sind, steht da auch noch ein Fragezeichen. /edit: Warum man in der Software derartig massiv hinterher hinkt, ist mir allerdings auch ein Rätsel.

[Dino-Fossil]

Warum man in der Software derartig massiv hinterher hinkt, ist mir allerdings auch ein Rätsel.

Vielleicht hat HOT recht und man hat sich vorrangig um die Pro-Sparte gekümmert. Bei den nach wie vor beschränkten Ressourcen der RTG kann man dann wohl keine Wunder erwarten.
Oder ihnen fehlen einfach die fähigen Leute. Reicht ja schon, wenn da ein oder zwei Schlüsselfiguren zur falschen Zeit ausfallen/abgeworben werden.

[Screemer]

SR-IOV ist für mich auch interessanter Punkt. Ein Rechner mit zwei user-sessions und beide können daddeln. Einer zB. im Wohnzimmer über inhome streaming und einer vor dem Rechner. Das kann für viele ne Konsole ersetzen. Gibts da eigentlich auch support unter Windows oder ist da was geplant? Zwei Windows vms unter Linux laufen zu lassen für das feature ist für die meisten sicherlich ne zu große Schwelle.
Vielleicht passt das hier besser als im review thread.

[basix]

Release: Wundertreiber Noi!

After Release Speku: Wundertreiber Ahoi! :D (Daumen drück, und das wirklich dicke...)

[Cyphermaster]

Bei den nach wie vor beschränkten Ressourcen der RTG kann man dann wohl keine Wunder erwarten.Keine Wunder, aber wenigstens einen "fertigen" Treiber (d.h. auch alles Versprochene drin) durfte man imho durchaus zu einem Launch erwarten.

[Dino-Fossil]

Keine Wunder, aber wenigstens einen "fertigen" Treiber (d.h. auch alles Versprochene drin) durfte man imho durchaus zu einem Launch erwarten.

Ja, das stimmt schon.
Übrigens zu Linux: Der freie Treiber wird mittlerweile auch wesentlich von AMD mitentwickelt und hat ggü dem offiziellen amdgpupro vermutlich vor allem den Vorteil, dass man da wirklich den aktuellsten Featurestand bekommen kann - wenn man auf aktuellsten Kernel+Treiber+Umgebung setzt (z.B. aus diversen ppa oder selbstkompiliert).
Der amdgpupro dürfte dem ziemlich sicher einiges hinterherhinken.

[iuno]

Wie schon oben geschrieben: nicht "mittlerweile", sondern schon immer. Nur war er frueher halt zusaetzlich da und jetzt auch offiziell die primaere Loesung fuer Spieler.
Der -pro stack hinkt featuremaessig nicht hinterher, immerhin bekommt man da ja auch Patches die noch nicht upstream sind - oder ganze Komponenten wie DC. Der freie Stack hat z.B. im Gegensatz zum -pro noch keinen FreeSync support, groesstenteils immer noch keine OpenCL- und einen halbfertigen Vulkantreiber (hier mal wirklich aus der Community, nicht von AMD).

[Dino-Fossil]

Ich beziehe das auf den Vega Support und da benötigt man aktuell nunmal einen sehr aktuellen Kernel und die neuesten Treiber.

Soweit ich weiß, bietet amdgpupro im aktuellen Release noch nicht so viel, aber vielleicht bin ich da im Irrtum.

[iuno]

Der aktuelle -pro ist fuer Kernel 4.10, fuer freie braucht man um ueberhaupt ein Bild zu bekommen enien non-upstream Branch. Das ist beides nicht besonders toll ;)

[y33H@]

Ich war der Meinung, die (Hardware) Shader stage, die frueher da war, fehlt jetzt und man packt etwa Vertex+Geometry Shader zu einer hardware stage zusammen. Wenn das nicht der Fall ist und die Stage immer noch da ist, aber nicht mehr genutzt werden soll, verstehe ich den ganzen Aufriss nicht.Beide existieren parallel.

[HOT]

Wie schon oben geschrieben: nicht "mittlerweile", sondern schon immer. Nur war er frueher halt zusaetzlich da und jetzt auch offiziell die primaere Loesung fuer Spieler.
Der -pro stack hinkt featuremaessig nicht hinterher, immerhin bekommt man da ja auch Patches die noch nicht upstream sind - oder ganze Komponenten wie DC. Der freie Stack hat z.B. im Gegensatz zum -pro noch keinen FreeSync support, groesstenteils immer noch keine OpenCL- und einen halbfertigen Vulkantreiber (hier mal wirklich aus der Community, nicht von AMD).

Na ja, Vega ist hier schon speziell, bei vorherigen Produkten war die Software eigentlich immer auf dem Featurestand, den die Hardware auch bot (mit kleinen Ausnahmen). Aber bei Vega fehlen immer noch Schlüsseltechnologien im Consumerbereich, das ist schon ne neue Qualität.

[G3cko]

Meine Einschätzung: Durch Maxwell hatte AMD keine andere Wahl als Vega vorzuziehen. Zusätzlich on Top kommt hinzu, dass LowLevel sich bisher nicht so durchgesetzt hat wie man das gerne gehabt hätte. Damit man man überhaupt unter DX11 halbwegs gut skaliert musste der Takt stark angehoben werden.

Wäre die Verbreitung von LL höher, hätte man lieber mehr Shader verbaut anstatt zusätzliche Piplines und wäre davon gezogen. So ist es eine kurzfristige Notlösung zu Lasten des Verbrauchs die man vermutlich erst mit dem Erscheinen von Maxwell beschlossen hat.

[Dural]

Vorgezogen? Vega hat sicherlich 1 jahr verspätung wenn nicht sogar mehr.

Da wurde rein nichts vorgezogen.

[HOT]

Das seh ich auch nicht. Eher ist man ca. 1 Jahr verspätet. Greenland wurde schon Anfang 2015 erwähnt. Dass man erst Mitte 2016 das Tapeout hinlegte zeigt, dass das Hardwareteam massive Probleme bei der Maske an sich hatte. Das Teil war ne schwere Gebuhrt aus meiner Sicht. Polaris hatte im Oktober 2015 Tapeout und schon im Juni 2016 release (na ja, bis darauf, dass man den Markt massiv unterschätzte, was die Absatzmenge anging). Greenland hätte Anfang 2016 Tapeout haben müssen und ca. September 2016 releast werden müssen. Dass das so nicht passierte sagt mir, dass man massive Entwicklungsprobleme hatte. Natürlich konnte man mit der neuen Software deshalb auch erst nach dem Tapeout anfangen und hier gingen die massiven Probleme offenbar nahtlos weiter.
Ich könnt mir auch vorstellen, dass man für Greenland einfach viel zuwenig Personal zur Verfügung gestellt hat, weil man schon sehr früh am eigentlichen Top-Produkt arbeitete, nämlich 7nm Navi. Denn hier soll ja ein vollmodulares Konzept aufgehen, das brauchte sicherlich stark Manpower, hat also ähnlich enorme Entwicklungskosten wie die IF-Entwicklung. Und dieses Projekt bindet auch massiv Softwarentwickler, das darf man nicht unterschätzen. MMn hat man Greenland auf die leichte Schulter genommen, weil Fiji so ernorm gut geklappt hat.

[aufkrawall]

Ich würd mich einfach mal von der Vorstellung verabschieden, dass AMD Desktop-Gaming so gut bedienen kann wie andere Bereiche. Da bekommt man dann halt die Abwandlungen der Server-Produkte vorgesetzt. Bei Ryzen hat das gut geklappt, bei Vega jetzt eben weniger. Vielleicht ist das Teil für Gaming eher als eine Art Pipecleaner für Navi anzusehen, mit den ganzen neuen, ungenutzten Features.

[Dural]

Meine meinung: amd wurde extrem vom takt bei pascal überrascht, nicht mal wegen dem takt für sich, sondern takt in verbindung mit dem verbrauch.

Ich habe sehr stark das gefühl das amd vega verzögert hat um ihn für etwas mehr takt zu optimieren.

[HOT]

Ich würd mich einfach mal von der Vorstellung verabschieden, dass AMD Desktop-Gaming so gut bedienen kann wie andere Bereiche. Da bekommt man dann halt die Abwandlungen der Server-Produkte vorgesetzt. Bei Ryzen hat das gut geklappt, bei Vega jetzt eben weniger. Vielleicht ist das Teil für Gaming eher als eine Art Pipecleaner für Navi anzusehen, mit den ganzen neuen, ungenutzten Features.
Jo das würd ich auch so sehen. Man versucht das Teil jetzt als Entwicklungsplattform zu nutzen, damit man bei Navi weniger Softwarearbeit hat.

[G3cko]

Das schließt sich ja nicht aus. Nur weil Greendland früh erwähnt wurde, heißt das eben nicht, dass der Chip in dieser From letztendlich so erscheint. Wie erwähnt wurde man durch den DSBR und den hohen Takt überrascht. Beides hilft, dass sich LL massiv verzögert. Nvidia wird solange bei DX11 bleiben wie nur möglich, da es ihnen durch den Treiber einen automatischen Wettbewerbsvorteil bietet.

Mit Fiji wird man gesehen haben wie die Skalierung abnimmt. Da hatte man praktisch nur die Wahl den DSBR einzuführen, auf Shader zu verzichten und den Takt hochzuziehen.

Neben den ganzen Features die Vega sowieso schon bieten sollte war das einfach zuviel. Dazu kommt noch Navi. Da führte dann eins zum anderen.

Würde die Hälfte aller Titel auf Vulkan und DX12 setzten wäre man den Weg mit dem hohen Takt vermutlich nicht gegangen.

Ich vermute eben auch, dass Vega die Grundarchitektur für Navi darstellt. Daher will man auch soviel wie möglich mitnehmen. Bei Navi wird man schon genug Probleme mit der Skalierung haben.

[HOT]

NV ist es letztendlich egal, welche API genutzt wird. Ich glaub, dass die angebliche DX11-Bevorzugung ein Mythos ist, das passt nämlich nicht zu NV. Die optimieren eh alles tot. Die APIs setzen sich mit neuen Engineversionen eh zwangsläufig marktweit durch.
Kann natürlich sein, dass man sich bei AMD Anfang 2015 gesagt hat "oh scheisse, NV nutzt ja ein neues Renderingverfahren, zurück ans Reißbrett", das würde auf jeden Fall die Verzögerung erklären. Andererseits hatte NV schon Ende 2014 Maxwell1 auf dem Markt... das war also eigentlich nix neues.

[Sunrise]

Meine meinung: amd wurde extrem vom takt bei pascal überrascht, nicht mal wegen dem takt für sich, sondern takt in verbindung mit dem verbrauch.

Ich habe sehr stark das gefühl das amd vega verzögert hat um ihn für etwas mehr takt zu optimieren.
Von dem Taktverhalten bei Pascal wurde jeder positiv überrascht. Ich glaube mich zu erinnern und das war ein regelrechter Schock, dass man nun plötzlich an die 2GHz fahren konnte, was ja Jensens Aussage war. Das ist heute noch fast nicht glaubhaft wenn man mal bedenkt, welche Taktraten wir vorher hatten.

Da das inzwischen schon 15 Monate her ist, ist deine Einschätzung nicht ganz unschlüssig.

Allerdings gebe ich zu bedenken, dass das nur dann Sinn ergibt, wenn AMD davon ausging, genug Bandbreite (etwa doppelt ausgehend von Polaris) zu haben, denn bei einem deutlich höheren Takt aber quasi verdoppelter GPU vgl. mit Polaris rennt man ohne weitere Maßnahmen gnadenlos in einen Bandbreiten-Flaschenhals.

Daher wurde auch genau hieran ordentlich Aufwand gesteckt.

Was AMD dann eher Angst machen sollte ist der Takt und die Effizienz, die NV mit 7nm erreichen könnte. Dagegen hat AMD aus aktueller Sicht keine Mittel und ich würde mal behaupten, dass NV, wenn sie sich hier nach 16FF+++ oder wie auch immer auf 7nm konzentrieren hier wieder eine GPU veröffentlichen, die sehr sehr nahe an GCN ist aber hier viel viel weniger dessen Schwächen im Design selbst.

[dargo]

NV ist es letztendlich egal, welche API genutzt wird.
Das glaubst aber nur du. :tongue: GCN bringt unter LL einfach mehr Leistung auf die Straße. Ich glaube kaum, dass das NV egal ist.

[Hübie]

AMDs Pendants überholen NV ja trotzdem nicht und es gibt keine verlässlichen Untersuchungen zum Anklang von LL APIs unter den Entwicklern. Kann mir gut vorstellen, dass man froh ist eine Engine zu lizensieren bei der man sich nicht damit herumschlagen muss wie es denn auf Hardware XY laufen wird (das darf dann der Lizenzgeber gerne machen, aber ist den -nehmern wohl ziemlich Wurscht). Das D3D11 auch noch gut performen kann wird regelmäßig gezeigt, aber das liegt halt am Hardware- und Engine-Ansatz.
Es ist NV trotzdem nicht egal. DX12 hat den Nachteil dass man viel mehr von der ISA herausgeben "muss".
Ich sehe dem entspannt entgegen, da D3D11 oftmals schneller als DX12 ist und auch schneller als die Konkurrenzprodukte (wenige Ausnahmen seien dahin gestellt).

btw: Doom empfand ich mit Vulkan übrigens deutlich konsistenter...

[iuno]

Na ja, Vega ist hier schon speziell, bei vorherigen Produkten war die Software eigentlich immer auf dem Featurestand, den die Hardware auch bot (mit kleinen Ausnahmen). Aber bei Vega fehlen immer noch Schlüsseltechnologien im Consumerbereich, das ist schon ne neue Qualität.
Im Zitat ging es eigentlich gerade um Linuxtreiber und insbesondere dem freien vs. dem Pro-Stack.


Kann mir nochmal jemand kurz erklaeren, was den DSBR jetzt genau von einem TBDR unterscheidet? Im Whitepaper steht
Pixel shading can also be deferred until an entire batch has been processed [...] Deferred shading reduces unnecessary work by reducing overdraw (i.e., cases where pixel shaders are executed multiple times when different polygons overlap a single screen pixel)
Hier hat man aber oefters gelesen (etwa von Gipsel), dass es bei einem IMR verbleibt. Auf die Schnelle konnte ich keine bessere Erklaerung finden. Wo ist die Grenze bzw. was fehlt Vega, dass man es einen TBDR nennen koennte?
Und warum geht man eigentlich ueberhaupt nicht auf TBDR bei grossen GPUs?

[vinacis_vivids]

Meine Einschätzung: Durch Maxwell hatte AMD keine andere Wahl als Vega vorzuziehen. Zusätzlich on Top kommt hinzu, dass LowLevel sich bisher nicht so durchgesetzt hat wie man das gerne gehabt hätte. Damit man man überhaupt unter DX11 halbwegs gut skaliert musste der Takt stark angehoben werden.

Wäre die Verbreitung von LL höher, hätte man lieber mehr Shader verbaut anstatt zusätzliche Piplines und wäre davon gezogen. So ist es eine kurzfristige Notlösung zu Lasten des Verbrauchs die man vermutlich erst mit dem Erscheinen von Maxwell beschlossen hat.


Die 4096SP treffen schon den sweetspot wenn >95% des Codes parallel verarbeitet werden kann. Bei mehr Breite hätte man mit dem Takt wieder runtergehen müssen oder der Chip wäre noch größer und die shader in schlecht optimierten Games noch schlecher ausgelastet.

Mit dem Wissen, dass am PC die Spiele oftmals schlecht optimiert sind, hat AMD den Taktweg gewählt (ineffizient) und Vega mit vielen features ausgestattet (effizient) um beide Wege gehen zu können wobei LL-API eindeutig im Vordergrund steht.

Die Lücke war ja riesig zu Pascal, der 3584SP@2Ghz packt und Fiji 4096@1Ghz. Mit 1,6-1,7Ghz ist Vega immer noch ein Stück hinten, aber taktmäßig für AMD schon eine (R)evolution.

Man muss auch sagen, dass transistorenmäßig von Fiji zu Vega lediglich 40% zugelegt wurden (12,5Mrd. vs 8,9Mrd.)
GP102 zu GP104 sind es 67% (12Mrd. vs 7,2Mrd.), da kommen auch keine 67% mehr Rohleistung auf die Straße.

[reaperrr]

Man muss auch sagen, dass transistorenmäßig von Fiji zu Vega lediglich 40% zugelegt wurden (12,5Mrd. vs 8,9Mrd.)
GP102 zu GP104 sind es 67% (12Mrd. vs 7,2Mrd.), da kommen auch keine 67% mehr Rohleistung auf die Straße.
"Lediglich" 40% ist für null zusätzliche Ausführungseinheiten (den verdoppelten L2 mal ausgeklammert) verdammt viel.

GP104 hat in 40% mehr Transistoren ggü. GM204 zusätzlich zur (weiter) verbesserten Taktbarkeit und Architektur auch 25% mehr SM gebracht.
AMD lag bei Performance pro Transistor eh schon weit hinten und ist dadurch jetzt leider noch deutlich weiter zurückgefallen, NV wird mit Volta wahrscheinlich um den Faktor 2 in Führung gehen, das entspricht einem perfekten Full-Node-Shrink.

Selbst ein V10 in 7nm wäre vermutlich nicht gut genug um das ganz aufzuholen, da die letzten FullNode-Shrinks immer "nur" ca. 60-70% mehr Perf/W gebracht haben, nicht 100%.

[Locuza]

[...]
Kann mir nochmal jemand kurz erklaeren, was den DSBR jetzt genau von einem TBDR unterscheidet? Im Whitepaper steht

Hier hat man aber oefters gelesen (etwa von Gipsel), dass es bei einem IMR verbleibt. Auf die Schnelle konnte ich keine bessere Erklaerung finden. Wo ist die Grenze bzw. was fehlt Vega, dass man es einen TBDR nennen koennte?
Und warum geht man eigentlich ueberhaupt nicht auf TBDR bei grossen GPUs?
Dazu steht folgendes im White-Paper:
Vega” uses a relatively small number of tiles, and it operates on primitive batches of limited size compared with those used in previous tile-based rendering architectures.
This setup keeps the costs associated with clipping and sorting manageable for complex scenes while delivering most of the performance and effciency benefits.

Ganz oberflächlich habe ich mitbekommen, dass die Effizienz bei komplexer Geometrie mit wenigen Pixeln stark sinkt, weswegen das die Hersteller nicht implementiert haben.
Nach all der Zeit hat man aber scheinbar den Kompromiss gefunden, dass ganze geschmacklich zu vereinen, um die Effizienz in allen Fällen hoch zu behalten.

[TheGood]

Hm also die Theorie dass der VEGA jetzt SOO spät ist kann ich immer noch noch nachvollziehen. IM Juni oder Juli 2016 gabs die Meldung auf Twitter die als "Design done" interpretiert wurde.

Tweet:
Design team is thrilled with your response. Celebrated a milestone with the team. Long way to go before you see it

Also so spät ist das alles dann doch nicht. GGf. hätten die KArten schon im Juni auf dem Markt sein können, dann hätten wir das gleiche zeitfenster wie bei Polaris gehabt. Für mich ist daher VEGA maximal 3 Monate zu spät und nicht mehr.
Im Vergleich zur GTS 1000 Serie sinds logischerweise mehr.

[Digidi]

Ist doch klar, es läuft schlecht auf Vega. Kann ja nur kaputt sein. Der Chip ist eben seiner Zeit voraus aber alle anderen sind seit Jahren nicht in der Lage diese Weisheit zu erkennen.
Async Compute war also auch nur ein Reinfall? Das hat so lange in Hawaii und Tahiti geschlummert und nun kann ja an DX12 und Mantel sehen was da geschlummert hat.

Amd fehlt einfach die Software-Unterstützung der Publisher da sie nicht Markt relevant sind.

Das gleiche prophezei ich für den primitive Shader


Previous hardware mapped quite closely to the standard
Direct3D rendering pipeline, with several stages including
input assembly, vertex shading, hull shading, tessellation, domain shading, and geometry shading. Given the wide variety of rendering technologies now being implemented by developers, however, including all of these stages isn’t always the most ecient way of doing things.
Quelle:
http://radeon.com/_downloads/vega-whitepaper-11.6.17.pdf

[iuno]

Dazu steht folgendes im White-Paper:

Ganz oberflächlich habe ich mitbekommen, dass die Effizienz bei komplexer Geometrie mit wenigen Pixeln stark sinkt, weswegen das die Hersteller nicht implementiert haben.
Nach all der Zeit hat man aber scheinbar den Kompromiss gefunden, dass ganze geschmacklich zu vereinen, um die Effizienz in allen Fällen hoch zu behalten.
Danke. Naja, die Effizienz eines Rasterizer sinkt ja sowieso (https://image.slidesharecdn.com/gdc2016compute-160318234955/95/optimizing-the-graphics-pipeline-with-compute-gdc-2016-51-638.jpg), wenn man kleinere Dreiecke hat. Die Aussage hilft mir so allgemein nicht wirklich weiter, aber ich muss das wohl nochmal auch anschauen.

Auf jeden Fall finde ich es spannend und irgendwie auch seltsam, dass es schon seine gut 20 Jahre gebraucht hat, bis man den Ansatz mal (zumindest in Ansaetzen) auf den Desktop uebernimmt. Schade dass es von Nvidia keine wirklichen Infos gibt. Hoffe, dass AMD das auch noch besser hinbekommt, gerade fuer APUs ist das ja sehr interessant.

[Hübie]

Es gibt auch bei NV Fälle, wo der per Treiber deaktiviert ist. Der Grund warum man es erst jetzt implementiert mag in der Fertigung begründet liegen. Man muss mit jeder GPU Kompromisse eingehen und man wollte vielleicht nicht die Transistoren dafür opfern. Oder man hat schlicht nicht daran geforscht. :D

[Locuza]

Danke. Naja, die Effizienz eines Rasterizer sinkt ja sowieso (https://image.slidesharecdn.com/gdc2016compute-160318234955/95/optimizing-the-graphics-pipeline-with-compute-gdc-2016-51-638.jpg), wenn man kleinere Dreiecke hat. Die Aussage hilft mir so allgemein nicht wirklich weiter, aber ich muss das wohl nochmal auch anschauen.

Auf jeden Fall finde ich es spannend und irgendwie auch seltsam, dass es schon seine gut 20 Jahre gebraucht hat, bis man den Ansatz mal (zumindest in Ansaetzen) auf den Desktop uebernimmt. Schade dass es von Nvidia keine wirklichen Infos gibt. Hoffe, dass AMD das auch noch besser hinbekommt, gerade fuer APUs ist das ja sehr interessant.
Meine ganz laienhafte Vorstellung von der ganzen Sache ist, dass du mit einem Tiler einen Ausschnitt vom Bild speicherst und die Hardware sich dann um die Verwaltung der Tiles kümmern muss und was pro Tile enthalten ist.
Je komplexer die Geometrie ist, desto mehr Speicher wird pro Tile benötigt und dann scheint man sich extra um den Fall kümmern zu müssen, falls Geometrie zwischen zwei Tiles liegt und wie man das managed.
Komplexe Geometrie erhöht die Kosten bei diesem Vorgang, bei einem IMR liegt das Problem hauptsächlich dabei, wenn pro Triangle nicht 16 Pixeln (Im Falle von AMD) enthalten sind, ansonsten interessiert die Geometrie nicht.
Nvidia deutet das bei ihren Slides an:
https://www.techpowerup.com/img/17-03-01/6e52a8ca916c.jpg
https://www.techpowerup.com/img/17-03-01/e28138b5c6aa.jpg

Im mobile Space scheint das Ganze sehr gut zu klappen, da die Geometrie für die Anwendungen simpel ausfällt und die Pixeldichte hoch, da die gängigen Tiler dort auch unnützes Shading aussortieren, profitiert man enorm.

Das Thema habe ich jetzt am Rande häufiger gelesen, ohne es wirklich zu verstehen.
Aber in Erinnerung ist mir geblieben, dass die Desktop-Hersteller wegen ständig komplexerer Geometrie den Aufwand gescheut haben.
Jetzt sind beide bei einem hybriden Ansatz gelandet und das scheint ganz gut zwischen den Vor- und Nachteilen zu sitzen.

Wer Zeit und Lust hat kann sich ein altes Paper durchlesen, ich habe es nicht, aber die Einführung umschreibt das ganze schön. :freak:
A technique that looks promising is tile-based rendering.
This technique decomposes a scene into tiles and renders the tiles one by one.
This allows the color components and z values of one tile to be stored in small, on-chip buffers, so that only the pixels visible in the final scene need to be stored in the external frame buffer.

However, in a tile-based renderer each triangle may need to be sent to the graphics accelerator more than once, since it might overlap more than one tile. In this paper we measure the total amount of external data traffic produced by conventional and tile-based renderers using several representative OpenGL benchmark scenes.
The results show that employing atilesizeof 32×32 pixels generally yields the best trade-off between the amount of on-chip memory and the amount of external data traffic.
In addition, the results show that overall, a tile-based architecture reduces the total amount of external data traffic by a factor of 1.96 compared to a traditional architecture.
We mention, however, that the reduction in bandwidth of tile-based rendering when compared to traditional rendering depends significantly on the workload used. For workloads with a high overlap factor and low overdraw, the traditional rendering can still outperform the tile-based rendering, while for workloads with a low overlap factor and high overdraw, the tile-based rendering is more suitable than traditional rendering.
https://www.aes.tu-berlin.de/fileadmin/fg196/publication/old-juurlink/Memory_Bandwidth_Requirements_of_Tile-Based_Rendering.pdf

Und wie immer gilt natürlich, dass es so viele unterschiedliche Mechanismen gibt und Kniffe, weswegen es für einen Laien überhaupt nicht ersichtlich ist, wo man jetzt die ganzen Raster-Vorgänge der Unternehmen einordnen kann, da (alte) Artikel und Forschungspaper Nachteile nennen, die durch andere Mechanismen im Chip aber verringert oder ganz ausgeschlossen werden.

[Gipsel]

Etwas aufgeräumt.

Bitte bleibt beim Thema!

[dargo]

Ist das schlechte Abschneiden von Vega aktuell in Crysis 3 kein Vega Thema? :confused:
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11462511&postcount=870

Wurde leider auch gelöscht. ;(

[Fragman]

vielleicht ists ja ne idee das aufgeraeumte einfach in einen neuen thread zu schieben, damit man zumindest mal drueber reden kann. oder einfach sagen in welchen thread das reingehoert. :confused:

[w0mbat]

Oder ein anderes Beispiel: Direct3D10.1.
Während schon die Ablösung des unglücklichen R600 D3D10.1 beherrschte, hat es bei Nvidia lange gedauert, bis auch Mittelklasse und schneller D3D10.1 beherrschten. Also wurde der Daseinsberechtigung von D3D10.1 verneint, schließlich hatte man nichts davon auf dem Bildschirm. Was aber nicht stimmte: Erstens konnte man die Kantenglättung erheblich verbessern (Stalker Clear Sky) oder aber neue Effekte wie das beliebte SSAO oder auch Schatten beschleunigen.

Ich kann mich noch dunkel erinnern, dass Assassins Creed (der 1. Teil :D) damals einen DX10.1 Patch bekam. Das wurde nicht angekündigt, das war mit einem Update plötzlich da und wurde nur entdeckt, weil die HD3000er plötzlich überall AA anwenden konnten und dabei auch noch schneller waren.

Computerbase hat damals nachgefragt und es gab die Bestätigung, dass es DX10.1 war. Das hat Nvidia nicht gefalllen, somit wurde es etwas später wieder entfernt.

Nvidia ist die größte Fortschrittsbremse im Spielemarkt. Klar, sie haben super Treiber für aktuelle Titel, die Zukunftsfähigkeit ihrer GPUs ist aber nur zweitrangig, da sie lieber eine neue GPU Verkaufen als dass die alten lange halten.

[Raff]

Ist das schlechte Abschneiden von Vega aktuell in Crysis 3 kein Vega Thema? :confused:
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11462511&postcount=870

Wurde leider auch gelöscht. ;(

Das ist kein grundsätzliches Problem, bei PCGH läuft Vega in Crysis 3 (Bestandteil des Leistungsindex seit 2013) normal. Da scheinen andere Dinge mit hineinzuspielen.

MfG,
Raff

[pilzsammler2002]

Das ist kein grundsätzliches Problem, bei PCGH läuft Vega in Crysis 3 (Bestandteil des Leistungsindex seit 2013) normal. Da scheinen andere Dinge mit hineinzuspielen.

MfG,
Raff

Gut scheint es ja trotzdem nicht zu laufen da die RX 64 LE "nur" 75 Fps schafft und ne 1070 schon 80 Fps (1080 = 95 Fps) :D

[dargo]

Das ist kein grundsätzliches Problem, bei PCGH läuft Vega in Crysis 3 (Bestandteil des Leistungsindex seit 2013) normal. Da scheinen andere Dinge mit hineinzuspielen.

Ohje... jetzt wirds komplett unübersichtlich.

[G3cko]

Man man man wer hat den alles eine Vega für 509€ abgreifen können? Und warum wurde ich nicht rechzeitig informiert...

[dargo]

Die waren zu dem Preis ruck zuck weg.

[Entropy]

Kann mir nochmal jemand kurz erklaeren, was den DSBR jetzt genau von einem TBDR unterscheidet? Im Whitepaper steht
Hier hat man aber oefters gelesen (etwa von Gipsel), dass es bei einem IMR verbleibt. Auf die Schnelle konnte ich keine bessere Erklaerung finden. Wo ist die Grenze bzw. was fehlt Vega, dass man es einen TBDR nennen koennte?
Bei TBDR wird erst die ganze Geometrie verarbeitet, danach wird rasterisiert und anschliessend wird erst das Shading gemacht. Es sind 3 Stufen die unabhängig voneinander sind, in der Theorie.

DSBR hingegen steckt Dreiecke eher oportunistisch in Buckets, dadurch musst du nicht, wegen z.B. einem Dreieck ein ganze Framebuffer-Tile dekomprimieren, mit einem Pixel modifizieren und wieder komprimieren. Du wirst mit den paar Dreiecken im Bucket, gerade wenn es einen Depth-Pass in der Engine gab, nichts an Shadingarbeit einsparen. DSBR ist also nichts anderes, als ein kleiner "Cache", der nun aber von der Rasterizer-Einheit entkoppelt, pro Bildausschnit ist.


Und warum geht man eigentlich ueberhaupt nicht auf TBDR bei grossen GPUs?
Weil bei TBDR alles vom Parameterbuffer abhängt. Du kannst mit 1M Dreiecken pro Bild rechnen, bei in etwa 1 Vertex pro Dreieck und 16 bis 128 Byte pro Vertex hast du schnell 16 MB bis 128 MB, was noch nichtmal die Redundanz durch Tiling beinhaltet.
Deswegen hast du auf Mobile bis heute keine Tesselierung.

[Digidi]

Bei TBDR wird erst die ganze Geometrie verarbeitet, danach wird rasterisiert und anschliessend wird erst das Shading gemacht. Es sind 3 Stufen die unabhängig voneinander sind, in der Theorie.

DSBR hingegen steckt Dreiecke eher oportunistisch in Buckets, dadurch musst du nicht, wegen z.B. einem Dreieck ein ganze Framebuffer-Tile dekomprimieren, mit einem Pixel modifizieren und wieder komprimieren. Du wirst mit den paar Dreiecken im Bucket, gerade wenn es einen Depth-Pass in der Engine gab, nichts an Shadingarbeit einsparen. DSBR ist also nichts anderes, als ein kleiner "Cache", der nun aber von der Rasterizer-Einheit entkoppelt, pro Bildausschnit ist.


Weil bei TBDR alles vom Parameterbuffer abhängt. Du kannst mit 1M Dreiecken pro Bild rechnen, bei in etwa 1 Vertex pro Dreieck und 16 bis 128 Byte pro Vertex hast du schnell 16 MB bis 128 MB, was noch nichtmal die Redundanz durch Tiling beinhaltet.
Deswegen hast du auf Mobile bis heute keine Tesselierung.

Aber gibt es deshalb nicht das Culling? Am Ende kann der Rasterizer ja nicht mehr Polygonen sinnvoll verarbeiten als es Pixel auf dem Bildschirm gibt. Wenn jetzt alle andern Polygonen die außerhalb des Sichtfeld sind, zu klein sind oder hinter Objekten stecken verworfen werden hat der DSBR immer die selbe Anzahl an max polygonen und darauf musste man auslegen.

[BoMbY]

Es sieht so aus als gäbe es zwei deutlich unterschiedliche Varianten von Vega-Packages:

https://tweakers.net/nieuws/128409/amd-levert-vega-chips-van-verschillende-hoogte-en-afwerkkwaliteit-aan-partners.html

[Loeschzwerg]

ES vs final

Da ist lediglich Molding dazugekommen. Igor hat hierzu auch schon was geschrieben im Test.

[BoMbY]

Dann hat Guru3D wohl ein ES als Review-Sample bekommen (http://www.guru3d.com/articles-pages/amd-radeon-rx-vega-64-8gb-review,4.html)?

[G3cko]

Bei praktisch nur 2 Händlern kann natürlich kein Wettbewerb entstehen. Klasse. Die einen bekommen die Karte zum Schnäppchenpreis die anderen dürfen 150€ mehr bezahlen...

[Loeschzwerg]

@BoMbY: Es fehlt schon mal der Aufdruck zur Identifikation oder dieser wurde bewusst wegretuschiert bzw. die Belichtung ist beschissen. Würde sagen dass es eine Pre-Production Karte ist.

[=Floi=]

welches stepping ist es eigentlich geworden? gibt es dazu was, wie problematisch oder unproblematisch das ganze nun war?


Bei praktisch nur 2 Händlern kann natürlich kein Wettbewerb entstehen. Klasse. Die einen bekommen die Karte zum Schnäppchenpreis die anderen dürfen 150€ mehr bezahlen...
dann kauf doch einfach nicht!

[Kriton]

Async Compute war also auch nur ein Reinfall? Das hat so lange in Hawaii und Tahiti geschlummert und nun kann ja an DX12 und Mantel sehen was da geschlummert hat.

Amd fehlt einfach die Software-Unterstützung der Publisher da sie nicht Markt relevant sind.

Das gleiche prophezei ich für den primitive Shader

Quelle:
http://radeon.com/_downloads/vega-whitepaper-11.6.17.pdf

Mit Blick auf meine Zustimmung verweise ich mal auf meine Ausführungen im Review-Thread:

IMHO wird hier generell der Fehler gemacht, dass die HW ständig losgelöst von der SW (mit Ausnahme des Treibers) betrachtet wird. Das erscheint mir ein grundsätzlicher und maßgeblicher Fehler. Das ist bei mir schon viele Jahre her, aber von Assembler-Programmierung aus kommend weiß ich, dass man sehr viel "falsch" machen kann auf der SW-Ebene bei fixer HW. Unterschiedliche SW-Lösungen für ein spezifisches Problem performen bei unterschiedlichen HW-Ansätzen ggf. ganz unterschiedlich.
Das heißt nicht, dass die Architektur von Vega keine Fehler hat (das kann ich nicht beurteilen), aber dies daran festzumachen, wie sie bei bestehender SW performt, ist zu kurz gegriffen (natürlich kann man argumentieren, dass die SW zuerst da war und sich die HW daran auszurichten hat, aber auch dann wäre lediglich die Aussage legitim ( weil soweit beweisbar), dass die Architektur für die aktuell vorliegende SW-Landschaft suboptimal ist). Und das ist auch nicht notwendigerweise ein (reines) Treiberthema (der insoweit ggf. nichts anderes tut als für die HW suboptimale Programmierung auszutauschen durch besser auf die HW abgestimmten Code).
Das ist IMHO auch das Thema der LL-APIs (wobei mir persönlich hier zu oft DX12 und nicht Vulkan genannt wird). Aufgrund höherer HW-Nähe bei guter Doku ist es zu erwarten, dass gute Programmierer dort für AMD mehr herausholen können, weil auf die Besonderheiten der Architektur eingegangen werden kann. Hier hat man also nicht das Problem, dass die HW sich nach der SW richten muss, sondern kann es umgekehrt handhaben.
Prinzipiell würde das auch für Nvidia gelten. Dort ist vermutlich die schlechtere Doku (in Verbindung mit einer Architektur, die bereits stark auf die Anforderungen der bestehenden SW ausgerichtet ist) dafür verantwortlich, dass man weniger Performancesteigerungen sieht. In Abhängigkeit inwieweit die HW-Architekturoptimierung geht, könnte man auch Nvidia noch bei LL einiges herausholen (bei entsprechender Doku). Bei den (uns) vorliegenden Infos scheint mir das aber Kaffeesatzleserei zu sein.

[DrFreaK666]

Apple sollte AMD mit einer Finanzspritze unter die Arme greifen. Schließlich hätten sie auch was davon..

[deekey777]

Apple sollte AMD mit einer Finanzspritze unter die Arme greifen. Schließlich hätten sie auch was davon..
Apple schreibt die Treiber selbst, also hätten sie nichts davon. Und wenn Apple wirklich seine eigenen GPUs bringt, wird es für AMD richtig blöd.

[y33H@]

ES vs final - da ist lediglich Molding dazugekommen. Igor hat hierzu auch schon was geschrieben im Test.Die Story ist größer als nur ES vs Retail ...

[M4xw0lf]

Die Story ist größer als nur ES vs Retail ...
Du immer mit den one-linern, die mehr Fragen aufwerfen als beantworten :ufinger:

[Locuza]

Samsung vs. Sk Hynix packaging line?

[DrFreaK666]

Apple schreibt die Treiber selbst, also hätten sie nichts davon. Und wenn Apple wirklich seine eigene GPUs bringt, wird es für AMD richtig blöd.

Die Apple-GPUs sind ja bisher nur für die mobilen Geräte geplant, soweit ich weiss

[TGKlaus]

vielleicht ists ja ne idee das aufgeraeumte einfach in einen neuen thread zu schieben, damit man zumindest mal drueber reden kann. oder einfach sagen in welchen thread das reingehoert. :confused:

Die Idee ist richtig gut. Leider wurden komischerweise ein paar echt interessante Punkte mit aufgeräumt ...

[Digidi]

Die Story ist größer als nur ES vs Retail ...

Wann kommt die Story ;)?

[Screemer]

Die Apple-GPUs sind ja bisher nur für die mobilen Geräte geplant, soweit ich weiss
Du Schlepper also deinen imac pro mit dir rum? Respekt!

Spaß beiseite. Vega kommt bei apple nicht mobil sondern in eben diesem imac pro. (https://www.apple.com/de/imac-pro/specs/)

[=Floi=]

Die Apple-GPUs sind ja bisher nur für die mobilen Geräte geplant, soweit ich weiss

vega kommt in den neuen mac pro.
wenn die das teil mit max. 1400mhz betreiben, dann sollte auch der durst im rahmen bleiben.

[iuno]

Apple sollte AMD mit einer Finanzspritze unter die Arme greifen. Schließlich hätten sie auch was davon..
Bis das Auswirkungen haette, hat Apple doch schon seine eigenen GPUs :D
Ausserdem reden wir hier ueber Apple...

Die Apple-GPUs sind ja bisher nur für die mobilen Geräte geplant, soweit ich weiss
Wenn sie eigene Grafik IP haben, die Metal (und ggf. GL und CL, was sie halt brauchen) unterstuetzt, koennen sie es auch gleich fuer ihre Macs nehmen. Die Architektur muss halt skalierbar sein. Ich sehe da ehrlich gesagt kein so grosses Problem, wenn man unbedingt unabhaengig sein will und so viel Kohle hat.

Die Story ist größer als nur ES vs Retail ...
Wann kommt der Artikel? ;)

Bei TBDR wird erst die ganze Geometrie verarbeitet, danach wird rasterisiert und anschliessend wird erst das Shading gemacht. Es sind 3 Stufen die unabhängig voneinander sind, in der Theorie.

DSBR hingegen steckt Dreiecke eher oportunistisch in Buckets, dadurch musst du nicht, wegen z.B. einem Dreieck ein ganze Framebuffer-Tile dekomprimieren, mit einem Pixel modifizieren und wieder komprimieren. Du wirst mit den paar Dreiecken im Bucket, gerade wenn es einen Depth-Pass in der Engine gab, nichts an Shadingarbeit einsparen. DSBR ist also nichts anderes, als ein kleiner "Cache", der nun aber von der Rasterizer-Einheit entkoppelt, pro Bildausschnit ist.
Danke fuer die Antwort. der TBDR bekommt also die ganze Geometrie, teilt das Bild auf und macht dann eine Tile von vorne bis hinten komplett fertig (vertex shader bis fragment shader), dann die naechste Tile usw.?
Waehrend der DSBR nur wirklich fuer die Rasterisierung Dreiecke sammelt und alles andere davon wieder unabhaengig ist.
Kann man das so sagen? Aber wie wird dann HSR noch vor dem ggf. deferred shading gemacht?

[DrFreaK666]

Du Schlepper also deinen imac pro mit dir rum? Respekt!

Spaß beiseite. Vega kommt bei apple nicht mobil sondern in eben diesem imac pro. (https://www.apple.com/de/imac-pro/specs/)

Das wollte ich damit sagen. Die Apple-GPUs sind erst für iPad und iPhone geplant
Vielleicht noch das von deekey777 zum Verständnis lesen ;)
Außer ich selbst habe es falsch verstanden ^^

[Loeschzwerg]

Die Story ist größer als nur ES vs Retail ...

Hui, bin gespannt :)

Was ich bis jetzt an Bildern gesehen habe sind mit Molding alle ab ca. April/Mai '17 und ohne Ende '16.

Mit "größer" gebe ich jetzt mal einen Tipp ab und vermute dass diese Sache u.a. zu Verzögerungen geführt hat? Richtig/Falsch?

Edit: Ok, habe auch ein Bild mit Molding von KW48 '16... KW44 und 46 sind z.B. ohne. Edit2: KW47 ist ebenfalls ohne Molding (Bild von Digital Foundry).

[Screemer]

Das wollte ich damit sagen. Die Apple-GPUs sind erst für iPad und iPhone geplant
Vielleicht noch das von deekey777 zum Verständnis lesen ;)
Außer ich selbst habe es falsch verstanden ^^
Irgendwie hab ich dein post als Frage in bezug auf Vega aufgefasst. Beim zweiten lesen frag mich mich warum :ugly:

[Locuza]

Hui, bin gespannt :)

Was ich bis jetzt an Bildern gesehen habe sind mit Molding alle ab ca. April/Mai '17 und ohne Ende '16.

Mit "größer" gebe ich jetzt mal einen Tipp ab und vermute dass diese Sache u.a. zu Verzögerungen geführt hat? Richtig/Falsch?

Edit: Ok, habe auch ein Bild mit Molding von KW48 '16... KW44 und 46 sind z.B. ohne. Edit2: KW47 ist ebenfalls ohne Molding (Bild von Digital Foundry).
Bei einem Package ohne Molding stand made in Taiwan, bei dem mit in Korea, ist das immer der Fall?

[Grendizer]

Was bedeutet das mit dem "Molding" ?

[deekey777]

Was bedeutet das mit dem "Molding" ?
Ist wohl diese Geschichte: https://www.hardocp.com/news/2017/08/16/amd_sampling_different_vega_64_gpus63

Die Apple-GPUs sind ja bisher nur für die mobilen Geräte geplant, soweit ich weiss

Ja, eigentlich ja: Apple will sich von IMG trennen.

Apple ist eigentlich der einzige treue PC-Hersteller, der Radeons verbaut. Ob AMD Apple dafür in den Arsch kriecht odr umgekehrt, sei dahin gestellt. Wenn (falls?) Apple seine GPUs abseits der iOS-Geräte verbaut, dann verliert AMD diesen langjährigen Partner. Denn abseits der mobilen Macs sieht es sehr düster aus, es werden überwiegend die M-irgendwas verbaut mit 320/384 SPs, neuere und/oder stärkere dedizierte Radeons sind sehr selten anzutreffen.


Nur so ein Gedanke:
Falls Raven Ridge wirklich die zweite Generation der Zen-Familie sein wird, wirkt das irgendwie auf Vega(-s) aus? Sprich 14nm+ oder so?

[Locuza]

Was bedeutet das mit dem "Molding" ?
Das eine Package wird mit einer Masse umgossen, welche die Lücken zwischen den Chips füllt und eine gemeinsame Fläche schafft, dass andere Package dagegen hat die Lücken:
https://uploads.disquscdn.com/images/1832be23e8d71bb03d02bc49a8c2339f24977349813e74ca69633464548e5876.jpg?w=800&h=591

[reaperrr]

Ist sonst noch jemandem aufgefallen, dass laut dem Update des CB-Reviews auf Fiji-Takt/-Bandbreite (1050 MHz GPU, 1000 MHz HBM), wo also die Bandbreite kaum bis gar nicht limitieren sollte (verglichen mit Ref-Takt), die V64 mit 14,2% mehr CUs trotzdem nur schlappe 5,2% vor der V56 landet?
Also entweder Frontend, Backend oder beides scheint da massiv zu limitieren.

Das lässt zumindest Hoffnung, dass Vega11 besser wird als V10 vermuten lässt, da zumindest das Frontend gleich breit bleiben sollte.
Hilft natürlich nur, wenn es entweder nicht an den ROPs liegt oder diese ebenfalls bei 64 belassen werden (wobei ich letzteres irgendwie bezweifle, allein schon weil der Chip dann wohl zu groß werden würde).

[Locuza]

1+ :freak:

Ich habe mich bei den Ergebnissen die ganze Zeit schon gewundert, die Bandbreite stellt kein Problem dar, der Takt skaliert auch halbwegs, dennoch sind die Ergebnisse sehr lausig.
Die Skalierung von den CUs ist aber offensichtlich weiterhin schwach.
Titanfall 2 ist das einzige Spiel, wo 14% auch wirklich ankommen, es ist gegenüber Fiji auch 24% schneller bei der Vega 64.
Bei Battlefield 1 legt Vega 64 25% gegenüber der Fury X zu, aber nur 3% gegenüber der Vega 56, was darauf hinweist das intern etwas deutlich besser abläuft, wo die Anzahl der CUs wenig entscheidend ist.

[Grendizer]

Das eine Package wird mit einer Masse umgossen, welche die Lücken zwischen den Chips füllt und eine gemeinsame Fläche schafft, dass andere Package dagegen hat die Lücken:
https://uploads.disquscdn.com/images/1832be23e8d71bb03d02bc49a8c2339f24977349813e74ca69633464548e5876.jpg?w=800&h=591


OK... und bringt das unterschiede ?

[Screemer]

Ohne molding soll mann wohl ziemlich beim Wechsel der kühler aufpassen. Dem package wird hohe Empfindlichkeit ohne molding nachgesagt, denn der interposer soll leicht bei ungleichmäßigem Druck brechen.

[Grendizer]

Ohne molding soll mann wohl ziemlich beim Wechsel der kühler aufpassen. Dem package wird hohe Empfindlichkeit ohne molding nachgesagt, denn der interposer soll leicht bei ungleichmäßigem Druck brechen.

Danke für die Info

[G3cko]

Gerade wieder das 2x im Mindstar für 609€. Ich warte aber ersteinmal ab bis die Wakü da ist. Die Bundels sind alle rechte unattraktiv.

[dargo]

Beim HBCC hat AMD noch etwas Arbeit vor sich. Ich finde HBCC aber sehr interessant. In einigen Spielen steigen die 99th Percentile um 20+% 15%. Und dann gibt es einen großen Unfall wie BF1 wo HBCC Off 50% 61% schneller ist als HBCC On. :freak:

Edit:
Haben CB und sonstige Reviewer eigentlich die Standard Benchmarks mit HBCC On oder Off durchgeführt? Blicke da noch nicht richtig durch.

[Dino-Fossil]

Edit:
Haben CB und sonstige Reviewer eigentlich die Standard Benchmarks mit HBCC On oder Off durchgeführt? Blicke da noch nicht richtig durch.

Da der HBCC standardmäßig auf aus steht bisher, sollten sie eigentlich ohne gebenched haben, oder?

[pixeljetstream]

Was die Fragen zum binning rasterizer usw. angeht, gibt es eigentlich nen extra thread für sowas
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11460294#post11460294

[Loeschzwerg]

Bei einem Package ohne Molding stand made in Taiwan, bei dem mit in Korea, ist das immer der Fall?

Es gibt von ASE in Taiwan zwei Standorte, Kaohsiung und ChungLi. In Korea gibt es ebenfalls einen.

Hier sind beide Packages aus Taiwan, aber vermutlich von unterschiedlichen Standorten:
http://www.tomshardware.de/vega-benchmarks-performance-leistungsaufnahme-temperaturen,testberichte-242382-3.html

Abseits der Empfindlichkeit dürfte es so oder so fast keine Auswirkungen haben.

[Cyphermaster]

Das könnte die teilweise erfolgte Warnung erklären, man solle extrem vorsichtig mit den Dingern umgehen - das dürften dann die ohne Molding gewesen sein. Aber warum sollte man das überhaupt weglassen? Zeitgründe? Die paar Cent für die Vergußmasse dürften es nicht gewesen sein.

[Loeschzwerg]

Zeitgründe? Die paar Cent für die Vergußmasse dürften es nicht gewesen sein.

Materialkosten alleine sicher nicht, aber der gesamte Prozess könnte durchaus ein Kostentreiber sein, je nach Stückzahl.

Vermutlich hat man aber einfach alle Kapazitäten zur Fertigung genutzt die verfügbar sind und eine Fabrik (oder Fertigungslinie/n) ist halt anders ausgestattet. Angepasste Verfahren und Maschinen werden für das Molding sicherlich benötigt (will man sich bestimmt nicht überall leisten, weil auch nicht zwingend nötig).

Schwer zu sagen, da fehlen mir leider die Einblicke.

[Cyphermaster]

Nächste Frage: Weiß irgendwer, wie viel mehr Strom (ungefähr) der HBM2 auf den aktuellen Spannungen mehr säuft, als geplant (http://www.pcgameshardware.de/Vega-Codename-265481/News/AMD-HBM2-Controller-Taktraten-1234291/)? Wenn man die ganzen Probleme zusammenzählt (Treiber, Spannung, Speichertakt,...) die Vega grade hat, wird glaube ich langsam klarer, warum die Mühle säuft wie ein russischer Bergarbeiter und trotzdem nicht überall auf Touren kommt.

[Dural]

Es wird vor allem eins Klar, HBM wurde von AMD völlig falsch eingeschätzt, obwohl NV schon seit einiger Zeit davon gewarnt hat das die hohen Erwartungen wohl nicht erfüllt werden.

Es würde mich nicht überraschen sollte AMD zurück rudern und plötzlich GDDR6 Karten bringen.

Und zu guter letzt, ich habe es euch ja immer gesagt und war einer der ersten der HBM auch kritisch angesehen hat. Damals wurde ich hier wegen meinen Aussagen noch zerrissen und HBM wurde als Wunder und Lösung für alle Probleme angesehen. :rolleyes:

[Cyphermaster]

HBM ist wohl kaum ein Problem per se - nur die bisherigen Taktraten. Daß eine Fertigungsprognose eines Zulieferers nicht hinkommt, ist nichts HBM-Spezifisches, sondern kann immer passieren. Auch bei GDDR6.

[HOT]

Also die maar MHz die da fehlen... ich glaub nicht, dass das den Bock fett macht.

[StefanV]

Das nicht, aber die 0,1V oder so mehr..

[dargo]

Es wird vor allem eins Klar, HBM wurde von AMD völlig falsch eingeschätzt, obwohl NV schon seit einiger Zeit davon gewarnt hat das die hohen Erwartungen wohl nicht erfüllt werden.

Es würde mich nicht überraschen sollte AMD zurück rudern und plötzlich GDDR6 Karten bringen.

Und zu guter letzt, ich habe es euch ja immer gesagt und war einer der ersten der HBM auch kritisch angesehen hat. Damals wurde ich hier wegen meinen Aussagen noch zerrissen und HBM wurde als Wunder und Lösung für alle Probleme angesehen. :rolleyes:
Du bist auch extrem kurzsichtig was das gesamte Programm von AMD angeht. Nvidia macht wie üblich nur das Nötigste für die aktuelle Gen. AMD plant schon weiter im voraus inkl. APUs.

[Isen]

Du bist auch extrem kurzsichtig was das gesamte Programm von AMD angeht. Nvidia macht wie üblich nur das Nötigste für die aktuelle Gen. AMD plant schon weiter im voraus inkl. APUs.

Ja... zu weit im Voraus, aber auch nötig, da Längerfristig geplant... NV kann sich kurzfristige Ziele leisten und ne Menge kompensieren.

[Dino-Fossil]

Naja, das Problem ist, dass sich AMD oft ein bisschen mit solchen Sachen verhebt, bzw. sie mehr kurzfristige Erfolge gebrauchen könnten als Projekte die sich erst in Jahren wirklich lohnen.
Rein wirtschaftlich wäre es daher, glaube ich, manchmal besser sie wären dabei ein wenig konservativer.

Wobei ich schätze, dass HBM heute besser dastünde, wenn nVidia (stärker) mitgezogen hätte.
Höhere Nachfrage hätte sicherlich dazu geführt, dass die Entwicklung und das Produktionsvolumen weiter wären.

[anddill]

Irgendwo schwirrte doch mal rum daß der HBM2 auf Vega mit 600MHz takten soll und damit mit 2 Stacks deutlich mehr Bandbreite bringen soll als die 4 500MHz HBM1-Stacks auf Fiji.
Dazu paßt daß Speicher-OC bei Vega in vielen Fällen die Karte deutlich beschleunigt. Das war sicher mit mehr Takt und weniger Volt geplant, als das was jetzt im Handel liegt.
Vielleicht hat AMD bis zuletzt gehofft doch noch die versprochenen 600MHz HBM2-Stacks zu bekommen, und hat daher den Launch so lange verzögert? Wobei das Treiber-Team sich sicher nicht über die zusätzliche Zeit geärgert hat :devil:

[dargo]

Nicht gut. :(

Grafikkarten: Preise für Videospeicher im August um 30 % gestiegen
https://www.computerbase.de/2017-08/videospeicher-preisanstieg-grafikkarten/

Ich hoffe das betrifft nicht zwangsläufig HBM2.

@anddill
Ich sehe aktuell nicht, dass RX Vega64 ein HBM2 mit 600Mhz erheblich beschleunigen würde.

https://www2.pic-upload.de/img/33752256/Zwischenablage32.jpg

Und 1630Mhz GPU ist schon ein hoher Takt der besonders von der Air nicht mit 100% PT gehalten wird. 600Mhz HBM2 würde vielleicht bei der AIO paar Prozentchen mehr bringen, aber nichts Weltbewegendes. Dem CB Test nach limitiert die Bandbreite überhaupt nicht, bzw. das Verhältnis zwischen Bandbreite und Rohleistung ist extrem gut ausbalanciert.

Edit:
4,4% mehr GPU-Takt resultieren in 1,6% mehr Leistung. 16,4% mehr Bandbreite resultieren in 3,5% mehr Leistung. Also vom Bandbreitenlimit sehe ich hier absolut nichts.

[Locuza]

Ursprünglich geplant und so wurde das auch von Speicherherstellern präsentiert, waren 1.000 Mhz (2Gbps) mit 1,2V Versorgungsspannung.
Die Vega 64 verwendet 945 Mhz mit scheinbar 1,35V.
Fiji hat seinen HBM1 (500 Mhz) auch mit 1,35V versorgt, da hat es auch schon nicht für die 1,2V Prognose gereicht.

Die Bandbreitentest belegen kein großes Limit, 16% (483 GB/s vs. 563 GB/s)) mehr bringen im Schnitt nur 3% mehr Leistung.
Watch Dogs 2 und Titanfall skalieren mit 6-7% überdurchschnittlich.

Mich verwirren aber zwei Taktergebnisse von CB.
Laut OC-Abschnitt haben sie es nicht geschafft den HBM2 von der Vega 56 über 950 Mhz zu takten, bei den Pro-Takt-Vergleichen geben sie aber 1000 Mhz an.
Wie hat man das ganze noch rausgekitzelt?

[Zergra]

Wieso 1,35V? Wenn ich bei Wattman gehe und dort auf custom, läuft der HBM auf 1,05V

[Cyphermaster]

@anddill
Ich sehe aktuell nicht, dass RX Vega64 ein HBM2 mit 600Mhz erheblich beschleunigen würde.

https://www2.pic-upload.de/img/33752256/Zwischenablage32.jpg

Und 1630Mhz GPU ist schon ein hoher Takt der besonders von der Air nicht gehalten wird. 600Mhz HBM2 würde vielleicht bei der AIO paar Prozentchen mehr bringen, aber nichts Weltbewegendes. Dem CB Test nach limitiert die Bandbreite überhaupt nicht, bzw. das Verhältnis zwischen Bandbreite und Rohleistung ist extrem gut ausbalanciert.

Edit:
4.4% mehr GPU-Takt resultieren in 1,6% mehr Leistung. 16,4% mehr Bandbreite resultieren in 3,5% mehr Leistung.Die 600MHz alleine wären es weniger, als eventuell weniger Spannung - denn nach allem, was bisher gemessen wurde, hängt Vega im Powerlimit. Weniger Verbrauch erlaubt höheren Takt, und der braucht dann auch wieder mehr Bandbreite.

[dargo]

Die Vega 64 verwendet 945 Mhz mit scheinbar 1,35V.

Was heißt jetzt genau "scheinbar"? Hat das denn einer gemessen?

Die 600MHz alleine wären es weniger, als eventuell weniger Spannung - denn nach allem, was bisher gemessen wurde, hängt Vega im Powerlimit. Weniger Verbrauch erlaubt höheren Takt, und der braucht dann auch wieder mehr Bandbreite.
Wenn der HBM2 um die 30-35W braucht (mir schwirren da diese Zahlen im Kopf, weiß aber nicht mehr wo das stand) dann ist das doch fast gar nichts im Vergleich zum Rest wo du am Ende bei ~295W landest. Der Hauptschlucker (und zwar im Übermaß) ist die GPU der hohe GPU-Takt.

Wieso 1,35V? Wenn ich bei Wattman gehe und dort auf custom, läuft der HBM auf 1,05V
Last oder Idle? Und wie verlässlich sind die ganzen Anzeigen? Wobei der Wattman es schon korrekt zeigen sollte.

[dargo]

doppelpost

[Zergra]

So wie ich das gedeutet habe ist das Last. Die anderen sind nicht einsehbar. Also geht's um state 4.

[anddill]

Ich hab gerade nochmal gegoogelt. Das mit den 600MHz was mir da im Kopf rumspukte habe ich nicht gefunden, dafür aber 700 (was wohl eher der Datentakt ist, also 350MHz Grundtakt). Und ich habe noch eine Aussage gefunden daß der Speichercontroller 1200MHz (Datentakt?) schafft. Vielleicht kommen die 600MHz daher.

ps: Zumindest HBM1 läuft mit konstantem Takt und damit auch Spannung. Wenn das bei HBM2 auch so ist (wovon ich ausgehe) und man sich mal die Idle-Leistungsaufnahme von Vega anschaut, dann kann der HBM2 incl. Controller max. um die 10W verbrauchen.

[Der_Korken]

Die 600MHz alleine wären es weniger, als eventuell weniger Spannung - denn nach allem, was bisher gemessen wurde, hängt Vega im Powerlimit. Weniger Verbrauch erlaubt höheren Takt, und der braucht dann auch wieder mehr Bandbreite.

Das Powerlimit bezieht sich bei AMD nur auf die GPU selbst, der Verbrauch der Speicherchips sollte da gar nicht mitzählen. Insofern würde sich am GPU-Takt nichts ändern, wenn der HBM auf 1,2V laufen würde (abgesehen davon, dass die Speicherchips weniger heiß würden).

Wieso 1,35V? Wenn ich bei Wattman gehe und dort auf custom, läuft der HBM auf 1,05V

Ich glaube die im Wattman angezeigte Spannung ist der Speichercontroller in der GPU. Bei meiner 470 steht da per Default auch 1000mV, aber das kann bei GDDR5 unmöglich stimmen, der liegt irgendwo bei 1,5V.

[dargo]

Das Powerlimit bezieht sich bei AMD nur auf die GPU selbst, der Verbrauch der Speicherchips sollte da gar nicht mitzählen.
Ist das wirklich so? Weil in dem Punkt blicke ich noch nicht durch. Was meint AMD genau mit Asicpower? Nur die GPU oder die gesamte Einheit, sprich GPU+HBM2?

[Der_Korken]

Ist das wirklich so? Weil in dem Punkt blicke ich noch nicht durch. Was meint AMD genau mit Asicpower? Nur die GPU oder die gesamte Einheit, sprich GPU+HBM2?

Ich ging bisher von GPU only aus, da es bei Polaris definitiv so war. Es kann natürlich sein, dass sich durch den Interposer was ändert, aber wenn der HBM schon in den 220W der Vega64 drin ist, frage ich mich, was dort dann weitere 75W verbraucht. Das werden ja wohl kaum die Wandlerverluste und der Lüfter allein sein.

[Mortalvision]

Umgangssprachlich ausgedrückt: die Elektronen werden erst fünfmal im Kreis durch den Chip gejagt, bevor sie da sind, wo sie hin sollen.

Technisch ausgedrückt: Schwächen in der Steuerung des Chips durch die Software, Schwächen in den internen Steuerwerken des Chips, und vermutlich eine 14nm Fertigung, die den Namen kaum verdient (sprich zu 80/90% 28nm, um das R&D Budget zu senken). Die Ideen von AMD sind alle samt und sonders zu loben. Für den Gamingbereich fehlt es aber hinten und vorne an der Umsetzung!

[Cyphermaster]

Wenn der HBM2 um die 30-35W braucht (mir schwirren da diese Zahlen im Kopf, weiß aber nicht mehr wo das stand) dann ist das doch fast gar nichts im Vergleich zum Rest wo du am Ende bei ~295W landest. Der Hauptschlucker (und zwar im Übermaß) ist die GPU der hohe GPU-Takt.Natürlich schluckt die GPU den Hauptteil. Aber die UV-/OC-Versuche zeigen, daß man bei Spannungsabsenkung an der GPU durchaus Takt bekommen kann, ohne daß die Karte gleich ein französisches AKW zum Qualmen bringt. Mit dem, was in den bisherigen Tests so stand, kommt man mit -0,1V praktisch jedes Mal hin, und landet dann stabil in der Region des Boosttaktes bei Stock-Verbrauch. Beim Übertakten hingegen hab ich bisher zwei Werte um die 1900Mhz gesehen, d.h. die aktuellen ~1600 Boost sind noch nicht Ende der Fahnenstange für die Leistung.

Das bedeutet unter dem Strich, daß jedes gesparte Watt auf der Karte Vega hinsichtlich des möglichen Taktes und damit nicht nur der Effizienz, sondern auch der maximalen Leistung gut tut (mehr oder weniger direkt). Bezüglich der Frage, wieviel an Leistungsplus genau dann dem Takt-Plus entspringt, sage ich angesichts des aktuell noch total desolaten Zustands der Treiber und der stark streuenden Performance in den Testparcours bewußt nichts. Daß aber wohl grundsätzlich noch was drin ist, zeigen ja schon die ersten Launchtests.

[24p]

Da glaube ich eher an den Auslesefehler als 1900MHz stabil.

[Dino-Fossil]

Ich frage mich, wie es in den Reviews angekommen wäre, hätte AMD die Karte mit etwas niedrigerem Takt gebracht, dafür ein paar mV Spannung gespart und eine RX Vega Referenz veröffentlicht, die zwar leicht hinter der 1080 liegt aber nur (relativ) wenig mehr Leistungsaufnahme hat - die Tests mit den Öko-Einstellungen zeigen ja, dass es potentiell möglich ist.

Was wäre der größere Fail in den Augen der Öffentlichkeit - 1080 Leistung bei exorbitantem Verbrauch oder 1080-x% bei nur mäßig höherem Verbrauch?
Ich schätze das hängt stark davon ab, woher der Reviewer kommt...

[Cyphermaster]

Da glaube ich eher an den Auslesefehler als 1900MHz stabil.
Wenn dem so wäre, würden sich die -mit den gleichen Programmen ausgelesenen- Daten in den Launch-Benchmarks allesamt ziemlich erübrigen.

[basix]

Ist das wirklich so? Weil in dem Punkt blicke ich noch nicht durch. Was meint AMD genau mit Asicpower? Nur die GPU oder die gesamte Einheit, sprich GPU+HBM2?

Ich finde gerade die Folie dazu nicht, aber AMD gibt ganz klar GPU+HBM an (z.B. im Balanced Modus die 220W)

[y33H@]

Nein, AMD spricht von "GPU Power" - auf dem Tech Day und im Reviewer's Guide. Wo sollen sonst auch 220W + 70W= 290W für die komplette Karte herkommen? Nur durch die Platine samt Wandlern?

[dargo]

Ich ging bisher von GPU only aus, da es bei Polaris definitiv so war. Es kann natürlich sein, dass sich durch den Interposer was ändert, aber wenn der HBM schon in den 220W der Vega64 drin ist, frage ich mich, was dort dann weitere 75W verbraucht. Das werden ja wohl kaum die Wandlerverluste und der Lüfter allein sein.
Würde ich bei 220W Asic Power nicht unbedingt ausschließen. Das Ding hat afaik 13 Phasen. Ich kann das aber schlecht einschätzen. 75W nur für die Wandler + Lüfter kommt mir auch etwas viel vor.

[dosenfisch24]

Vega Ergebnisse mit über 1900MHz sind ein Fehler. Die Karten laufen dann tatsächlich langsamer als Stock. Selbst mit LN2 sind wohl nur Taktraten im unteren 1800 MHz Bereich drin. Buildzoid hat das gerade in einem Youtubevideo (https://www.youtube.com/watch?v=m2-xZvv5wd8) abgehandelt.

[dargo]

Natürlich schluckt die GPU den Hauptteil. Aber die UV-/OC-Versuche zeigen, daß man bei Spannungsabsenkung an der GPU durchaus Takt bekommen kann, ohne daß die Karte gleich ein französisches AKW zum Qualmen bringt. Mit dem, was in den bisherigen Tests so stand, kommt man mit -0,1V praktisch jedes Mal hin, und landet dann stabil in der Region des Boosttaktes bei Stock-Verbrauch. Beim Übertakten hingegen hab ich bisher zwei Werte um die 1900Mhz gesehen, d.h. die aktuellen ~1600 Boost sind noch nicht Ende der Fahnenstange für die Leistung.

Ich kann dir nur raten... vergiss das mit den -100mV, du wirst nur enttäuscht sein. Das kann unter Umständen bei dem einen oder anderen Spiel ohne hohe Auslastung von Vega klappen. Wird aber nicht überall funktionieren. Und ich kann mir beim besten Willen nicht vorstellen, dass du für jedes einzelne Spiel ein separates UV-Maximum ausloten möchtest. AMD haut da nicht aus Jux und Dollerei um die 1,20V bei Takt X drauf. Es wird Workloads geben wo diese Spannung benötigt wird. Wenn AMD pauschal etwas mehr Spannung über alle Chips gibt um die Ausbeute zu erhöhen kannst du natürlich Glück, aber auch Pech haben. Je nachdem welche Güte du beim Chip erwischst.

Und, dass man beim UV mehr Boosttakt gewinnt sofern man ohne UV sich im PT-Limit befindet ist schon lange bei GCN der Fall. Ist jetzt nichts Neues. :)

Ich frage mich, wie es in den Reviews angekommen wäre, hätte AMD die Karte mit etwas niedrigerem Takt gebracht, dafür ein paar mV Spannung gespart und eine RX Vega Referenz veröffentlicht, die zwar leicht hinter der 1080 liegt aber nur (relativ) wenig mehr Leistungsaufnahme hat - die Tests mit den Öko-Einstellungen zeigen ja, dass es potentiell möglich ist.

Die Karte gibt es bereits, nennt sich Powersave-Modus. Die Reviewer müssen halt nur alle Möglichkeiten beim Test auch durchgehen.

[Bucklew]

Nein, AMD spricht von "GPU Power" - auf dem Tech Day und im Reviewer's Guide. Wo sollen sonst auch 220W + 70W= 290W für die komplette Karte herkommen? Nur durch die Platine samt Wandlern?
AMD hatte doch mal etwas von >35 GB/s pro W Leistungsaufnahme für HBM versprochen:
http://www.anandtech.com/show/9266/amd-hbm-deep-dive/4

Bei 480GB/s kommt man ja auf nicht mal 15W für den Speicher. 55W für Platine und Wandler klingt aber auch sehr hoch. Wäre ein Indiz dafür, dass die Ersparnis durch HBM in der Leistungsaufnahme weit davon entfernt ist, was AMD sich versprochen hat. Dafür spricht auch die erhöhte Spannung und die reduzierte Taktrate.

Das lässt den Vorteil HBM <-> GDDR5(X) massiv schrumpfen. GDDR5X für die GTX1080 (256 bit SI, 350 GB/s) liegt bei unter 20W:
http://www.anandtech.com/show/9883/gddr5x-standard-jedec-new-gpu-memory-14-gbps

[Der_Korken]

Das lässt den Vorteil HBM <-> GDDR5(X) massiv schrumpfen. GDDR5X für die GTX1080 (256 bit SI, 350 GB/s) liegt bei unter 20W:
http://www.anandtech.com/show/9883/gddr5x-standard-jedec-new-gpu-memory-14-gbps

Das ist dann aber nur die DRAM Power Consumption. Der Großteil des Verbrauchs entfällt allerdings auf die PHYs der GPU und das ist genau der Teil, wo HBM so extrem viel einspart. Es gibt ein nettes Diagramm von Nvidia (welches eigentlich zeigen sollte, dass HBM keine Zukunft hat, obwohl dort genau das Gegenteil abzulesen war), welches in den Speku-Thread etliche Male gepostet wurde und welches ich an meinem Heim-PC afaik auch bookmarked habe. Jedenfalls konnte man dort genau den Effekt sehen, dass der Verbrauch für die Speicherchips selbst kaum durch HBM sinken, dafür aber der GPU-seitige Verbrauch.

[iuno]

http://static1.gamespot.com/uploads/original/92/929129/3027242-4368030567-NV-HB.png
;)

[pilzsammler2002]

Edit:
Wurde ja schon gesagt...

[Cyphermaster]

Ich kann dir nur raten... vergiss das mit den -100mV, du wirst nur enttäuscht sein. Das kann unter Umständen bei dem einen oder anderen Spiel ohne hohe Auslastung von Vega klappen. Wird aber nicht überall funktionieren.Sollte man eigentlich annehmen, ja. Aber: Bisher ist das mit den -0,1V ein ziemlich durchgängiges Ergebnis bei den UV-Tests; sowohl bei der FE, als auch den RX64 und RX56. Da die die Karten dann auch auf diesen Settings erfolgreich durch ihre Spiele-Testparcours gejagt haben, spricht das für deutlich mehr als nur ein paar vereinzelte Gewinner bei der Silizium-Lotterie, wo das klappt.
Und, dass man beim UV mehr Boosttakt gewinnt sofern man ohne UV sich im PT-Limit befindet ist schon lange bei GCN der Fall. Ist jetzt nichts Neues. :)Ich sage nicht, daß es neu wäre, sondern daß in dieser Richtung anscheinend bei Vega noch nennenswert Potential besteht, d.h. zweistellige Prozentzahlen zum Basistakt.

[Dino-Fossil]

Die Karte gibt es bereits, nennt sich Powersave-Modus. Die Reviewer müssen halt nur alle Möglichkeiten beim Test auch durchgehen.

Weiß ich doch. Aber es ist schon ein Unterschied, ob eine Karte manuell erst in den Modus versetzt werden muss (noch dazu per Software,die z.B. unter Linux gar nicht existiert), oder ob das schon der offizielle default Modus ist.
Gerade wenn die Zeit knapp ist (und dafür kann ja hier primär AMD was) fällt der ganze Kram der ordentlich Zusatzaufwand macht halt hinten runter.

[dargo]

Sollte man eigentlich annehmen, ja. Aber: Bisher ist das mit den -0,1V ein ziemlich durchgängiges Ergebnis bei den UV-Tests; sowohl bei der FE, als auch den RX64 und RX56. Da die die Karten dann auch auf diesen Settings erfolgreich durch ihre Spiele-Testparcours gejagt haben, spricht das für deutlich mehr als nur ein paar vereinzelte Gewinner bei der Silizium-Lotterie, wo das klappt.

Nochmal... das sind doch keine Langzeittests, höchstens Kurzaufnahmen. Und ob jeder Reviewer da auch explizit nach Grafikfehlern den Bildschirm abgesucht hat bezweifle ich ebenfalls. Richtig albern wird es bei ein paar Loops im 3DMark. Für aussagekräftiges UV brauchst du mehrere Spielstunden je Game.

[Cyphermaster]

Die Karte gibt es bereits, nennt sich Powersave-Modus. Die Reviewer müssen halt nur alle Möglichkeiten beim Test auch durchgehen.Nope. Powersave limitiert nicht nur die Spannung, sondern auch weiterhin Takt und PT (afair). Die Einstellung mit nur abgesenkter Spannung, aber offenem PT (= die, die sich bezüglich Leistung@Stock-Verbrauch als am Besten in den Tests gezeigt hat) ist nicht über die BIOS-Modi einstellbar.

[Bucklew]

Das ist dann aber nur die DRAM Power Consumption. Der Großteil des Verbrauchs entfällt allerdings auf die PHYs der GPU und das ist genau der Teil, wo HBM so extrem viel einspart.
Da das SI ein bidirektionales Interface ist, kann ich mir nicht vorstellen, dass der PHY im Speicherbaustein so sparsam sein , aber in der GPU viel Leistung aufnehmen soll. Das ergibt IMHO wenig Sinn. Ich würde da eigentlich eine identische bzw. ähnliche Leistungsaufnahme auf beiden Seiten erwarten, so die Prozesse identisch sind. Micron GDDR5X ist aber wohl in 20nm gefertigt.

Fakt ist: Wenn die 70W für die Nicht-GPU bei RX Vega hinkommen, kann HBM2 einfach nicht so sparsam sein, wie AMD behauptet. Wo soll die Leistung denn verbraucht werden? Der Lüfter? ;D

[dargo]

Nope. Powersave limitiert nicht nur die Spannung, sondern auch weiterhin Takt und PT (afair). Die Einstellung mit nur abgesenkter Spannung, aber offenem PT (= die, die sich bezüglich Leistung@Stock-Verbrauch als am Besten in den Tests gezeigt hat) ist nicht über die BIOS-Modi einstellbar.
Ich spreche auch nicht vom "Gefrickel" sondern einfachen, verständlichen Sachen für den "08/15" Hans. Biosschalter ggf. umstellen (zweites Bios ist noch etwas sparsamer) und im Wattman entsprechendes Profil wählen. Beim Ausloten vom max. UV bei Takt X wirds für den Hans wesentlich komplizierter. Wer mit ersterem immer noch überfordert ist sollte sich vielleicht besser ne Konsole kaufen.

[Cyphermaster]

Nochmal... das sind doch keine Langzeittests, höchstens Kurzaufnahmen. Und ob jeder Reviewer da auch explizit nach Grafikfehlern den Bildschirm abgesucht hat bezweifle ich ebenfalls. Richtig albern wird es bei ein paar Loops im 3DMark. Für aussagekräftiges UV brauchst du mehrere Spielstunden je Game.
Deshalb spreche ich auch nicht schon von einer Garantie oder sowas, sondern einer Tendenz/Wahrscheinlichkeit. Natürlich braucht es zur Verifikation Zeit und mehr Karten zum Testen, die war aber nun mal noch nicht drin.
Und wir reden nicht nur über ein oder zwei Loops 3DMurks, sondern ganzen Testparcours; u.a. auch Spiele wie Doom, die Vega ganz offensichtlich ordentlich auslasten können. Das geht ja sogar noch zurück bis zur FE und professionellen Anwendungen, die man gefahren hat. Wenn so viele verschiedene Karten in so vielen verschiedenen Anwendungen und Spielen sich so ähnlich verhalten, kann man imho durchaus begründet in Frage stellen, daß das alles nicht reproduzierbare Zufälle wären.

[dargo]

Und wir reden nicht nur über ein oder zwei Loops 3DMurks, sondern ganzen Testparcours; u.a. auch Spiele wie Doom, die Vega ganz offensichtlich ordentlich auslasten können. Das geht ja sogar noch zurück bis zur FE und professionellen Anwendungen, die man gefahren hat.
Hast du schon mal gesehen wie lange so ein Benchmark pro Spiel im Test dauert? Über welche Zeit reden wir da? 60, 120, 180 Sekunden? Zum Thema Doom... da muss ich dich enttäuschen. Bei meinem Grenada damals war der Takt in Witcher 3 sogar geringfügig niedriger als in Doom @Vulkan bei gleichem PT-Limit. Sprich... die Karte hatte in Witcher 3 etwas mehr gesoffen.

[Hübie]

Er redet von Doom das Vega auslasten kann und du kommst mit Hawaii aka Grenada... :|

[=Floi=]

Du bist auch extrem kurzsichtig was das gesamte Programm von AMD angeht. Nvidia macht wie üblich nur das Nötigste für die aktuelle Gen. AMD plant schon weiter im voraus inkl. APUs.

aber bringen tut es nichts und mit GDDR5 fährt man aktuell bzw. seit 2 jahren noch ganz gut und günstiger. Das märchen vom HBM technologievorteil kannst auch in der schublade lassen.
hmb2 bringt es wohl erst ab 32gb und mehr. bei der transistorverschwendung am chip muss man sich auch fragen, warum es amd nicht schafft auch GDDR 5 zu bedienen.


Und NV setzt deshalb noch auf GDDR5, weil es mehr als ausreichend ist, funktioniert und günstiger ist. Breite verfügbarkeit in der masse ist eben mehr wert.

[dargo]

Er redet von Doom das Vega auslasten kann und du kommst mit Hawaii aka Grenada... :|
Und Grenada legt in Doom @Vulkan nicht zu oder wie? Bis zu 50% sogar. Nur weil eine Applikation die GPU stärker unter low level auslastet heißt es nicht automatisch, dass der Stromverbrauch dort am höchsten ist. Mehr wollte ich damit nicht sagen.

aber bringen tut es nichts und mit GDDR5 fährt man aktuell bzw. seit 2 jahren noch ganz gut und günstiger. Das märchen vom HBM technologievorteil kannst auch in der schublade lassen.
hmb2 bringt es wohl erst ab 32gb und mehr. bei der transistorverschwendung am chip muss man sich auch fragen, warum es amd nicht schafft auch GDDR 5 zu bedienen.

Ich sags ja... extrem kurzsichtige Sichtweise. Wie kommst du überhaupt auf die absurde Idee mit den 32GB oder mehr? In einer APU reichen dir schon 2GB HBM mit HBCC für 1080p wie AMD es vorgeführt hatte. Und da ging es um V10. Ich übertrage das auf eine APU mit ca. 2-3 TFLOPs. Also eher E-Sports Bereich bis Mainstream.

[Hübie]

Ach so. Für mein Verständnis ist eine höhere Auslastung mit mehr Energiebedarf einhergehend, da hier Bits bewegt werden und das kostet eben Energie (wenige pJ). :confused:
Da sind so viele interne Dinge, dass du das vor dem Bildschirm so gar nicht beurteilen kannst. Was ist wenn Witcher 3 mehr ALUs belastet, mehr Verbrauch voraus berechnet wird und die PCU so schon den Takt etwas senkt, während Doom mehr fixed function units belastet (die afaik weniger Energie verbrauchen).

[=Floi=]

Gibt es EINE APU mit GDDR?
warum sollte dann die küpplige APU dann auf die teure HBM lösung setzen?

Und am ende vom Tag hat HBCC noch immer nur die bandbreite des rams.

[dargo]

Ach so. Für mein Verständnis ist eine höhere Auslastung mit mehr Energiebedarf einhergehend, da hier Bits bewegt werden und das kostet eben Energie (wenige pJ). :confused:

Normalerweise ist es auch so. Der Takt beim Grenada war auch etwas tiefer @Vulkan gegenüber OpenGL. Der höhere Stromverbrauch muss aber nicht zwangsläufig quer über zwei verschiedene APIs in unterschiedlichen Games gelten.

Gibt es EINE APU mit GDDR?

Nicht am PC, Konsole ja.


warum sollte dann die küpplige APU dann auf die teure HBM lösung setzen?

Wer sagt, dass 2GB HBM2 @400Mhz so teuer ist? Vor allem wenn ich dadurch mit einem einzigen Stack 200GB/s Bandbreite bekomme?


Und am ende vom Tag hat HBCC noch immer nur die bandbreite des rams.
Was bitte?

[BoMbY]

Gibt es EINE APU mit GDDR?
warum sollte dann die küpplige APU dann auf die teure HBM lösung setzen?

Und am ende vom Tag hat HBCC noch immer nur die bandbreite des rams.

Klar, in XBone und PS4 gibt es APUs mit GDDR. Bei APUs für Desktops würde HBM Sinn machen, da es auf dem Package der APU sitzen könnte, und man könnte auch Mini-Boards komplett ohne RAM-Sockel bauen - GDDR5 müsste auf dem Mainboard verlötet werden, und nimmt relativ viel Platz weg.

[Hübie]

DRAM wird man dennoch benötigen, da der HBM hier eine Cache-Stufe darstellt.

[Cyphermaster]

Ich spreche auch nicht vom "Gefrickel" sondern einfachen, verständlichen Sachen für den "08/15" Hans. (...) Beim Ausloten vom max. UV bei Takt X wirds für den Hans wesentlich komplizierter.Warum sollte man denn unbedingt "Frickeln" müssen? Wenn sich zeigen sollte, daß die Karten durchgängig mit zu viel Sicherheitsaufschlag bei der Spannung gelauncht wurden, reicht eine Anpassung der BIOS-Parameter (ggf. was, was schon bei den Customs kommt?). Theoretisch könnte man das sogar jetzt schon und damit "auf Verdacht" machen, weil es über simples Zurückflashen reversibel ist.

Das bisher Setting PT offen, Spannung niedrig (Keine Ahnung, was "Powersave" aktuell setzt, wäre aber interessant, ob das die -0,1V oder weniger sind), Taktraten@Default liefert jedenfalls in allen bisherigen Versuchen über alle getesteten Karten und alle getestete Software bei ~Stock-Verbrauch knapp 10% mehr Performance im Mittel; bei und wegen stabil anliegendem Boost-Takt. Das wäre also den Werks-"Balanced"-Einstellungen vorzuziehen, und ist nicht gleich dem aktuellen "Powersave".

[dargo]

Bei APUs für Desktops würde HBM Sinn machen, da es auf dem Package der APU sitzen könnte, und man könnte auch Mini-Boards komplett ohne RAM-Sockel bauen - GDDR5 müsste auf dem Mainboard verlötet werden, und nimmt relativ viel Platz weg.
Das kann erst funktionieren wenn große Kapazitäten bei HBM2 massentauglich sind. Das dürfte noch etwas dauern. Der Zwischenschritt heißt DDR4 + kleiner HBM2 Speicher mit mindestens Vega IP wegen HBCC. Durch HBCC sparst du ja die Hälfte der Speicher Kapazität.

[Tesseract]

Ich sags ja... extrem kurzsichtige Sichtweise.

sry, aber in diesem fall ist das keine kurzsichtige sichtweise von nvidia sondern einfach ein resultat der gewaltigen kluft im R&D-budget. von den theoretischen vorteilen die HBM2 bietet hat vega nix umgesetzt: weder ist der speicherausbau wesentlich größer, noch ist die platine kleiner, noch ist die bandbreite wesentlich höher - ergo hat er nutzer absolut nix davon. der vorteil für AMD liegt darin, dass sie für die nächsten paar generationen den speichercontroller nicht groß umdesignen müssen, aber dieser vorteil wird dadurch negiert, dass nvidia es einfach tut und das HBM-design, wenn es dem user dann einen vortei bringt, trotzdem hat. an diesem misstand ist niemand anderes als AMDs (teilweise früheres) management schuld.

[Cyphermaster]

warum sollte dann die küpplige APU dann auf die teure HBM lösung setzen?

Und am ende vom Tag hat HBCC noch immer nur die bandbreite des rams.So wie bei Turbocache auch: Solange man nicht über den schnellen Speicher hinaus RAM braucht, ist so eine Lösung extrem viel schneller. Für die mit den paar CUs einer APU vernünftig zu fahrenden Auflösungen und Detailstufen dürfte der Bedarf an teurem HBM überschaubar sein - insbesondere mit HBCC, wie ja schon von AMD vorgeführt wurde (2GB fast so performant wie 4GB in DeusEx:MD, was bis zu FHD und damit P10/P20-Level reichen dürfte = mehr, als die APUs bringen).

[24p]

Wenn dem so wäre, würden sich die -mit den gleichen Programmen ausgelesenen- Daten in den Launch-Benchmarks allesamt ziemlich erübrigen.

Naja, war dem nicht auch so. Im THG Review gibt es einen Kommentar in die Richtung, dass man die aktuellen Werte nicht für voll nehmen kann.

http://www.tomshardware.de/vega64-wasserkuhlung-benchmarks-temperaturen-ubertaktung,testberichte-242383.html

[Cyphermaster]

Wir können ja alle Diskussionen einstellen, bis sich in einigen Wochen herauskristallisiert hat, ob die Daten stimm(t)en... ;)

[24p]

Oder auch einfach mal einsehen, dass die 1,9 GHz fraglich sind, anstatt sich und seinen Bias hinter Ironie zu verstecken. ;)

[MadPenguin]

http://www.pcgameshardware.de/Radeon-RX-Vega-64-Grafikkarte-266623/Specials/HBCC-Gaming-Benchmark-1236099/

Alle HBCC aktivieren :)
Vielleicht zaubert AMD wirklich innerhalb Weihnachten einen Wundertreiber :)

[iuno]

Naja, war dem nicht auch so. Im THG Review gibt es einen Kommentar in die Richtung, dass man die aktuellen Werte nicht für voll nehmen kann.

http://www.tomshardware.de/vega64-wasserkuhlung-benchmarks-temperaturen-ubertaktung,testberichte-242383.html

So wie ich das verstehe, geht es nicht um den tatsaechlich anliegenden Takt, sondern um den angegebenen Boosttakt. Bei der RX Vega ist man da von DPM State 7 auf 6 runtergegangen. So wird die V64 etwa mit 1546 MHz Boosttakt beworben obwohl das Maximum (ohne OC) bei 1670 MHz liegt.

[|MatMan|]

Durch HBCC sparst du ja die Hälfte der Speicher Kapazität.
Das ist bislang völlig unbewiesen. Es gibt nur eine AMD Demo dazu, ohne harte Zahlen. Es ist überhaupt nicht klar, dass man bei jedem Spiel / jeder Anwendung mit der Hälfte des nominellen Speichers auskommt. Der DSBR sah auf den AMD Werbefolien auch gut aus. Ebenso wurde der Gaming Treiber ordentlich gehypt und heraus kam Ernüchterung. Daher wäre ich auch beim HBCC erstmal vorsichtig. Leider kann man die HBC-Größe nicht per Treiber reduzieren, was vernünftige Tests aktuell sehr schwierig macht (welches Game braucht schon 16GB Speicher?).

Selbst wenn deine Annahme stimmt, müsste man bei 2GB HBCC mindestens 4GB normalen System-RAM reservieren (schön bei PCGH beschrieben). Die müssten also zusätzlich verbaut werden, d.h. 8 GB System-RAM sind zu wenig und 16 GB RAM an sich Pflicht - was wieder mehr kostet. Ob das den OEMs so gefällt? Für eine Highend APU sicher kein Problem. Für den Massenmarkt halte ich das für sehr fragwürdig.

[dargo]

http://www.pcgameshardware.de/Radeon-RX-Vega-64-Grafikkarte-266623/Specials/HBCC-Gaming-Benchmark-1236099/

Alle HBCC aktivieren :)
Vielleicht zaubert AMD wirklich innerhalb Weihnachten einen Wundertreiber :)
Das hatte sich CB auch schon angeschaut. Nur komischerweise hats keinen interessiert. Hinter HBCC steckt viel Potential, besonders bei den wichtigeren 99th Percentile. Nur funktioniert der aktuell noch nicht optimal querbeet über mehrere Spiele. Wahrscheinlich ist er deshalb aktuell noch per Default deaktiviert.

sry, aber in diesem fall ist das keine kurzsichtige sichtweise von nvidia sondern einfach ein resultat der gewaltigen kluft im R&D-budget. von den theoretischen vorteilen die HBM2 bietet hat vega nix umgesetzt: weder ist der speicherausbau wesentlich größer, noch ist die platine kleiner, noch ist die bandbreite wesentlich höher - ergo hat er nutzer absolut nix davon.
Für was braucht Nvidia in naher Zukunft HBM im Gamingsektor? Nvidia hat im Bereich APUs (x86) nichts zu bieten. Und warum nimmt Nvidia im Profibereich seit GP100 kein GDDR5x? Oh wait...


Selbst wenn deine Annahme stimmt, müsste man bei 2GB HBCC mindestens 4GB normalen System-RAM reservieren (schön bei PCGH beschrieben). Die müssten also zusätzlich verbaut werden, d.h. 8 GB System-RAM sind zu wenig und 16 GB RAM an sich Pflicht - was wieder mehr kostet. Ob das den OEMs so gefällt? Für eine Highend APU sicher kein Problem. Für den Massenmarkt halte ich das für sehr fragwürdig.
Wieso muss ich 4GB beim Systemspeicher bei einer hypothetischen APU mit 2GB Vram reservieren? Afaik reichen 2GB um auf theoretische 4GB Vram zu kommen. In dem Fall reichen 8GB Systemspeicher noch aus für eine APU die Low-End bis Mainstream abdeckt. In diesem Bereich schlummern aktuell P11/P12 und GP107. Diese Karten gibt es ab 2GB.

[|MatMan|]

Wieso muss ich 4GB beim Systemspeicher bei einer hypothetischen APU mit 2GB Vram reservieren? Afaik reichen 2GB um auf theoretische 4GB Vram zu kommen. In dem Fall reichen 8GB Systemspeicher noch aus für eine APU die Low-End bis Mainstream abdeckt. In diesem Bereich schlummern aktuell P11/P12 und GP107. Diese Karten gibt es ab 2GB.
Ok, ich nehm es zurück. Hab die Artikel nochmal gelesen und das beim ersten mal lesen etwas anders aufgefasst. Üblicherweise ist ein Cache nur ein Zwischenspeicher, in dem eine Kopie der Daten aus dem eigentlichen Speicher liegt. Werden Daten in den Texturcache einer GPU geladen, werden sie ja nicht aus dem VRAM gelöscht.
Beim HBCC scheint es aber tatsächlich so zu sein, dass die Daten erst aus dem HBC in den System-RAM geschrieben werden müssen, bevor neue Daten aus dem System-RAM nachgeladen werden können (wenn der HBC voll ist). Wäre sonst auch etwas verschwenderisch :D

Davon abgesehen wären 2GB für eine zukünftige Highend-APU nicht mehr zeitgemäß, auch wenn man aktuell GPUs in dem Leistungsbereich kaufen kann.

[Locuza]

Was heißt jetzt genau "scheinbar"? Hat das denn einer gemessen?
[...]
Das habe ich von der Vega FE so in Erinnerung, laut GamerNexus sind es bei einer RX Vega 56 1,3V:
Other changes to the card are also present and probe-able, like HBM2 being volted at 1.3V on V56 (rather than 1.35 on VFE), limiting clocks to 800MHz stock and ~980MHz overclocked. Of course, mileage will vary per unit, but we were doing ~1100MHz with VFE. Vcore now maxes out at 1.2V as well, rather than the 1.25V of VFE previously. Granted, we’re bumping into a power limit first.
http://www.gamersnexus.net/hwreviews/3020-amd-rx-vega-56-review-undervoltage-hbm-vs-core

[Cyphermaster]

Oder auch einfach mal einsehen, dass die 1,9 GHz fraglich sind, anstatt sich und seinen Bias hinter Ironie zu verstecken. ;)Natürlich ist das zu einem Teil fraglich, wie der Rest der (ersten) Daten aus den Tools auch. Ist nicht umsonst Speku-Subforum hier ;). Es ist aber stärker biased, wenn man bei mehreren Datensätzen, die mit ein und demselben Tool gemessen wurden, trotzdem von vorn herein und ohne weitere Anhaltspunkte unterschiedliche Zuverlässigkeiten annimmt. Mir geht im Übrigen garantiert keiner ab, wenn Vega 2,x GHz schafft, und ich geh nicht heulen, wenn die 1,6GHz in Wirklichkeit nur 1,4 GHz sind. Wär Vega nicht als Architektur so neu und anders, würde mich der Chip überhaupt nicht interessieren.

[dargo]

Davon abgesehen wären 2GB für eine zukünftige Highend-APU nicht mehr zeitgemäß, auch wenn man aktuell GPUs in dem Leistungsbereich kaufen kann.
Ich sprach von keiner High-End APU mit 2-3 TFLOPs.

[basix]

Raven Ridge soll 704 Shader Cores habe. 2 TFLOPs erreicht man also mit ca. 1.42 GHz.

[Pick]

http://www.pcgameshardware.de/Radeon-RX-Vega-64-Grafikkarte-266623/Specials/HBCC-Gaming-Benchmark-1236099/

Alle HBCC aktivieren :)

Ja, 2% im Deus Ex MD.

Aber... Wo sind die versprochenen +50% Ergebnisse?
https://www.techpowerup.com/img/17-02-28/b694ac8550f0.jpg

[dargo]

Dafür musst du 6GB von deinem HBM2 Speicher entfernen. :D

Spaß... ;) einfach zuhören was Raja da erzählt.
https://www.youtube.com/watch?v=85ProuqAof0

[=Floi=]

Durch HBCC sparst du ja die Hälfte der Speicher Kapazität.

die 16GB ram kaufst du mir dann?
Du als user sparst dir im grunde nichts, weil du auch den ram vorhalten und somit kaufen musst.
Das sind auch ~100€ mehr auf der rechnung!

edit
nebenbei belastest du bei dual channel den ram controller zusätzlich, und hier ist intel das beste beispiel, dass dann auch die cpu performance eklatant einbrechen kann.

[N0Thing]

Mich würde auch mal interessieren, ob HBCC mit 16GB RAM sinnvoll und nutzbringend eingesetzt werden können. Soweit ich das bisher gesehen habe, steckte in den Testrechnern immer 32GB, oder?

[Digidi]

Die Story ist größer als nur ES vs Retail ...
Die Storry muss Mega sein das sie noch nicht draußen ist ;)

[|MatMan|]

Ich sprach von keiner High-End APU mit 2-3 TFLOPs.
:confused: Wer außer Highend-Käufern sollte sonst den Aufpreis für HBM bei ner APU bezahlen und wofür??

[HOT]

die 16GB ram kaufst du mir dann?
Du als user sparst dir im grunde nichts, weil du auch den ram vorhalten und somit kaufen musst.
Das sind auch ~100€ mehr auf der rechnung!

edit
nebenbei belastest du bei dual channel den ram controller zusätzlich, und hier ist intel das beste beispiel, dass dann auch die cpu performance eklatant einbrechen kann.

http://www.pcgameshardware.de/Radeon-RX-Vega-64-Grafikkarte-266623/Specials/HBCC-Gaming-Benchmark-1236099/

Sind wir jetzt fertig, einen handfesten Vorteil als Nachteil umzudeuten? Wer sagt denn, dass man 16GB zuweisen muss... so ein Schwachsinn, echt...

[Cyphermaster]

Ein einzelner HBM-Stack wäre wohl kaum besonders teuer, würde aber übliche Anwendungen wie 2D, Video usw. immens beschleunigen können. Mit 2GB und HBCC dürfte im Rahmen der verbauten CUs ausreichend Dampf für bis zu FHD (nicht die höchsten Details, nicht die höchsten FPS, aber ausreichend) sein. SOHO, Video, Surfen und ab und an ein Casual Game, da ist doch genau das Nutzungsfester für solche APUs. Mit den 16 CUs bzw. 1024 Shadern für die kolportierte große Lösung (die "Mandolin" mit 11 CUs und 800MHz ist dann wohl eher nur für's Büro) trifft sich das auch grob mit dem Leistungslevel einer RX 460 (je nach endgültigem Takt), die für solche Zwecke auch beworben wurde (bzw. als RX 560 wird).

[dargo]

die 16GB ram kaufst du mir dann?

Welche 16GB? :facepalm:

:confused: Wer außer Highend-Käufern sollte sonst den Aufpreis für HBM bei ner APU bezahlen und wofür??
Ich liebe diese Fragen. Dann erzähle mir mal wie teuer eine 2TFLOPs APU mit 4C/8T auf CPU-Seite und 2GB HBM2 @400Mhz mit einem Stack ist? Dann können wir erstmal über Preise gegenüber einem Ryzen 5 1400 bis 1500X und einer dedizierten Grafikkarte X reden.

[Dural]

Selbst für APU ist HBM derzeit völlig uninteressant.

HBM kann man derzeit nur einsetzten wenn es um maximale Leistung geht, alles andere ist nicht rentabel.

[VooDoo7mx]

Also zu mindestens für eeine Notbook APU brauch kein HBM, die haben eh schon immer extra schnelle dedizierte GPUs wie die Radeon M445 verbaut(quasi der 27. Oland Rerererererebrand), die reichen locker aus um das schmucke 1366x768 TN Display zu befeuern. ;)

[dildo4u]

Buildzoid hat hier erwähnt das HBM bei AMD extrem Effektiv ist und das der Core einfach Absurd viel Power zieht.Er spekuliert das wenn AMD versucht hätte das Polaris Interface aufzublasen es noch katastrophaler gewesen wäre.

https://youtu.be/ejVNhOvwtuI?t=16m3s

[tm0975]

hatten wir das hier schon? auf der hauptseite sind siherlich noch die alten werte...

http://www.it-times.de/news/amd-veroffentlicht-neues-softwarepaket-fur-das-mining-von-kryptowahrungen-125370/

[Loeschzwerg]

Buildzoid hat hier erwähnt das HBM bei AMD extrem Effektiv ist und das der Core einfach Absurd viel Power zieht.Er spekuliert das wenn AMD versucht hätte das Polaris Interface aufzublasen es noch katastrophaler gewesen wäre.

https://youtu.be/ejVNhOvwtuI?t=16m3s

Um das zu erkennen sollten wir hier eigentlich kein Buildzoid Video benötigen :freak:

[|MatMan|]

Ein einzelner HBM-Stack wäre wohl kaum besonders teuer, würde aber übliche Anwendungen wie 2D, Video usw. immens beschleunigen können. Mit 2GB und HBCC dürfte im Rahmen der verbauten CUs ausreichend Dampf für bis zu FHD (nicht die höchsten Details, nicht die höchsten FPS, aber ausreichend) sein. SOHO, Video, Surfen und ab und an ein Casual Game, da ist doch genau das Nutzungsfester für solche APUs. Mit den 16 CUs bzw. 1024 Shadern für die kolportierte große Lösung (die "Mandolin" mit 11 CUs und 800MHz ist dann wohl eher nur für's Büro) trifft sich das auch grob mit dem Leistungslevel einer RX 460 (je nach endgültigem Takt), die für solche Zwecke auch beworben wurde (bzw. als RX 560 wird).
HBM braucht man für übliche 2D Anwendungen? Läuft dann Word oder SAP schneller?? Um ein Video abzuspielen braucht man jetzt auch unbedingt HBM? Das ist doch wohl nicht dein Ernst?

Ansonsten bleiben also nur wieder die (Gelegenheits-) Spiele übrig.
Eine RX 460 hat 112 GB/s Bandbreite. Da wäre ein HBM Stack mit ~200 GB/s etwas Overkill.

Ich liebe diese Fragen. Dann erzähle mir mal wie teuer eine 2TFLOPs APU mit 4C/8T auf CPU-Seite und 2GB HBM2 @400Mhz mit einem Stack ist? Dann können wir erstmal über Preise gegenüber einem Ryzen 5 1400 bis 1500X und einer dedizierten Grafikkarte X reden.
Mir geht es darum, dass der HBM Zusatzkosten verursacht, selbst wenn es nur 10$ in der Herstellung sind (Zahl aus der Luft gegriffen). Eine APU damit muss einen entsprechenden Mehrwert gegenüber einer APU ohne HBM bieten - und das im Massenmarkt, damit es ein erfolgreiches Produkt wird.
Ich finde eine APU mit HBM technisch auch interessant, nur sehe ich dafür nicht mehr als eine Nische wie Intels GTe Varianten.

[dargo]

Etwa Faktor 5-6 bei der Bandbreite gegenüber DDR4 Dual Channel ist für dich kein entsprechender Mehrwert?

HBM braucht man für übliche 2D Anwendungen? Läuft dann Word oder SAP schneller?? Um ein Video abzuspielen braucht man jetzt auch unbedingt HBM? Das ist doch wohl nicht dein Ernst?

Bei dir gibt es nur Bürorechner, Performance und High-End oder? Ab sofort kann AMD und Nvidia alles unter Polaris und GP106 einstellen, die Welt braucht es nicht. Vor nicht allzu langer Zeit konnte sich auch noch keiner vorstellen wie erfolgreich CPUs mit IGP sein können. Heute sehen wir die Auswirkungen.


Eine RX 460 hat 112 GB/s Bandbreite. Da wäre ein HBM Stack mit ~200 GB/s etwas Overkill.

Wie willst du das bei HBM sonst skalieren? Einen halben Stack? Drei Viertel vielleicht? :freak: Die 200GB/s ergeben sich nun mal aus dem langsamsten HBM2 je Stack. Es gab mal Gerüchte über einen lowkost HBM. Vielleicht kommt da noch was mit weniger Frequenz als 400Mhz. Oder man nimmt dafür den kompletten "Abfall" der nicht mal die 400Mhz schafft. Nvidia verwendet beim GP100 HBM2 mit 360Mhz. Also scheint es langsamere HBM2 Speicher zu geben. Oder läuft der nur nicht mit der max. Frequenz? Da bin ich jetzt überfragt.

[Der_Korken]

Ansonsten bleiben also nur wieder die (Gelegenheits-) Spiele übrig.
Eine RX 460 hat 112 GB/s Bandbreite. Da wäre ein HBM Stack mit ~200 GB/s etwas Overkill.


Mir geht es darum, dass der HBM Zusatzkosten verursacht, selbst wenn es nur 10$ in der Herstellung sind (Zahl aus der Luft gegriffen). Eine APU damit muss einen entsprechenden Mehrwert gegenüber einer APU ohne HBM bieten - und das im Massenmarkt, damit es ein erfolgreiches Produkt wird.
Ich finde eine APU mit HBM technisch auch interessant, nur sehe ich dafür nicht mehr als eine Nische wie Intels GTe Varianten.

Für APUs würde ein "halber" Stack reichen, der nur halbe Busbreite, halbe Herstellungskosten und entsprechend halbe Bandbreite (100GB/s bei 800Mhz, später theoretisch mehr) mitbringt. Eventuell nutzt Ryzen irgendwann auch HBM als L4-Cache, sodass sowohl CPU als auch GPU profitieren würden. Aber sowas sehen wir wenn überhaupt wohl erst mit Ryzen 2 und Navi.

[Cyphermaster]

HBM braucht man für übliche 2D Anwendungen? Läuft dann Word oder SAP schneller?? Um ein Video abzuspielen braucht man jetzt auch unbedingt HBM? Das ist doch wohl nicht dein Ernst?Tja, dann sind auch SSDs oder USB3 für solche Rechner wohl totaler Unfug. Bringt ja alles nix, und brauchen tut man es auch nicht, man kann ja billig HDD+USB2 nehmen...

Natürlich hilft schneller Grafikspeicher auch in 2D. Ob du nun mehr FPS in einem 3D-Shooter hast, oder einen flüssigeren Bildaufbau/Bildwechsel beim Switchen von Tab zu Tab (grade, wenn es nicht nur ein oder zwei sind, sondern eine Onlinerecherche mit Dutzenden), dem Durchscrollen eines langen Dokuments oder das Umschalten zwischen PowerPoint-Folien. Und das sind wirklich nur die simpelst möglichen Ansätze, also nix mit CPU-Geschichten, die man mittlerweile auch auf die GPU auslagern kann.
Mir geht es darum, dass der HBM Zusatzkosten verursacht, selbst wenn es nur 10$ in der Herstellung sind (Zahl aus der Luft gegriffen). Eine APU damit muss einen entsprechenden Mehrwert gegenüber einer APU ohne HBM bieten - und das im Massenmarkt, damit es ein erfolgreiches Produkt wird.Nimm eine APU, die gute CPU-Leistung bringt, aber zum Zocken nix reißt - dann kannst du entweder eine extra Karte oder eine Konsole zukaufen. Teurer als der HBM-Aufpreis. Oder nimm eine APU, mit der du dank HBM auf einem günstigen APU-Client bestimmte GPU-beschleunigte Arbeiten erledigen kannst, für die man sonst eine Workstation bräuchte. Auch der Preisunterschied ist größer als die paar Euro für etwas HBM. Dazu kommt noch AMD-seitig, daß eine durchgehende Vega-Linie natürlich nur eine statt mehrere Architekturen braucht und nur eine statt mehrere Treiberschienen (was die Architekturanpassungen angeht, Pro vs. Gaming vs. Mining wird natürlich bleiben) zu entwickeln und supporten ist. Spart fühlbar Entwicklungskosten, verbilligt die Produkte.

[aufkrawall]

Für 2D-Beschleunigung reichen Lowend-GPUs in Smartphones und entsprechend sogar Intel-IGPs ohne EDRAM.

[basix]

Low-Cost HBM war mit 512 Datenleitungen und 200 GB/s im Gespräch. Für eine 1024 Shader APU schon Overkill, aber man kann ja den Takt reduzieren. Da muss es auch gar nicht zwingend ein Si-Interposer sein sondern ein normales Substrat.

2GB HBM wären für eine APU wirklich perfekt. Inkl. HBCC genug für alle Games und Anwendungen in diesem Leistungsbereich (vor allem wenn die CPU auch vom HBM profitieren kann). Zudem kann man dann auch langsameren DDR4 nehmen, um die gewünschte Performance zu erreichen (günstigere Systemkosten, geringerer Stromverbrauch). Das kompensiert unter dem Strich evtl. die Kosten des HBM Stacks bei zusätzlichen Vorteilen.

[Fragman]

frueher hat man noch games angefuehrt, die von guten 2d karten profitiert haben, wie quake zb, das war ein guter benchmark. :D

[reaperrr]

Low-Cost HBM war mit 512 Datenleitungen und 200 GB/s im Gespräch.
Ob das dann auch so mit vernünftigen Yields, Volumen und Kosten produziert werden kann muss man abwarten, aber für etwas der Leistungsklasse Vega 56 wäre diese Lösung natürlich sinnvoll (fast gleiche Bandbreite zu deutlich geringeren Kosten).

[=Floi=]

http://www.pcgameshardware.de/Radeon-RX-Vega-64-Grafikkarte-266623/Specials/HBCC-Gaming-Benchmark-1236099/

Sind wir jetzt fertig, einen handfesten Vorteil als Nachteil umzudeuten? Wer sagt denn, dass man 16GB zuweisen muss... so ein Schwachsinn, echt...


zitat
Wir beschränkten uns einstweilen auf das niedrigste Setting, welches 11729 MiByte Grafikspeicher bereitstellt


naja, 8gb umgelegt auf 2x4 macht doch eigentlich wenig sinn und 2x8 sind eben die 16gb im zusätzlichen ausbau.
leute, das ist auch ne quad channel platform.

[|MatMan|]

Etwa Faktor 5-6 bei der Bandbreite gegenüber DDR4 Dual Channel ist für dich kein entsprechender Mehrwert?
Wenn die dazugehörige GPU die Bandbreite nicht vernünftig nutzen kann, ist das für mich tatsächlich kein Mehrwert.

Bei dir gibt es nur Bürorechner, Performance und High-End oder? Ab sofort kann AMD und Nvidia alles unter Polaris und GP106 einstellen, die Welt braucht es nicht. Vor nicht allzu langer Zeit konnte sich auch noch keiner vorstellen wie erfolgreich CPUs mit IGP sein können. Heute sehen wir die Auswirkungen.
Bei dir gibt es scheinbar nur den Gaming-Markt. Über die Hälfte des PC Marktes sind Laptops. Dafür muss die APU optimiert sein, am besten noch für die 15W Klasse. Dementsprechend ist auch die GPU Leistung und deren Bandbreitenbedarf -> nichts was HBM erzwingen würde.

Daher macht meiner Meinung nach, wenn dann nur eine "Highend-APU" Sinn, also im Leistungsbereich einer einer RX 570/580. Dazu würden dann auch gut die ~200 GB/s passen. Nur ist dafür aus AMD Sicht wahrscheinlich der Markt zu klein und damit R&D Aufwand sowie Risiko zu groß.

Wie willst du das bei HBM sonst skalieren? Einen halben Stack? Drei Viertel vielleicht? :freak: Die 200GB/s ergeben sich nun mal aus dem langsamsten HBM2 je Stack. Es gab mal Gerüchte über einen lowkost HBM. Vielleicht kommt da noch was mit weniger Frequenz als 400Mhz. Oder man nimmt dafür den kompletten "Abfall" der nicht mal die 400Mhz schafft. Nvidia verwendet beim GP100 HBM2 mit 360Mhz. Also scheint es langsamere HBM2 Speicher zu geben. Oder läuft der nur nicht mit der max. Frequenz? Da bin ich jetzt überfragt.
Eben weil sich HBM aktuell nicht so skalieren lässt, sehe ich keinen Sinn darin ihn zu verbauen. Wenn es irgendwann eine low-cost Variante gibt, sieht das anders aus. Sehe ich ähnlich wie Der_Korken / basix.

Tja, dann sind auch SSDs oder USB3 für solche Rechner wohl totaler Unfug. Bringt ja alles nix, und brauchen tut man es auch nicht, man kann ja billig HDD+USB2 nehmen...
Ganz im Gegenteil, von SSD und USB3 merkt jeder Nutzer im Alltag sofort etwas. Von der 5-fachen Bandbreite des GPU Speichers eben lange nicht jeder.

Natürlich hilft schneller Grafikspeicher auch in 2D. Ob du nun mehr FPS in einem 3D-Shooter hast, oder einen flüssigeren Bildaufbau/Bildwechsel beim Switchen von Tab zu Tab (grade, wenn es nicht nur ein oder zwei sind, sondern eine Onlinerecherche mit Dutzenden), dem Durchscrollen eines langen Dokuments oder das Umschalten zwischen PowerPoint-Folien. Und das sind wirklich nur die simpelst möglichen Ansätze, also nix mit CPU-Geschichten, die man mittlerweile auch auf die GPU auslagern kann.
Sorry das ist einfach nur Unsinn. Such doch bitte mal Tests heraus, wo Powerpoint Folien oder Tabs schneller umschalten, weil die IGP/GPU schnelleren Speicher hat.

Nimm eine APU, die gute CPU-Leistung bringt, aber zum Zocken nix reißt - dann kannst du entweder eine extra Karte oder eine Konsole zukaufen. Teurer als der HBM-Aufpreis. Oder nimm eine APU, mit der du dank HBM auf einem günstigen APU-Client bestimmte GPU-beschleunigte Arbeiten erledigen kannst, für die man sonst eine Workstation bräuchte. Auch der Preisunterschied ist größer als die paar Euro für etwas HBM. Dazu kommt noch AMD-seitig, daß eine durchgehende Vega-Linie natürlich nur eine statt mehrere Architekturen braucht und nur eine statt mehrere Treiberschienen (was die Architekturanpassungen angeht, Pro vs. Gaming vs. Mining wird natürlich bleiben) zu entwickeln und supporten ist. Spart fühlbar Entwicklungskosten, verbilligt die Produkte.
Sehe ich genauso, nur soll dann die APU auch so viel GPU Power haben, das es lohnt (siehe "Highend-APU" oben). RX 460 Leistung reicht IMO nicht um was zu reißen, also einen wirklichen Unterschied zu aktuellen APUs / IGP zu haben. Das heißt aber auch, dass man mindestens 2 APUs entwickeln müsste. Eine günstige für die Masse sowie eine teurere und schnellere.

Dass Vega IP in APUs kommt steht fest. Vega bedingt aber nicht den HBCC (den man eh abschalten kann) und sicher auch nicht HBM. Das ist also kein Argument.

[Kriton]

So wie ich das verstehe, geht es nicht um den tatsaechlich anliegenden Takt, sondern um den angegebenen Boosttakt. Bei der RX Vega ist man da von DPM State 7 auf 6 runtergegangen. So wird die V64 etwa mit 1546 MHz Boosttakt beworben obwohl das Maximum (ohne OC) bei 1670 MHz liegt.

Das kommt IMHo daher, dass AMD nicht mehr den Maximalboost angibt (wie früher), sondern den durchschnittlichen/zu erwartenden (eher wie Nvidia).

[Cyphermaster]

zitat
Wir beschränkten uns einstweilen auf das niedrigste Setting, welches 11729 MiByte Grafikspeicher bereitstellt= 8GB Karten-HBM + 3GB RAM?

[Der_Korken]

zitat
Wir beschränkten uns einstweilen auf das niedrigste Setting, welches 11729 MiByte Grafikspeicher bereitstellt

Bedeutet das, dass zusätzlich 11GB RAM reserviert werden oder dass es inklusive HBM dann insgesamt 11GB sind (also nur 3GB extra RAM)? Ersteres wäre irgendwie bescheuert, was soll ich denn mit 19GB VRAM als Minimum? ;D

[Cyphermaster]

Das heißt aber auch, dass man mindestens 2 APUs entwickeln müsste. Eine günstige für die Masse sowie eine teurere und schnellere.Bisher munkelt man doch von einer APU mit 11CU Vega (--> "Masse"?) und einer 16CU-Version, also Shaderausbau ungefähr wie RX460 bzw. RX560. Wenn die 16CU-Version nicht zu lahm getaktet wird, könnte das für das eine oder andere Spielchen auf FHD reichen, oder nicht?

[dargo]

Sehe ich genauso, nur soll dann die APU auch so viel GPU Power haben, das es lohnt (siehe "Highend-APU" oben). RX 460 Leistung reicht IMO nicht um was zu reißen, also einen wirklichen Unterschied zu aktuellen APUs / IGP zu haben. Das heißt aber auch, dass man mindestens 2 APUs entwickeln müsste. Eine günstige für die Masse sowie eine teurere und schnellere.

Das ist doch Bestandteil der ganzen Diskussion. :confused: Der letzte Spekulationsstand war ca. 170mm² APU mit DDR4 Controller und ca. 210mm APU mit DDR4 Controller + HBM.


= 8GB Karten-HBM + 3GB RAM?
Ich habe das Gefühl manche verstehen nicht wie man mit HBCC den Speicher erweitert.

[pilzsammler2002]

Bisher munkelt man doch von einer APU mit 11CU Vega (--> "Masse"?) und einer 16CU-Version, also Shaderausbau ungefähr wie RX460 bzw. RX560. Wenn die 16CU-Version nicht zu lahm getaktet wird, könnte das für das eine oder andere Spielchen auf FHD reichen, oder nicht?

Also ich kann aus Erfahrung sagen das auch mit der RX 460 alle spielbar war wenn man hier und da (oder auch mal mehr) nen paar Details etc. reduziert...
Sowas wie Doom lief auf der APU (7850k) auch ohne dedicated GPU schon derbe gut :freak:

[dargo]

Und das Ding hängt schon mit mickrigen 0,7 TFLOPs derbe an der Bandbreite.
https://www.computerbase.de/2014-01/amd-kaveri-test/7/

Knapp 29% mehr Bandbreite resultieren in +15% Leistung im Schnitt. Worst Case sogar +23% (Planetside 2).

[|MatMan|]

Bisher munkelt man doch von einer APU mit 11CU Vega (--> "Masse"?) und einer 16CU-Version, also Shaderausbau ungefähr wie RX460 bzw. RX560. Wenn die 16CU-Version nicht zu lahm getaktet wird, könnte das für das eine oder andere Spielchen auf FHD reichen, oder nicht?
Ohne HBM gehe ich da mit. Für eine 16CU-Version mit HBM wäre der Leistungsgewinn in Relation zum zusätzlichen Aufwand durch HBM zu gering. Das ist natürlich immer eine Frage des Preises - man wird ja wohl nicht das nächste Produkt haben wollen, was man unter Wert verkaufen muss.

Das ist doch Bestandteil der ganzen Diskussion. :confused: Der letzte Spekulationsstand war ca. 170mm² APU mit DDR4 Controller und ca. 210mm APU mit DDR4 Controller + HBM.
Bei Ryzen deckt AMD bisher alles mit einem Die ab. Jetzt soll AMD gleich 2 Dies auflegen, die so nah aneinander (nichtmal 25% größer) liegen? Klingt für mich nicht überzeugend. AMD hat nunmal deutlich geringere Stückzahlen als Intel.

Wir werden sehen ob in dieser Runde (Zen1, Vega) eine APU mit HBM erscheint. Ich kann man das aktuell nur für eine Konsole vorstellen, evtl. noch als Premium Produkt.

[Cyphermaster]

Ich habe das Gefühl manche verstehen nicht wie man mit HBCC den Speicher erweitert.
Sorry, hab nicht erst komplett nachgelesen gehabt, daß das wohl das insgesamte "HMS" ist.

[dargo]

Ich meinte nicht dich damit. :wink:

[HOT]

zitat
Wir beschränkten uns einstweilen auf das niedrigste Setting, welches 11729 MiByte Grafikspeicher bereitstellt


naja, 8gb umgelegt auf 2x4 macht doch eigentlich wenig sinn und 2x8 sind eben die 16gb im zusätzlichen ausbau.
leute, das ist auch ne quad channel platform.
Jo wir beschränken und auf 3,5GB SystemRAM, da der HBCC HBM mit dem Systemspeicher addiert als VRAM anbietet. HBCC funktioniert voll transparent für die Software, die Allokation übernimmt der Controller.

[dargo]

Bei Ryzen deckt AMD bisher alles mit einem Die ab.
Nenne mir die Alternative wenn Raven Ridge ca. 1 Jahr später kommt.

[pilzsammler2002]

Und das Ding hängt schon mit mickrigen 0,7 TFLOPs derbe an der Bandbreite.
https://www.computerbase.de/2014-01/amd-kaveri-test/7/

Knapp 29% mehr Bandbreite resultieren in +15% Leistung im Schnitt. Worst Case sogar +23% (Planetside 2).

Jup... Bei mir brachte z.B. AMD 2400er Dual Ranked RAM bei Grid (als Bsp.) nen schwung von 78,36 Fps (2133 SR) bzw. 82,46 Fps (2400 SR) auf 95,59 Fps (2400 DualRanked) :freak:

Will gar nicht wissen was da so alles mit HBM möglich wäre/ist :biggrin:
Deshalb hoffe ich das sie es in Betracht ziehen...

[|MatMan|]

Nenne mir die Alternative wenn Raven Ridge ca. 1 Jahr später kommt.
Dieselbe Frage kannst du dir umgekehrt auch zu den beiden möglichen Raven Ridge Dies stellen ;)

[akuji13]

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

Es besteht also noch Hoffnung was die Lautstärke angeht. :)
Ich hoffe man bekommt etwas ähnlich leises noch auf 2 slot hin.

[dargo]

Dieselbe Frage kannst du dir umgekehrt auch zu den beiden möglichen Raven Ridge Dies stellen ;)
Ihr denkt einfach viel zu kurzsichtig. Womit wirbt AMD bei der RX560? Damit...
https://www.extremetech.com/wp-content/uploads/2017/04/RX560.jpg
http://www.amd.com/system/files/10738-radeon-rx560-table-800x600_0.jpg

Die 4GB RX560 fängt bei 130€ an. Aktuell kannst du zwar eine kleine CPU mit einer dGPU wie zb. P21 oder GP107 kombinieren. Wenn AMD aber diese APU mit 16 CUs @VegaIP hat kann sich AMD einen P21 oder dann halt entsprechende dGPU auf Vega Basis komplett schenken. Die braucht AMD nicht mehr. Und jede verkaufte AMD APU ist ein doppelter Gewinn für AMD. Wer so eine APU kauft, kauft weder die CPU bei der Konkurrenz (Intel) noch eine dGPU bei der Konkurrenz (Nvidia).

[YfOrU]

Das ist doch Bestandteil der ganzen Diskussion. :confused: Der letzte Spekulationsstand war ca. 170mm² APU mit DDR4 Controller und ca. 210mm APU mit DDR4 Controller + HBM.

Der letzte Stand ist 4C+11CUs sowie 2C+3CUs
https://videocardz.com/69428/amd-snowy-owl-naples-starship-grey-hawk-river-hawk-great-horned-owl

Great Horned Owl ist Raven Ridge für Embedded und der Nachfolger von Merlin Falcon (Bristol Ridge). R-Series.
Banded Kestrel ist der Nachfolger von Brown Falcon (Stony Ridge). G-Series.

AMD braucht bereits zwei APU Dies um das bisherige Portfolio (Bristol und Stony Ridge) zu ersetzen. Im Embedded Bereich ist AMD recht erfolgreich aber auf ewig funktionieren die 4C Jaguar/1M Excavator 28nm SoCs dort auch nicht mehr. Raven Ridge alleine ist dafür deutlich zu groß. Auch als mobiles Entry Level Produkt. Ist für AMD viel wichtiger als eine fettere APU mit HBM welche am Ende realistisch betrachtet in einer handvoll Notebooks landet. Das ist eher etwas für die nächsten Generationen wenn man insgesamt wieder besser dasteht (Ressourcen, Kapital und Marktanteile) und bei der Produktplanung der OEMs wieder eine feste (etablierte) Größe darstellt.

[StefanV]

Gibt es EINE APU mit GDDR?
Nein, 4, eigentlich sogar 5.
PS4 in 28 und 16nm, PS4 Pro, XBox Scorpio.


Und laut offiziellen Specs unterstützt Kaveri auch GDDR5, wurde nur meines Wissens nie implementiert. Carizzo weiß ich nicht.

[dargo]

@YfOrU

Hmm... ich sehe jetzt erst, dass die TDP bei RR auf max. 65W anvisiert ist. Ich hatte immer max. 95W im Kopf. Dann klappt dann natürlich nicht mit den 16 CUs. Für 11 CUs braucht AMD auch keinen HBM. Mehr als 1Ghz würde ich jetzt bei Vega IP auch nicht erwarten. Womöglich sogar nur 800-850Mhz.

[Cyphermaster]

Mehr als 1Ghz würde ich jetzt bei Vega IP auch nicht erwarten. Womöglich sogar nur 800-850Mhz.
Die ersten Datenbankeinträge zeigen (wie zuverlässig das ist, mal dahin gestellt - sonst gibt es einfach keine Infos) 800Mhz bei einer 11CU-APU.

Mal ganz blöde gefragt (IC-Design ist nicht mein Fachgebiet): Wäre bei so niedrigen Taktraten eine Art "entschleunigte" Vega-Architektur, respektive umgekehrt eine nicht auf Speed sondern nur Erweiterung auf GCN5-Features gepimpte Fiji-Architektur möglich? Spart ordentlich Transistoren (Speed-Anpassungen) und bei Vega wichtiger: wohl auch dicke Strom. Und durch die ungraden Zahlen der vorgesehenen CUs kann man immer auch leicht beschädigtes Silizium verwenden.

[Digidi]

Gibts was neues zum Molding? Und warum reden wir hier über Apus ?

Morgen kommt meine Vega Liquid weiß jemand wie man das ohne Auseinanderschrauben überpüfen kann mit dem Molding?

[basix]

Und warum reden wir hier über Apus ?

Weil das hier der Vega-(Architektur) Speku-Thread ist und Raven Ridge wird Vega verwenden ;)

[G3cko]

Was meinst du mit Molding? Mein kühler ist auch unterwegs. Fehlt nur noch die Karte. ^^

[Digidi]

Was meinst du mit Molding? Mein kühler ist auch unterwegs. Fehlt nur noch die Karte. ^^

Es gibt 2 unterschiedliche Güteklassen bei den Chips

https://nl.hardware.info/reviews/7525/3/asus-radeon-strix-rx-vega-64-preview-sneller-en-vooral-stiller-twee-chiptypes-geen-verschil

Weil das hier der Vega-(Architektur) Speku-Thread ist und Raven Ridge wird Vega verwenden ;)
Also ich lese Vega 10 Vega 11 Vega 20

[cat]

Die vermeitliche GDDR-Unterstützung kommt durch die Fehlinterpretation zweier toter Speicherschnittstellen-Überbleibsel von dem verpaaren von GCN mit einem CPU-Speicherinterface.
Ob diese Überbleibsel ganz tot sind oder als Zombies für den Vorteil mit Dual-Ranked-Speicher mitverantwortlich sind ist bis heute nicht bestätigt.

Keine AMD-APU vor Carrizo nutzt Delta-Speicher-Kompression, bisher sind meines Wissens keine der (Desktop) AMD-APUs die diese Kompression nutzen übertaktbar oder hinreichend in Games mit gutem Speicher getestet worden.
Bristol-Ridge ünterstützt angeblich auch kein OC, aber nutzt DDR4 allerdings auch nicht schneller als 2400er.
http://products.amd.com/en-us/search/APU/AMD-A-Series-Processors/AMD-A12-Series-APU-for-Desktops/7th-Gen-A12-9800-APU/201

Bei RavenRidge könnte man durch die InfinityFabric eine APU mit HBM+DDR4-Intrefaces ausstatten, glaub ich. die CPU-Teile der Consolen-APUs scheinen gut mit dem Zugriff auf das CPU-untypische Interface zurecht zu kommen.
Also rein technisch wäre eine APU ohne DDR4/5-RAM aber dafür mit 32GB HBM2 durchaus machbar.... aber auch sehr teuer.

[Cyphermaster]

Also ich lese Vega 10 Vega 11 Vega 20

Da das durchaus richtig ist (und ich mich dabei selber auch an der Nase packen muß), bitte ich höflich darum, den Bogen zu den reinen GPUs wieder zu kriegen, und APU-Betrachtungen auf maximal Architektur-Gleichheiten zu beschränken. Der Rest kann dann in den APU-Speku-Thread.

[Locuza]

Gamestar hat ebenfalls den HBCC getestet, bei ihnen schneidet der HBCC am schlechtesten ab.
Während bei PCGH der HBCC durchgehend gleich bis besser performt hat und bei CB gemischte Ergebnisse vorlagen, verliert bei Gamestar der HBCC in jedem Fall oder liegt maximal gleich auf.
Im Schnitt ist HBCC off 4-5% schneller.
http://www.gamestar.de/artikel/radeon-rx-vega-64-benchmarks-mit-high-bandwith-cache-controller,3318564.html


PCGH hat als Testsytem einen 6800K @ 4,4 Ghz mit 32GB (3200) im Quad-Channel-Modus verwendet, ~4GB davon reserviert für ~12 GB unified memory.

CB verwendet im Testsystem 32GB (vermutlich Quad-Channel (3000) mit dem 6850K @ 4,3 Ghz?)
Davon wurden 8GB für Vega reserviert für insgesamt 16GB unified mememory.

Gamestar dagegen setzt auf einen 7700K @ Default mit 16GB (2400) Speicher, wovon auch ungefähr 4GB für 12GB unified memory reserviert worden sind.

[Dino-Fossil]

Ich schätze, AMD hätte den HBCC standardmäßig aktiviert, wenn er (fast) immer einen positiven Effekt hätte. Daher könnte es vielleicht sein, dass es noch zu stark vom jeweiligen System abhängt?

[Locuza]

Wieso könnte?
Nach drei unterschiedlichen Test stellt das genau den Fall dar. :)

[Thomas Gräf]

Wieso könnte?
Nach drei unterschiedlichen Test stellt das genau den Fall dar. :)

Auweia, wenn das so System RAM speed abhängig ist, war das dann im Sinne des Erfinders?

[AlphaNUSS]

Nun Ryzen läuft mit schnellem Ram doch eh viel besser :D

[Locuza]

Auweia, wenn das so System RAM speed abhängig ist, war das dann im Sinne des Erfinders?
Nun bisher haben wir nur einen groben Überblick, niemand hat im Detail die Auswirkungen von unterschiedlichen Parametern getestet.
Eine andere Sache ist auch, dass AMD an der Verwaltung vom HBCC noch aktiv arbeitet, sprich die Ergebnisse könnten mit der Zeit besser und besser ausfallen.

[Thomas Gräf]

Gestern dachte ich noch...oh man 2018 wird ja so langweilig. Vega hat leider gefailt.
Aber mittlerweile seh ich das entspannter.

[Digidi]

@Y33H@

Du spannst uns mit dem Molding ganz schön auf die Folter :confused:

Hier ein Video wo es ums Molding geht.
https://nl.hardware.info/tv/1103/amd-vega-update-prijzen-chips-custom-kaarten-en-mining

[reaperrr]

@YfOrU

Hmm... ich sehe jetzt erst, dass die TDP bei RR auf max. 65W anvisiert ist. Ich hatte immer max. 95W im Kopf. Dann klappt dann natürlich nicht mit den 16 CUs. Für 11 CUs braucht AMD auch keinen HBM. Mehr als 1Ghz würde ich jetzt bei Vega IP auch nicht erwarten. Womöglich sogar nur 800-850Mhz.

Warum denn das?

Der A12-9800 macht in 65W TDP auch fast 1,1 GHz GPU-Takt, und das mit Tonga/Fiji-IP in 28nm.

Also 1-1,1 GHz mit 11 Vega-CUs sollte selbst in 65W kein Problem sein, wahrscheinlich hält der CPU-Teil dann sogar noch über 2,5 GHz Takt, statt wie beim 9800 teils auf 1,4 zu drosseln.

TDP ist außerdem nicht zwangsläufig Verbrauch bzw. festes PowerTarget.

[Digidi]

Und laut Tomshardware bringt das Molding gar nichts :facepalm:

"Der Interposer sitzt nämlich trotz Molding immer noch etwas hohl auf dem PCB des Packages, so dass wir besser keinen allzu großen Druck beim Säubern ausüben möchten, auch nicht auf diese kleine Platine. Denn wir haben nun mal nur eine einzige Karte."

http://www.tomshardware.de/vega64-wasserkuhlung-benchmarks-temperaturen-ubertaktung,testberichte-242383.html

[Locuza]

Immer noch etwas hohl != genau so hohl.
Da benötigt es doch keinen Facepalm, die Aussage ist einfach, dass es weiterhin noch fragil "wirkt" und sie lieber nicht die Grenzen ausprobieren.

[Digidi]

Immer noch etwas hohl != genau so hohl.
Da benötigt es doch keinen Facepalm, die Aussage ist einfach, dass es weiterhin noch fragil "wirkt" und sie lieber nicht die Grenzen ausprobieren.

Der Facepalm war in Bezug auf die Konstruktion gedacht. Wie kann man nur sowas fragiles bauen und dann auch noch ein Molding integrieren was so gut wie nichts bringt. Stattdessen muss man Angst haben, das durch den zusätzlichen Arbeitsschritt Risse im Interposer gibt. Diese Fehler dann zu finden ist dann keine leichte Arbeit. So was taucht dann je nach Belastung und Temperaturlage sporadisch auf.

Gibt's eigentlich ein Programm was Rechenfehler in der GPU erfassen kann?

Ich bin Mal gespannt wie lange meine Vega lebt.

[basix]

Gamestar hat ebenfalls den HBCC getestet, bei ihnen schneidet der HBCC am schlechtesten ab.
Während bei PCGH der HBCC durchgehend gleich bis besser performt hat und bei CB gemischte Ergebnisse vorlagen, verliert bei Gamestar der HBCC in jedem Fall oder liegt maximal gleich auf.
Im Schnitt ist HBCC off 4-5% schneller.
http://www.gamestar.de/artikel/radeon-rx-vega-64-benchmarks-mit-high-bandwith-cache-controller,3318564.html


PCGH hat als Testsytem einen 6800K @ 4,4 Ghz mit 32GB (3200) im Quad-Channel-Modus verwendet, ~4GB davon reserviert für ~12 GB unified memory.

CB verwendet im Testsystem 32GB (vermutlich Quad-Channel (3000) mit dem 6850K @ 4,3 Ghz?)
Davon wurden 8GB für Vega reserviert für insgesamt 16GB unified mememory.

Gamestar dagegen setzt auf einen 7700K @ Default mit 16GB (2400) Speicher, wovon auch ungefähr 4GB für 12GB unified memory reserviert worden sind.

Sieht schwer nach RAM und/oder CPU-(Last)Abhängigkeit aus. Die Frage ist, ob auch der L3 der CPU mit rein spielt. Gäbe eine interessante Testreihe mit 2-CH Memoryinterface 7700K ohne HT vs. 7600K vs. 8700K @ 4C ohne HT vs. 8700K @ 6C ohne HT und mit gleicher Architektur aber 2 / 4-CH Memoryinterface 4790K ohne HT vs. 4670K vs. 5820K @ 4C ohne HT vs. 5820K @ 6C ohne HT. Alternativ 5820K mit mir 2-CH Modus. Fühlt sich wer bereit? :D

[HOT]

Als ich grade den PCGH-Heftartikel zur Vega FE nochmals durchgeblättert hab bin ich über die Einzelbetrachtung der Synthetiktests gestolpert, da soll Vega ca. 1/4 weniger TMU-Leistung raushauen als Fiji. Wenn das der Wahrheit entspricht, ist glasklar wo die Leistung hin ist, und auch warum V56 fast exakt ihre weniger Shaderanzahl an Leistung umsetzt. Damit hätte Vega einen massiven Texturflaschenhals. Mich würd interessieren, ob man das vernünftig verifizieren kann, denn das würde einiges erklären - beispielswiese warum der DSBR annähernd 0 Effekt hat bei sehr vielen Spielen, demnach würden nämlich nur die Spiele gut performen, die im Verhältnis weniger Texturleistung anfordern und warum es Titel gibt, bei denen Vega pro Takt weniger Performance liefert als Fiji.

[BoMbY]

Sieht schwer nach RAM und/oder CPU-(Last)Abhängigkeit aus. Die Frage ist, ob auch der L3 der CPU mit rein spielt. Gäbe eine interessante Testreihe mit 2-CH Memoryinterface 7700K ohne HT vs. 7600K vs. 8700K @ 4C ohne HT vs. 8700K @ 6C ohne HT und mit gleicher Architektur aber 2 / 4-CH Memoryinterface 4790K ohne HT vs. 4670K vs. 5820K @ 4C ohne HT vs. 5820K @ 6C ohne HT. Alternativ 5820K mit mir 2-CH Modus. Fühlt sich wer bereit? :D

Ich würde fast wetten der HBCC funktioniert am Besten auf einem Ryzen-System.

Und wofür bringt Vega eigentlich diese Geräte mit:

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

?

[Locuza]

Als ich grade den PCGH-Heftartikel zur Vega FE nochmals durchgeblättert hab bin ich über die Einzelbetrachtung der Synthetiktests gestolpert, da soll Vega ca. 1/4 weniger TMU-Leistung raushauen als Fiji. Wenn das der Wahrheit entspricht, ist glasklar wo die Leistung hin ist, und auch warum V56 fast exakt ihre weniger Shaderanzahl an Leistung umsetzt. Damit hätte Vega einen massiven Texturflaschenhals. Mich würd interessieren, ob man das vernünftig verifizieren kann, denn das würde einiges erklären - beispielswiese warum der DSBR annähernd 0 Effekt hat bei sehr vielen Spielen, demnach würden nämlich nur die Spiele gut performen, die im Verhältnis weniger Texturleistung anfordern und warum es Titel gibt, bei denen Vega pro Takt weniger Performance liefert als Fiji.
PCGH hat die Beyond3D-Suite auch bei der RX Vega laufen lassen, die komischen Resultate bei der Texel-Fillrate sind nun behoben:
http://www.pcgameshardware.de/Radeon-RX-Vega-64-Grafikkarte-266623/Tests/Benchmark-Preis-Release-1235445/3/

Ein anderes komisches Ergebnis sah man bei der effektiven Texturbandbreite oder einfach beim Durchsatz bei AIDA.
Mit der Beyond3D Suite erreicht die Fury X effektiv 37% mehr Bandbreite bei random colored Textures, gegenüber der Vega FE.
Die RX Vega hat gegenüber der FE hier 18% zugelegt, sodass die Fury X nur noch 15% besser dasteht.

Geh man weiter und schaut sich AIDA an, dann hat die Fury X dort 366 GB/s beim Memory Copy erreicht, die Vega FE nur 303 GB/s.
RX Vega aber präsentiert sich völlig normal mit 375 GB/s.
Was heißt, dass die RX Vega doch ihre Bandbreite abrufen kann, weswegen PCGH auch spekuliert, dass der Microbenchmark von der Beyond3D-Suite nicht lange genug läuft, um die volle Bandbreite von Vega abzurufen.

Bei Skalierungstext mit Memory-OC und was man grob so ableiten kann, stellt sich jedenfalls kein starker Bandbreitenmangel heraus.


Entsprechend würde ich sagen, dass die Hardware völlig normal aussieht, die Software ist noch sehr unreif.
Zweistellige Zuwächse würde ich im Verlauf der Zeit durchaus erwarten.

[Hübie]

In so einigen dieser Benchmarks steht sogar FuryX über Pascal, aber schaut man sich die Historie an, wurde FuryX sogar langsamer. Da ist ganz gewaltig was im argen. Vega müsste davon fliegen, wenn man diese Werte so anschaut. Eine Garantie für die Zukunft kann man daran auch nicht ableiten (siehe FuryX). Das in der Summe wäre mir keine 700 € wert.

[dargo]

Was für 700€? Das Ding gab es kurz für 509€, und das am Releasetag. :P Außerdem kommt noch der Salvage für weniger.

[Digidi]

So meine Vega ist hier. Interessant ist das das Stepping C0 ist. Das heißt doch das es schon sehr weit vortgeschritten ist?

[horn 12]

Umbau auf Wasser? ----> und die Black oder Limited Edition?

[Digidi]

Ich hab die Liquid

[Locuza]

So meine Vega ist hier. Interessant ist das das Stepping C0 ist. Das heißt doch das es schon sehr weit vortgeschritten ist?
Das Stepping ist A1, was du ausliest ist vermutlich ein Teil der Device-ID (Bei Polaris wurde unter GPU-Z C7/E7 angezeigt)
Testing on the emulator also helped us to be ready for silicon bringup and find HW issues during the narrow window between A0 silicon back and design freeze for A1 silicon (which is what actually shipped).
https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/970352-radeon-x-org-driver-gets-fixed-up-to-always-allow-page-flipping-with-tearfree?p=970689#post970689

Eine weitere und interessante Äußerung von bridgman:

Draw Stream Binning Rasterizer is not being used yet in the open drivers yet. Enabling it would be mostly in the amdgpu kernel driver but optimizing performance with it would be mostly in radeonsi and game engines.

HBCC is not fully enabled yet, although we are using some of the foundation features like 4-level page tables and variable page size support (mixing 2MB and 4KB pages). On Linux we are looking at HBCC more for compute than for graphics, so SW implementation and exposed behaviour would be quite different from Windows where the focus is more on graphics. Most of the work for Linux would be in the amdgpu kernel driver.

Primitive Shader support - IIRC this is part of a larger NGG feature (next generation geometry). There has been some initial work done for primitive shader support IIRC but don't know if anything has been enabled yet. I believe the work would mostly be in radeonsi but haven't looked closely.

For both DSBR and NGG/PS I expect we will follow the Windows team's efforts, while I expect HBCC on Linux will get worked on independently of Windows efforts.

https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/969834-more-benchmarks-showing-how-gallium3d-with-rx-vega-smacks-amdgpu-pro-s-opengl-proprietary-driver?p=970697#post970697

[basix]

Also sind die Hauptfeatures von Vega allesamt noch inaktiv oder nur zu einem kleinen Teil. Wann haben wir das mal bei einem Launch gesehen? Ich kann mich zumindest nicht an so einen Fall erinnern.

[aufkrawall]

Er sagt nicht, dass die Windows-Treiber noch nicht fertig wären. Das kann man vielleicht teilweise so interpretieren, aber dabei kann man sich auch irren.

[reaperrr]

Also sind die Hauptfeatures von Vega allesamt noch inaktiv oder nur zu einem kleinen Teil. Wann haben wir das mal bei einem Launch gesehen? Ich kann mich zumindest nicht an so einen Fall erinnern.
AMD-bridgman bezieht sich auf den Linux-Treiber.

Dass auch der Windows-Treiber noch einiges an Arbeit gebrauchen kann ist sicher trotzdem so, aber deutlich weiter als der Linux-Treiber wird er schon sein.

[AtTheDriveIn]

Er redet doch deutlich von den Linux Treibern.

[horn 12]

AMD will wohl in Aller Munde bleiben
Schaun wann das nächste große Treiber Update kommt, da kann Alles oder Nix möglich sein.
Interessant wird es erst wenn Vega die GTX 1080TI erreichen könnte und somit auch beim hohen Stromverbrauch dann nicht mehr so zu lästern ist.
Da steckt gewaltiges Potential drinn, die Frage ob es sich für AMD loht dies umzusetzen,- oder es einen wirklichen Bug im GPU Chip gibt... In welcher Richtung auch immer!

[Tesseract]

auf längere sicht wird man wohl deutlich über der 1080 landen, aber an die 1080 Ti kommt man garantiert nicht, dazu ist der treiber schon zu fortgeschritten und der rückstand zu groß bzw. zu umfassend. selbst wenn man von doom als basis ausgeht und da nochmal 15% drauf legt reicht das nicht mal für die 1080Ti FE geschweige denn die custom designs.

[dargo]

auf längere sicht wird man wohl deutlich über der 1080 landen, aber an die 1080 Ti kommt man garantiert nicht, dazu ist der treiber schon zu fortgeschritten und der rückstand zu groß bzw. zu umfassend. selbst wenn man von doom als basis ausgeht und da nochmal 15% drauf legt reicht das nicht mal für die 1080Ti FE geschweige denn die custom designs.
Muss es auch nicht. ;)

Jetzt nachdem die Karten offen sind wissen wir, dass AMD die TFLOPs bei Vega wieder schön gerechnet hat. Angegeben wird der zweithöchste Pstate, ergo 1536Mhz was 12,66 TFLOPs ergibt. Real taktet die luftgekühlte Karte allerdings eher mit 1,4Ghz, zumindest bei Witcher 3.
http://www.tomshardware.de/vega64-wasserkuhlung-benchmarks-temperaturen-ubertaktung,testberichte-242383-3.html

Erfreulicherweise hat CB bei der GTX1080TI Referenz auch die Taktraten in Witcher 3 bei 4K ermittelt.
https://www.computerbase.de/2017-03/geforce-gtx-1080-ti-test/#abschnitt_taktraten_nach_20_minuten_last

Und so haben wir folgendes Bild.

GTX1080TI = 1582Mhz im Schnitt @11,34 TFLOPs
RX Vega64 = 1401Mhz im Schnitt @11,48 TFLOPs

Ich bin schon echt auf Wolfenstein 2 gespannt. Erst da werde ich sehen wo Vega tatsächlich steht. Ich hoffe nur Maschine Games investieren bei GCN den gleichen Hirnschmalz wie id.

Edit:
Achso, und bevor gleich wieder einer kommt... aber in Witcher 3 ist die GTX1080TI 29% schneller. Das weiß ich selbst. Kein low level, kein Async Compute, kein FP16, keine Shader Intrinsics.

[reaperrr]

auf längere sicht wird man wohl deutlich über der 1080 landen, aber an die 1080 Ti kommt man garantiert nicht, dazu ist der treiber schon zu fortgeschritten und der rückstand zu groß bzw. zu umfassend. selbst wenn man von doom als basis ausgeht und da nochmal 15% drauf legt reicht das nicht mal für die 1080Ti FE geschweige denn die custom designs.
So sieht es aus (wobei ich Zweifel an dem 'deutlich' habe).

Man braucht sich im Prinzip auch nur die Specs ansehen, Vega hat nur beim reinen ALU-/TMU-Durchsatz und der Roh-Bandbreite überhaupt eine Chance auf ungefähren Gleichstand gegen die 1080 Ti (bei gleichem oder zumindest ähnlichem Takt, was ja schon schwer genug ist), der Rest ist selbst bei gleichem Takt [höchstens] auf GP104-Niveau (4 SE vs. 4 GPC, 64 ROPs).

Bei einzelnen Aspekten wie Culling, Durchsatz von schwarzen Texturen (DCC?) und höchstwahrscheinlich auch dem Z/Stencil-Durchsatz (den AMD vorsichtshalber auf seinen Folien ganz unterschlagen hat, hätten sie garantiert nicht wenn der verdoppelt worden wäre) hat sich wenig bis gar nichts seit Fiji getan und damit hängt Vega in diesen Bereichen schon architekturell so weit hinterher, dass selbst V10 in diesen Einzel-Disziplinen nicht mal auf GP106-Level rangiert, so kann man natürlich nicht vernünftig aufholen.

[BoMbY]

Muss es auch nicht. ;)

Jetzt nachdem die Karten offen sind wissen wir, dass AMD die TFLOPs bei Vega wieder schön gerechnet hat.

[...]

Und so haben wir folgendes Bild.

GTX1080TI = 1582Mhz im Schnitt @11,34 TFLOPs
RX Vega64 = 1401Mhz im Schnitt @11,48 TFLOPs


Die Vega 64 Liquid kann locker 14+ TFlops erreichen:

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

Ich denke die Custom-Karten werden auch kein Problem haben bei 12.5 zu landen.

[dargo]

Die Vega 64 Liquid kann locker 14+ TFlops erreichen:

Garantiert nicht mit 220W Asicpower. Die AIO hat schon @balanced 44W mehr Asicpower als die Air Version. Und selbst damit erreichst du nie im Leben 1,7+Ghz. Igor kam gerade mal auf 1,6Ghz in Witcher 3 bei einer auf Wakü umgebauten RX Vega64. Und da hatte er schon eine Asicpower von wahnsinnigen 330W (max. Powerlimit = 220W *150%), was für die gesamte Karte unglaubliche 402W bedeutet.
http://www.tomshardware.de/vega64-wasserkuhlung-benchmarks-temperaturen-ubertaktung,testberichte-242383-3.html


Ich denke die Custom-Karten werden auch kein Problem haben bei 12.5 zu landen.
Auch das wird nicht mit einer Asicpower von 220W gelingen. Sieht man schon an der Asus Strix OC.
https://www.computerbase.de/2017-08/asus-radeon-rx-vega-64-vorserie-test/2/#abschnitt_taktraten_unter_last

Im Schnitt 1,5Ghz (12,29 TFLOPs) bei 260W Asicpower.

[BoMbY]

Die theoretische maximale Rechenleistung wird bei NVidia auch immer für den Max Boost angegeben, und wenn der permanent gehalten wird, wird auch dort mehr Strom als angegeben verbraucht.

[Dural]

Nein, nv gibt keinen max boost an, weil sie das schlicht auch gar nicht können. Jede karte taktet etwas anders.

Und man könnte meinen das es von der 1080ti keine custom versionen gibt... und in anbetracht desen das auf der ti nur ein verschnitt des gp102 drauf ist würde ich es gleich sein lassen ;)

[Hübie]

Was für 700€? Das Ding gab es kurz für 509€, und das am Releasetag. :P Außerdem kommt noch der Salvage für weniger.

Gerade du willst die Air kaufen oder was? Laut, heiß und noch weniger Effizienz. Dass ich von der Liquid sprach sollte doch klar sein, denn die anderen sind aktuell unbrauchbar für Menschen mit Gehör. ;) Salvage hat dann noch weniger Leistungsplus. Vor allem wenn man die effizient betreiben will. Ich warte nun auf Volta und melde mich hier ab.
Was ich gestern von Vega gesehen hab, reichte um zu sagen: Braucht keiner der ne 980 Ti OC / 1070 OC hat. Von Fury / FuryX aus lohnt es sich schon eher. Von einer 390 sowieso.

ps: Falls jemand in BF1 starke spikes hat: Ingame framelimiter und Treiber framelimiter vertragen sich offenbar mal so gar nicht. Ingame auf 60 ergibt mit 21:9 WQHD (3440*1440) ein super smoothes Ergebnis.

[horn 12]

Nun, lieber Hübie was hast gesehen
So laut ist der Lüfter bei weitem Nicht,- und mit 2400 bis 2700 U/Minute leiser, gleich laut als der Quiet Modus der R9 290,- was 40% damals betrug.

[dargo]

Gerade du willst die Air kaufen oder was? Laut, heiß und noch weniger Effizienz. Dass ich von der Liquid sprach sollte doch klar sein, denn die anderen sind aktuell unbrauchbar für Menschen mit Gehör. ;)
Ist schon mal perse Blödsinn.

Dass der Referenzkühler für Leute mit empfindlichen Ohren nichts ist war noch nie anders. Zumindest wenn man sich in ähnlichen TDPs bewegt. Die Liquid hat übrigens eine noch etwas schlechtere Effizienz. Ganz einfach weil sie eine um 44W höhere Asicpower hat als die Air. Die Custom Luküs werden weder laut noch heiß sein. Am Beispiel der Asus Strix sieht man schon wohin die Reise geht. Mit 260W Asicpower @Default im Bios 1 ergeben sich mit Powersave Profil 195W Asicpower. Das sind 5W weniger als bei der Referenz @balanced im Bios 2. Damit wird so eine Asus Strix praktisch unhörbar bei noch recht kühlen Temps. Man muss sich auch nicht auf die vorhandenen Profile beschränken. Dank 2 Biosen und Wattman von -50% bis +50% hat man jede Menge Möglichkeiten. Der User selbst entscheidet was die Karte schlucken darf.

[akuji13]

Nun, lieber Hübie was hast gesehen
So laut ist der Lüfter bei weitem Nicht,- und mit 2400 bis 2700 U/Minute leiser, gleich laut als der Quit Modus der R9 290,- was 40% damals betrug.

Aber nur wenn man einen Hörschaden hat oder mit Kopfhörern spielt. :D

Alles über 40dB(/A) ist für mich unerträglich.

[foenfrisur]

Also die liquid ist zwar ineffizienter, aber sie hält den takt schön hoch.

Habe 1770mhz gpu und 1000mhz hbm2 takt festgetackert bei 63grad in bf1.

Bios 2 btw. Mit +50%

Mfg

[Elite_Warrior]

Wobei man da aufpassen sollte, scheint noch einige Bugs zu geben wo der Takt nicht korrekt ausgegeben wird und man denkt man habe viel mehr Clock als es in Wirklichkeit hinten raus kommt.

https://www.youtube.com/watch?v=SBx73n-fgdE

[BoMbY]

Nein, nv gibt keinen max boost an, weil sie das schlicht auch gar nicht können. Jede karte taktet etwas anders.


Tesla V100 (https://www.heise.de/newsticker/meldung/Tesla-V100-Nvidia-uebergibt-erste-Volta-Rechenkarten-an-Deep-Learning-Forscher-3781130.html): GPU Boost Clock 1455 MHz * 5120 SP = 7449600 FLOP/s (FP64)

[24p]

Das ist nicht der max Boost.

[Hübie]

Ist schon mal perse Blödsinn.

Dass der Referenzkühler für Leute mit empfindlichen Ohren nichts ist war noch nie anders. Zumindest wenn man sich in ähnlichen TDPs bewegt. Die Liquid hat übrigens eine noch etwas schlechtere Effizienz. Ganz einfach weil sie eine um 44W höhere Asicpower hat als die Air. Die Custom Luküs werden weder laut noch heiß sein. Am Beispiel der Asus Strix sieht man schon wohin die Reise geht. Mit 260W Asicpower @Default im Bios 1 ergeben sich mit Powersave Profil 195W Asicpower. Das sind 5W weniger als bei der Referenz @balanced im Bios 2. Damit wird so eine Asus Strix praktisch unhörbar bei noch recht kühlen Temps. Man muss sich auch nicht auf die vorhandenen Profile beschränken. Dank 2 Biosen und Wattman von -50% bis +50% hat man jede Menge Möglichkeiten. Der User selbst entscheidet was die Karte schlucken darf.

Ja und das Wort "aktuell" ignorierst du gekonnt. :rolleyes: Gibt nur drei Karten. Zwei Schrott eine OK. Die Liquid kannst du effizienter betreiben und ist dabei weder laut noch heiß. Aber nicht mal wenn man die ineffizient betreibt ist die laut oder heiß.
Deine Argumentation können wir in zwei Wochen oder so mal wieder aufgreifen. Aber wie damals wo du geleugnet hast, dass Vega spät dran ist, wirst du dich auch hier wieder heraus winden wollen. Schon klar. ;D Wie gesagt ist das Produkt für mich gestorben. Nicht zuletzt auch wegen der Freesync-Monitore.

@Rest: Habt ihr Probleme mit dem Treiber? Powercolor scheint eine Sub-DeviceID## einprogrammiert zu haben, weshalb der AMD-Treiber die Installation verweigert. Echt clever. Ist das ein Sonderfall von denen oder sind die anderen genau so dran? :confused:
Gestern bei einer kleinen Testsession schmierte das System mehrfach mal ab. Da gibt es also definitiv noch Handlungsbedarf. Aber gut - neue µArch, neues Speichermanagement und neue Oberfläche (die ja immer noch nicht vollständig vom CCC ins neue UI transferiert wurde). Da verzeiht man so etwas.
Als jahrelanger NV-Hase gefiel mir die auf Anhieb gut von der Hand gehende, intuitive Bedienung der gesamten UI (und konnte meinem AMD-Fanboy-Bro sogar noch was zeigen :biggrin:).
Positiv war auch das Spielgefühl in BF1, wenn es denn mal flüssig lief (Problem wegen fps-limiter. Der gretschte gerne mal rein - siehe oben). Also abseits von bloßen Zahlen kann man Vega* schon empfehlen, so ist das ja nun nicht. :wink:

*Aktuell nur Liquid, Air@Umbau oder später die Customs.

@BoMbY: NVIDIA hat einen Algorithmus in der PCU die je nach leakage, actual power draw, estimated power draw, temperature, voltage supply und current density die clocks dynamisch anpasst. Das hast du auf Teslas per Treiber oder Firmware zwar nur stark eingegrenzt, aber gilt eben nicht allgemein. Meine Karte ist das perfekte Beispiel: Ausgepackt, eingebaut: 1430 MHz :eek: Pendelt sich dann immer bei 1418 ein. Nie drunter bei entsprechend hoher Last.

[dargo]

Ja und das Wort "aktuell" ignorierst du gekonnt. :rolleyes:
Genau wie du Powersaves. :rolleyes:

Die Liquid kannst du effizienter betreiben und ist dabei weder laut noch heiß.
Die Air kannst du noch effizienter betreiben. :P
https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11465635&postcount=1264

[Hübie]

Effizienz kommt Perf/W. Ich sehe da nur die schnöden Watt-Angaben (GPU? GPU+HBM? Board??).