3DMark Time Spy wegen angeblicher Nvidia-Bevorzugung in der Kritik

-Xe0n- schrieb:

Schön das du deinen Kopf nicht selber benutzt sondern lieber anderen vertraust.

Nein die Spiele sind nicht auf Amd Karten optimiert sondern die Entwickler versuchen lediglich das maximale aus der Engine raus zu kitzeln.

Zum Vergrößern anklicken....

Die Radeons profitieren vom AC in Time Spy ja bekanntlich mit ~15% - die 480 etwas weniger, was aber mit der besseren Grundauslastung zu erklären wäre.

Soweit ich weiß, gibt es zur Zeit kein Spiel, bei dem AC soviel bringt. In der Regel waren das immer so um die 10%. Man kann sich jetzt um die Implementierung streiten, aber das Ergebnis sieht für AMD doch ziemlich gut aus.

Die 390 und die 480 platzieren sich in Time Spy auf GTX 980 Niveau - da liegen sie (abgesehen vom Nvidia Sponsor Game RotTR) in jedem DX12 Spiel. Passt soweit! Einzig die Fury X kommt nicht aus dem Knick und ist nur 25 bis 30% schneller als die 390, weshalb sie die 1070 nicht schlagen kann. In anderen DX12/Vulkan Benches ist die Fury gerne mal 45% vor der 390 - so wie man das von den Shadern her erwarten würde.

Für mich also eher ein Fury X Problem und kein AMD Problem.

Locuza
Das mit der Tessalation ist mir bewusst, aber das auf ARM-besierende Prozessoren ebenfalls Tessalation untersützten, dies allerdings über die Arithmetic-Logical-Units umsetzen, wusste ich nicht. Hab mich da aber auch, zugegebener Maßen, nicht tiefer informiert.
Natürlich ist die Frage der Sinnvoll- oder Sinnlosigkeit, insbesondere beim Tessalationsfaktor, wichtig. Und genau da liegt meiner Meinung nach auch der höchste Beeinflussungsfaktor. Hat meine Hardware spezielle Vorlieben, versuche ich diese ja auch immer hervorzuheben. Aber sollte man dieses Prinzip nicht eventuell etwas vorsichtig betrachten? Ab diesem Punkt spielt einfach nur noch Manpower, Geld, Propaganda und Zielgruppen eine Rolle.
Wie auch immer. Hier hört mein Fachwissen dann langsam auch auf. Die genaue Umsetzung bestimmter Funktionen ist dann eher etwas für die richtigen Freaks. Trotzdem gut, solche Leute im Forum zu haben.
Wie gut oder schlecht eine Seite abschneided ist mir eigentlich egal. Ich habe halt ein erhöhtes Neutralitätsbedürfnis wenn es um vergleichsorientierte Bewertungen geht.
Danke für Deine ausführlichen und neutralen Antworten.

Wegen den Vorlieben der Hardware ist es unmöglich für die Entwickler die genaue Mitte zwischen allen Herstellern zu treffen.
Die Frage ist natürlich was verlangt man einem Benchmark ab?
Muss er neutral sein oder realistisch bzw. am besten beides?

Realistisch kann der 3DMark Spy nur begrenzt sein, wenn er versucht "neutral" zu bleiben, im Sinne davon das jeder Hersteller den selben Pfad berechnet.
Einige Entwickler kooperieren mit den Herstellern, dass kann den Fokus beeinflussen, andere Entwickler optimieren GCN lastig, weil GCN der kleinste gemeinsame Nenner dank den Konsolen darstellt.
Doom verwendet exklusive Shader-Funktionen für Radeons, die außerhalb der APIs sind.
Die Entwickler versuchen hier einfach das meiste aus der jeweiligen Hardware zu holen und manchmal liegt der Fokus mehr bei GCN oder bei Nvidias GPUs.

Der 3D Mark kann deswegen Spiele nicht völlig realistisch abzeichnen, außer er macht das gleiche wie Spiele, aber das kann er nicht, weil jedes Spiel macht etwas anders.

Den aktuellen 3D Mark nutze ich nicht, die früheren Versionen kenne ich aber. Da wären immer unterschiedliche Tests drin, die verschiedene Schwerpunkte hatten. Das würde hier doch auch gehen. Ein Test der Aufgaben so und ein anderer der sie so berechnen lässt. So dass alle Featurelevel getestet werden. Kann eine bestimmte Architektur dies nicht, Punktabzug und gut ist. Wäre das nicht möglich Locuza?

PCGH-Redaktion schrieb:

AMD-Grafikkarten gewinnen bei der Leistung mit AC nicht so stark wie in den bisherigen DirectX-12- und Vulkan-Spielen, weil Futuremark laut eigenen Aussagen auf spezielle Architekturoptimierungen sowohl bei AMD als auch Nvidia verzichtet habe. Es ging also nicht darum, so viel zu parallelisieren, dass selbst ein unausgewogener Fiji optimal ausgelastet wird. Durch den Verzicht auf Optimierungen wolle man die Unabhängigkeit wahren.

Zum Vergrößern anklicken....

Ich dächte dies wäre ohnehin immer der Fall bei einem 'Vergleichsbenchmark', das jede VGA 1:1 den selben Code bekommt, ohne Extrawürste oder Abkürzungen?!

Cleriker schrieb:

Den aktuellen 3D Mark nutze ich nicht, die früheren Versionen kenne ich aber. Da wären immer unterschiedliche Tests drin, die verschiedene Schwerpunkte hatten. Das würde hier doch auch gehen. Ein Test der Aufgaben so und ein anderer der sie so berechnen lässt. So dass alle Featurelevel getestet werden. Kann eine bestimmte Architektur dies nicht, Punktabzug und gut ist. Wäre das nicht möglich Locuza?

Zum Vergrößern anklicken....

Theoretisch ist immer viel möglich, aber nicht alles ist praktisch umsetzbar.

Du musst natürlich wissen welche Funktionen in den höheren Feature-Levels enthalten sind und wozu sie verwendet werden können.
Wenn die Hardware z.B. Conservative Rasterization oder ROVs nicht unterstützt, macht es kaum Sinn die Hardware untereinander zu bewerten.
Die Hardware die es nicht unterstützt wird die Sachen einfach nicht direkt berechnen können und einen plausiblen Punkteabzug wirst du dafür kaum definieren können.
Du könntest die Effekte für die Hardware die es nicht durch "A" berechnen kann über einen anderen Weg "B" realisieren, dann macht die eine Hardware "A" und die andere "B", aber hier muss man den Aufwand und die Entwicklungskosten beachten und natürlich wäre die Performance je nach Fall wesentlich schlechter und bis zu welchem Punkt macht denn ein Vergleich noch Sinn?

Futurmark hat den simplen Weg genommen, FL11.0 ist das Grundlevel, jede DX12 GPU wird unterstützt, jede DX12 GPU berechnet die selben Anweisungen, am Ende gibt es einen Wert.

Man könnte natürlich auch einen anderen Benchmark entwickeln, der z.B. Testszene 1, 2 und 3 besitzt.
Und je nach Hardware kann nur Testszene 1, 2 oder jede berechnet werden, wo der Benchmark dann einen Score ausgibt.
Das ist dann halt wieder Aufwand- und Business-Sache.

PS: Der 3DMark Time Spy lässt übrigens einige Einstellungen zu, z.B. den Tessellation-Faktor, Mutliengine (Async Compute) ein oder aus, AF-Grad und mehr:
http://www.legitreviews.com/wp-content/uploads/2016/07/timespy-settings.jpg

In der technischen Dokumentation findest du mehr Details zu den Berechnungen und es gibt zwei Testszenen mit unterschiedlichen Schwerpunkten.
Testszene 2 verwendet z.B. viel mehr Tessellation-Patches.

Hm... also wenn ac dort aktiviert wird rechnet Pascal so wie GCN parallel die Aufgaben weg und Maxwell nacheinander, richtig? So wie ich das verstehe ist die Art und Weise wie AC berechnet wird nicht direkt vorgegeben, sondern es ist den engine Entwicklern, sowie der Hardware überlassen. Demnach wäre das dann völlig legitim.
Sollte hingegen DX12 Genau und das entsprechende featurelevel Genau dafür gedacht sein es parallel abzuarbeiten, dann wäre die Funktion es einzuschalten ja überflüssig. Im Ergebnis sollte dann eine direkte Vergleichvarkeit nicht gegeben werden. Beispielsweise wenn Maxwell getestet werden soll, sollte der Benchmark die Funktion nicht freigeben, sondern es ausgrauen, als deaktiviert und dies irgendwo beim Ergebnis ersichtlich sein.
Ansonsten wäre es genau so witzlos als würden wir eine Karte in 1080p und eine andere in 1440p direkt miteinander vergleichen und danach behaupten, erstere ist schneller.

Locuza schrieb:

...
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 das 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.
...

Zum Vergrößern anklicken....

Sorry aber das ist so nicht richtig. Das was Microsoft beschreibt ist was der Engine Entwickler tun kann, also der Engine Entwickler kann die Queues Nutzen wie er will zB: priorisiert oder nicht priorisiert , parallel oder nicht parallel oder aber alles einfach nur in die 3D Queue usw usw
Aber auf keinen Fall darf der Treiber dies eigenmächtig tun, das wäre ja ein "vollkommenes Desaster" -ups.

Microsoft adressiert damit den"Konsumenten/Entwickler" der API und nicht die Treiber/HardwareHersteller.

EDIT

Locuza schrieb:

PS: Der 3DMark Time Spy lässt übrigens einige Einstellungen zu, z.B. den Tessellation-Faktor, Mutliengine (Async Compute) ein oder aus, AF-Grad und mehr:
Not Found - Legit Reviews ...

Zum Vergrößern anklicken....

Und ist in der Disziplin mit das beste was ich an Optimierung in Sachen Tessellation je gesehen habe, echt Hut ab dafür.

Cleriker schrieb:

Hm... also wenn ac dort aktiviert wird rechnet Pascal so wie GCN parallel die Aufgaben weg und Maxwell nacheinander, richtig? So wie ich das verstehe ist die Art und Weise wie AC berechnet wird nicht direkt vorgegeben, sondern es ist den engine Entwicklern, sowie der Hardware überlassen. Demnach wäre das dann völlig legitim.
Sollte hingegen DX12 Genau und das entsprechende featurelevel Genau dafür gedacht sein es parallel abzuarbeiten, dann wäre die Funktion es einzuschalten ja überflüssig. Im Ergebnis sollte dann eine direkte Vergleichvarkeit nicht gegeben werden. Beispielsweise wenn Maxwell getestet werden soll, sollte der Benchmark die Funktion nicht freigeben, sondern es ausgrauen, als deaktiviert und dies irgendwo beim Ergebnis ersichtlich sein.
Ansonsten wäre es genau so witzlos als würden wir eine Karte in 1080p und eine andere in 1440p direkt miteinander vergleichen und danach behaupten, erstere ist schneller.

Zum Vergrößern anklicken....

Eine korrekte Antwort auf die Frage ist komplex zu formulieren.
Zur Vereinfachung, ja die Aufgaben werden je nach Hardware "parallel" ausgeführt, bei anderer dagegen eher nacheinander.
Die DX12 Spezifikation schreibt nicht vor wie Multiengine (Async Compute) berechnet werden muss, die Fähigkeiten der Hardware entscheiden darüber, wie es effektiv ausgeführt wird.

Vielleicht hilft ein CPU-Beispiel.
Du programmierst eine Anwendung die bis zu 4 Threads ausführen kann, du hast einen Schalter eingebaut der die Verteilung auf mehrere CPU-Kerne erlaubt und einmal der die Verteilung ausmacht und nur immer einen Thread freigibt.
Wenn du eine CPU hast die nur einen Kern hat, dann wird das so oder so nacheinander ausgeführt, der Schalter die Verteilung auszumachen wird einfach nichts bewirken.
So ähnlich ist der Fall hier.

openSUSE schrieb:

Sorry aber das ist so nicht richtig. Das was Microsoft beschreibt ist was der Engine Entwickler tun kann, also der Engine Entwickler kann die Queues Nutzen wie er will zB: priorisiert oder nicht priorisiert , parallel oder nicht parallel oder aber alles einfach nur in die 3D Queue usw usw
Aber auf keinen Fall darf der Treiber dies eigenmächtig tun, das wäre ja ein "vollkommenes Desaster" -ups.
[...]

Zum Vergrößern anklicken....

Der Entwickler kann natürlich machen was er will, aber er hat am Ende keine direkte Kontrolle über die Ausführung davon.
Wenn die Hardware die Queues nicht "parallel" ausführen kann, dann kann sie es natürlich nicht und es ist egal ob die Anwendung Multiengine mit 20 Queues verwendet.

Du hast meinen Text vielleicht so verstanden, dass der Treiber eigenständig die Command-Queues definiert, wobei das theoretisch vermutlich auch möglich wäre.
Aber aus Sicherheitsgründen bezüglich korrekter Ergebnisse und/oder wegen dem Aufwand würde das vermutlich kein Hersteller machen.

Danke für die Antwort.

Tun wir doch alle ,auch wenn es manchmal schlecht ist .

Deinen post verstehe ich nicht. Worauf beziehst du dich und was meinst du?