AW: 3D Mark Time Spy: D3D12-Benchmark veröffentlicht, GTX 1070 / 1080 mit Zuwächsen durch Async Compute
Zeit die Sau wieder durch das Dorf zu treiben.
Falls es wahr sein sollte verstehe ich denn Sinn dahinter nicht. Es wird doch noch andere AC Test geben. Wenn da Nvidia immer schlecht abschneidet und besonders in den Games was haben sie davon es nur in diesem einen Benchmark vorzugaukeln?
Eben genau das, besser in einem Benchmark auszusehen als es in der Regel der Fall ist.
Das Marketing liebt es Spiele auszusortieren oder einfach nur einen synthetischen Benchmark wie den 3D Mark zu nehmen, um die Leistung der GPUs anzugeben, entsprechend wird auch gerne dafür optimiert.
Andererseits würde es aber ja bedeuten dass man Programme ja an diese Arbeitsweise anpassen kann wodurch die Grünen gewinnen. Ist irgendwo geregelt wie man AC genau zu nutzen hat? Wenn nicht bleicht es doch den Entwicklern überlassen auf welche Architektur sie sich einschießen. Wer scheibt denn vor dass man AC dann nur exakt auf GCN zuschneiden darf? Wie gesagt falls es da keine Reglung gibt.
Nein, der Vorwurf ist haltlos und das ist nicht das erste mal das Mahigans falsche Ausführungen eine Hysterie auslösen.
Das hier ist der öffentlich dokumentierte Abschnitt zu Multiengine:
Synchronization and Multi-Engine (Windows)
Man definiert hier welchen Queue-Typen man haben möchte, GFX, Compute oder Copy und fühlt diese dann mit den entsprechenden Befehlslisten auf.
Ein Synchronisationsmechanismus wird verwendet um im Programmverlauf anzugeben, ab wann die zusätzlichen Queues zum Einsatz kommen und ab wann sie beendet werden.
Es gibt noch die Möglichkeit die Priorität anzugeben, falls bestimmte Berechnungen und ihre Ergebnisse früher gewünscht sind.
Das ist auch schon praktisch das ganze Software-Konstrukt, dass einem allerdings keine Garantie darüber gibt, ob die Hardware die Anweisung genau so konsumiert wie man sich das vorstellt, da die Spezifikation in der Hinsicht der Hardware nichts vorschreibt.
Die Hardware könnte die Queues parallel bearbeiten, sie könnte allerdings auch das ganze nacheinander forcieren, die Hardware kann auf die angegebene Priorität achten, sie kann das aber auch ignorieren.
Der Knackpunkt ist einfach, dass dies eine Software-Abstraktion ist die unter jeder Hardware funktionieren muss, aber keine Vorschriften darüber macht wie genau.
Als Entwickler muss man sich deswegen bezüglich der Hardware erkundigen und Testläufe unternehmen, ob der Programmcode auch in der Praxis effizient ausgeführt wird.
Der 3D Mark verwendet hier den absolut gleichen Mechanismus, wie alle anderen Entwickler bei ihren DX12 Anwendungen auch.
Der Vorwurf hier würde gar nicht Async Compute verwendet werden, ist einfach falsch.
Was man sowieso bei der ganzen Async Compute Geschichte haben möchte, ist eine Überlagerung von Aufgabenbereichen die unterschiedliche Hardwareblöcke auslasten.
Z.B. bei Shadow-Maps drehen die ALUs häufig Däumchen, hier könnte die Hardware dank einer zusätzlichen Compute-Queue parallel noch Compute-Shader durch die ALUs berechnen lassen.
Daraus folgt dann ein effektiver Gewinn der Performance, man möchte natürlich nicht Aufgaben mixen, welche die selben Flaschenhälse hat.
Und die Time Spy Demo hat das erfolgreich umgesetzt, für AMD und sogar Nvidia:
3DMark Time Spy mit DirectX 12 im Benchmark (Seite 2) - ComputerBase
9-17% Gewinn für die Radeons, bei Ashes of the Singularity sind es ein paar % weniger, bei Hitman gibt der Entwickler 5-10% an.
Da muss es erst einmal ein Spiel geben, was auch bei den Radeons bessere Resultate hervorbringt.
Theoretisch wäre es vorstellbar das man das ganze in einem Benchmark so hindreht das man den Compute Pipes von Pascal genügend Möglichkeit gibt um die Grafik und Computing Aufgaben seperat voneinander "besser" zu erledigen und zu profitieren. Das wäre dann natürlich eine Verfälschung da man so etwas nur in einem fix definierten Szenario umsetzen koennte und in einem Game wohl eher so nicht machbar ist... Also in der Praxis dann wohl wertlos.[...]
Ohne den Programmcode zu kennen ist es natürlich nur eine Spekulation, ob Spiele ihre Pipelines genau so designen könnten oder nicht.
Ganz klar muss man sagen, dass jeder Entwickler das anders umsetzen könnte, die Time Spy Demo kann vom Code niemals eine allgemeine Referenz für alle Anwendungen sein.
Diese Erkenntnis ist aber nichts neues, man sollte die Ergebnisse immer als das betrachten was sie sind, Ergebnisse für eine einzige Anwendung.
Man kann keine App schreiben die 100% Herstellerneutral ist und die optimale Vergleichsbasis bietet, sowohl für die Hardware, als auch die Software.
