AMD Vega 10: Linux-Patch nennt weitere technische Eckdaten

[RawMangoJuli]

jezz hab ich das mit den 4x powerefficiency doch gefunden ^^

https://scr3.golem.de/screenshots/1701/AMD-Vega-10/thumb620/AMD-Vega-10-02a.png

Die "Effizienzlüge" stimmt aber nicht, denn Polaris ist sehr effizient, vorrausgesetzt sie wird nicht übertaktet. Aber die 1.266 MHz Grundtakt waren schon deutlich über dem Sweetspot. Mit 1000 MHz hätte die Karte unter 100 Watt liegen können. Natürlich wäre sie dann kein Konkurrent zu irgendetwas von nVidia gewesen und daher musste der Takt zwangsweise erhöht werden. Ja, nVidia ist viel effizienter als AMD aber ganz so schlecht, wie du sie hier zu machen versuchst, sind sie auch nicht ^^

dennoch keine Konkurenz für NV

meine 1070 braucht mit 1700MHz@0,8V auch nur 100-110W und is dabei wesentlich schneller

Sind wohl doch nur 2 Fache Leistung pro Pipeline.
Front- wie Backend aufgemobelt - Grafikchip: AMD zeigt Vega 10 und erlautert Architektur - Golem.de
Ich weiß nicht wie ich auf 4 kam.
Vielleicht hatte ich das ganze mit doppelt so vielen Pipelines wie bei Fiji in Erinnerung.

ich weiß nich mehr wo aber irendwo auf ner Vea Slide hab ich das mit den 4x bei der Geometrie auch gesehen

 

[Atent123]

jezz hab ich das mit den 4x powerefficiency doch efunden ^^

https://scr3.golem.de/screenshots/1701/AMD-Vega-10/thumb620/AMD-Vega-10-02a.png

Ich glaube aber das sich das auf HBM bezieht.

 

[Rollora]

Schau dir mal an wann der Fiji Chip gekommen ist. Der kam Mitte 2015, die GTX 980 wurde aber schon im Herbst 2014 herausgebracht.
Das heißt also AMD lag auch damals schon mit einer Fury nur auf GTX 980 Niveau und war mit einer Fury X zumindest in Full HD nicht relevant schneller.
Nvidia hat sich derweil weiterentwickelt, hat sehr viel Geld eingenommen und das Entwicklungsbudget vergrößert während AMD gespart hat. Das kann die Entwicklung schonmal erheblich verlangsamen.
Im Prinzip hätte Vega ergo schon 2016 kommen müssen. Dass AMD den Topdog gegen die Mittelklasse von Nvidia stellen könnte ist gar nicht mal so unwahrscheinlich.

Das stimmt alles.
Aber auch AMD hat sich weiterentwickelt. Nur war der Schritt mit Polaris ebensogroß wie der Schritt von Nvidia mit Pascal. Sodass am Ende wieder ein gleich (riesiger) Vorsprung rausgekommen ist, weil eben Maxwell schon so gut war. Das skaliert natürlich in den nächsten Prozess mit rein.
Damals habe ich immer von allen seiten "Shit" bekommen, weil ich vorgerechnet hab' , dass Nvidia für mehr Leistung weniger Transistoren, Chipfläche und Energie braucht und sich das natürlich nach belieben skalieren lässt. Das Wort "alternative Fakten" gab es damals noch nicht, aber es lief darauf hinaus, dass mir selbige vorgeworfen wurden, nur weil niemand anscheinend rechnen kann oder lieber die Welt mit rosa Brille betrachtet.
Den Vorsprung den Nvidia derzeit hat, kann AMD mit den alten Versionen der GCN einfach nicht aufholen, es braucht halt eine große Veränderung.
Diese wird halt mit Vega erhofft. Sonst seh' ich einfach schwarz mir in den nächsten Jahren AMD zu kaufen.
Ich warte noch auf Vega ab, aber wenn das wieder so ein Chip ist, der nur mit brachial mehr Verlustleistung oder Chipgröße annähernd das erreicht, was Nvidia seit Jahren hat, wirds im Spielerechner erstmals eine Nvidia.

Von den reinen Rohdaten her ist es jedenfalls schon irgendwie seltsam, dass diese genauso ausfallen. Sicher ist das kein Shrink. Aber große Verbesserungen würde ich mir jetzt auch nicht grade erwarten.

Wäre Vega ein "Shrink" von Fiji, hätte er knappe 300, nicht 500mm².
Denn der 14nm Prozess skaliert eigentlich recht gut was die Transistordichte betrifft. Es sind also doch einige Änderungen unter der Haube. Obs mal wieder nur verschwendete Transistoren sind, die nicht viel Leistung bringen sei dahingestellt.
Ich war übrigens neulich überrascht: (ist jetzt OT)
Meine uralt 5850 hat knappe 2,2 Mrd Transistoren, die 7 Jahre später erschienene "mittelklasse" von Nvidia nur 4.4 Mrd (1060), da hat sich gar nicht so viel getan. Auch die Leistungsdaten sprechen nicht von 7 Jahren Unterschied.
Das Tempo ist aber dann dennoch ein wesentlich anderes

Gegenfrage: Wer sind denn die Kunden für Ryzen?
Kunden, die die (annähernd) gleiche Leistung wie bei Intel günstiger, teilweise sogar zum halben Preis kaufen!.

Es ist aber ein trauriges Los von AMD, dass sie immer nur dann Kunden haben, wenn sie etwas, was man bei der Konkurrenz seit Jahren hat, wesentlich später und zu einem günstigeren Preis verkaufen muss.

 

[DKK007]

Es ist aber ein trauriges Los von AMD, dass sie immer nur dann Kunden haben, wenn sie etwas, was man bei der Konkurrenz seit Jahren hat, wesentlich später und zu einem günstigeren Preis verkaufen muss.

Das hat aber nichts mit AMD zutun, sondern mit Intel und Nvidia. Wie man bei Coffeelake sehen wird, kann auch Intel den Hexacore für unter 300€ verkaufen.

 

[Rollora]

Das liegt daran weil es seicht Off Topic ist, zumindest gibt es aber einen Zusammenhang mit AMD´s angekündigter Vega Effizienz auf den Folien Ende 2015.



Ja, genau darauf bezog man sich und das 3D Center ermittelte eine Effizienzsteigerung von 1,6 zwischen diesen beiden Karten.



Der real erreichte Energieeffizienz-Gewinn bei AMDs Polaris | 3DCenter.org

Das heißt also selbst bei der Kirschenpickerei hat AMD die Wahrheit sehr sehr weit gedehnt.
Bei Vega hat man sich nicht zu solchen Werten im Vorfeld hinreißen lassen, was das bedeutet, lasse ich mal offen.^^

Danke für den Link, kannte ich so noch nicht! Endlich mal eine Detaillierte Analyse. Gibts das auch zu Nvidia (wobei die haben nicht 6 Monate lang vom Effizienzwunder und "designed for FinFET"geredet

Hab nur bis ca. #50 gelesen und stelle mir die Frage, warum hier niemand die Leistung eines einzelnen Shaders hinterfragt. Ich meinem, ein Shader ist ein komplexer Funktionsblock wie ein Prozessorkern. Also hat der einzelne Shader so etwas wie eine IPC.
Die Leistung einer CPU bestimmt man ja auch nicht nur durch Kerne*Takt, also wie kann man nur von der Anzahl der Shader und dem Takt etwas über die Leistung aussagen, ohne die 'IPC' zu kennen?

Hab' ich doch geschrieben...

Wollen wir nicht auch darüber diskutieren wie daneben Nvidia's Behauptung die 1080 sei schneller als 2 980er tatsächlich war? Von dem "Pascal = 10x Maxwell" Schwachsinn reden wir gar nicht. Oder einigen wir uns doch darauf, dass Herstellerangaben generell Kirschenpickerei sind und dass die Anzahl bestimmter GPU-Bestandteile kein Indiz für einen Die-Shrink ist?

In meinem Hirn hab' ich dunkel die Erinnerung, dass es sich dabei um VR Beispiele handelte, die im Falle der speziellen neuen VR Technik von Nvidia dann die 2x 980 Leistung erreicht

Das hat aber nichts mit AMD zutun, sondern mit Intel und Nvidia. Wie man bei Coffeelake sehen wird, kann auch Intel den Hexacore für unter 300€ verkaufen.

Ich hab' mich falsch ausgedrückt:
Viele hier fordern immer, dass AMD was tolles neues bringt, wären aber nur bereit es zu kaufen, wenns dann weniger Geld kostet

Wobei ~7,5 TFLOPS für Vega11 und 12,5 TFLOPS für Vega 10 realistisch klingen und schon zu den Shadern passen.

3072*2*1220 = 7500000
4096*2*1530 = 12500000

die Frage ist: wieviel von der Theoretischen Leistung landet dieses Mal "auf der Straße"

 

[Locuza]

Verstehe bis heute nicht,warum man nicht eine doppelt do große Polaris 10 aufgelegt hat. Klar für Titan un Ti hätte es dennoch nicht gereicht,die Effizienz wär auch im A....,aber wenigstens mal wieder flotte Karten von AMD und mitmischen im Preisbereich über 350€ statt 200

Nah, dass hätte Ressourcenverschwendung dargestellt.
Ein Projekt mit der Brechstange, welches Männer, Geld und Zeit bindet und dann ein Jahr später durch Vega direkt ersetzt wird?
AMD hat nicht die Mittel dafür, wenn sie schon jetzt nur wenige Chips über Marktsegmente und Jahre verteilen müssen.

Stell dir einen Shrink von Fiji auf 14nm vor: Der Chip wäre wahrscheinlich ein gutes Stück kleiner als Hawaii: Um die 380-400mm².
Warum ist Vega nun aber über 100mm² größer. Was ist da nur passiert? Detailverbesserungen?

Bei der gleichen Packdichte wie bei Polaris 10 wäre Fiji ~ 360mm² groß.

Hawaii (GCN Gen 2): 14,2 Millionen Transistoren pro mm² (6,2 Mrd. Transistoren / 438mm²)
Tonga (GCN Gen 3) : 13,9 Millionen Transistoren pro mm² (5 Mrd. Transistoren / 359mm²)
Fiji (GCN Gen 3): 14,9 Millionen Transistoren pro mm² (8,9 Mrd. Transistoren / 596mm²)
Polaris 10 (GCN Gen 4): 24,4 Millionen Transistoren pro mm² (5,7 Mrd. Transistoren / 234mm²)

Eher kleiner natürlich, da Fiji eine höhere Packdichte erreicht hat, als andere GCN-Chips.


Was ist passiert?
Ein paar Dinge aus folgendem Menü:

Von Gen 4:

- Instruction Buffer sind größer geworden
- Intstruction Prefetch wird unterstützt
- Primitive Discard Accelerator
- Die Geometry-Engines puffern jetzt die meshes selber, nicht mehr der L2$.
- Die verbesserte Delta-Color-Compression

Von Gen 5:

- Draw-Stream-Binning-Rasterizer
- Der Rasterizer wird nun auch Conservative Rasterization unterstützen
- Die Instruction Buffer werden erneut vergrößert
- Die ALUs sollen eine höhere Taktrate unterstützen
- Die ALUs werden Double-Rate FP16 unterstützen, aktuell ist es nur Single-Rate und vermutlich ist vierfach Int8 auch etwas neues, was GCN Gen 4 noch nicht konnte
- Die Geometry-Engines werden den theoretischen Durchsatz von einem Dreieck auf 2,75 erhöhen (liest sich krude, gilt vielleicht nur für spezielle Fälle), was insgesamt 11 Dreiecke pro Takt bedeutet, anstatt 4 wie bei Fiji.
- Die ROPs sind nun die Clients vom L2$, weswegen AMD möglicherweise auch Rasterizer Ordered Views unterstützt, es könnte sein das deswegen der Flächenbedarf steigt.
- Da der Rasterizer jetzt Kacheln im L2$ speichert und auch die ROPs die Konsumenten vom L2$ sind, wird die Kapazität vom L2$ garantiert steigen, vermutlich von 2MB auf 4MB.
- Und AMD hat noch mehr Dinge getan, die aktuell noch nicht genannt wurden.

Kann doch bitte ein anderer Redakteur die Vega Artikel schreiben.
Gefühlt hat die Qualität der Artikel stark abgenommen (Meine Meinung)!

Solange der Online-Auftritt keinen wesentlichen Umsatztreiber darstellt, wird die Qualität der Online-News sich wenig verändern.

Die "Effizienzlüge" stimmt aber nicht, denn Polaris ist sehr effizient, vorrausgesetzt sie wird nicht übertaktet. Aber die 1.266 MHz Grundtakt waren schon deutlich über dem Sweetspot. Mit 1000 MHz hätte die Karte unter 100 Watt liegen können. Natürlich wäre sie dann kein Konkurrent zu irgendetwas von nVidia gewesen und daher musste der Takt zwangsweise erhöht werden. Ja, nVidia ist viel effizienter als AMD aber ganz so schlecht, wie du sie hier zu machen versuchst, sind sie auch nicht ^^

Sehr effizient muss man im Markt eben als relativ betrachten und dort ist Pascal eine Generation voraus, Vega muss einen Generationssprung darstellen, um überhaupt auf Pascal-Niveau zu landen.
Eine 1070 kannst du auch am Sweetspot betreiben, um noch 75% der Leistung zu erreichen, aber den Verbrauch um 50% zu senken:
Detaillierte Effizienzbetrachtung - GTX 1070/1080 vs. GTX 980 Ti: Effizienzanalyse & Leistungsaufnahme

Das ist schon ein dramatischer Standpunkt und ein Grund wieso AMD viele Notebook-Deals flöten gehen und auch im Server-Markt stellt so etwas ein Problem dar.

 

[Rollora]

Es ging schon um Vega allgemein.
Anhang anzeigen 951596
Vorzeitiger Vega-Teaser offenbart 16 GB HBM2-Speicher samt "Vega Next Compute Unit" | 3DCenter.org

Wenn die Karten schon nicht so hoch takten, sollten sie diesmal deutlich näher am Sweetspot liegen und daher auch deutlich weniger verbrauchen.

Deutlicher als das "Effizienzwunder" Polaris? Hoffentlich!

Die "Effizienzlüge" stimmt aber nicht, denn Polaris ist sehr effizient, vorrausgesetzt sie wird nicht übertaktet. Aber die 1.266 MHz Grundtakt waren schon deutlich über dem Sweetspot. Mit 1000 MHz hätte die Karte unter 100 Watt liegen können. Natürlich wäre sie dann kein Konkurrent zu irgendetwas von nVidia gewesen und daher musste der Takt zwangsweise erhöht werden. Ja, nVidia ist viel effizienter als AMD aber ganz so schlecht, wie du sie hier zu machen versuchst, sind sie auch nicht ^^

Naja runtergetaktet kriegst du einfach alles irgendwann Effizient (im Vergleich zu einer hoch getakteten, ineffizienten Ausgangsbasis). Das ist keien Kunst.
Kannst auch einen 600mm² Chip runtertakten (Nano). Dann ist das plötzlich auch "Effizient", und alle die behaupten AMD baue keine Effizienten GPUs sind dann "Lügner".
Was natürlich nonsens ist, ich fahre meinen Motor ja auch nicht nur zwischen 1200 und 1700 U/m, weil er dort am wenigsten Sprit verbraucht. Natürlich muss man den Chip irgendwo am Sweet Spot orientieren. Am besten knapp drunter, damit moderates Übertakten (Partnerkarten) nicht die Netzteile explodieren lassen

 

[Mephisto_xD]

ein Shader hat immer eine Rechenleistung von 2 FLOPs

man kann eher darüber diskutieren wie effizient die einzelnen Shader ausgelastet werden

Sollte wohl eher 2 FLOP/Takt heißen.

Selbst dann: Für die Angabe der theoretischen maximalen Rechenleistung beim Matrixmultiplizieren mag das stimmen, anstonsten ist die Angabe aber wertlos. Ein Shader macht in seinem Leben noch was anderes als FMA auszuführen. Und ob der dann für eine Division einen einzelnen Takt oder 100 Takte braucht lässt sich aus der tollen maximalen Rechenleistung eben nicht herauslesen. Oder wie viel Register / Cache einem Shader zur Verfügung steht, ergo wie oft der Shader Däumchen dreht weil er auf Daten wartet.

Es hat seine Gründe, warum die Shader bei nVidia deutlich dicker sind als bei AMD. Und warum nVidia selbst bei gleichem Takt und gleicher Shaderzahl an AMD vorbeizieht.

 

[spawa93]

Der LPP+ Prozess macht Polaris durchaus viel effizienter. Es liegt demnach nicht alleine an der Architektur, daß Polaris 10 mit dem LPP schlechter abschneidet, als Pascal. Es gibt bei Polaris 10 schlicht mehr Leckströme, als bei Polaris 20.

 

[Casurin]

Wenns um die Effizienz geht - wenn man den Takt erhöht sinkt die Effizienz. das ist halt nunmal so, kommt direkt aus den elektrotechnischen Grundlagen und daran kann weder Amd, noch Intel oder nvidia etwas ändern.
Durch bessere Fertigung wird die Bauteilgröße verkleinert undd er Energieverbauch gesenkt, ergo Effizienter. Und dieser vorteil wird dan aufgebraucht in dem man eben den Takt so weit erhöht bis die gpu wieder den selben Stromverbrauch hat - was meist der limitierende Faktor für Chips ist. Die Fury-Nano war da ja ein gutes Beispiel - den takt etwas niedriger, die Temperaturen schön unten halten und das ding ist wirtklich extrem Effizeint.

Wenn vega dann wirklich eine Verbesserung von Fiji ist (was sehr anzunehmen ist) kann man sich auch guta darauf einstellen:
Taktraten etwas unter Polaris, dafür mehr Shader die ewtas leistungsfähiger sind => beim selben Herstellungsverfahren höhere Leistung bei selben Verbrauch.


Dennoch nerft mich das AMD entweder shcweigt oder das Blau vom Himmel herredet.
(Nvidia/Intel sind da imo nur marginal besser )

Spoiler

Nicht unbedingt. Das GCN-Mantle-Konzept etwa wurde ja weniger wegen dem PC-Markt entwickelt, sondern war wichtiger Kernbestandteil der AMD-Konsolenplattform Angebote an Sony und MS. Neben der Custom-Chip-Expertise AMD's und dem Umstand, daß man weltweit der einziger Hersteller ist, der für beide Welten - CPU und GPU - grundlegende Patente und fertige Lösungen besitzt, war GCN+Mantle ein geniales hardwarenahes Konzept zur Grafikbeschleunigung und Parallelisierung, das konnte 2011-2012, als die Vorverträge mit Sony und MS geschlossen wurden, sicherlich kein anderer Hersteller in dieser "Komplettheit" bieten.

Aber natürlich profitieren die AMD-Desktop-Karten ebenso von GCN. Niemand würde bestreiten, daß DX12 einfach nur eine Kopie von Mantle war, dass MS DX12 nach Mantle nur deshalb so schnell aus dem Hut zaubern konnte, weil sie im Rahmen der Vorverhandlungen zur Xbox One natürlich schon Jahre vor 2013 Zugang zur Mantle-Technologie inkl. Source-Code hatten und daß sie vermutlich auch mit AMD einen Lizenz-Deal abgeschlossen haben, daß sie Mantle-Technologie in veränderter Form (bischen "umgeschrieben") als nächste DX-Version verwenden dürfen. Eine Hand wäscht die andere. AMD stand damals kurz vor dem finanziellen Exitus und verdient nun prächtig am Konsolengeschäft. Es ist kein Zufall, daß sich beide Apis wie ein Ei dem anderen gleichen.

nvidia hat dagegen zwei Generationen (Maxwell, Pascal) später immer noch keine vollständige Hardware-Unterstützung für grundlegende DX12/Vulkan/Mantle Konzepte (Async-Compute), was AMD spätestens seit Mantle in den ersten Games einen ziemlichen Achtungserfolg in der Gaming-Szene verschafft hat. Und der Grund dafür war einfach: nvidia hat Mantle naturgemäß nicht kommen sehen und die Entwicklung einer neuen Architektur dauert eben Jahre. Völlige Hardware Unterstützung wird dementsprechend wohl erst Volta bieten, offenbar kommt Volta aber nicht mal 2017 raus. Da kann AMD in 2017 also sogar noch nachlegen, evtl. ja mit einer Vega-Version mit 2.0 Gbps HBM2 und 16GB onboard später im Jahr.

Und wieder jemand der wenig Ahnung hat aber groß mitreden will.

Weder Vulcan noch Mantel sind der Grund für Dx12 als Lowlevel-Api. Lowlevel Api sind halt einfach wieder "in mode" obwohl sie gewaltige Nachteile haben.
Lustigerweise ist es OpenGL das heir Vorreiter ist - und dann behaupten leute auchnoch Vulkan sei die Weiterentwicklung....

Auch Hat nvidia ganz normal Dx12 in Hardware - sonst würde das ganze nicht wirklicch rund Laufen. Nur es gibt eben dafür verschiedene Ansätz. So hat zB AMD Async-Compute mehr als nur ein bisschen gehyped - denn im Grunde ist es ncihts anderes als eine Entschuldigung das ganze Scheduling den Software-Entwicklern auf den Hals zu brummen. Und bei nvidia? ja, sie haben ganz normal Dx12 Async Compute in Hardware - schon seit viele Generationen. Nur eben wird hier auf einen anderen Ansatz gesetzt: Die GPU wird von haus aus vollkommen ausgelastet und das Scheduling von Graphic- und Compute-Workloads funktioniert einwandfrei. Nur wenn dann ein programm auf die idee kommt das ganze Scheduling über den haufen zu werfen und einfach fröhlich drauf los dauerhaft context-switches durchführt dann leidet die Leistung unter der grotten schlechten Programmierung.


Ist das selbe wie auch mit den "Vulkan/Dx12 können soooo viele drawcalls" bullshit.
In wlechem fall bringt sowas einen Vorteilß Ach ja - nur wenn gegen jede Vernunft alles von CPU-seiten her gemanaged wird, der Hardware-scheduler umgangen und jedes einzelne Objekt als drawcall gesendet wird. leistungstechnisch ein Abltraum da man nicht nur eine vorhande Hardwarefunktion in Software implementiert sondern die ganzen daten nun auchnoch von der Cpu zur GPU gestreamed werden müssen.

 

[spawa93]

Und wieder jemand der wenig Ahnung hat aber groß mitreden will.

Weder Vulcan noch Mantel sind der Grund für Dx12 als Lowlevel-Api. Lowlevel Api sind halt einfach wieder "in mode" obwohl sie gewaltige Nachteile haben.
Lustigerweise ist es OpenGL das heir Vorreiter ist - und dann behaupten leute auchnoch Vulkan sei die Weiterentwicklung....

Auch Hat nvidia ganz normal Dx12 in Hardware - sonst würde das ganze nicht wirklicch rund Laufen. Nur es gibt eben dafür verschiedene Ansätz. So hat zB AMD Async-Compute mehr als nur ein bisschen gehyped - denn im Grunde ist es ncihts anderes als eine Entschuldigung das ganze Scheduling den Software-Entwicklern auf den Hals zu brummen. Und bei nvidia? ja, sie haben ganz normal Dx12 Async Compute in Hardware - schon seit viele Generationen.

Aja... Danke Dir für die Erleuchtung...

Ich habe kein Mitleid mit den Entwicklern, die haben schließlich "Spaß am Coden" (TM) und es ist ihr Job, den Scheduler intelligent auszulasten.. Das mit dem Spass war allerdings nicht ernst gemeint. Klar ist es angenehmer, je abstrahierter die Api ist, aber die Zeiten sind halt mit DX12/Vulkan vorbei und für den Druck dahinter sorgen nicht zuletzt die Millionen ewigen Benchmark-meiner-ist-schneller Dödel auf den diversen Hardwareseiten. Das bleibt ganz sicher keine Modeerscheinung.

 

[Mephisto_xD]

Ist das selbe wie auch mit den "Vulkan/Dx12 können soooo viele drawcalls" bullshit.
In wlechem fall bringt sowas einen Vorteilß Ach ja - nur wenn gegen jede Vernunft alles von CPU-seiten her gemanaged wird, der Hardware-scheduler umgangen und jedes einzelne Objekt als drawcall gesendet wird. leistungstechnisch ein Abltraum da man nicht nur eine vorhande Hardwarefunktion in Software implementiert sondern die ganzen daten nun auchnoch von der Cpu zur GPU gestreamed werden müssen.

Man sollte hier erwähnen, dass es durchaus Szenarien gibt in denen die "vielen Drawcalls" immense Vorteile bringen - z.B. wenn man eine 300€ Konsole baut und eine aufgemotzte Netbook-CPU mit einer RX 480 verkuppelt

Wenn das Spiel dank moderner CPU hingegen schon in DX11 vollständig GPU-limitiert wird sind Vorteile in der Tat nicht zu erwarten.

Und wieder jemand der wenig Ahnung hat aber groß mitreden will.

Glashaus und so, wenn ich mir die folgenden Abschnitte angucke:

Weder Vulcan noch Mantel sind der Grund für Dx12 als Lowlevel-Api. Lowlevel Api sind halt einfach wieder "in mode" obwohl sie gewaltige Nachteile haben.
Lustigerweise ist es OpenGL das heir Vorreiter ist - und dann behaupten leute auchnoch Vulkan sei die Weiterentwicklung....

Schon mal was in Vulkan oder OpenGL entwickelt? Vermutlich nicht, denn ansonsten würdest du nicht behaupten, dass OpenGL eine Low-Level Schnittstelle ist.

Auch Hat nvidia ganz normal Dx12 in Hardware - sonst würde das ganze nicht wirklicch rund Laufen. Nur es gibt eben dafür verschiedene Ansätz. So hat zB AMD Async-Compute mehr als nur ein bisschen gehyped - denn im Grunde ist es ncihts anderes als eine Entschuldigung das ganze Scheduling den Software-Entwicklern auf den Hals zu brummen. Und bei nvidia? ja, sie haben ganz normal Dx12 Async Compute in Hardware - schon seit viele Generationen. Nur eben wird hier auf einen anderen Ansatz gesetzt: Die GPU wird von haus aus vollkommen ausgelastet und das Scheduling von Graphic- und Compute-Workloads funktioniert einwandfrei. Nur wenn dann ein programm auf die idee kommt das ganze Scheduling über den haufen zu werfen und einfach fröhlich drauf los dauerhaft context-switches durchführt dann leidet die Leistung unter der grotten schlechten Programmierung.

Bwahaha . Schade, dass AMD nicht auf den Ansatz gekommen ist die GPU "einfach von Haus aus" auszulasten.

Im Ernst: Völliger Blödsinn. Async Compute brummt dem Softwareentwickler nicht einfach das Scheduling auf, sondern beschreibt die Möglichkeit Compute und "normale" GPU-Calls ohne Context-Switch auf der gleichen GPU ausführen zu können. nVidia-GPUs können das eben nicht, weshalb sie immer den zeitaufwendigen Context-Switch brauchen - den dann halt im Zweifel der Treiber macht, statt das Programm.

 

[XD-User]

Fiji done right reicht aber wohl eben nicht AMD

Wenn das Ding genau aufgebaut ist wie schon 2015 Fiji, wenn auch inklusive GCN 5/1.4 und wir sogesehen nur auf 14nm gesprungen sind, wieso ist das Ding von 596mm² nur auf knapp unter 500mm² gesunken?
Das einzige was ich mir spontan denken kann, ist das VEGA seine Rohleistung dank Neuerungen weitaus besser auf die Straße bringen kann... als Fiji und co und man deswegen wenig mehr Rohleistung braucht?

 

[wolflux]

Das stimmt alles.
Aber auch AMD hat sich weiterentwickelt. Nur war der Schritt mit Polaris ebensogroß wie der Schritt von Nvidia mit Pascal. Sodass am Ende wieder ein gleich (riesiger) Vorsprung rausgekommen ist, weil eben Maxwell schon so gut war. Das skaliert natürlich in den nächsten Prozess mit rein.
Damals habe ich immer von allen seiten "Shit" bekommen, weil ich vorgerechnet hab' , dass Nvidia für mehr Leistung weniger Transistoren, Chipfläche und Energie braucht und sich das natürlich nach belieben skalieren lässt. Das Wort "alternative Fakten" gab es damals noch nicht, aber es lief darauf hinaus, dass mir selbige vorgeworfen wurden, nur weil niemand anscheinend rechnen kann oder lieber die Welt mit rosa Brille betrachtet.
Den Vorsprung den Nvidia derzeit hat, kann AMD mit den alten Versionen der GCN einfach nicht aufholen, es braucht halt eine große Veränderung.
Diese wird halt mit Vega erhofft. Sonst seh' ich einfach schwarz mir in den nächsten Jahren AMD zu kaufen.
Ich warte noch auf Vega ab, aber wenn das wieder so ein Chip ist, der nur mit brachial mehr Verlustleistung oder Chipgröße annähernd das erreicht, was Nvidia seit Jahren hat, wirds im Spielerechner erstmals eine Nvidia.
Wäre Vega ein "Shrink" von Fiji, hätte er knappe 300, nicht 500mm².
Denn der 14nm Prozess skaliert eigentlich recht gut was die Transistordichte betrifft. Es sind also doch einige Änderungen unter der Haube. Obs mal wieder nur verschwendete Transistoren sind, die nicht viel Leistung bringen sei dahingestellt.
Ich war übrigens neulich überrascht: (ist jetzt OT)
Meine uralt 5850 hat knappe 2,2 Mrd Transistoren, die 7 Jahre später erschienene "mittelklasse" von Nvidia nur 4.4 Mrd (1060), da hat sich gar nicht so viel getan. Auch die Leistungsdaten sprechen nicht von 7 Jahren Unterschied.
Das Tempo ist aber dann dennoch ein wesentlich anderes
Es ist aber ein trauriges Los von AMD, dass sie immer nur dann Kunden haben, wenn sie etwas, was man bei der Konkurrenz seit Jahren hat, wesentlich später und zu einem günstigeren Preis verkaufen muss.

DEIN letzter Satz.
Genau genommen ist es ja später auch kein günstiges Produkt mehr.

 

[spawa93]

Fiji done right reicht aber wohl eben nicht AMD

Wenn das Ding genau aufgebaut ist wie schon 2015 Fiji, wenn auch inklusive GCN 5/1.4 und wir sogesehen nur auf 14nm gesprungen sind, wieso ist das Ding von 596mm² nur auf knapp unter 500mm² gesunken?
Das einzige was ich mir spontan denken kann, ist das VEGA seine Rohleistung dank Neuerungen weitaus besser auf die Straße bringen kann... als Fiji und co und man deswegen wenig mehr Rohleistung braucht?

cmon, wie naiv ist es zu glauben, Vega sei bloss eine Art von Die-Shrink von Fijii. Sorry, aber da der Artikel dies offenbar zu suggerieren versucht, sorgt er unfreiwillig für einigen Spott hier im Forum...

 

[RicoBrassers]

Lowlevel Api sind halt einfach wieder "in mode" obwohl sie gewaltige Nachteile haben.
Lustigerweise ist es OpenGL das heir Vorreiter ist - und dann behaupten leute auchnoch Vulkan sei die Weiterentwicklung....

Korrigiere mich, wenn ich falsch liege, aber OpenGL ist eigentlich eher eine "High-Level API", während Vulkan eine "Low-Level API" ist.
AMD hatte der Khronos Group den Mantle-Code zur Verfügung gestellt, praktisch als Basis für Vulkan, womit Mantle der Vorgänger von Vulkan wäre.

Und naja, Vulkan ist nicht die "Weiterentwicklung" von OpenGL, sondern eine meist performantere Alternative.

 

[XD-User]

Der Zeit weit voraus zu sien bringt nur leider in den seltensten Fällen was, außer vielleicht ner Verbrennung auf dem Scheiterhaufen oder ähnliches

Naja ins Regal legen würde ich mir als Nerd/Fan/Hobbyist die Karte defintiv, der erste kommerzielle Chip mit HBM und einiger technischen Änderungen welche mal etwas ab vom Schuss sind.
Man muss sie weder nutzen noch wirklich lieben, aber etwas "neues" war es defintiv.

Die nackte (sehr kleine) Platine hat in meinen Augen und als Fan meines Hobbys doch schon etwas
Genau wie die Nano.

 

[Kaby-Lame]

Hmmm...
Auf Cb liest sich das bedeutend weniger negativ. Ich glaube nicht, dass Vega schlecht wird! Und sollte es doch so sein glaube ich das erst nach den ersten Tests. Die 12,5 TFlops der Radeon Mi25 werden mMn durch höhere Taktraten wohl noch übertroffen. Aber es ist wohl das klügste einfach zu warten.

 

[Gelöschtes Mitglied 130761]

Hmmm...
Auf Cb liest sich das bedeutend weniger negativ. Ich glaube nicht, dass Vega schlecht wird! Und sollte es doch so sein glaube ich das erst nach den ersten Tests. Die 12,5 TFlops der Radeon Mi25 werden mMn durch höhere Taktraten wohl noch übertroffen. Aber es ist wohl das klügste einfach zu warten.

Eben, wir haben schon die MI25 als Richtwert und Szenen mit diesem Modell sind schon ein paar Monate alt. Wie man nun ernsthaft auf die Idee kommt, dass der Consumer-VEGA so "langsam" wird, wie hier beschrieben, erschließt sich mir überhaupt nicht. Viel Blabla und nichts, aber auch gar nichts Handfestes. Ich sage VEGA wird gut - und ich sage VEGA sollte langsam mal kommen.

 

[Casurin]

Und naja, Vulkan ist nicht die "Weiterentwicklung" von OpenGL, sondern eine meist performantere Alternative.

Eine alternative - sicher.
Aber das macht es weder besser noch schlechter als OpenGL.
Man kann da OpenGl und Vulkan mit VW und Königsegg vergleichen:
Ja Königsegg sind durchwegs Sportwagen. aber zu sagen sie währen generell schneller als VW ist falsch, den dort gibt es alles vom einfachen Familienfahrzeug bis zu Supersportwagen.
OpenGl beitet genauso lowLevel zugriff wie Vulkan - wenn man es richtig macht mit noch weniger Driver-overhead und beinahe direktem zugriff auf die Hardware. Aber eben auch das genaue gegenteil wo man es sich wirklich einfach machen kann und der treiber die ganze Arbeit übernimmt.

Schon mal was in Vulkan oder OpenGL entwickelt? Vermutlich nicht, denn ansonsten würdest du nicht behaupten, dass OpenGL eine Low-Level Schnittstelle ist.

Tja - habe ich a eben - OpenGl ist eine gewaltig umfangreiche API, die eben neben Highlevel auch lowlevel zugriff bietet. Oder war das letzte was du von OpenGl gesehen hast version 2.1?

Bwahaha . Schade, dass AMD nicht auf den Ansatz gekommen ist die GPU "einfach von Haus aus" auszulasten.

Du hast in den letzten jahren anscheinend nicht aufgepasst . was glaubst du hat AMD den an der GCN verändert das die karten jetzt bei 1080p um einiges stärker sind und mit der auflösung gleich skalieren wie Nvidia-kartenß
Ah richtig - das Frontend und den Scheduler angepasst damit die karten auch bei nierdigerer last besser ausgelastet werden.

Im Ernst: Völliger Blödsinn. Async Compute brummt dem Softwareentwickler nicht einfach das Scheduling auf, sondern beschreibt die Möglichkeit Compute und "normale" GPU-Calls ohne Context-Switch auf der gleichen GPU ausführen zu können.

Noep, ein context-switch ist IMMER von nöten wenn der thread geändert wird. Nur eben hat AMD sich dazu entschlossen für den Context-switch extra caches einzubauen damit dieser shcneller von statten geht.
Lies dir hierzu doch einfach AMDs Dokumentation der GCN durch..... oder ihre Präsentationen wo sie schön darauf aeingehen das sie eben den Context-Switch beschleunigen um Dx12 Async-compute Eingriffe zu beschleunigen - was wiederum gemacht wird um die Shader-Auslastung zu steigern.
Wenn man das ganze dann mit Nvidia vergleicht sieht man dies schon bei maxwell nichts gebracht hätte da der Scheduler die Hardware bereits effizient mit Threads versorgt. Da werden Compute-tasks gut in den ablauf integriert und somit bringen extra context-switches, auch wenn sie mit 0 Overhead vonstatten gehen würden keinen Leistungsvorteil.



Ich kanns für dich auch vereinfachen:
Dx12 Asynch Compute ist nur die Option die Aktuelle Aufgabe beiseite zulegen um einen anderen Task auszuführen. Mann kann sich das ganze wie ein großes Büro mit vielen Angestellten vorstellen.
Bei AMD bekommt jeder angestellte die gleiche Art von Arbeit nur oft sind einige Arbeiter schon früh mit der Aufgabe fertig bzw haben weniger oder gar keine Erhalten. Wenn ein async-Befehl daherkommt kann jeder Arbeiter seine derzeitige Aufgabe auf einen eigenen Abstellstapel legen und den Compute-taks abarbeiten udn sich dannach wieder um die eigentliche Aufgabe kümmern.
Bei nvidia ist die Aufgabenverteilung etwas komplexer und es wird so verteilt das alle Arbeiter dauerhaft beschäftigt sind. Wobei jeder Arbeiter einen konstanten Strom von Grafik bzw Compute-threads erhält. Wenn aber ein Dx12 Async-befehl kommt muss der aktuelle Thread zurückgelegt werden - er beleibt eben nicht in einem localen cache.
Heisst Async wird sehr wohl Hardwareseitig unterstüzt, nur es wird nicht extra durch einen cache beschleunigt da unter normalen Bedingungen (volle Auslastung der Cores, Compute-tasks im normalen Scheduler) dadurch kein Vorteil entsteht.

Der Sinn von Async-compute ist eben genau das man den Scheduler umgeht und zu einem beliebigen zeitpunkt einen Compute-task einschieben kann - was selten effizient ist und meist von sehr schlechtem Code-design zeugt - genauso wie bei CPUs das dauerhafte nutzen von Interrupts.