• Mitspieler gesucht? Du willst dich locker mit der Community austauschen? Schau gerne auf unserem ComputerBase Discord vorbei!

Test World of Warcraft: DirectX 12 macht AMD schneller, Nvidia bricht ein

Feranor schrieb:
Prinzipiell richtig, aber ich hätte lieber nützliche und leicht ungenaue Zahlen, als exakte Zahlen, die kaum eine Aussagekraft haben.
die wären nicht nur leicht ungenau ;)
in den nächsten Wochen wirst du mehr wissen - es wird mehr tests geben.
cb wird seinen test auch nochmal wiederholen - atm ist es eher ein gpu test.
ich kann nix testen - hab weder wow gerade installiert, noch hab ich Windows 10 ^^
 
Ehrlich gesagt verstehe ich die gesamte Diskussion hier nicht.

a) Es ist gut, dass es eine DX-Weiterentwicklung gibt, auch wenn ich Vulkan für viel besser halte, da es betriebssystemunabhängig ist.
b) DX12 macht genau das was es soll. Unter anderem gibt es bei langsameren CPUs und einer schnellen Graka noch mehr FPS. Siehe mein Bild, da die ganz rechte Spalte...
c) Das die nVidia Karten so abkacken liegt einzig und allein an nVidia. 1) Schaffen die es nicht die DX12 API richtig zu implementieren. 2) Wird die Karte evtl. sogar von der Hardware her nicht dazu in der Lage sein. So wie sie bei der einen Gen. behauptet haben, dass sie DX12 kann, aber es in Wirklichkeit nur DX11_2 war.
d) Wartet mal die nächsten nVidia Treiber ab, die werden wohl noch optimieren. Zumindest hoffe ich das für alle armen Teufel die nVidia gekauft haben.
 

Anhänge

  • cpus.png
    cpus.png
    28,4 KB · Aufrufe: 595
cruse schrieb:
die wären nicht nur leicht ungenau ;)

Ich habe zum Testen die Greater Invasion in der "Pilz-Zone" benutzt. Ist fast immer gleich: 40 Leute feuern auf den einen Boss Mob, der in regelmäßigen Abständen Debuffs verteilt. Dort hatte ich mit meinem alten UI zunächst ~20 FPS und nach dem Aufräumen (keine Damage Meter etc. mehr) ~45.

Mythic Varimathras / Sisters of Elune sind ebenso recht konsistent, aber eben wesentlich schwieriger zu organisieren.
 
Mein Q6600@3Ghz mit einer AMD HD6870/1GB läuft noch mit WoW ... obwohl er unter den Mindestanforderungen ist. Allerdings ist die Grafik jetzt kantiger - ich wurde also downgegradet ;) (Stufe 2 oder 3) ... ABER: die CPU ist 10 Jahre alt. Die GPU 8 Jahre. Was will ich da erwarten. Da meckere ich nicht! Blöd ist das die HD6870 unter MacOSX kein Metal unterstützt - der PC soll in paar Wochen/Monaten zu einem Hackingtosch mutieren .... WoW unter MacOSX kann ich somit knicken :|

Worüber ich aber mecker ist das der Vollbild-Modus entfernt wurde. Gerade wenn man mal auf den Desktop switchen möchte, geht das mit TAB nur noch mäßig - da kann ich nur noch in offene Anwendungen switchen. Also WIN+D um auf den Desktop zu switchen ... die BÖSE WIN-Taste wo man versehentlich immer mal drauf kommt, weswegen nicht wenige Gamer-Tastaturen die WIN-Taste per Hardware bzw. Software deaktivieren. Ich hab die deaktivierung rausgenommen und landete in 2h spielen nicht selten mal auf der WIN-Taste :( ES NERVT! Also heißt es: ständig deaktivieren, aktivieren ...

Ist das beim Fenstermodus nicht so das die GPU ALLES rendert was irgendwo aufm Desktop offen ist ... also JEDES Fenster. Im Vollbildmodus aber die GPU zu 100% dem Vollbild zur verfügung steht? Heißt: je mehr GPU-Intensives ich im Hintergrund aufhabe (z.b. komplexere Webseiten ... in 3-4 Tabs)m desto mehr FPS-Verlust erleide ich im SPIELE-Fenster?

Ich hab eine Logitech G910. WIN kann ich per Taste deaktivieren. Kann man WIN+D auf eine MAKROTASTE legen und WIN somit DEAKTIVIERT lassen? Würde mein WIN-Problem enorm verbessern - auf eine Makrotaste bin ich noch nie versehentlich gekommen :p
 
Wulfman_SG schrieb:
die BÖSE WIN-Taste
strg+esc :rolleyes:
Feranor schrieb:
(keine Damage Meter.
was hast du vorher benutzt ? ich glaub ich hatte zum schluss "Details!".
auf jeden fall sind dmg meter etc nicht ganz unschuldig an low fps ;)

Ist die Invasion immer verfügbar ?

cb hätte nur im LFR testen können...den kann man nonstop wiederholen
suramar ist solo auch nicht schlecht
Wolfgang liefert bestimmt noch was nach ;):evillol:
 
Die Überschrift ist mir zu reißerisch. Wo ist denn jetzt AMD soviel schneller, eure Benchmarks zeigen doch was völlig anderes auf.

Unter DX12 schließt AMD mit +9% lediglich zu Nvidias DX11 Performance auf, was sich unter höheren Auflösungen als 1080p völlig egalisiert und eigentlich zeigt das die DX12 CPU Multicore Drawcalloptimierungen ins Leere laufen, weil es eben kein reiner DX12 API Stack ist, sondern eher eine Mischung aus DX11.3 und optionalen DX12 Optimierungen (also eher DX12 ready, was Steigerungen bei der Drawcallperformance ausschließt). Solange ein i3 8100 bei den CPU Benchmarks oben mitspielt, ist das ein klarer Beweis dafür, dass sich die Optimierungen für den Entwickler und die vielen Zeilen Code mehr, die unter LowLewel erforderlich sind kaum lohnen, weil sie einen Haufen Mehrarbeit und grundlegende Anpassungen bei der Engine bedeuten. Davor scheuen sich die meisten Publisher und Studios.

Das Nvidia kurz vor Einführung einer neuen Gen, die Alte eher etwas vernachlässigt, um den Abstand zur neuen dann demonstrativ gut aussehen zu lassen, ist ja auch nicht neu. Damit haben sich die Nvidiakäufer ja mehr oder weniger abgefunden.

Die Super DX12 Performance bei Vega sucht man immer noch vergebens, wenn man bedenkt das die Karten zeitweise genauso teuer wie eine 1080ti waren und im Handel immer noch zirka 100$ mehr kosten als eine 1080. Aus Preis/Leistung Sicht stimmt das Gefüge also völlig und nVidia wird wohl mit Turing nachlegen.

Diese ganzen "DX11 to DX12 Ports" sind eben nicht das Wahre, wie man an Doom oder Wolfenstein gut sieht, kann AMD Hardware LowLevel viel mehr leisten.

Wulfman_SG schrieb:
Ist das beim Fenstermodus nicht so das die GPU ALLES rendert was irgendwo aufm Desktop offen ist ... also JEDES Fenster. Im Vollbildmodus aber die GPU zu 100% dem Vollbild zur verfügung steht? Heißt: je mehr GPU-Intensives ich im Hintergrund aufhabe (z.b. komplexere Webseiten ... in 3-4 Tabs)m desto mehr FPS-Verlust erleide ich im SPIELE-Fenster?
Der Codeunterschied Borderless vs Fullscreen ist eigentlich marginal und für Multitask ist Borderless einfach die bessere Wahl. Dabei ist Borderless technisch eigentlich kein Problem, erhöht aber den Inputlag was auch zu fiesen FPS Spikes führen kann. Beeinflussen lässt sich dieser Lag je nach Hardware, durch Wahl der Skalierung in % (z.B. FHD = 50% usw.)

Da es sich bei Borderless auch um ein anderes "Gamedesign" handelt, sind dabei eher Treiberprobleme zu vermuten. Die Framerate Borderless vs Fullscreen ist eigentlich völlig identisch (natürlich auch Hardwareabhängig, der Messungenauigkeit bei Reviews geschuldet bzw. was und wie M$ dabei verbockt).

Unter DX12 bricht die Framerate eher ein, weil die GPU dann einfach mehr Feature zu rendern hat, höher ausgelastet wird und die Optimierungen in CPU lastigen Szenen fehlen, siehe auch Drawcall. Bestimme Runtimeversionen ermöglichen die Steigerung der Drawcallperformance nicht, die ist erst ab reinen DX12 Entwicklungen möglich, was bei Ports (DX11 zu DX12) meist nicht der Fall ist.

Wie man sieht kann Ryzen durch seine Multicoreperformance unter Borderless Multitask gut aufschliessen, wenn man hinsichtlich der CCX Latenz vergleichsweise gut optimiert. Gerade wenn man eine reines AMD Setup fährt einschließlich dazugehöriger Treiber, da AMD sich zum Ziel gesetzt hat die Treiber hinsichtlich dieser internen Latenzen (unter Gaming) besonders anzupassen.

Ich bin mal gespannt wie das wird, wenn AMD irgendwann mal mehr als 8 Kerne im Bereich Consumer/Mainstream einführt.
 
Zuletzt bearbeitet von einem Moderator:
Steini1990 schrieb:
Auch als jemand mit AMD Graka sollt man eher gegen DX12 sein. Wenn eine Low Level API genutzt werden soll, dann ist es Vulkan. Aber definitiv nicht DX12. Der extrem geringe Mehrwert von DX12 wiegt nicht den höheren Entwicklungsaufwand auf. Bei Vulkan bekommt man für den Aufwand weit mehr Vorteile.
Als Radeon Nutzer sehe ich DX12 erstmal als das kleinere Übel an denn man bekommt zumindest eine aktuelle API mit aktuellen Features und, sofern nicht nur ein weiterer lausiger Port, der Möglichkeit ohne singlethread Flaschenhals spielen zu können.
Vulkan wäre ohne Zweifel das Optimum gewesen aber zumindest ist im Gegensatz zu vielen anderen beispielen ein Fortschritt erkennbar.
 
Wadenbeisser schrieb:
Vulkan wäre ohne Zweifel das Optimum gewesen aber zumindest ist im Gegensatz zu vielen anderen beispielen ein Fortschritt erkennbar.
Das glaube ich nicht, da die UWP DX9 d3d zu DX11 Portierung mit Zuordnung entsprechender DX Feature vergleichsweise weniger Aufwand bedeutet, als einen generell neuen LowLewel Renderpfad einzupflegen.

Siehe auch Wegfall DX9 unter WOW und Portierung zu DX12, was auch abhängig von der Engine ist und der reinen Runtimeumgebung unter Windows. Blizzard wollte wohl alle Fans der Serie ansprechen, auch die die nicht über reine DX12 Hardware verfügen. Dann ist ein Fallback auf DX11 und optionaler Feature immer gut um Neuerungen bei der Entwicklung auch visuell sichtbar einfließen zu lassen.

Ab DX11 ist das DX9 "Legacyfeature" Shadermodell mit fester Zuordnung nicht mehr aktuell und muss ein Modell mit frei programmierbarer Pipeline unterstützt werden (siehe auch: "uwp key differences and map feature").

Daher flog DX9 auch raus.:)
 
Zuletzt bearbeitet von einem Moderator:
Ich muss nächste Woche mal gucken. Ich war vorgestern und gestern nur kurz drin (C2D E6700, 8GB RAM, HD5870, 1920 x 1200) und in Dalaran (Northrend) waren die FPS gefühlt gleich wie vor dem Patch. Regler war automatisch auf 5, habe ich dann aber selber wieder auf 1 gestellt. So war es vorm Patch ja auch.

Am Wochenende sitze ich dann am "besseren" Computer (C2Q Q9300, 8GB RAM, GTX 660, 2560 x 1440). Da werde ich eventuell auch mal reinschauen.
 
So macht die Engine von World of Warcraft bereits die zweite, große API-Änderung mit. Ursprünglich wurde das Spiel mit DirectX 9 ausgeliefert, läuft aber bereits seit Jahren mit DirectX 11. Nun hat Blizzard die Low-Level-API DirectX 12integriert, die Grafik an sich, anders als zuvor, aber unangetastet gelassen.

Das was Blizzard in WoW die ganze Zeit als DX11 angegeben hat war DX10. Erst mit BFA wurde das bisher als DX11 gelabelte DX10 tatsächlich auf DX11 umgestellt (auch wenn es technisch kein großer Unterschied ist).
DXVK z.B. ist ein DX11 auf Vulkan Wrapper mit dem es bisher nicht (bzw. nur mit Tricks) möglich war WoW laufen zu lassen da WoW sich sonst mit dem Fehler meldete dass keine ausreichende 3D-Hardware vorhanden sei und DXVK entsprechend ein "DXGI: CheckInterfaceSupport: No D3D10 Support" ausgibt. Erst seit BFA kann man DXVK direkt nutzen.

Tatsächlich wurde also mit BFA von DX9 & DX10 auf DX11 & DX12 gewechselt.

Ein Wechsel auf Vulkan wäre aber deutlich besser gewesen. Statt DX11, DX12 und Metal hätte man nur eine API, eine wesentlich Breitere Unterstützung (auch der Betriebssysteme) und weniger Aufwand.
 
Ist wirklich nicht verständlich wieso man nicht auf Vulkan setzt jeder Laie erkennt die Vorteile wieso die vom Fach nicht?
 
  • Gefällt mir
Reaktionen: m.Kobold
Der Leie lässt die Nachteile immer außen vor.
Eine Umstellung auf Vulkan ist deutlich aufwändiger und das nicht nur in der Implementierung Mann muss auch sicherstellen daß das ganze alte Zeug funktioniert. Da gehen tausende Mannstunden extra drauf die man a. nicht "über" hat und b. bezahlt werden müssen.
 
Zuletzt bearbeitet:
@donend
DX9 wird wohl eher nicht mehr offiziell unterstützt weil dafür seitens der Hardware schon seit Jahren kein Bedarf mehr besteht. Grafikkarten bzw. GPUs die max. DX10 konnten wurden bereits vor gut 9 Jahren abgelöst. Deren Rolle als Fallback API hat nun DX11 übernommen.
Zudem dürfte sich die Programmierung für DX12 erheblich von der von DX11 und Co. unterscheiden weil man sich ganz einfach um erheblich mehr Sachen selbst kümmern muss die einem zuvor die API abgenommen hatte. Von der Programmierung her dürfte DX12 daher erheblich näher an Vulkan sein als an DX11.
 
  • Gefällt mir
Reaktionen: Luxmanl525
BOBderBAGGER schrieb:
Der Leihe lässt die Nachteile immer außen vor.
Eine Umstellung auf Vulkan ist deutlich aufwändiger und das nicht nur in der Implementierung Mann muss auch sicherstellen daß das ganze alte Zeug funktioniert. Da gehen tausende Mannstunden extra drauf die man a. nicht "über" hat und b. bezahlt werden müssen.
Das stimmt doch hinten und vorne nicht, für DX12 gilt genau das selbe... bei LowLevelAPI muß der Developer selbst hand anlegen um noch mehr Leistung rauszukitzeln und das gilt für Vulcan wie auch für DX12. Nur das DX12 in allen bereichen schlechter skalliert als Vulcan.

Und wenn ein Developer Ressourcen einsparren möchte, setzt er halt auf DX11 und hat ne API die mit vorgegeben einstellungen schon recht gut performt.
 
Wenn man das volle feuture Set nutzen will ist das richtig möchtest du z.B nur von dem geringeren API Overhead profitieren kannst du das relativ simpel portieren viel mehr wird hier auch nicht passiert sein. Weshalb die größten Zuwächse dort zu sehen sind wo CB nicht getestet hat, im CPU Limit.

Ihr könnt es noch so oft wiederholen es ändert sich nicht. Lernen mit Vulcan umzugehen und das ganze in gut und funktionstüchtig umzusetzen ist einfach mehr Aufwand als man betreiben möchte.
 
Zuletzt bearbeitet:
@BOBderBAGGER
Nein kannst du nicht, wenn du vom geringeren Overhead profitieren willst dann brauchst du das volle Programm, unabhängig davon ob die bestimmte weitere Funktionen nutzen willst oder nicht. Wer sich die Mühe nicht machen will lässt das Ding im DX11 Modus laufen und erbt damit auch dessen Probleme.
Es gibt ja mehr als genug erbärmliche DX12 Ports die mit den gleichen Problemen daher kommen oder gar noch mehr CPU Leistung fressen.
 
MichiSauer schrieb:
Wer es noch nicht kapiert hat...
Nvidia kommt auf den llvl renderpfaden nicht klar. Die art wie calls erzeugt werden widerspricht hier der philosophie der architektur. Dazu kommt noch, dass dx 12 vor allem dann etwas bringt, wenn der cpu overhead groß wird. Amd ist von beidem stark betroffen und zweiteres greift verstärkt bei leistungsschwachen prozessoren. Daher ist dx12 nicht per se scheiße, sondern in speziellen bereichen (low fps) deutlich besser und auf schnellen Systemen nur gleich gut. Nvidia hat dazu eben das problem, dass die callerzeugung in dx11 vom treiber gemanagt wird und nicht von der hardware, also gegenteilig zu amd, die diesen weg in dx11 nicht gehen können.
Die Art der Draw-Call-Erzeugung ist aus Hardwaresicht die gleiche.
Von der CPU über die PCIe-Pipe kommen Befehlsströme.
Anstatt das das der Treiber implizit sich um die Generierung der Command-Buffer unter DX11 kümmert, erledigt das der Entwickler unter DX12 explizit selber.
Die Architektur spielt in dem Sinne keine Rolle, ich weiß auch das die ganzen Falschinformationen von diesem YouTube-Video kommen, wo eine Menge verwechselt und falsch ausgegeben wurde.

Sowohl bei AMD, als auch Nvidia sieht die Arbeitsverteilung im großen und ganzen sehr ähnlich aus, was die Aufgaben auf Seiten der CPU und GPU angeht.
AMD könnte ihre interne DX11-Treiberarchitektur jeder Zeit verbessern und ähnlich wie Nvidia umsetzen, es gibt keine Gründe, wieso das unter DX11 nicht funktionieren sollte, wo die meisten Teile der Maschinerie implizit vom Treiber umgesetzt werden.

Und bei Nvidia kümmern sich genauso wie bei AMD mehrere unterschiedliche Hardware-Scheduler um unterschiedliche Verwaltungsbereiche, von der Aufnahme der Command-Buffer, dann der Threadverteilung auf die Compute-Units etc.

Steini1990 schrieb:
Auch als jemand mit AMD Graka sollt man eher gegen DX12 sein. Wenn eine Low Level API genutzt werden soll, dann ist es Vulkan. Aber definitiv nicht DX12. Der extrem geringe Mehrwert von DX12 wiegt nicht den höheren Entwicklungsaufwand auf. Bei Vulkan bekommt man für den Aufwand weit mehr Vorteile.
Man bekommt im Prinzip "nur" den Vorteil W7/8-Kunden ansprechen zu können, denn Windows-Kunden stellen bei den meisten Entwicklern 99% der Einnahmequellen dar, weswegen es auch nicht viele Publisher motiviert.
Daneben war es am Anfang sowieso relativ unattraktiv für Entwickler auf Vulkan zu setzen, denn bis vor Version 1.1 wurden HLSL-Shader nicht direkt unterstützt und man musste sich selber um eine robuste Translation-Pipeline bemühen, MultiGPU/fortschrittlichen VR-Support gab es zu Beginn auch nicht und allgemein kam man später.

EdwinOdesseiron schrieb:
Naja. Aber MS wird alles dafür tun, dass DX12 in den Spielen benutzt wird statt Vulkan. Das ist im Prinzip fast das einzige, was die Gamer bei Windows hält. Vulkan wird nämlich auch unter Linux voll unterstützt und sobald die Spielehersteller darauf umschwenken würden, gäbe es eine riesengroße Hürde weniger, um Spiele unter Linux "richtig" zum laufen zu bringen. Und ja ich weiß, dass jede Menge Spiele schon unter Linux laufen, aber ihr wisst wie ich das meine ;)
MS kann nicht die ganze Welt schmieren.
Sie können ihren eigenen Studios diktieren, was sie machen müssen oder dürfen, aber der Rest trifft Entscheidungen wie es für sie sinnhaft erscheint.
 
Locuza schrieb:
AMD könnte ihre interne DX11-Treiberarchitektur jeder Zeit verbessern und ähnlich wie Nvidia umsetzen, es gibt keine Gründe, wieso das unter DX11 nicht funktionieren sollte, wo die meisten Teile der Maschinerie implizit vom Treiber umgesetzt werden.
Stimmt so aufgrund der Batch Queue Size und den Cache Sizes bei GCN leider nicht. Polaris und Vega wurden hinsichtlich dessen etwas erweitert, sind aber noch lange nicht so umfangreich, dass man wie bei nVidia mehrere Worker Threads größere Batches erstellen lassen könnte. GCN bleibt daher weiterhin effizienter, wenn man viele kleinere Batches direkt über den Main-Thread erstellt und an den Scheduler abgibt.
Dadurch kann GCN einfach nicht so gut mit diesem Programmiermodell skalieren, da der Overhead exponentiell größer ausfallen würde als bei nVidia.
 
Immer schön vorsichtig mit dem Begriff "Overhead" umgehen denn gerade bei diesen Diskussionen wird er immer wieder nur allso gern falsch genutzt.
Der Overhead ist der Verlußt der bei der genutzten Leistung flöten geht. Nvidias Variante des Shedulings hat eher prinzipbedingt einen höheren Overhead, macht aber mehr CPU Leistung nutzbar welche diesen höheren Verlußt überkompensiert.
 
  • Gefällt mir
Reaktionen: Iscaran und Luxmanl525
Wadenbeisser schrieb:
Immer schön vorsichtig mit dem Begriff "Overhead" umgehen denn gerade bei diesen Diskussionen wird er immer wieder nur allso gern falsch genutzt.
Der Overhead ist der Verlußt der bei der genutzten Leistung flöten geht. Nvidias Variante des Shedulings hat eher prinzipbedingt einen höheren Overhead, macht aber mehr CPU Leistung nutzbar welche diesen höheren Verlußt überkompensiert.

Korrekt. AMDs Treiber hat inhärent weniger Overhead, liegt aber mit auf dem Main Commit Thread. Wenn die jeweilige Engine auf diesem Thread nun die Logik mit draufknallt, leidet die AMD-Performance enorm.

Würde AMD nVidias Treibermodell nachstricken, müssten die Commits dennoch deutlich häufiger als bei nVidia durchgeführt werden (selbst bei Polaris und Vega noch), was bei einem Worker Thread Modell nunmal für mehr Overhead sorgt. Je mehr Einzel-Commits man reduzieren und dadurch länger auf die Worker "warten" kann, umso weniger zusätzlichen Overhead erzeugt man.
 
  • Gefällt mir
Reaktionen: Iscaran
Zurück
Oben