1) Selbst M$ hat gesagt, dass DX12 das alte DX11 mittelfristig nicht ersetzt, sondern nur ergänzt. Der Grund ist, dass sich die Benutztung der Schnittstelle viel aufwendiger als die ihres Vorgängers gestaltet, weshalb sich für die meisten Spiele ein Umstieg nicht lohnt. Persöhnlich habe ich mit DX12 noch nicht gearbeietet, ich habe aber Erfahrungen mit OpenGL und Vulkan. Während man in OpenGL leicht zu Ergebnissen kommt, und man den Programmablauf weitgehend "lesen" kann, braucht es bei Vulkan über 1000 Zeilen bis überhaupt mal ein Dreieck auf dem Bildschirm erscheint, und Leute die sich nicht mit Grafiktreiberaufbau und Co. befasst haben dürften keine Ahnung haben was da gerade passiert. Der Aufwand ein Spiel oder eine Engine performant zu entwickeln ist deutlich größer.
Das glaub ich dir sofort. Hab mal versucht mich an Vulkan zu setzen, und kam nicht mal in die Nähe von irgendwas, was auch nur mit Bildausgabe zu tun hatte.
Aber nur weil etwas komplexer ist, heißt das ja nicht, dass man es deswegen nicht macht. Ein Laserpointer ist auch deutlich komplexer als eine Glühbirne, aber trotzdem ist ein Laserpointer sinnvoll (in manchen Szenarien).
2) Dieser Modus ist mir nicht bekannt, ich habe mich aber wie gesagt mit DX12 auch noch nicht ernsthaft beschäftigt. Es wäre aber ein wenig Zauberei, oder nicht? Der geringe Overhead von DX12 und Vulkan rührt ja schließlich aus der Abgabe von Kontrolle vom Grafiktreiber an den Spieleentwickler. Wenn man also ein "High-Level-DX12" so einfach wie DX11 und so performant wie DX12 machen könnte, warum macht man das dann nicht einfach direkt mit DX11, wovon 99% der Spiele direkt profitieren würden?
Ich dachte, der geringere CPU-Load liegt nicht nur am Entwickler (natürlich auch). Auszug aus
Wikipedia:
Windows 10 includes WDDM 2.0, which is designed to dramatically reduce workload on the kernel-mode driver for GPUs that support virtual memory addressing, to allow multithreading parallelism in the user-mode driver and result in lower CPU utilization.
3) Einfacher gesagt als getan. Für einfache (Indie) Spiele ist das sicher möglich, aber die meisten größeren Projekte müssen irgendwann an der zugrunde liegenden Engine basteln. Das Problem ist, die einfachen Indiespiele brauchen den DX12 Modus meistens nicht, denn viele davon sind grafisch onehin eher schlicht. Größere Projekte, die an der Engine rumfummeln, laufen dagegen in Problem 1), und müssen deutlich mehr Zeit und damit Geld in die Entwicklung des DX12 Pfads investieren.
Naja, die meisten Indie Spiele benutzen UE oder Unity. Für "größere" Indie Spiele wie Cities Skyline würde sich DX12 sofort rentieren. Bei so Indie Spielen wie BattleBlock Theater sind wir uns aber einig, dass da DX12 nicht nötig ist. Aber das läuft auch auf einer iGPU von Intel.
GCN hatte seit der Geburt ACEs.
Bei GCN Gen 1 (Tahiti, Pitcairn, Cape Verde, Oland) gab es zwei ACEs, wobei die technische Implementierung simpel zu sein scheint.
Zwei Compute-Pipes die jeweils eine Compute-Queue managen.
Ich weiß schon, aber bei den entsprechenden Spielen bringt das kaum Performance Vorteile (hatte ich in Erinnerung).
Ab GCN Gen 2 hat AMD das Ganze umfangreicher gestaltet, mit einer separaten Engine (MEC) die 4 Compute-Pipes beherbergt und bis zu 32 Compute-Queues managen kann, zusätzlich gibt es auch Microcode-Support, dass ganze ist also auch ein wenig programmierbar.
Mit GCN Gen 3 gab es wieder ein paar Verbesserungen was das Management von Compute-Queues anging und es gibt einen größeren Microcode-Speicher.
Das bezieht sich jetzt aber nur auf Async Compute Fähigkeiten.
Es gab zwischen den Generationen natürlich mehrere feine, aber nennenswerte Unterschiede.
Unified Memory kam erst mit GCN Gen 2, Compute Context Switches mit GCN Gen 3, ebenso eine bessere Cross-Lane-Implementierung und eine bessere Scalar-Unit.
Ich will ja gar nicht dementieren, dass nichts passiert ist. Nur die meisten Änderungen sind, wie du sagt, sehr "fein". Für die meisten eher unwichtig, weil daraus keine direkten Performance Vorteile rausspringen.
Das Problem an Hawaii und Fiji waren nicht die Feinheiten. Bei Hawaii weniger, aber vor allem bei Fiji könnten die Shader nicht genug rechnen. Polaris zeigt, wie es besser geht.
Fiji hat 4096 Shader, also ~78% mehr als Polaris, dafür aber ~10% weniger Takt. Trotzdem ist sie nur 30-40% schneller (selbst wenn der VRAM nicht limitiert, z. B. TW3 @WQHD).
Aber allgemein bedeutet allerdings Async Compute nicht einfach einen Prozessor mit Compute-Queue-Management irgendwo reinpflanzen, der Rest der Architektur muss mehrere Blöcke unabhängig operieren können, sonst kann man keine nennenswerte Vorteile daraus ziehen.
Das ist sehr komplex, weil es keine simple Beurteilung in jeder Form gibt.
Es kommt darauf an wie lange die Arbeitspipeline einer Architektur ist, wie viele Blasen es im Arbeitsstrom beim regulären Ablauf gibt usw.
Die Vorteile würden je nach Architektur stärker oder schwächer wiegen und es gibt kein pauschales Urteil wie --> kann Async Compute = cool.
Hab ich vermutlich falsch ausgedrückt, aber das meinte ich. Wenn NV einfach irgendwo ACEs in Maxwell / Pascal klatschen würde, würde das sicher keine Performance Vorteile bringen. Da gehört mehr dazu.
Aber trotzdem: je mehr Shader, desto mehr "Blasen" können entstehen. Klingt für mich zmdst logisch.
AMDs Effizienznachteil liegt an vielen unterschiedlichen Stellen begründet, ACEs oder nur eine GFX-Queue ist definitiv nicht der (alleinige) Grund, wieso Nvidia soweit vorne liegt.
Sicher. Größeres Speicherinterface hatte ich z. B. auch schon angesprochen. Und sicherlich gibt es auch noch andere Stellen. Was ich meinte, dass man vieles nicht so einfach verbessern kann, ohne das Prinzip von GCN und den ACEs "über Board zu werfen".