Test Forza 7 Benchmark: Vega hat mehr Benzin im Blut als Pascal

[xexex]

Was DX12 angeht stimme ich dir zu, aber DX11 ist bereits schon lange nicht mehr adequat. Das sieht man daran wieviel Aufwand getrieben werden muss um die Unzulänglichkeiten von DX11 zu umgehen.

Die Entwickler äußern sich da eher ganz anders und sehen viele Probleme auf der DX12 Seite.

“If you take the narrow view that you only care about raw performance you probably won’t be that satisfied with amount of resources and effort it takes to even get to performance parity with DX11,” explained Rodrigues. “I think you should look at it from a broader perspective and see it as a gateway to unlock access to new exposed features like async compute, multi GPU, shader model 6, etc.”
https://www.pcgamesn.com/microsoft/ubisoft-dx12-performance

Consequently, memory management under DirectX 12 is still a challenge, albeit one that’s evolving. Under DirectX 11 memory management was typically a driver problem, and the drivers usually got it right – though as Baker noted in our conversation, even now they do sometimes fail when dealing with issues such as memory fragmentation. DX12 on the other hand gives all of this control over to developers, which brings both great power and great responsibility. PC developers need to be concerned with issues such as memory overcommitment, and how to gracefully handle it. Mantle users will be familiar with this matter: most Mantle games would slow to a crawl if memory was overcommitted, which although better than crashing, is not necessarily the most graceful way to handle the situation.
https://www.anandtech.com/show/10136/discussing-the-state-of-directx-12-with-microsoft-oxide-games

Im Gespräch identifiziert er zahlreiche Fallstricke bei der Softwareentwicklung und macht direkt klar, dass es nicht leicht ist, die Spiele-Performance mit DirectX 11 zu schlagen. 2016 musste sich Nixxes vor allem mit Early-Adopter-Problemen von DirectX 12 herumschlagen. Fehlende Debugging Tools, spärliche Dokumentationen und langwierige Treiberprobleme machten die DirectX-12-Versionen zu einer mühsamen Erfahrung. Dies führte auch zu den späten Nachreichungen der DirectX-12-Versionen der genannten Spiele. Auch wenn diese Probleme über die Zeit weniger werden, warten weiterhin zahlreiche Schwierigkeiten. Vor allem die Speicherverwaltung von DirectX 12 ist sehr unterschiedlich zu DirectX 11 und anfällig, wenn man den physischen Grafikspeicher überfüllt. Durch den low-level-Ansatz gibt es auch zahlreiche Leistungsunterschiede je nach verwendeter Hardware. Dadurch muss man sehr viele Hardwarekombinationen durchtesten um Performance-Bottlenecks auf den meisten Plattformen zu finden. Zu guter Letzt ist die gewonnene Performance durch den verminderten Overhead leicht verdeckt, in dem man z.b. GPU-limitiert arbeitet. Ein schneller Prozessor und hohe Grafikeinstellungen sowie Auflösungen können die Gewinne maskieren, wodurch der Nutzer keinen Unterschied zu DirectX 11 feststellt. Async-Compute ist derzeit der richtige Weg für die Zukunft, bringt jedoch hauptsächlich auf Konsolen spürbare Vorteile.
https://www.notebookcheck.com/Zahlt-sich-DirectX-12-aus-Ein-Game-Developer-packt-aus.199704.0.html

The DX12 API places more responsibilities on the programmer than any former DirectX™ API. This starts with resource state barriers and continues with the use of fences to synchronize command queues. Likewise illegal API usage won’t be caught or corrected by the DX-runtime or the driver. In order to stay on top of things the developer needs to strongly leverage the debug runtime and pay close attention to any errors that get reported. Also make sure to be thoroughly familiar with the DX12 feature specifications.
https://developer.nvidia.com/dx12-dos-and-donts

Vom Prinzip ist der Tenor aber überall gleich. Einen Leistungsvorsprung durch DX12 gibt es nur, wenn man viele Ressourcen in die Optimierung steckt und diese Optimierung auch noch für jede der Architekturen durchführt. Das Ergebnis sehen wir ja bei den bisherigen Titeln und der erhöhte Aufwand dürfte einige Entwickler abschrecken.

 

[Esenel]

Ich weiß nicht, ob es schon wer geschrieben hat, aber so lange hier für Ryzen ausgebremste Benchmarks gemacht werden, ist die CPU Liste nutzlos.
Ryzen muss mit Ram 3466 CL14 betrieben werden. Der Rest bremst unnötig aus.

https://youtu.be/S6yp7Pi39Z8

Kann sich jeder selber mal ansehen.

 

[Zuckerwatte]

Ich habe heute auch eine Schwalbe gesehen: Der Frühling kommt

Was hat Fußball mit einer Jahreszeit zu tun?

(ja ich bin kindisch)

 

[modena.ch]

ist das so? Wenns drum geht 400 FPS in FHD auszugeben mag das sein, aber es gibt viele Titel bei denen DX12 / DX11 kaum was bringt (bei AMD wie Nvidi) oder zT sogar DX12 leicht langsamer ist.

Da DX11 serienmässig die Hauptrechenlast auf einen Thread legt-> selbstverständlich.
Das was da nebenbei noch läuft könnte ein Pentium1 abarbeiten.

Nur dank Treibermagie und Gepfusche gegen die API-Standards kann man das umgehen.

Es ist allerhöchste Zeit dass wir davon weg kommen!

 

[Taxxor]

Habe ich nicht ignoriert, Mr. Cherrypicker. Es gibt genügend Beispiele, die meine Aussage untermauern.

Sagte er, nachdem er für seine Aussage genau ein Beispiel angeführt hat.

 

[LyGhT]

Sagte er, nachdem er für seine Aussage genau ein Beispiel angeführt hat.

Er hat es "gekonnt" ignoriert, ob man es glauben will oder nicht.

 

[Limit]

Aber wenn jeder GPU Hersteller wieder seine eigenen Bibliotheken für DX12 entwickelt und zur Verfügung stellt, wären wir dann nicht wieder beim Gameworks Konzept?

Um möglichst hohe Leistung zu erhalten braucht man auf jeden Fall Optimierungen, die man nicht auf der DX11-API implementieren kann, d.h. jeder Hersteller muss diese separat in seinen Treibern umsetzen. Das betrifft aber nicht nur Hersteller- und/oder Architektur-spezifische Optimierungen, sondern auch viele, die eher generisch oder Engine-abhängig sind. Was die Entwickler durch eine modulare Bibliotheks-Architketur gewinnen würde wäre Flexibilität, so könnten sie z.B. Teile der Hersteller-Implementierung nehmen und diese mit eigenen oder 3rd-Party-Modulen mischen. Je mehr Optimierungen man in generische Module packen kann, desto weniger Architektur-spezifischen Code muss man schreiben.

Ich denke das liegt durchaus auch mit an der Architektur. AMD verbaut traditionell relativ viele ALUs und hatte unter DX11 und davor immer sehr viele Probleme die richtig mit Arbeit zu versorgen.

Das Problem besteht im Grundsatz allerdings auch unter DX12 noch. Ich bin nicht sicher, ob man das durch eine neue API wirklich lösen kann. Sicherlich hilft DX12 und Async Compute dabei, aber Software-seitigen Optimierungen sind Grenzen gesetzt.

Vom Prinzip ist der Tenor aber überall gleich. Einen Leistungsvorsprung durch DX12 gibt es nur, wenn man viele Ressourcen in die Optimierung steckt und diese Optimierung auch noch für jede der Architekturen durchführt. Das Ergebnis sehen wir ja bei den bisherigen Titeln und der erhöhte Aufwand dürfte einige Entwickler abschrecken.

Natürlich ist es erst einmal ein großer Aufwand, aber man hat diesen ja nicht bei jedem Projekt auf's neue. Wie oben schon geschrieben sind viele dieser Optimierungen, die bisher in den Treibern steckten von Natur aus generisch, sprich sie funktionieren unabhängig von der GPU-Architektur und waren bisher nur in den Treibern, weil sie für DX11 zu Low-Level waren. Aber selbst bei den Architektur-spezifischen Optimierungen dürften viele ein guter Teil über mehrere Generation mit bestenfalls leichte Anpassungen wiederverwendbar sein wenn man sich die eher evolutionäre Entwicklung der GPUs anschaut.

 

[Taxxor]

Vom Prinzip ist der Tenor aber überall gleich. Einen Leistungsvorsprung durch DX12 gibt es nur, wenn man viele Ressourcen in die Optimierung steckt und diese Optimierung auch noch für jede der Architekturen durchführt.

Ich weiß nicht so recht, bei Forza 7 profitieren ja alle AMD Karten, von der 380 bis zur Vega, das sind insgesamt 5 Architekturen, auch wenn sie sich natürlich alle ähneln.
Ich kann mir schwer vorstellen, dass Turn 10 für alle diese Architekturen einzeln optimieren musste.

 

[xexex]

Wie oben schon geschrieben sind viele dieser Optimierungen, die bisher in den Treibern steckten von Natur aus generisch, sprich sie funktionieren unabhängig von der GPU-Architektur und waren bisher nur in den Treibern, weil sie für DX11 zu Low-Level waren.

Die Aussage stimmt so leider nicht und genau das hier ist doch der Punkt, den auch die Entwickler ansprechen. Um wirklich gute Leistungen zu erhalten müssen diese Optimierungen nun für jede Hardware einzeln in die Anwendungen fließen.

Durch den low-level-Ansatz gibt es auch zahlreiche Leistungsunterschiede je nach verwendeter Hardware. Dadurch muss man sehr viele Hardwarekombinationen durchtesten um Performance-Bottlenecks auf den meisten Plattformen zu finden.

Während nun die Optimierungen bisher in den Treibern stattfanden und von Herstellern an jede Hardware und Anwendung optimiert wurden, liegt diese Arbeit bei den Applikationsentwicklern. Gerade in Anbetracht an zukünftige Entwicklung ist das erschreckend, oder glaubt jemand ein Spielehersteller wird jahrelang Updates für kommende Grafikkartengenerationen bereitstellen?

 

[aldaric]

Mal drüber nachgedacht das es eine schöne Ausrede ist um schlechte DX12 Ports zu erklären oder sich direkt den Aufwand zu sparen?

Warum was neues lernen, wenn man Jahre brauchte um bei DX11 die API-Probleme zu umgehen.

 

[kisser]

Benutzt man DX11 so wie es designt wurde, kann man selbst aus modernen Grafikkarten kaum die Leistung herausholen, die für anspruchsvolle Spiele nötig ist.

Das beweisen dir aber jede Menge Entwickler das Gegenteil. Man muss eben nur die Limits dieser API beachten.

 

[Taxxor]

kisser: Das liegt aber eben nur daran, dass man es eben nicht so benutzt, wie es designed wurde, sondern diese Limits per Treiber so gut es geht umschifft.
Die Kernaussage bleibt also richtig.

Wenn ich meine Grafikkarte undervolte und/oder übertakte um mehr Leistung und/oder weniger Verbrauch zu erhalten, benutze ich die Karte ja auch nicht so, wie sie designed wurde.

 

[kisser]

Was DX12 angeht stimme ich dir zu, aber DX11 ist bereits schon lange nicht mehr adequat. Das sieht man daran wieviel Aufwand getrieben werden muss um die Unzulänglichkeiten von DX11 zu umgehen.

Dieser Aufwand ist derzeit noch weitaus geringer als der Aufwand, den man für DX12 betrieben muss. Man muss unter DX11 vernünftig mit den "Draw Calls" haushalten, weil sonst die CPU limitiert. Irgendwann wird das einmal unwirtschaftlich werden, weil man auch nicht beliebig viel in einen Draw Call reinpacken kann. Da sind wir aber noch weit davon weg.

Ergänzung (4. Oktober 2017)

Vom Prinzip ist der Tenor aber überall gleich. Einen Leistungsvorsprung durch DX12 gibt es nur, wenn man viele Ressourcen in die Optimierung steckt und diese Optimierung auch noch für jede der Architekturen durchführt.

Genau das, was ich die ganze Zeit sage.

Ergänzung (4. Oktober 2017)

Ryzen muss mit Ram 3466 CL14 betrieben werden. Der Rest bremst unnötig aus.

Und du garantiert dann, dass das auch jeder Ryzen schafft?

Ergänzung (4. Oktober 2017)

Da DX11 serienmässig die Hauptrechenlast auf einen Thread legt-> selbstverständlich.

Macht DX11 nicht. Das Multithreading muss sauber im Treiber implemetiert sein und da klemmt es bei AMD ganz gewaltig. Deshalb wird es so wenig genutzt. Henne-Ei-Problem.
https://msdn.microsoft.com/de-de/library/windows/desktop/ff476889(v=vs.85).aspx

 

[Limit]

Die Aussage stimmt so leider nicht und genau das hier ist doch der Punkt, den auch die Entwickler ansprechen. Um wirklich gute Leistungen zu erhalten müssen diese Optimierungen nun für jede Hardware einzeln in die Anwendungen fließen.

Manche Optimierungen ja, viele aber auch nicht. Das sieht man z.B. auch an den Linux-Treibern. Dort gibt es mit Gallium3D eine Treiber API mit der große Teile der GPU-Treiber gemeinsam genutzt werden können. Natürlich gibt es auch dort architekturspezifische Teile. Diese machen aber nur einen geringen Teil aus. So teilen sich z.B. die offenen AMD und nVidia Treiber, sowie mehrere Treiber von GPUs in verschiedenen ARM-SoCs große Teile des Codes. Die Modularität geht sogar soweit, dass es mittlerweile für Gallium3D ein Modul gibt, dass DX9 unter Linux bereitstellt (ein DX10/11 Modul ist in Arbeit). Tests mit einer angepassten wine-Version, die dieses Modul nutzt zeigt eine größtenteils gleiche Performance unter Windows und Linux und die offenen Linux-Treiber enthalten garantiert keinerlei Optimierungen für Windows-Spiele.

Während nun die Optimierungen bisher in den Treibern stattfanden und von Herstellern an jede Hardware und Anwendung optimiert wurden, liegt diese Arbeit bei den Applikationsentwicklern. Gerade in Anbetracht an zukünftige Entwicklung ist das erschreckend, oder glaubt jemand ein Spielehersteller wird jahrelang Updates für kommende Grafikkartengenerationen bereitstellen?

Du glaubst doch nicht etwa, dass AMD/nVidia bei Optimierungen für neue GPU-Generationen noch irgendwie groß Rücksicht auf alte Software nimmt? Für alles, was nicht halbwegs aktuell oder zumindest noch sehr oft gespielt/gebencht wird müssen einfach die generischen Optimierungen mit der höheren Rohleistung der neuen GPUs ausreichen, was in der Regel auch der Fall sein dürfte.

Das beweisen dir aber jede Menge Entwickler das Gegenteil. Man muss eben nur die Limits dieser API beachten.

Bei DX11 war es niemals vorgesehen, dass die Spiele-Entwickler auf spezielle Architekturen und/oder Treiber optimieren. Genauso wenig war vorgesehen, dass die Treiber für jedes Spiel extra Anpassungen enthält. Wenn du diese Optimierungen entfernst, wirst du kaum ein anspruchsvolles Spiel gescheit zum laufen bekommen, selbst mit absoluter High-End-GPU nicht.

 

[Taxxor]

oder glaubt jemand ein Spielehersteller wird jahrelang Updates für kommende Grafikkartengenerationen bereitstellen?

Das ist aber dort, wo die Updates für den Treiber kommen auch nicht anders. Es gibt viele ältere Spiele, in denen ich rein von der Rohleistung weit über 300fps haben müsste, aber trotz relativ hoher Auslastung nicht mal 100 rauskommen.

 

[Iscaran]

Kisser:
Mit dir zu diskutieren ist hoffnungslos. Man sieht dass du keine Ahnung hast wie man Multithreaded software erstellt.

Dieser Aufwand ist derzeit noch weitaus geringer als der Aufwand, den man für DX12 betrieben muss. Man muss unter DX11 vernünftig mit den "Draw Calls" haushalten, weil sonst die CPU limitiert. Irgendwann wird das einmal unwirtschaftlich werden, weil man auch nicht beliebig viel in einen Draw Call reinpacken kann. Da sind wir aber noch weit davon weg.

Das Draw Call "limit" in Games wurde bereits vor Jahren erreicht und seitdem immer wieder durch "kreatives" arbeiten wie von Limit beschrieben umgangen.

Beispiele: Oxide games Engine, Open World Spiele mit vielen vielen Objekten. (z.B. Total war serie). usw.
AoTs um mal ganz konkret was zu nennen - ein game von dem die Entwickler sagten sie hätten gerne mehr gemacht aber sie hängen im Draw Call limit...

Macht DX11 nicht. Das Multithreading muss sauber im Treiber implemetiert sein und da klemmt es bei AMD ganz gewaltig. Deshalb wird es so wenig genutzt. Henne-Ei-Problem.
https://msdn.microsoft.com/de-de/library/windows/desktop/ff476889(v=vs.85).aspx

[/Quote]

Du hast sicherlich auch gelesen:
https://msdn.microsoft.com/de-de/library/windows/desktop/ff476884(v=vs.85).aspx
https://msdn.microsoft.com/de-de/library/windows/desktop/ff476893(v=vs.85).aspx
https://msdn.microsoft.com/de-de/library/windows/desktop/ff476890(v=vs.85).aspx

Da steht dann z.B. das das Multithreading nicht von DX11 erledigt wird sondern vom Treiber...und DX11 lediglich die Option bietet das der Treiber dies Multithreaded angehen kann.
Zitat: "Der Grad der Gleichzeitigkeit bei Ressourcenerstellung und Rendering, den Ihre Anwendung erreichen kann, hängt von der Stufe der Multithreadingunterstützung ab, die vom Treiber implementiert wird."

Das Problem dabei ist aber...WIE sollen denn die Treiberleute (z.B. von AMD) wissen:
- Wieviele Objekte, in welcher Abhängigkeit voneinander und ggf. mit welcher Synchronisation aber an unterschiedliche Threads ausgegeben werden können und das OHNE einblick in den Source Code der Anwendung zu haben ?
Henne / Ei Problem ?
Ja vielleicht. Aber genau diese Dinge können am ehesten die Softwareprogrammierer wissen und sehen - insbesondere das mit den Abhängigkeiten.
Daher ist Multithreading etwas das der Softwareentwickler liefern muss und nicht die Treibercrew "reverse engineered" hinterher an die Software anpasst.
NUR DANN funktoniert multithreading richtig, wenn es nämlich schon DIREKT bei der Codeerstellung verwendet und beachtet wird.

In DX12 ist das eben genau anders. Die Multithreadunterstützung ist DIREKT eine Kernfähigkeit der API geworden....man kann nun unendlich viele Renderthreads haben und nicht nur 1 Hauptthread der nebenthreads spawnen kann sofern X damit verbunden Probleme gelöst sind.

Klar muss diese Multithreadunterstützung der Entwickler liefern. Denn der muss/kann feststellen wieviele wirklich unabhängige Variablen in seinem Code stecken und kann diese Entsprechend parallelisieren.
Reverse Engineering von Multithreading über den Treiber war und ist eine Krücke gewesen. Dies wurde nur exzessiv von nVidia in den letzten Jahren praktiziert (und dank gameworks wohl auch "vereinfacht" da man damit bestimmtes codeverhalten halt "kannte" bzw. "standardisiert" hatte. Dennoch war es eine Krücke um wenigstens halbwegs SINNVOLL mit der verfügbaren CPU Power umzugehen und die Limits von DX11 auszuhebeln.

Klar stimmt es schon dass AMD GPUs in DX11 generell nicht ihre Rohleistung auf die Strasse bringen - z.T. auch wegen der Architektur. Aber diese Architektur ist so fundamental auf Multithreading ausgelegt dass Sie eben auch einfach "an der DX11 API verhungert" (zumindest seit GCN).

P.S.: Diesen Link hier finde ich immer wieder gut zu lesen - habe ich irgendwann zufällig über eine Diskussion bei Beyond3D aufgeschnappt:
http://ext3h.makegames.de/DX12_Compute.html

EDIT NACHTRAG: Oh by the way - etwas Lektüre fürs Verständnis (allerdings nur in Englisch):
https://www.pcper.com/reviews/Editorial/What-Exactly-Draw-Call-and-What-Can-It-Do
http://www.theappguruz.com/blog/learn-draw-call-reduction-and-make-your-games-run-superfast
Besonders "Nice":
https://www.reddit.com/r/Games/comments/2vafix/directx_12_is_able_to_handle_600k_draw_calls_vs/
Zitat:
"Why is it comparing itself to DX9... and not 10 or 11? DX9 isn't exactly cutting edge."
Antwort:
"Because DX 9, 10 and 11 are the same when it comes to how many draw calls they can handle. It doesn't matter if they're comparing it to DX 9."
Allerdings ist diese Sicht der Dinge zu einfach - das "instancing" das mit DX10 eingeführt wurde war ein erster Versucht dieses Problem anzugehen und hat auch dazu geführt dass man von einigen "hundert" Draw calls auf einige Zehntausend gehen konnte....Aber damit ist man immernoch Meilenweit von den einigen hunderttausend bis Millionen entfernt die man heutzutage für Games so braucht.

EDIT2: https://stackoverflow.com/questions/4853856/why-are-draw-calls-expensive
Zitat: But the main cost of draw calls only apply if each call submits too little data, since this will cause you to be CPU-bound, and stop you from utilizing the hardware fully. Just like Josh said, draw calls can also cause the command buffer to be flushed, but in my experience that usually happens when you call SwapBuffers, not when submitting geometry. Video drivers generally try to buffer as much as they can get away with (several frames sometimes!) to squeeze out as much parallelism from the GPU as possible.

=> Das Buffer flushing das nVidia Treiber wohl sehr exzessiv nutzen z.B. könnte meiner Ansicht nach das Problem sein warum Ryzen hier durch die Cache-Architektur bedingt so "Probleme" hat...Denn ein voller Cache flush kostet bei Ryzen direkt Speed da cross-CCX ans RAM gebunden. @Intel kostet das viel weniger Leistung (zumindest solange man kein Mesh hat).

 

[Mcr-King]

Mann ich sage immer wieder die meisten Entwickler sind faull und unfähig punkt warum wird der RAM und VRAM so verschwendet. Natürlich auch der Zeitdruck der Publishers kommt auch noch dazu. Denn als gutes gegen Beispiel schaut euch Crysis an wie gut dass immer noch aussieht und und und.

Naja auch an der Switch sieht man gut was Vulkan leisten kann plus Gameworks natürlich. ;-)

Ja die Switch hat auch sowas ähnliches wie Gameworks.

Gut Fakt ist eins ich will nach über 6 Jahren endlich mehr echte DX12 Games sehen.

 

[Wadenbeisser]

Ach herrlich wie einige wieder mit den Benchmarks angekrochen kommen die mit maßlos übertakteten CPUs arbeiten, damit den größten Vorteil der neuen APIs aushebeln und sich dann hinstellen und sagen das die neue API überflüssig wäre.

 

[SimsP]

@Limit: Prinzipiell eine schöne Idee mit den Libs, nur bezweifle ich, dass es sich so einfach wird realisieren lassen können.
AMD hat bislang nicht gerade besonders viel Manpower in das Bauen von Libraries und Treibern gesteckt. Man baut wohl eher auf den Opensource-Weg im Sinne von Arbeit auslagern wo es nur geht. Das mag ja auch ganz nett sein, nur nicht unbedingt sinnvoll wenn es um hardwarenahe Softwareoptimierung geht, denn dazu braucht man Insider-Wissen von der Architektur und die gibt AMD natürlich genausowenig raus wie NVidia.
Ich bin mir auch sicher, dass NVidia für DX12 wieder entsprechende Softwareoptimierungen umsetzen wird, nur bezweifle ich, dass es quelloffen wird und dementsprechend auch schlecht geeignet für eine Zusammenführung mit AMD Libraries. Da bekleckern sich beide nicht gerade mit besonders viel Ruhm.

Ich weiß nicht so recht, bei Forza 7 profitieren ja alle AMD Karten, von der 380 bis zur Vega, das sind insgesamt 5 Architekturen, auch wenn sie sich natürlich alle ähneln.
Ich kann mir schwer vorstellen, dass Turn 10 für alle diese Architekturen einzeln optimieren musste.

Naja also Polaris profitiert nicht so wirklich . Wenn man sich mal anschaut, dass eine RX580 normalerweise im Schnitt fast 2,5 mal so schnell ist wie eine RX460, in Forza 7 hingegen nur 1,9 mal. Auch Vega schneidet hier gegenüber der normalerweise 3,6 mal so hohen Leistungsfähigkeit mit 3,2 mal eher schlecht ab. Dafür wird die Leistungslücke zwischen RX580 und Vega etwas größer als sonst.
Alles in allem muss man aber sagen, dass auch Vega im Verhältnis zum CB Durchschnitt bei 1080p gegenüber einer Standard RX460 eher schlecht abschneidet. Sie bricht nicht ganz so stark ein wie Polaris oder die NVidia GPUs, aber ein tolles Ergebnis ist es eben auch nicht.
Daher kommt es auch, dass Vega in 1080p deutlich an den 1080er Modellen vorbeizieht, wohingegen eine RX580 sich wieder in etwa auf dem Niveau einer 1060 bewegt.
Vermutlich liegt es daran, dass Vega, wie man aus den Benchmarks zu den CPUs entnehmen kann in 1080p, wie wahrscheinlich alle anderen Karten auch, immer noch im CPU Limit hängt. Nicht so sehr wie Polaris und Pascal, aber trotzdem sichtbar. Hier wäre es mal interessant, wenn von CB ein Test zur CPU Performance über mehr GPU Architekturen kommen würde, als nur Vega. Zumindest CPU Vergleichsdiagramme für Polaris und Pascal wären ebenfalls durchaus interessant.

Wie dem auch sei, das alles spricht in meinen Augen eher für eine verduddelte Optimierung des Spiels im Bezug auf CPU-Performance als für irgendwas anderes. Deswegen vllt. erst mal die ersten Patchs abwarten bevor man voreilige Schlussfolgerungen trifft.

 

[Limit]

@Limit: Prinzipiell eine schöne Idee mit den Libs, nur bezweifle ich, dass es sich so einfach wird realisieren lassen können.

Einfach wird das sicherlich nicht, aber solche Libs werden auf jeden Fall entstehen. Das ist eigentlich nur eine Frage der Zeit, denn jeder, der DX12 nutzt wird solche Libs entweder selbst entwickeln oder einkaufen. Ich hoffe ja, dass sich die GPU-Hersteller auf eine gemeinsame Lib einigen könnten und die als Open Source verteilen. Bei AMD und Intel halte ich das sogar für halbwegs realistisch, denn unter Linux arbeiten die beiden jetzt schon gemeinsam an den Treibern während nVidia weiterhin ausschließlich auf ihren propritären Treiber setzt.

AMD hat bislang nicht gerade besonders viel Manpower in das Bauen von Libraries und Treibern gesteckt.

Richtig, aber wenn sie die Optimierungen in den Treibern in eine Lib packten, wäre das schon ein großer Schritt und würde vielen Entwicklern das Leben vereinfachen.

Man baut wohl eher auf den Opensource-Weg im Sinne von Arbeit auslagern wo es nur geht. Das mag ja auch ganz nett sein, nur nicht unbedingt sinnvoll wenn es um hardwarenahe Softwareoptimierung geht

Das ist richtig, allerdings wird der Bedarf an wirklich architekturspezifischem Code häufig deutlich überschätzt. In vielen Fällen könnte man auch Code teilen und ihn einfach nur parametrisieren um kleinere Unterschiede auszugleichen. Das sieht man bei den Open Source Treibern unter Linux wo der Architektur-/Hersteller-spezifische Codeanteil nur einen geringen Anteil ausmacht.

denn dazu braucht man Insider-Wissen von der Architektur und die gibt AMD natürlich genausowenig raus wie NVidia.

Bei nVidia hast du größtenteils recht, aber AMD hat sehr detailierte Architekturbeschreibungen veröffentlicht mit deren Hilfe Entwickler z.B. die offenen Linux-Treiber geschrieben haben. Mittlerweile ist der Open Source Treiber bei einigen Anwendungen deutlich schneller als der propritäre und nur noch selten deutlich langsamer.

Ich bin mir auch sicher, dass NVidia für DX12 wieder entsprechende Softwareoptimierungen umsetzen wird, nur bezweifle ich, dass es quelloffen wird und dementsprechend auch schlecht geeignet für eine Zusammenführung mit AMD Libraries. Da bekleckern sich beide nicht gerade mit besonders viel Ruhm.

Das befürchte ich auch, aber das wäre keine Verschlechterung, denn nVidia macht das heutzutage ja auch nicht anders.