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

[Mcr-King]

So DX12 und Vulkan sollten CPU last besser verteilen und offener sein einfacher für Entwickler da sie mehr selbst machen können und und.

Trotzdem die Entwickler sind einfach fauler geworden dieser Punkt lässt sich nicht leugnen. Auch ein Grund warum soviel Beta-Zeug als fertiges Produkt verkauft wird oder es immer mehr erly Mist gibt, aber Hauptsache irgendwie DLCs verkaufen auch wenn das Game noch Beta ist.

Witzig ist nur die Leute stört dass überhaupt nicht tja, okay ab und zu durch schlechte Steam Bewertungen.

 

[Wadenbeisser]

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

Gerade im Falle einer API die nicht nur von den eigenen Produkten genutzt werden soll ist es sinnvoll diesen Schritt zu gehen.
Die Konkurrenz wird einen Teufel tuen sich auf eine Technologie einzulassen die der Konkurrent unter seiner Kontrolle hat.

 

[tek9]

Leonidas vom 3DC hat vor geraumer Zeit spekuliert das LL APIs dazu führen werden das größtenteils nur noch Engines von Zulieferern verwendet werden, weil es für kleine Studios einfach sehr aufwendig sein wird eine Engine auf Basis einer LL API "from scratch" zu entwickeln.

Da mittlerweile aber eh alle mit eingekauften Engines, Frameworks und Middleware arbeiten, sehe ich nur bedingt wo das Problem liegen soll.

Die von Nixxes aufgeführten Probleme sind größtenteils Early Adopter Themen, wie sie selber auf ihren Folien geschrieben haben. Das es (immer noch?) keine Debugger für DX12 gibt, finde ich sehr befremdlich. Das es keine Tools der IHVs gibt, mit denen man das Memory Management in den Griff bekommt, ist schon ein starkes Stück.

Wenn den die IHVs ihr Augenmerk auf die Bereitstellung von Frameworks und Tools legen würden, wäre die Branche weit über die Pionierarbeit hinaus. Das gleiche gilt für die Anbieter der großen Engines.

Das LL APIs bei gleicher Anzahl an Polygonen nur wenig Mehrwert bringen wie die alten High Level pendants, ist eine Binsenweisheit und war bereits vor dem Release von DX12 und Vulcan bekannt. Mit LL APIs können die Entwickler in Sachen Geometrie sehr viel mehr erreichen als mit der alten Technik. Daher ist es Quatsch zu sagen das LL APIs keinen Sinn machen.

 

[Alefthau]

Hi,

Guckt mal, hier ist ne tolle Tabelle, wo erklärt wie es mit DX12 auf den einzelnen Grakas aussieht!

http://www.pcgameshardware.de/Grafi...tX-12-Support-Geforce-Radeon-Treiber-1204767/

Ich empfehle hier auch einen Blick auf Polaris und was dieser unterstützt, genauso Fiji, Tonga&Co, weil ja AMD schon immer alles von DX12 vollständig unterstützt habe und NVIDIA ja nur Softwareemulation betreibt!

Es wird langsam albern ständig dieses falsche Mantra von sich zu geben was NVIDIA betrifft, zumal es nicht nötig ist, da die AMD-Karten ja auch ohne dieses unter DX12 gut performen und ich vermute, dass NVIDIA vielleicht auf, aber nicht wirklich überholen kann mit optimierten DX12-Treibern.

Gruß

Alef

 

[tek9]

Ja und?

Die Tabelle besagt das AMD seit den Tonga Karten Feature Level 12_0 beherrschen und Nvidia dann mit Maxwell 2.0 nachgezogen hat und nun 12_1 mitbringt, was Vega auch im Angebot hat.

Desweiteren steht unter der Tabelle zu Nvidia:

DX12-Treiber akzeptieren Befehle aus Graphics/Compute-Queue, in der Hardware werden sie jedoch nicht parallelisiert, sondern seriell ausgeführt. Laut Nvidia unterstützt Maxwell 2.0 Asynchronous Compute, "es sei derzeit im Treiber nicht aktiviert". Pascal unterstützt AC durch dynamische Zuweisung einzelner SMs an die Graphics und Compute Queues, jedoch keine Mischbeschickung eines SMs aus beiden Warps. Femi dürfte Multi-Engine nur seriell unterstützen.

Von daher könnte man schon sagen das DX12 bei Nvidia seit langer Zeit ein Checklisten Feature ist und sie sich noch immer auf DX11 konzentrieren

 

[SimsP]

Stimmt AMD hat mit Tonga Anfang September 2014 mit DX12 Unterstützung vorgelegt und bei NVidia hat es dann ganze 17 Tage länger gedauert bis Maxwell 2 rauskam. Ja das ist ein riesen Vorsprung für AMD, muss ich dir Recht geben. Da hat sich NVidia echt lange Zeit gelassen. Jetzt seh ichs ein NVidia baut einfach keine DX12 Karten...

@Limit: Hast du zu den von dir benannten detailierten AMD Architektur Dokus zufälligerweise gerade ne Quelle da? Ich kenne da eigentlich auch nur diese recht oberflächlichen Schaltbilder, die es auch von NVidia gibt + Dokus zu ein paar neuen Features aber nicht deren genauer Umsetzung in Hardware.
Das würde zwar reichen um Software auf die Hardware zu optimieren, aber nicht für einen kompletten Treiber. Von daher wär's mal interessant zu wissen, ob's da noch mehr Material gibt.

 

[Wadenbeisser]

So wie ich das sehe ist die Sache doch recht einfach, korregiert mich wenn ich da falsch liege.
Das was nvidia in Hardware unterstützt entspricht den aufgebohrten DX11 Versionen, das was den DX12 Support ausmacht ist in Software angeflanscht. Mag ja sein das Microsoft hier die Art der Ausführung nicht vorschreibt aber Hardware technisch hängen sie immernoch auf dem Stand von DX11 fest.

 

[tek9]

Stimmt AMD hat mit Tonga Anfang September 2014 mit DX12 Unterstützung vorgelegt und bei NVidia hat es dann ganze 17 Tage länger gedauert bis Maxwell 2 rauskam. Ja das ist ein riesen Vorsprung für AMD, muss ich dir Recht geben. Da hat sich NVidia echt lange Zeit gelassen. Jetzt seh ichs ein NVidia baut einfach keine DX12 Karten....

Das Nvidia kein DX12 anbietet hat hier keiner behauptet und deine dümmliche Ironie kannst du dir sparen.

Der kleine aber feine Unterschied ist der Text unter der Tabelle

Den hast du natürlich ignoriert...

 

[Limit]

Stimmt AMD hat mit Tonga Anfang September 2014 mit DX12 Unterstützung vorgelegt und bei NVidia hat es dann ganze 17 Tage länger gedauert bis Maxwell 2 rauskam. Ja das ist ein riesen Vorsprung für AMD, muss ich dir Recht geben. Da hat sich NVidia echt lange Zeit gelassen. Jetzt seh ichs ein NVidia baut einfach keine DX12 Karten...

Obwohl das formal richtig ist, sollte man doch Unterschiede zwischen den Implementierungen von AMD und nVidia machen. nVidia implementiert, zumindest vor Pascal nur die Minimalversion in Hardware was dazu führt, dass es zwar formal den Vorgaben entspricht, die erhoffte Leistungssteigerung ist damit aber nur unter sehr speziellen Bedingungen zu erreichen.

@Limit: Hast du zu den von dir benannten detailierten AMD Architektur Dokus zufälligerweise gerade ne Quelle da? Ich kenne da eigentlich auch nur diese recht oberflächlichen Schaltbilder, die es auch von NVidia gibt + Dokus zu ein paar neuen Features aber nicht deren genauer Umsetzung in Hardware.
Das würde zwar reichen um Software auf die Hardware zu optimieren, aber nicht für einen kompletten Treiber. Von daher wär's mal interessant zu wissen, ob's da noch mehr Material gibt.

Es gibt auf der Developer-Seite von AMD einen Reference Guide zur ISA. Dieser enthält im Prinzip alles, was man für Optimierungen braucht (z.B. für Vega: http://developer.amd.com/wordpress/media/2013/12/Vega_Shader_ISA_28July2017.pdf).
Wer einen eigenen Treiber entwickeln will sollte zusätzlich in die Header-Dateien der offenen Linux-Treiber schauen, dort findet man noch mehr Informationen zur Architektur. Für Spiele-Entwickler sind diese allerdings nicht relevant.

 

[Wadenbeisser]

Minimalversion ist gut, bis hin zur ersten Maxwell Version lag man vom Feature level her noch hinter der ersten GCN Generation hinterher.
Und nein, bei den Imlentierungen muss man keinen Unterschied machen. Der Unterschied liegt bei den unterstützten Funktionen an sich die schon lange nicht mehr an die DX Version gebunden sind.

 

[modena.ch]

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.

Du raffst es nicht. Das war unter DX11 nie so vorgesehen und ist nix als Gewurstel, eine Krücke um
die DX11 Limits zu umgehen.
Und das geht bei AMD schlicht so wie von NV umgesetzt nicht, weil es keinen Software Sheduler gibt!!

Und in Hardware würde ich das für eine sterbende API, welche ohne NV schon lange, lange tot wäre, sicher nicht
mehr einbauen an AMDs Stelle. Also weg mit dem alten Scheiss und wir kommen alle deutlich weiter....
Auch die NV Jünger, weil sie mal wieder eine neue Architektur aufsetzen müssen, statt immer nur ollen
Mist wieder und wieder neu aufzulegen.

 

[SimsP]

Obwohl das formal richtig ist, sollte man doch Unterschiede zwischen den Implementierungen von AMD und nVidia machen. nVidia implementiert, zumindest vor Pascal nur die Minimalversion in Hardware was dazu führt, dass es zwar formal den Vorgaben entspricht, die erhoffte Leistungssteigerung ist damit aber nur unter sehr speziellen Bedingungen zu erreichen.

Naja gut was heißt Minimal-Version? Mit Maxwell haben die Karten halt noch nicht von Async Compute profitiert. Das werden NVidia Karten, zumindest die aktuellen, aber sowieso niemals so stark wie AMD Hardware. Von daher mag für AMD Async Compute ja eines der wichtigeren Features von DX12 sein, für NVidia aber nicht. Auch wenn es häufig so dargestellt wird, weil AMD so stark von Async Compute profitieren kann, es ist nicht das einzige wichtige Feature von DX12.
Genauso könnte ich jetzt hergehen mir ein anderes DX12 Feature raussuchen wie Rasterizer Ordered Views und behaupten das wäre maßgeblich für DX12 und keine AMD Grafikkarte bis Vega konnte das.
Oder Tile Based Rasterizing, warum hat das bei AMD solange bis zur Umsetzung gedauert?
Warum sollte NVidia denn bei DX12 gerade da mit einer umfangreichen Unterstützung anfangen, wo sie nicht so stark profitieren können wie die Konkurrenz?

Letztlich haben doch beide gleichzeitig mit DX12 begonnen nur die Herangehensweise welche Features zuerst im Fokus standen ist eine andere. Gut ich glaube auch NVidia hat nicht unbedingt geplant die erste Async Compute Implementierung so zu verkacken wie man jetzt rückblickend sagen muss, dass sie es getan haben. Erinnert so ein bisschen an den Transactional Memory von Haswell...

Es gibt auf der Developer-Seite von AMD einen Reference Guide zur ISA. Dieser enthält im Prinzip alles, was man für Optimierungen braucht (z.B. für Vega: http://developer.amd.com/wordpress/media/2013/12/Vega_Shader_ISA_28July2017.pdf).
Wer einen eigenen Treiber entwickeln will sollte zusätzlich in die Header-Dateien der offenen Linux-Treiber schauen, dort findet man noch mehr Informationen zur Architektur. Für Spiele-Entwickler sind diese allerdings nicht relevant.

Ja aber ich finde so ein "Reversengineering" an Hand von Headerfiles immer sehr mühsam. Speziell wenn ich eigentlich keinen eigenen Treiber schreiben will, sondern mich nur für die Hardware dahinter interessiere. Da ist das von dir verlinkte Dokument nach kurzem Überfliegen schon deutlich interessanter. In einer ruhigen Minute werde ich mir das mal zu Gemüte führen. Danke!

 

[Wadenbeisser]

@SimsP
Welche in Hardware gegossene DX12 Features sind das denn die nicht bereits Teil der aufgebohrten DX11 Versionen sind?

 

[Limit]

Naja gut was heißt Minimal-Version? Mit Maxwell haben die Karten halt noch nicht von Async Compute profitiert. Das werden NVidia Karten, zumindest die aktuellen, aber sowieso niemals so stark wie AMD Hardware. Von daher mag für AMD Async Compute ja eines der wichtigeren Features von DX12 sein, für NVidia aber nicht. Auch wenn es häufig so dargestellt wird, weil AMD so stark von Async Compute profitieren kann, es ist nicht das einzige wichtige Feature von DX12.

DX12 umfasst verschiedene Änderungen, einige sind einfach nur Erweiterungen wie sie bei jeder neuen DX-Version vorkommen. Der Teil von DX12 wurde nachträglich auch in DX11 (als DX 11.3/11.4) eingebaut. Darüberhinaus enthält DX12 aber auch eine sehr grundlegende Änderung, nämlich der Wechsel von einer einzelnen Command-Queue hin zu mehreren. Um das effizient umzusetzen muss man größere Teile der Hardware-Architektur ändern. nVidia hat das vor Pascal nicht getan und selbst bei Pascal ist die Implementierung weniger flexibel als es bei AMD schon länger der Fall ist. Sie haben zwar software-seitig mehrere Queues, aber diese können nicht parallel abgearbeitet werden. Zusätzlich kommt noch das fehlende/deaktivierte Async Compute, das das Mischen von Compute und Graphics innerhalb einer Queue ohne Kontextwechsel erlauben würde.

Genauso könnte ich jetzt hergehen mir ein anderes DX12 Feature raussuchen wie Rasterizer Ordered Views und behaupten das wäre maßgeblich für DX12 und keine AMD Grafikkarte bis Vega konnte das.

In Anbetracht, dass dieses Feature auch in DX11.3 eingebaut wurde, taugt es als Aushängeschild für DX12 nicht wirklich.

Ja aber ich finde so ein "Reversengineering" an Hand von Headerfiles immer sehr mühsam. Speziell wenn ich eigentlich keinen eigenen Treiber schreiben will, sondern mich nur für die Hardware dahinter interessiere. Da ist das von dir verlinkte Dokument nach kurzem Überfliegen schon deutlich interessanter. In einer ruhigen Minute werde ich mir das mal zu Gemüte führen. Danke!

Für interessierte Laien wäre eine ausführliche Dokumentation "in Prosa" wohl deutlich angenehmer zu lesen. Diese(r) Dokumente/Code richten sich allerdings auch eher an Entwickler. Reverse-Engeineering musst du aber auch nicht gleich betreiben, auch die Kommentare in den Header-Files sind teils schon recht aufschlussreich. Generell muss man aber auch sagen, dass genaue Details zur Hardware nur soweit in diesen Docs enthalten sind wie es für die Software/Treiber-Entwickler nötig sind. Reine Hardware-Features, für die nicht optimiert werden kann/muss wirst du darin nicht finden (z.B. das genannte Tile-Based-Rasterizing)

 

[SimsP]

DX12 umfasst verschiedene Änderungen, einige sind einfach nur Erweiterungen wie sie bei jeder neuen DX-Version vorkommen. Der Teil von DX12 wurde nachträglich auch in DX11 (als DX 11.3/11.4) eingebaut. Darüberhinaus enthält DX12 aber auch eine sehr grundlegende Änderung, nämlich der Wechsel von einer einzelnen Command-Queue hin zu mehreren. Um das effizient umzusetzen muss man größere Teile der Hardware-Architektur ändern. nVidia hat das vor Pascal nicht getan und selbst bei Pascal ist die Implementierung weniger flexibel als es bei AMD schon länger der Fall ist. Sie haben zwar software-seitig mehrere Queues, aber diese können nicht parallel abgearbeitet werden. Zusätzlich kommt noch das fehlende/deaktivierte Async Compute, das das Mischen von Compute und Graphics innerhalb einer Queue ohne Kontextwechsel erlauben würde.

Doch die Parallele Abarbeitung von Compute and Graphics Tasks gibt es tatsächlich schon seit Maxwell. Das Schedulingwar nur sehr ... sagen wir unvorteilhaft, sodass daraus eher Nachtheile als Vorteile entstanden.
Mehrere Command Queues gibt es tatsächlich schon seit Kepler, aber die waren dort noch ausschließlich für Compute Aufgaben gedacht. Mit Maxwell hat sich das geändert und mit Pascal wurde mit dem überarbeiteten Scheduling eine der wesentlichen Leistungsbremsen abgebaut.

Für interessierte Laien wäre eine ausführliche Dokumentation "in Prosa" wohl deutlich angenehmer zu lesen. Diese(r) Dokumente/Code richten sich allerdings auch eher an Entwickler. Reverse-Engeineering musst du aber auch nicht gleich betreiben, auch die Kommentare in den Header-Files sind teils schon recht aufschlussreich. Generell muss man aber auch sagen, dass genaue Details zur Hardware nur soweit in diesen Docs enthalten sind wie es für die Software/Treiber-Entwickler nötig sind. Reine Hardware-Features, für die nicht optimiert werden kann/muss wirst du darin nicht finden (z.B. das genannte Tile-Based-Rasterizing)

Naja gut was heißt Laie. Ich versteh schon was von Hardware(-Entwicklung). Deswegen interessiert es mich ja. Nur kommt man halt nicht oder nur sehr schwer an Dokus zur Umsetzungen der Hersteller ran. Is ja auch klar, damit verdienen die maßgeblich ihre Brötchen.

 

[Wadenbeisser]

Der Teil von DX12 wurde nachträglich auch in DX11 (als DX 11.3/11.4) eingebaut.

Das kam so ziemlich gleichzeitig. Zusammen mit DX12 wurde auch DX11.3 vorgestellt das eben
https://www.computerbase.de/2014-09/directx-11.3-erscheint-parallel-zu-directx-12/

Async Compute scheint das einzige Hardware Feature von DX12 zu sein das nicht bereits Teil der neuen DX11 Aufgüsse ist und genau das wird von den Geforce Chips eben nicht in Hardware unterstützt sonder per Software draufgebügelt.

Wer detailiertere Infos hat, immer her damit.

Hier nochmal die Aufschlüsselung der DX11 Erweiterungen:
https://msdn.microsoft.com/en-us/library/windows/desktop/dn914596(v=vs.85).aspx

 

[Limit]

Doch die Parallele Abarbeitung von Compute and Graphics Tasks gibt es tatsächlich schon seit Maxwell. Das Schedulingwar nur sehr ... sagen wir unvorteilhaft, sodass daraus eher Nachtheile als Vorteile entstanden.

Kann sein, dass ich das falsch verstanden habe, aber afaik konnte Maxwell das nur rein logisch, sprich man kann entsprechende commands zwar parallel absetzen, intern muss weiterhin ein Kontextwechsel vorgenommen werden um zwischen Compute und Graphics Tasks hin- und herzuwechseln.

Mehrere Command Queues gibt es tatsächlich schon seit Kepler, aber die waren dort noch ausschließlich für Compute Aufgaben gedacht.

Ja, für OpenCL bzw. neuere CUDA-Versionen. Für DX ist das aber eine Neuerung ab DX12.

Das kam so ziemlich gleichzeitig.

Ich meinte eigentlich nur, dass diese Features nicht in der ursprünglichen DX11-Version enthalten waren.

 

[Iscaran]

... intern muss weiterhin ein Kontextwechsel vorgenommen werden um zwischen Compute und Graphics Tasks hin- und herzuwechseln.

Das ist nach wie vor korrekt. nVidia arbeitet gemischte compute / Graphics Queues mittels Context Switching ab. Bei so einem Switch musste aber meines Wissens bis mindestens Maxwell 2.0 dann der Rest der gequeuten commands verworfen werden. Was eben zu Leistungseinbußen führt.
Soweit ich weiss ist das selbst bei Pascal noch so - allerdings leidet die Performance nicht mehr so stark darunter weil man den Context-Switch nun (noch) schneller abarbeiten kann und AFAIK nicht mehr der ganze danach folgenden Rest verworfen werden muss - dieser wird afaik quasi "zwischengeparkt" und kann dann weiterverarbeitet werden. Kostet aber immer noch Leistung da man quasi erst in späteren Takten damit weitermachen kann.

 

[kisser]

Du raffst es nicht. Das war unter DX11 nie so vorgesehen

Doch. Kannst du ja selbst nachlesen. Multithreading war eine der Neuerungen von DX11.

 

[Taxxor]

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.

Dafür ist eine RX580 aber 7% vor einer 1060, wo sonst quasi Gleichstand herrscht.

Eine R9 380 liegt nur 5% hinter einer GTX970, im Vega Test waren es 29%

Eine RX460 liegt 9% vor der GTX960, im Vega Test liegt sie 28% dahinter.

Die kleineren Karten scheinen also mehr zu profitieren als die größeren, was dann auch den geringeren Unterschied zwischen RX580 und RX460 erklärt.
Im Vergleich mit den jeweiligen Nvidia Karaten sind aber durchweg alle stark.