News DirectX 12: Disput zwischen Oxide und Nvidia geht weiter

Alle die jetzt meinen, Nvidia-Fanboys seien nun geknickt oder Nvidia in Verlegenheit: Ihr liegt definitiv falsch. Es bringt auch nichts Nvidia madig zu reden bzw. infrage zu stellen. Ihr überseht dabei nämlich einen Punkt.
Die meisten Fanboys kaufen sich ihre Grafikkarten nicht gerade wegen der Firmenphilosophie, Glaubwürdigkeit, dem Speicher, DX12 oder gar nach Preis/Leistung. Deshalb werden die News solchen Leuten auch am Arsch vorbeigehen. Ist doch ihr Recht.

Theoretisch kann man die ganze Diskussion also direkt einstellen. Jeder kann sich sein Urteil bilden.
 
Zuletzt bearbeitet:
scootiewolff schrieb:
Yolo, bis DX12 Salonfähig wird, gibt es die neuen Grakas, was interessiert mich dann das Geschwätz von gestern

Bei Windows 8 und direkt x 11.3 bleiben, wenn du eine starke CPU hast. Selbes Feature-set, aber ohne die CPU-Entlastung.
 
Die Engine wurde entsprechend entworfen um entsprechend viele Einheiten eines Strategiespiels darstellen zu können. Sie nutzt die Fähigkeiten von Mantle und DX12 (und letzteres ist ja so toll von nvidia unterstützt) um die entsprechende Leistung abzurufen.
Das Problem ist jedoch momentan, dass die Engine eben in mancher Hinsicht schlecht für diesen Zweck, nämlich viele Einheiten zeichnen zu können, entworfen worden ist. GPUs können bereits ohne DX12 über das sogenannte "Instancing" (https://en.wikipedia.org/wiki/Geometry_instancing) sehr schnell das gleiche Objekt mehrmals über einen einzigen Draw-Call zeichnen. Die Nitrous Engine scheint aber kein Instancing zu verwenden, sondern pro Einheit einen Draw-Call zu machen. Das ganze wurde zum Beispiel hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=550926) bei der Star-Swarm Demo diskutiert. Eventuell gibt es ja in neueren Versionen der Engine Instancing-Support. Da sie aber immer noch Draw-Call-Intensiv ist, lässt das mich das persönlich daran zweifeln.

Btw: Huhuhu Moon_Knight! :)
 
Lord_X

Was ich damit meinte. Entwickler mussten damals, wenn sie ein DX10 Spiel machen wollten, das Game komplett anders programmieren als mit DX9. Mit DX11 wurden dann Feature Level ect eingeführt werden. DX11 ist mit DX9 abwärts kompatibel.
Das heißt ein Entwickler kann ein DX9 Spiel machen und davon schnell eine DX11 Version. Mit DX12 funktioniert es soviel ich gelesen habe genauso. Somit war DX10 einfach ein schlechte Schnittstelle, auf die es lange gedauert hatte, bis man auf diese Mehrheitlich Games hatte und dann wieder auf DX11 umsteigen konnte. DX11 selbst ist aber wesentlich schneller wieder aufgenommen worden.

Heute gibt es ja weiterhin viele Free to Play Games auf DX9, weil alle aktuelle Grafikkarten diese Version unterstützten und weil DX9 Games doch von mehr Rechner gestartet und gespielt werden kann. (Desweiteren wahrscheinlich auch wesentlich günstiger in der Produktion).

http://www.hardwarecanucks.com/foru...-12-detailed-dx11-gpu-compatibility-more.html

Es gibt aber noch irgendwo im Internet andere Berichte, die das besser und "richtiger" als ich erklären können.


Nai

Was ich nur interessant finde. Laut Entwickler ist das Game gar kein Beispiel für den "effektiven" Einsatz von ACE. Obwohl das so ist, zeigt sich trotzdem ein Vorteil für AMD aktuell (Nagut vllt auch deshalb ?).
Aber immerhin, für NV ist alles offen/einsehbar und sie können ja mit Treiber nachhelfen. Eventuell möchte man aber auch einfach nur Zeit gewinnen damit man mit Pascal wieder "glänzen" kann. Denn dann zieht das Argument " was interessiert mich dann das Geschwätz von gestern" wieder.
Bei Kepler hat das doch auch gut geklappt, wieso mit Maxwell nicht ?
 
Zuletzt bearbeitet:
Moon_Knight schrieb:
Bei Windows 8 und direkt x 11.3 bleiben, wenn du eine starke CPU hast. Selbes Feature-set, aber ohne die CPU-Entlastung.

Genau! Dann bleibt der 1500,- DX11.3-Rechner wenigstens gleichwertig zu einem 500,- DX12-Rechner!

@Nai

Du warst bei der Entwicklung dabei?

Zitat Nai:

Das Problem ist jedoch momentan, dass die Engine eben in mancher Hinsicht schlecht für diesen Zweck, nämlich viele Einheiten zeichnen zu können, entworfen worden ist.
 
Zuletzt bearbeitet:
Und wenn Oxcide keine "geklonten Einheiten" haben möchte und jede einzelne Einheit einzeln berechnet werden soll bzgl Physikalischer Eigenschaften und deren Optik und nicht nur einer Health Status Anzeige?

Bsp: Panzer A vorne links getroffen, dadurch schlechtere Zielsicherheit.
Panzer B seitlich getroffen und Fahrwerk beschädigt, daher weniger beweglich etc.
Inkl Schadensmodell usw.
 
Du warst bei der Entwicklung dabei?
Ich hab so ein mehr oder weniger nicht geringes Wissen darüber, wie Computergraphik und GPUs funktionieren. . . .

Und wenn Oxcide keine "geklonten Einheiten" haben möchte und jede einzelne Einheit einzeln berechnet werden soll bzgl Physikalischer Eigenschaften und deren Optik und nicht nur einer Health Status Anzeige?
Geht doch auch? Man muss nur noch kreativ sein das Instancing entsprechend anpassen.
 
Dann bleibt die Frage, was einfacher ist: entsprechend anpassen oder einfach vorhanden fertige Methoden/Technik nutzen?
 
Ja, oder man passt das Instancing nicht an und nutzt die neuen Möglichkeiten, da kein Flaschenhals mehr vorhanden bzw der Hals wesentlich dicker ist.

Es zeigt dennoch eine schwäche der nvidia Architektur. Bei der Tesselation Schwäche, in einem echten Benchmark wohlgemerkt, wurde ordentlich auf AMD eingeprügelt.
Nutzt ein Spiel mitsamt Engine die neuen Möglichkeiten einer API und nvidia verkackt in dem Bereich... Oh da wird gerechtfertigt.
 
Ich weiss ja nicht warum hier alles auf die Draw Calls abgestellt wird.
Meines Wissens geht es bei AS doch darum, dass GPGPU-Befehle gleichzeitig mit Renderbefehlen abgearbeitet werden können. Ohne AS müssten diese nämlich nacheinander verarbeitet werden. Und hier scheint die Stärke der GCN-Architektur einfach zu greifen.
Korrigiert mich bitte, wenn ich mich irren sollte.
In diesem Zusammenhang stellt sich mir dann die Frage, ob dieser Umstand überhaupt softwareseitig umsetzbar ist. Ich denke eher nicht.
 
Zuletzt bearbeitet:
Prozessor Knox schrieb:
Du möchtest aber noch ernst genommen werden?

Man kann Ihm viel unterstellen, aber das Nai keine Ahnung in diesem Bereich hat wohl nicht. Das zeugen die passenden Beiträge in diesem Forum. Die dir wiederum fehlen und bis dato keine technischen Details kamen. Entweder technisch Diskutieren und dies auch belegen oder einfach nur lesen.
 
Zunächst zum Hintergrund: Zur Überraschung Vieler schnitten aktuelle Nvidia-Grafikkarten in Ashes of the Singularity schlechter ab als in anderen Spielen gewohnt. AMDs Radeon-GPUs konnten zunächst besser mit der neuen API umgehen als Nvidias GeForce-Modelle und profitierten vom Wechsel von DirectX 11 auf DirectX 12 viel stärker.

Die Formulierung finde ich etwas unglücklich.
Schlechter als in anderen Spielen gewohnt... Die DX12-Vergleiche sind ja irgendwie schon Mangelware. Gewohnt ist man die Performance der Karten nur aus DX11 und da ist es ja nun so, dass die Nvidia-Karten im DX11-Modus des Spiels den AMD-Karten haushoch überlegen waren, bzw dort die AMD-Karten unnatürlich schlecht waren (Fury X hinter 960). Da ist dann auch klar, dass die Sprünge bei AMD klar größer sind, wenn beide unter DX12 arbeiten.
Klar sieht man in den Tests auch, dass Nvidia mit DX12 wenig zulegt, teils sogar verliert. Wenn man aber mal die DX12-Ergebnisse mit dem normalen Leistungsgefüge vergleicht, sind das keine Sprünge, die man je nach Spiel nicht auch schon in DX11 mal in die eine und mal in die andere Richtung beobachten konnte.
Von daher ist eine Bewertung der allgemeinen DX12-Performance anhand von einem einzelnen Spiel, das dazu noch eine Beta ist, für mich noch nicht besonders aussagekräftig. Erstens sind die Ergebnisse beider Hersteller sehr inkonsistent (bei AMD bezüglich DX11, bei NVidia bezüglich der DX12-Optimierung) und zweitens kann das Spiel natürlich auch einfach ein AMD-freundlicher Titel sein, so wie z.B. Civilization oder Dragon Age oder es andersherum Call of Duty für Nvidia ist.
 
Eines der Highlights im neuen Catalyst 15.8 Beta der grade rausgekommen ist:

"Ashes of the Singularity - Performance optimizations for DirectX® 12" :D

Wäre ja mal cool wenn AMD da noch etwas zulegen kann um es Nvidia mal so richtig reinzuwürgen, völlig egal ob das letztendlich representativ für die tatsächliche Performance unter Dx12 ist, aber es wäre ein guter Marketing Schachzug von AMD diese Techdemo noch besser für sie aussehen zu lassen und gutes Marketing (so sehr ich AMD auch mag) ist nicht deren große Stärke :D.

Und bevor mir jetzt jemand unterstellt ich bin AMD Fanboy, ich hab grade einen GTX 780 verbaut und auch schon davor Nvidia verbaut gehabt, aber ebenso auch AMD, ich kaufe was gerade taugt, nicht ob das Ding ein grünes oder rotes Logo hat ;)
 
Wen interessiert DX12 denn jetzt schon? Jeder der hier ne GPU im 200+ Euro Bereich hat wird doch eh umsteigen bevor DX12 relevant wird.
 
Man braucht win10...
Man braucht gute dx12 games, die nur mit dx12 laufen werden.

Alles Dinge, die vielleicht in 1-2 Jahren interessant werden.

Momentan fährt man mit einer Nvidia besser,
AMD hat bei vielen Spielen Probleme, zumindest in der Anfangszeit, bei manchen Games bleiben diese Nachteile für immer.

Nvidia ist hier ebenfalls nicht immer ideal, aber deutlich problemloser, besonders, wenn man nur spielen will und sich um Treiber usw. keine Sorgen machen möchte.

~2016 wird man dann sehen, was Sache ist.

Peinliche Fanboys werden sich weiterhin wegen einem Stück Hardware streiten,
wie bei Apple vs Samsung. usw.

Naja, Kinder brauchen auch eine Beschäftigung...
(Hauptsache, die sind weg von der Straße!^^)
 
Also wenn ich das richtig verstehe, ist die Unterstützung von ACEs ein Kernfeature von DX12. Und Maxwell kann das anscheinend nicht bzw nicht richtig. Aber Nvidia bewirbt die 900er Serie doch als voll DX12 kompatibel, die Fanboys behaupteten sogar die Kompatibilität sei sogar "voller" als bei AMD...
Und nun heißt es wieder halb so wild, genau wie bei dem 970 Desaster. Ja was solls, Nvidia bewirbt seine Produkte halt mit falschen Angaben, ja und? Bis DX12 Spiele da sind, gibt es auch schon neue Grafikkarten die das auch können... :lol:

Und das sind ja immer die üblichen Verdächtigen hier. Ist euch eine solche Argumentation echt nicht peinlich? Ja genau, und bei AMD ist ja das Fehlen von HDMI 2.0 ein absolutes no-go...

Achja, was ich ganz interessant finde:
In the end, I think everyone has to give AMD alot of credit for not objecting to our collaborative effort with Nvidia even though the game had a marketing deal with them. They never once complained about it, and it certainly would have been within their right to do so.
Na ob sich Nvidia an AMD's Stelle genauso verhalten würde... :rolleyes: Stichwort Gameworks.

Das meint Robert Hallock von AMD dazu
Oxide effectively summarized my thoughts on the matter. NVIDIA claims “full support” for DX12, but conveniently ignores that Maxwell is utterly incapable of performing asynchronous compute without heavy reliance on slow context switching.
GCN has supported async shading since its inception, and it did so because we hoped and expected that gaming would lean into these workloads heavily. Mantle, Vulkan and DX12 all do. The consoles do (with gusto). PC games are chock full of compute-driven effects.
If memory serves, GCN has higher FLOPS/mm2 than any other architecture, and GCN is once again showing its prowess when utilized with common-sense workloads that are appropriate for the design of the architecture.
 
Zuletzt bearbeitet:
Nai, hat man bei AotS nicht bewusst auf Instacing verzichtet, um mehr Draw Calls zu produzieren?
Das heisst doch, dass absichtlich die CPU etwas "realitätsfremd" belastet wurde, um die Vorteile von DX12 über DX11, nämlich den verringerten CPU-Overhead aufzuzeigen?
In welcher Weise steht dies nun mit dem effizienterem Auslasten einer GPU durch Async Shaders in Verbindung? Wenn man sich im GPU-Limit befindet, sollte eine Karte, die ACEs (oder den nVidia-Gegenpart) ausnutzt besser sein als eine Karte, die es nicht nutzen kann (DX12>DX11).
Wenn nun nVidia im GPU-Limit keinen Nutzen daraus ziehen kann, bedeutet das doch entweder, dass sie ihre Shader bereits unter DX11 sehr effektiv auslasten, oder (was für mich auch logischer klingt, da für ein Frame unterschiedliche Bereiche einer GPU angesprochen werden müssen, während in dieser Zeit andere Teile idlen -> was Async Shaders ja beheben sollen) nVidia besitzt nicht die notwendige Voraussetzung um diese Technik zu nutzen?
 
Zuletzt bearbeitet:
Nai schrieb:
Mein Ziel wäre es gewesen, nicht einfach die Informationen wie es von vielen hier so gerne gemacht wird blind zu übernehmen, sondern ersteinmal genau nachvollziehen was Oxide abgefragt hat, bzw. wie genau das abgefragte definiert ist.

Vielleicht hilft dir das hier weiter:

https://msdn.microsoft.com/en-us/library/windows/desktop/dn899124(v=vs.85).aspx

IMO scheint es keine direkte Abfragemöglichkeit zu geben, da dieses API-Feature von ALLEN Chips mit DX12 Treiber unterstützt wird. Man kann nur durch Tests herausfinden, ob die Abarbeitung der unterschiedlichen Queues (Direct, Compute, Copy) parallel oder seriell erfolgt.
 
Zurück
Oben