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

[Dennisth]

Dann hast Du das nicht so geschrieben, dass ich die Kritik richtig verstehe. In diesem Thread geht es nicht darum, dass kein FL 12_x unterstützt wird, sondern um den Vorwurf, dass nVidia durch den Test bevorzugt werden würde.

Gut das wir uns am Ende doch noch verstanden haben. Das eine hängt aber wahrscheinlich mit dem anderen zusammen, denn würde der "Benchmark" FL 12_0 voraussetzen und auch excessive nutzen würde Nvidia bestimmt massiv abstürzen. AMD würde zwar auch abstürzen aber wahrscheinlich nicht so viel, da die Rohleistung ja besser umgesetzt werden kann.

Ein Erzwingen von FL 12_1 würde tatsächlich AMD Karten aussperren.

Ja stimmt, aber um ein DX12 Benchmark zu sein würde ja schon das FL 12_0 als Minimum ausreichen. Man hätte ja einen Benchmark für FL 12_0 machen können und einen zweiten für FL 12_1

TimeSpy nutzt die DX12 API und nutzt auch viele DX12 exklusive Features, die die Performance verbessern können. Es nutzt nur nicht die optionalen Featurelevels von DX12. Das wurde aber auch nirgendwo versprochen und ist eigentlich auch nicht das Ziel des Benchmarks. Man will die generelle DX12 Performance vergleichen und nicht die Abdeckung der FL 12_x und deren Performance.

Naja das Problem ist hier, dass diese "optionalen" Features eben genau mehr, bzw. viel mehr, Leistung bringen und diese wohl nur mit AMD Karten so gut skalieren. Dazu noch die Tatsache das der VRAM nicht wirklich genutzt wird und das obwohl die high-End Karten doch 4+ GB haben.

 

[Grestorn]

Gut das wir uns am Ende doch noch verstanden haben. Das eine hängt aber wahrscheinlich mit dem anderen zusammen, denn würde der "Benchmark" FL 12_0 voraussetzen und auch excessive nutzen würde Nvidia bestimmt massiv abstürzen. AMD würde zwar auch abstürzen aber wahrscheinlich nicht so viel, da die Rohleistung ja besser umgesetzt werden kann.

Diese Vermutung entbehrt jede Grundlage. Hast Du irgendeine Quelle, dass nVidia die FL 12_0 Features nur mit schlechter Performance unterstützt? Dass AC auf Maxwell nichts bringt lässt erst mal absolut keine Aussage für FL 12_0 zu.

Du hast in so fern recht, als dass es schade ist, dass TimeSpy keinerlei Aussage über die Performance der FL 12 Features zulässt.

Naja das Problem ist hier, dass diese "optionalen" Features eben genau mehr, bzw. viel mehr, Leistung bringen und diese wohl nur mit AMD Karten so gut skalieren.

Woraus schließt Du das? Ich halte das für eine sehr gewagte Aussage.

 

[rum]

Hier kommt es darauf an welche Regeln die API aufstellt und wie viel Freiraum bei der konkreten Umsetzung verfügbar ist.
Wenn du ins extreme gehen willst, kannst du dich auch schon beschweren das jeder Shader anders übersetzt und ausgeführt wird.
Du kannst eine Zeile-Code egal zu was schreiben und sofort kritisieren, dass Hardware A es unter der Haube anders ausführt, als Hardware B.
Es liegt hier kein Standard vor, der vom Software-Modell bis zur Hardware-Instruktion vorschreibt wie etwas genau ausgeführt werden muss.
Wenn du die absolute Vergleichbarkeit haben willst, dann hast du auch überall die absolut gleiche Software und Hardware und die gleichen Ergebnisse.

Ein fiktives Beispiel:
Wenn du mit deinen Freunden in Italien bist, könntet ihr festlegen vom Startpunkt A nach Rom zu gehen.
Jeder von euch nimmt einen anderen Weg, am Ende landet ihr alle beim dem Endpunkt B, nämlich Rom und das Ergebnis (nach Rom zu gehen) ist korrekt.
Man kann dann testen wie schnell jeder von euch es nach Rom geschafft hat.
Du kannst dich jetzt beschweren das nicht jeder den gleichen Weg genommen hat, aber haben das die Regeln vorgeschrieben?
Beim 3DMark ist es eben die DX12 API welche die Regeln vorschreibt und damit muss man halt leben, die Rahmenbedingung ist aber immer die gleiche.

Jetzt kommt praktisch die Kritik, nein das finde ich nicht cool das jeder einen unterschiedlichen Weg nach Rom nehmen darf, dass verzerrt die Ergebnisse und ist nicht vergleichbar.
Und damit schränkst du die Testbedingungen natürlich wesentlich ein, aber wird das Ergebnis jetzt realistischer oder fairer?
Weil jetzt muss jeder den gleichen Weg nehmen, wo man einen kleinen Berg hochklettern muss.
Wer wird da versagen? Dein Freund im Rollstuhl, der zuvor einfach einen flachen Weg daneben genommen hat, er kann die Anweisung nach Rom gehen dann gar nicht unterstützen.
Du hast noch einen der ziemlich schnell auf einem Fahrrad unterwegs war, der schleppt das dann mühselig auf dem Rücken.
Macht die explizite Festlegung bezüglich der Art und Weise im Kontext der Kandidaten mehr Sinn?

Macht das bei der Hardware Sinn die Art und Weise fest vorzuschreiben, obwohl sie es auf eine andere Art viel besser erledigen könnte?
Am Ende kannst du zu dem Schluss kommen, dass keine Testbedingung 100% fair oder realistisch ist und man nichts vergleichen kann.
Okay, sie kann natürlich nicht 100% optimal sein, sie kann natürlich auch sehr sub-optimal sein.
Ist der Futuremark sehr sub-optimal? Nein, der Futurmark befolgt die Regeln der API und alle GPUs landen ungefähr dort, wo man sie meistens im Schnitt anhand von Spiele-Parkours erwartet.
Trickst Nvidia? Nein, sie befolgen die Regeln der API. Ist der Benchmark 100% Herstellerneutral? Nein. Bildet der Benchmark eine 100% genaue Referenz für Software ab? Nein.
Kann man mit dem Benchmark trotzdem Ergebnisse vergleichen? Ja, natürlich.


Die einfache Antwort lautet einfach gar nicht, jedenfalls nicht genau.
Die Zukunft ist mit der Glaskugel verbunden und kein Entwickler kann dir ein Programm schreiben, welches die Zukunftsfähigkeit oder Performance einer API testet, weil jeder Entwickler kann seine Software etwas anders umsetzen.
Außer der Entwickler ist Moses und schafft es zufällig im Schnitt von 2000 Programmen beim gleichen Durchschnittswert zu landen.
Aber vielleicht spielst du nur 10 Spiele davon, die stark vom Durchschnitt ausweichen, tja Mist aber auch.

Ich meine man muss mal etwas realistisch bleiben und die Dinge vielleicht nicht zu eng sehen.

Verstehe.
Demnach ist das DX12 Advanced Programming Interface im Prinzip der ausschlaggebende Punkt.
Seit wann ist das denn so, das die Rahmenbedingungen so aufgeweicht sind? Erst nach DX11? Soweit ich weiß kommt diese API ja von Microsoft, so wie die Vorgänger auch.
Bleibt für mich der bittere Nachgeschmack, auf keinerlei Vergleichsebenen mehr blicken zu können, sobald es um DX12 geht. Das Wettrennen scheint durch diese API ja mehr oder weniger um Regelwerke reduziert oder erweitert wurden zu sein.
Die kompletten technischen Details sind mir dann meine Zeit auch nicht wert.


Aktuell finde ich es übrigens gut, wie die GTX1060 abgeschnitten hat. Aber ich auch die RX 480! Beides gute Karten mit unerschiedlicher Fokussierung und dadurch sicher auch Geschmacksorientierter als früher.


Zu dem Vorwurf meines Benehmens hier. Das war die Antwort auf ein Forenmitglied, von dem ich viele Seiten immer nur eines gelesen habe: Du hast Unrecht, ich habe Recht. Und diese Aussage wiederholte sich mehrfach, immer und immer wieder. Nicht eine einzige persönliche Aussage oder Meinung zum Topic! Was soll das? Da vergeht mir persönlich die Lust ein Forum zu lesen ... und vielleicht auch die Zeitung zu kaufen.
Es gibt ein Thema in welchem wir auch im Kontext antworten sollten. Wenn man dieses ganze :: DU - ICH - nein DU - nein Ich :: weglassen würde, wäre das PCGH-Forum für mich wirklich das Beste, was es im Bereich PC & Gaming, bezogen auf Hardware, zu lesen gibt.

 

[Locuza]

Ich würde vermuten das es seit Anbeginn der Zeit so ist.
Die Frage ist eher, warum das auf einmal bei Async Compute eine Rolle spielen sollte und zuvor oder bei anderen Dingen nicht?
Weil natürlich das konkrete Wissen über die Materie fehlt und Beschreibungen wie Async Compute wird im Treiber deaktiviert dazu verleitet simple Urteile zu fällen.

Um noch ein anderes Beispiel zu nennen, Tessellation.
Die Hardware muss die Hull- und Domain-Shader Funktionen unterstützen und den Tess-Faktor von bis zu x64.
Das muss funktionieren, aber wie schreibt die Spec nicht vor.
Deswegen kannst du dich als Programmierer auch nicht verlassen, dass Tessellation auf jeder Hardware schnell und effizient abläuft.
AMD hat bis Heute Nachteile bezüglich der Performance wenn ein hoher Tess-Faktor verwendet wird, häufig kam auch deswegen Kritik auf.

Man kann natürlich legitime Kritik aufstellen, welcher Einsatz ergibt Sinn und welcher ist sehr unrealistisch und verstopft die Pipeline?
Aber ist x32 besser oder x16 oder x12? Auf welche Flächen wird der Tess-Faktor angewendet,auf Große oder Kleine ? Gibt es überhaupt Angaben dazu?
Hier kann man natürlich viel debattieren wie eine gute Umsetzung auszusehen hat, was fair ist oder unfair.
Wirft man jetzt einem Hersteller schwache Hardware vor oder ist das eine blöde Spec oder ist die Software einfach schlecht geschrieben?
Das ist nicht nicht immer simpel zu beantworten.

Warum ich aber Tessellation genannt habe, weil die Bandbreite der Umsetzungen auf dem Markt teilweise sehr unterschiedlich ist.
AMD und Nvidia setzen die Tessellation bezüglich der Zerlegung der Flächen durch Fixed-Function-Hardware um, ARM hat sich die Fixed-Function-Hardware dafür gespart und setzt das über die ALUs um.
Die Spec schreibt nicht vor das Tessellation über spezifische Hardware umgesetzt wird, es muss nur funktionieren und der Freiraum hat es eben ARM erlaubt es einfach über die ALUs umzusetzen.

Multiengine trifft in die gleiche Kerbe, es spezifiziert Funktionen, die müssen unterstützt werden, wie die Hardware es dann macht ist egal.
Und da gibt es auch wirklich nichts verwerfliches, weil es schon immer so war und man nicht jeden Hardwarehersteller zwingen kann etwas nach einem konkreten Muster umzusetzen.
Hier eignet sich das Rom Beispiel mit dem Rollstuhlfahrer oder dem Fahrradfahrer, die nur wegen einer unsinnigen Festschreibung einen Berg hochklettern müssten.

 

[Tod_Allen_Meisen]

Eventuell noch ein weiteres Beispiel dazu: Der DirectX 12 Standard beinhaltet auch mal wieder Cubemaps. Wie die Cubemaps aber von der Hardware und vom Treiber her funktionieren müssen ist ebenfalls mal wieder nicht im Standard definiert. AMD implementiert deshalb die Cubemaps auf GCN in Software: Eine Cubemap besteht dort aus 6 normalen 2D texturen. Wird eine Cubemap in der Shaderhochsprache gesamplet, so ersetzt der Compiler das durch mehrere Maschinenbefehle. Die bestimmen zuerst, wo bzw. auf welche 2D-Textur der Richtungsvektor hinzeigt, und samplen diese entsprechende 2D Textur dann in einer weiteren Instruktion eben an dieser Stelle. Hier würde auch niemand auf die Idee kommen herumzujammern, dass GCN nicht wirklich Cubemaps bzw Cubemaps nur in Software und damit nicht den DirectX 12 Standard unterstützt.

Btw: Huhuhu Locuza

 

[_ZweiUndVierzig_]

Keine Optimierung kann für den einen IHV schon ein optimaler Fall sein und für den anderen nicht...

 

[Laggy.NET]

Nun, mit dem, was Futuremark hier gemacht hat, scheinen sie dennoch praxisnahe Ergebnisse zu erzielen.

Computerbase hat hier nen Test der GTX 1060 veröffentlicht Nvidia GeForce GTX 1060 im Test (Seite 3) - ComputerBase
und selbst wenn man hier ausschließlich die DX12/Vulkan Spiele zur Wertung markiert (Ashes, Doom, Hitman, ROTTR, TotalWar) dann ist z.B. die RX480 auch immernoch 11% langsamer, als eine GTX980 mit Werks OC . Und das bei bestmöglichen Umständen für AMD, incl. der Ausreißer mit Hitman und Doom!.

Zieht man alle Spiele hinzu, dann sinds 14% zur 980 OC.

Und wenn man dann hier sieht, wie extrem nah die RX480 an einer GTX 980 im TimeSpy drann ist: [computerbase.de] DOOM + Vulkan Benchmarked. - Page 23
Dann ist der 3D Mark für AMD eigentlich noch relativ wohlwollend.


Aber gut, einige übertragen die Leistung, die AMD in Ausnahmefällen erzielt gleich auf alle Spiele. Oft wird ja auch vergessen, dass z.B. Hitman selbst unter DX11 schon erheblich besser auf AMD Karten läuft. DX12 erweitert den Vorsprung da nur noch geringfügig.

Natürlich könnte man jetzt noch 10 weitere Karten genauestens durchgehen, aber Soo viel verändert Async Compute jetzt eben auch nicht. Wie gesagt, für die RX480 reicht es nichtmal, um in DX12/Vulkan spielen im Schnitt an der GTX 980 vorbeizuziehen. Sie bleibt also trotz Async Compute in der Rangliste auf dem selben Platz.

 

[Chinaquads]

Also alles nur halb so wild, wie ich schon vermutet habe. Es wurde bewusst auf Optimierungen verzichtet, damit keine der beiden Hersteller Vorteile haben.

Schön, das Nvidia mit der Pascal Serie nun auch paralleles AC beherrscht

 

[murkskopf]

Keine Optimierung kann für den einen IHV schon ein optimaler Fall sein und für den anderen nicht...

Exakt! Das dies bisher von den meisten Nutzern ignoriert wird ist wirklich schade. Das Time Spy wohl eine Async-Compute-Implementierung verwendet, welche deutlich näher an Nvidias Ideallösung liegt scheint kein Geheimnis zu sein. Wie man im Forum von Anandtech entdeckt hat, verwendet Nvidia-Hardware unter der gegeben Implementierung immer doppelt soviele Hardware-Queues (4 im Fall mit und 2 im Fall ohne Async-Compute), obwohl AMD-Hardware theoretisch in der Lage sei, deutlich mehr Queues zu handlen als Pascal.

Dann ist der 3D Mark für AMD eigentlich noch relativ wohlwollend.
[...]
Natürlich könnte man jetzt noch 10 weitere Karten genauestens durchgehen, aber Soo viel verändert Async Compute jetzt eben auch nicht. Wie gesagt, für die RX480 reicht es nichtmal, um in DX12/Vulkan spielen im Schnitt an der GTX 980 vorbeizuziehen. Sie bleibt also trotz Async Compute in der Rangliste auf dem selben Platz.

Wie Computerbase gezeigt hat, verhält sich die RX 480 mit Asynchronous Compute aber anders als die vorherigen AMD-Chips: im nBodyGravity-Sample erhält die RX480 vergleichsweise geringen Partikelmengen einen kleineren Leistungszuwachs als GCN-1.1- und GCN-1.2-basierte GPUs. Erst bei größeren Partikelmengen erweist sich die RX 480 als schneller, da hier die älteren Karten leistungsmäßig einbrechen.

Dein Versuch zu beweisen, dass Time Spy ein "guter" Benchmark sei, dass sich eine einzelne Karte - und zwar ein Sonderfall - in etwa ähnlich verhält wie in Spielebenchmarks funktioniert nicht wirklich. Die Karte basierend auf GCN 1.1 und GCN 1.2 verlieren im Vergleich zum Großteil aller Spielebenchmarks (~ alle DirectX 12/Vulkan-Titel außer dem Nvidia-optimierten RoTR) in Time Spy deutlich an Boden; z.T. mehr als 15%.

 

[Najuno]

Also alles nur halb so wild, wie ich schon vermutet habe. Es wurde bewusst auf Optimierungen verzichtet, damit keine der beiden Hersteller Vorteile haben.

Schön, das Nvidia mit der Pascal Serie nun auch paralleles AC beherrscht

Nachdem ja nun eine Stellungnahme von den Machern des 3D Marks vorliegt, kann man wohl getrost diese Diskussion begraben. War mir aber schon vorher klar, daß wenn man hier zu Gunsten von nVidia getrickst hätte, sich Futuremark und nVidia wohl keinen Gefallen getan hätten und der 3D Mark sämtliche Bedeutung für immer verloren hätte.

 

[Laggy.NET]

Dein Versuch zu beweisen, dass Time Spy ein "guter" Benchmark sei, dass sich eine einzelne Karte - und zwar ein Sonderfall - in etwa ähnlich verhält wie in Spielebenchmarks funktioniert nicht wirklich. Die Karte basierend auf GCN 1.1 und GCN 1.2 verlieren im Vergleich zum Großteil aller Spielebenchmarks (~ alle DirectX 12/Vulkan-Titel außer dem Nvidia-optimierten RoTR) in Time Spy deutlich an Boden; z.T. mehr als 15%.

Ok, weil du es bist, machen wir das Spiel nochmal bei der R9 390X OC vs GTX980 OC

Aktiviert man alle Spiele im CB Benchmark, dann ist die 390X 8% langsamer, als die GTX 980
Aktiviert man nur die DX12/Vulkan spiele, dann ist die 390X 4% langsamer. als die GTX 980

Bei der Fury ist es ein klein wenig anders. Mit allen Titeln ist sie 2% langsamer, als die 980, DX12/Vulkan-only ist sie 4% schneller.


Ich sehe immernoch nicht, wo Futuremark hier ungewöhnliche Ergebnisse liefert.... Zumal AMD im TimeSpy durch Async doppelt so viel hinzugewinnt, wie Pascal.
Sorry, aber die Diskussion, dass Nvidia favorisiert wird ist einfach nur völlig bekloppt.

 

[der-sack88]

Für mich ist das genau so, als hätte Futuremark zwar Tessellation eingebaut, dieses aber auf 16x begrenzt. Damit wäre das ganze auch nicht "optimiert", trotzdem würde in diesem Fall AMD profitieren statt so eben nVidia.

Wenn die Entwickler in Zukunft ihre Spiele einigermaßen vernünftig auf beide Hersteller optimieren dürfte Time Spy also die Reealität in Spielen nicht wirklich widerspiegeln. Ist natürlich auch nicht der Anspruch und war es auch nie, aber das zeigt ja wieder nur, wie sinnlos solche Benchmarks für den Alltag für alle sind, die OC nicht als Wettbewerb betreiben...

Ok, weil du es bist, machen wir das Spiel nochmal die der R9 390X OC vs GTX980 OC

Aktiviert man alle Spiele im CB Benchmark, dann ist die 390X 8% langsamer, als die GTX 980
Aktiviert man nur die DX12/Vulkan spiele, dann ist die 390X 4% langsamer. als die GTX 980

Bei der Fury ist es ein klein wenig anders. Mit allen Titeln ist sie 2% langsamer, als die 980, DX12/Vulkan-only ist sie 4% schneller.


Ich sehe immernoch nicht, wo Futuremark hier ungewöhnliche Ergebnisse liefert....

Aber auch nur, weil offensichtlich kaputte Spiele wie ROTR da mit reinspielen. Wer nutzt in solchen Spielen DX12, wenn DX11 sogar schneller ist? Wenn man solche Fälle rausnimmt (DX12 langsamer->nutzt eh keiner->kann ignoriert werden) sieht das ganze doch anders aus...
Wie genau sich das ganze entwickelt kann natürlich keiner abschätzen, aber so ein DX12 wie in ROTR kann sich doch keiner wirklich wünschen. Gut, vielleicht die grünen Propellerjungs, denen die absolute Leistungsfähigkeit ihrer Karte vollkommen egal ist, solange sie relativ gesehen schneller ist als die der Konkurrenz...

 

[Locuza]

Exakt! Das dies bisher von den meisten Nutzern ignoriert wird ist wirklich schade. Das Time Spy wohl eine Async-Compute-Implementierung verwendet, welche deutlich näher an Nvidias Ideallösung liegt scheint kein Geheimnis zu sein.

Und wie stellt man fest, dass Time Spy Multiengine in der Art verwendet, die praktisch das Ideal für Nvidia GPUs darstellt?
Wie würde denn das Ideal für AMD aussehen und wo würde theoretisch die Mitte liegen?

Wie man im Forum von Anandtech entdeckt hat, verwendet Nvidia-Hardware unter der gegeben Implementierung immer doppelt soviele Hardware-Queues (4 im Fall mit und 2 im Fall ohne Async-Compute), obwohl AMD-Hardware theoretisch in der Lage sei, deutlich mehr Queues zu handlen als Pascal.

Futurmark hat doch selber die GPUView für Maxwell, GCN Gen 3 und Pascal gezeigt:

970: Eine Queue (GFX + Compute)
http://www.futuremark.com/static/images/news/nvidia-gtx-970-async.png

Fury X: Zwei Queues ( Einmal GFX und einmal Compute)
http://www.futuremark.com/static/images/news/amd-radeon-fury-async.png

1080: Zwei Queues ( Einmal GFX und einmal Compute)
http://www.futuremark.com/static/images/news/nvidia-gtx-1080-async.png

Der Profiler listet manchmal mehrere Queues auf, welche allerdings nicht verwendet werden.

Dein Versuch zu beweisen, dass Time Spy ein "guter" Benchmark sei, dass sich eine einzelne Karte - und zwar ein Sonderfall - in etwa ähnlich verhält wie in Spielebenchmarks funktioniert nicht wirklich. Die Karte basierend auf GCN 1.1 und GCN 1.2 verlieren im Vergleich zum Großteil aller Spielebenchmarks (~ alle DirectX 12/Vulkan-Titel außer dem Nvidia-optimierten RoTR) in Time Spy deutlich an Boden; z.T. mehr als 15%.

15% gegenüber wen und welche Benchmarks nehmen wir zum Vergleich von Spielen?

 

[murkskopf]

Schön, das Nvidia mit der Pascal Serie nun auch paralleles AC beherrscht

Wie kommst du darauf? Laut dem GPU View Tool ist das nicht der Fall. Die Compute-Blöcke und die 3-D-Queue werden ständing abwechselnd unterbrochen, was für einfaches Context-Switching spricht.

Und wie stellt man fest, dass Time Spy Multiengine in der Art verwendet, die praktisch das Ideal für Nvidia GPUs darstellt?
Wie würde denn das Ideal für AMD aussehen und wo würde theoretisch die Mitte liegen?

Wie Futuremark selber bestätigt hat, gibt es keine IHV-spezifischen Pfade, sondern einen Code, welcher optimal auf aller Hardware läuft. Dass es sich hierbei um keine echte Parallelausführung von AC handelt kann man im GPU View Tool im Vergleich mit anderen Spielen sehen. Die 3D-Queues werden stets unterbrochen, wobei es eine mit der Unterbrechung deckungsgleiche Compute-Queue gibt. Dies ist bei echten Spielen mit AC nicht der Fall.

15% gegenüber wen und welche Benchmarks nehmen wir zum Vergleich von Spielen?

Z.B. bei demm Verhältnis Fury X zu GTX 1070 und allen DirectX 12/Vulkan Titeln mit AC ausgenommen RotR. In QB, AotS, Warhammer, Hitman, GoW, Doom, etc. zeigt sich die Fury X mit AC schneller als die 1070, in Time Spy ist die GTX 1070 aber 11% schneller.

 

[HardStyler3]

selbst mit der stellungnahme steht immernoch im raum das dieser "neutrale weg" mehr auf das parallele der pascal architektur zugeschnitten ist als das parallele der gcn architektur

was sich eig durch die stellungnahme nur bestätigt hat

 

[Brainwaver]

Damit macht es doch den Benchmark aber total nutzlos, den die Spieleentwickler werden doch nicht auf diese Funktionen verzichten, wie es Futuremark hier angeblich aus Neutralitätsgründen möchte.
Mal ganz davon abgesehen wüsste ich jetzt nicht das Asynchronous Compute ein spezielles Feature von AMD wäre, das gehört doch zu DX12 dazu, wenn NVidia in dem Fall pennt kann doch AMD nichts dafür.

 

[Locuza]

Wie kommst du darauf? Laut dem GPU View Tool ist das nicht der Fall. Die Compute-Blöcke und die 3-D-Queue werden ständing abwechselnd unterbrochen, was für einfaches Context-Switching spricht.

Durch Context-Switching gewinnt allerdings keine GPU Performance, sie verlieren alle.

Die 3D-Queues werden stets unterbrochen, wobei es eine mit der Unterbrechung deckungsgleiche Compute-Queue gibt. Dies ist bei echten Spielen mit AC nicht der Fall.

Das sieht in einigen Fällen wirklich so aus, im Vergleich dazu Hitman:
https://abload.de/img/1080hitmanasynccomputytjvv.jpg
DX12 Performance Discussion And Analysis Thread | Page 70 | Beyond3D Forum
Hat jemand zufällig noch GPU-Views zu anderen Spielen?

Eine "simultane Ausführung" liegt allerdings auch bei Time Spy vor, ansonsten würde hier niemand Performance gewinnen.

Z.B. bei demm Verhältnis Fury X zu GTX 1070 und allen DirectX 12/Vulkan Titeln mit AC ausgenommen RotR. In QB, AotS, Warhammer, Hitman, GoW, Doom, etc. zeigt sich die Fury X mit AC schneller als die 1070, in Time Spy ist die GTX 1070 aber 11% schneller.

Bei Quantum Break scheint eine Fury X ein paar Frames schneller zu laufen, ich habe aber keine Zahlen mit einer 1070 im Vergleich gefunden:
Quantum Break DX12 GTX 1080 Vs GTX 980 TI Vs AMD Fury X Frame Rate Comparison - YouTube

Warhammer: ((1080p mit MSAA) Unter DX12 im GPU-Limit ist eine übertaktete 980Ti ~ 30% schneller als eine Fury X, eine 1070 sollte schneller sein, unter 1440p mit FXAA ist die 980 Ti nur noch 13% schneller, die 1070 ist dann möglicherweise langsamer)
Total War: Warhammer - Test der DirectX-11-Version sowie erste Ergebnisse mit DirectX 12

Hitman: (Bei PCGH gewinnt die Fury X mit 5% unter 1440p, bei CB ist die Fury X 13% schneller in 1440p, wobei CB DX12 bei AMD und DX11 bei Nvidia nimmt)
GTX 1060 im Test: Benchmarks und Fazit
https://www.computerbase.de/2016-06/nvidia-geforce-gtx-1070-test/4/#diagramm-hitman-2560-1440

Ashes of the Singularity: (9% Vorsprung für eine Fury X, AMD DX12, Nvidia DX11)
https://www.computerbase.de/2016-06.../#diagramm-ashes-of-the-singularity-2560-1440

Zu GoW hätte ich gerne aktuelle Zahlen, ich kenne nicht einmal alte.

Doom verwendet auch Shader Intrinsics auf Radeons. (Möglicherweise kommen noch Compute-Queues für Pascal, aber vielleicht auch nie)

Rise of the Tombraider: (Eine 1060 ist 33% schneller als eine RX 480 in DX12, aber nur 2% unter DX11. Die Fury X ist unter DX11 38% langsamer als eine 1070, unter DX12 sehr wahrscheinlich immer noch stark)
http://www.pcgameshardware.de/Nvidi...karte-264678/Tests/GTX-1060-Review-1201931/2/

Wenn ich die Time Spy Ergebnisse bei CB nehme:
https://www.computerbase.de/2016-07...ark/2/#abschnitt_19_grafikkarten_im_vergleich

Dann liegt der 3D Mark Score einer 1070 9% vor einer Fury X, der Graphics Score 12%, in der ersten Testszene 6%, in der zweiten 12%.
Durch Async Compute gewinnen Radeons hier 9-15% und damit bisher mehr als in Ashes oder vermutlich Hitman, wo die Entwickler 5-10% angeben.
Man könnte kritisieren, dass hier Radeons allgemein nicht so gut abschneiden, ausgehend von dem eher begrenzten Material was wir bisher zum Vergleichen haben.
Und man muss teilweise natürlich auch akzeptieren, dass der Time Spy Benchmark keine absolute Referenz sein kann.

 

[Chinaquads]

Wie kommst du darauf? Laut dem GPU View Tool ist das nicht der Fall. Die Compute-Blöcke und die 3-D-Queue werden ständing abwechselnd unterbrochen, was für einfaches Context-Switching spricht.



Wie Futuremark selber bestätigt hat, gibt es keine IHV-spezifischen Pfade, sondern einen Code, welcher optimal auf aller Hardware läuft. Dass es sich hierbei um keine echte Parallelausführung von AC handelt kann man im GPU View Tool im Vergleich mit anderen Spielen sehen. Die 3D-Queues werden stets unterbrochen, wobei es eine mit der Unterbrechung deckungsgleiche Compute-Queue gibt. Dies ist bei echten Spielen mit AC nicht der Fall.



Z.B. bei demm Verhältnis Fury X zu GTX 1070 und allen DirectX 12/Vulkan Titeln mit AC ausgenommen RotR. In QB, AotS, Warhammer, Hitman, GoW, Doom, etc. zeigt sich die Fury X mit AC schneller als die 1070, in Time Spy ist die GTX 1070 aber 11% schneller.

Da ich der PCGH und ihren Redakteuren und deren Recherchefähigkeit und Auffassungsvermögen voll und ganz als Laie vertraue, so darf ich folgenden Text zitieren

"Im Falle von Pascal und GCN werden 3D-Grafik und Compute parallel abgearbeitet, wodurch die Leistung steigt - bei Radeons durchschnittlich etwas mehr als bei Geforces."


Ich verstehe das so, das Futuremark standartisierte Verfahren angewendet hat, wobei bei anderen Spielen ( AOS, Tomb Raider, Hitman ) die AC Geschichte etwas mehr auf AMD zugeschnitten worden ist.

Korrigiert mich Bitte, wenn ich falsch liege.

 

[-Xe0n-]

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.

 

[Chinaquads]

Was heißt hier meinen Kopf nicht selber benutzen ?

Ich hör von Async Compute nur die ganze Zeit die AMD Fraktion jubeln, das sie Nvidia eins reinwürgen können, sobald das einmal nicht der Fall ist, flippt diese Fraktion aus und unterstellt anderen Betrug etc.

So siehts doch aus!