DX10, DX11 – wann kommt was Neues?

[aths]

Ich bin recht unzufrieden mit D3D11. Es gibt ein paar neue Shadertypen, neue Datenformate und man kann flexibler auf den Speicher zugreifen. Dafür gleich eine komplett neue Version? Warum heißt das nicht D3D 10.2?

Schon D3D10 war relativ enttäuschend: Geometry-Shader, Validierung der Ressourcen nicht mehr pro Frame sondern nur bei der Erstellung, zwei neue Formate für HDR-Daten, stärkere Vereinheitlichung des Befehlssatzes: Es bleibt Feintuning. Immerhin machten die GPU-Entwickler hier den Sprung zur Unified-Shader-Technik, so dass die Rechenwerke gleichmäßiger ausgelastet werden können.

DX8 bot einen Sprung, weniger in den Fähigkeiten, dafür in der Standardisierung. DX9 SM2 litt noch unter der Beschränkung dass man nicht beliebig oft zwischen Textur-Sampling und arithmetischen Optionen wechseln kann. SM3 erlaubt endlich relativ freie Shader-Programmierung mit meistens ausreichender Programm-Länge. Seitdem bleiben die großen Fortschritte aus.

[mapel110]

Mal so rum gefragt, was fehlt denn deiner Meinung nach an Features?

[Brillus]

Ich erwarte persönlich als nächsten großen Schritt, die abkehr von den APIs und vollprogrammierebare Grafikkarten(bis hin zu Grafikkarten die in die CPU wandern wie es schon mal die x86 FP Einheiten gemacht wurde).

[RLZ]

DX10: Komplettes Redesign, neues Ressourcenmodell, neue Pipelinestufe, vereinheitlichte Shader, stark erweiterter Shaderbefehlssatz bis hin zu Bitoperationen, Predicated Rendering, enorm gesteigerte Effizienz
= enttäuschend?

DX11: Einführung von Techleveln, MT-Rendering, "OOP" in Shadern, Computer Shader, 3(!) neue Pipelinestufen für Tesselation,...
Sogar Order Independent Transparency kann man einigermaßen gut realisieren...
= enttäuschend?

Was erwartest du?
Was hättest du gern gesehen?
Mehr neue Fixed function Einheiten?

Der nächste Schritt wird imo sein die Pipeline "frei" (unter gewissen Restriktionen) selbst gestalten zu können. Dazu gabs von Stanford letztens sogar schon ein Paper dazu, in dem eine Beschreibungssprache für Grafikpipelines vorgestellt wurde.

[Demirug]

Es konnte nicht 10.2 sein weil es breaking changes bei den Interfaces gab.

[Gast]

Ich bleibe solange wie moeglich mit/bei dx9. Dx10 und Dx11 moegen die GPU "entlasten" aber das ist fuer mich wurscht. Wenn es unter dx9 fast gleichgut aussieht, warum sollte ich auf dx10 oder dx11[dirt2 :) lol] wechseln wenn das Spiel at dx9 gut und gerne 30% und mehr fps schneller gerendert wird?

[Neomi]

Kurz zusammengefaßt: "Abgesehen von den Neuerungen bleibt alles beim Alten." Auf die Art kann man jeden Fortschritt, egal wie groß, kleinreden. Das Problem sehe ich, wie die anderen hier ebenfalls, in deiner Erwartungshaltung. Ich für meinen Teil bin mit D3D11 zufrieden, auch wenn es natürlich nicht die perfekte Schnittstelle ist. Und um mal zu der einzigen konkreten Frage zu kommen:

Warum heißt das nicht D3D 10.2?

D3D11 erweitert nicht nur, sondern ändert ein paar Dinge der API. 10.1 war eine reine Erweiterung von 10, es kamen neue Interfaces hinzu ohne was an den alten zu ändern. Die API-Änderungen, die D3D11 auch für Karten vom D3D10-Techlevel bietet, müssen aber, um nutzbar zu sein, in die Hauptinterfaces rein.

[aths]

Mal so rum gefragt, was fehlt denn deiner Meinung nach an Features?Ich will eben keine neuen Features im Sinne von festen Möglichkeiten sehen. Ich will dass man bei Datenformaten nur noch die Bitbreite bestimmt und die genaue Verwendung der einzelnen Bits selbst programmiert. Die GPU kann beim Multisampling oder der Texturfilterung meinetwegen vorläufig noch Fixed-Function sein.

Was erwartest du?
Was hättest du gern gesehen?
Mehr neue Fixed function Einheiten?

Der nächste Schritt wird imo sein die Pipeline "frei" (unter gewissen Restriktionen) selbst gestalten zu können. Dazu gabs von Stanford letztens sogar schon ein Paper dazu, in dem eine Beschreibungssprache für Grafikpipelines vorgestellt wurde.Da ich keine 3D-Anwendungen entwickle weiß ich nicht, ob das was ich jetzt schreibe, stimmt, aber die neuen Shader-Typen scheinen mir die Grafikpipeline als Ganzes betrachtet wieder komplexer zu gestalten. Man muss diese Shader nicht nutzen, aber mir schwebt eine viel freiere Programmierung vor, dass es nur noch einen Shader-Typ gibt der auf alles Zugriff hat. Wie man das dann synchronisiert (Geometrie -> Pixel) müsste man sich überlegen, also ob es Flush-Befehle braucht die sicherstellen, dass vor der Abarbeitung des nächsten Shaders alle Daten auf die der nächste Shader zugreift schon geschrieben sind.

Es konnte nicht 10.2 sein weil es breaking changes bei den Interfaces gab.Wie aufwändig ist es dann, eine DX10-Engine für DX11 anzupassen?

Kurz zusammengefaßt: "Abgesehen von den Neuerungen bleibt alles beim Alten." Auf die Art kann man jeden Fortschritt, egal wie groß, kleinreden. Das Problem sehe ich, wie die anderen hier ebenfalls, in deiner Erwartungshaltung.Ja, wahrscheinlich. Ich wünsche mir wie schon gesagt die Abkehr von unterschiedlichen Shader-Typen. Die GPU sollte einfach programmierbar sein, wobei die Hardware noch bestimmte feste Funktionionen bietet wie Texturfilterung. Mit meiner Noob-Sicht auf D3D fügen die paar neue Sachen hinzu ohne dass es in die richtige Richtung geht.

[Demirug]

Ich will eben keine neuen Features im Sinne von festen Möglichkeiten sehen. Ich will dass man bei Datenformaten nur noch die Bitbreite bestimmt und die genaue Verwendung der einzelnen Bits selbst programmiert. Die GPU kann beim Multisampling oder der Texturfilterung meinetwegen vorläufig noch Fixed-Function sein.

Da ich keine 3D-Anwendungen entwickle weiß ich nicht, ob das was ich jetzt schreibe, stimmt, aber die neuen Shader-Typen scheinen mir die Grafikpipeline als Ganzes betrachtet wieder komplexer zu gestalten. Man muss diese Shader nicht nutzen, aber mir schwebt eine viel freiere Programmierung vor, dass es nur noch einen Shader-Typ gibt der auf alles Zugriff hat. Wie man das dann synchronisiert (Geometrie -> Pixel) müsste man sich überlegen, also ob es Flush-Befehle braucht die sicherstellen, dass vor der Abarbeitung des nächsten Shaders alle Daten auf die der nächste Shader zugreift schon geschrieben sind.

Nimm die native Larrabee ISA und du hast was du willst. Ich für meinen Fall habe keine List auf diesen Blödsinn.

Wie aufwändig ist es dann, eine DX10-Engine für DX11 anzupassen?

Ich habe bei uns 4 Stunden gebraucht.

Ja, wahrscheinlich. Ich wünsche mir wie schon gesagt die Abkehr von unterschiedlichen Shader-Typen. Die GPU sollte einfach programmierbar sein, wobei die Hardware noch bestimmte feste Funktionionen bietet wie Texturfilterung. Mit meiner Noob-Sicht auf D3D fügen die paar neue Sachen hinzu ohne dass es in die richtige Richtung geht.

Ist es nicht etwas anmassend von dir zu glauben was die „richtige Richtung“ ist wenn du selbst keine komplexen 3D Anwendungen schreibst?

[Neomi]

Wenn es unter dx9 fast gleichgut aussieht, warum sollte ich auf dx10 oder dx11[dirt2 :) lol] wechseln wenn das Spiel at dx9 gut und gerne 30% und mehr fps schneller gerendert wird?

Da hast du deinen Fehler doch schon. Wenn es mit D3D9 nur fast so gut aussieht wie mit D3D10/11, dann wird bei letzteren für das (wenn auch kleine) Plus an Optik eben mehr Arbeit investiert.

Es gibt nur wenige Gründe, weshalb D3D10 langsamer ist als D3D9 oder D3D11 langsamer als D3D10:

- Treiber für die neuere API sind nicht so gut optimiert wie für die ältere
Das sollte inzwischen für D3D10 nicht mehr der Fall sein, aber die Benchmarks aus der Zeit, als das noch so war, haben sich in manchen Köpfen festgesetzt. Das ist allerdings kein API-Problem, sondern ein Treiberproblem. Dazu kam bei Vista auch noch das neue Treibermodell, weshalb D3D9 (Vista) anfangs langsamer war als D3D9 (XP).

- die neuere API wird wie die ältere benutzt, nur mit neuen Interfaces
Sowas passiert, wenn eine vorhandene Engine mit minimiertem Aufwand umgeschrieben wird fast zwangsläufig. Wenn in der alten API noch bestimmte Verrenkungen nötig waren, um bestimmte Dinge zu erreichen, bleiben sie oft in der Engine, falls sie mit der neuen API immer noch funktionieren. Und zwar auch dann, wenn sie gar nicht mehr nötig wären. Das ist dann verschenkte Performance dank unsachgemäßer Nutzung, aber kein Problem der API selbst. Um es etwas positiver zu formulieren: umgeschriebene Engines haben für die neuere API meist noch Optimierungspotential, welches für die ältere API bereits ausgeschöpft ist.

- die neuere API bekommt mehr Arbeit zu tun
Endnutzer (und Publisher) wollen einen Fortschritt "sehen", und dafür reichen Zahlen zu identischen Screenshots nicht aus. Also werden zusätzliche Effekte draufgelegt, daß es dann langsamer wird ist klar und kein Problem der API selbst.

D3D10 bietet mehr Möglichkeiten zur Nutzung der GPU und mehr Chancen zur Entlastung von sowohl CPU als auch GPU als D3D9. Gleiches gilt für D3D11 gegenüber D3D10. Die APIs sind nur definierte Interfaces, die können von sich aus nicht langsamer sein.

[aths]

Nimm die native Larrabee ISA und du hast was du willst. Ich für meinen Fall habe keine List auf diesen Blödsinn.Besteht Larrabee nur aus den x86-Rechenwerken oder hat der Chip für das Triangle-Setup, Texturfilterung etc. noch eigene Units?

Ich habe bei uns 4 Stunden gebraucht.Sind die Unterschiede im Interface denn nun klein oder groß? Oder kann die Anpassung im Quelltext weitgehend mit Search&Replace gemacht werden?

Ist es nicht etwas anmassend von dir zu glauben was die „richtige Richtung“ ist wenn du selbst keine komplexen 3D Anwendungen schreibst?Ja, aber wie alle Noobs diskutiere ich trotzdem groß darüber. Zwei Gründe: Bei einer 3D-Grafikdemo, die Software-Rendering nutzt, gab es einen Effekt dass die Bildzeilen durcheinandergeschüttelt wurden. Mit 3D-Grafikkarten zu damaliger Zeit kaum zu machen.

In Quake 2 (wenn ich mich nicht irre) hatte man als Unterwasser-Effekt ein Bildwabern, was die 3D-beschleunigte Version nicht hatte. Das wäre heute problemlos (und natürlich in viel besserer Qualität) auf GPUs machbar. Komplett frei programmierbar ist die GPU aber noch nicht – warum nicht? Wäre die effektive Rechenleistung zu gering?

[Aquaschaf]

Komplett frei programmierbar ist die GPU aber noch nicht – warum nicht? Wäre die effektive Rechenleistung zu gering?

Es gibt immer einen Tradeoff zwischen Flexibilität und Performance. Mit der Programmierbarkeit die man heute hat kann man aber bereits "ziemlich alles" umsetzen.

[MuLuNGuS]

wenn die neue xbox auf DX11 basiert behaupte ich mal dass da laaange laaange nix kommen wird.

[Coda]

Besteht Larrabee nur aus den x86-Rechenwerken oder hat der Chip für das Triangle-Setup, Texturfilterung etc. noch eigene Units?
Es gibt TMUs, der Rest ist Software.

In Quake 2 (wenn ich mich nicht irre) hatte man als Unterwasser-Effekt ein Bildwabern, was die 3D-beschleunigte Version nicht hatte. Das wäre heute problemlos (und natürlich in viel besserer Qualität) auf GPUs machbar. Komplett frei programmierbar ist die GPU aber noch nicht – warum nicht? Wäre die effektive Rechenleistung zu gering?
Natürlich ist sie komplett frei programmierbar. Es steht dir frei einen kompletten Rasterizer in CUDA, OpenCL oder DirectCompute zu schreiben. Wird halt nicht wirklich schnell sein.

[aths]

Es gibt TMUs, der Rest ist Software.Gut. Dass die TMU-Funktionalität irgendwann komplett in Shader wandert, hielt ich früher für sicher. Inzwischen bin ich mir nicht mehr so sicher.

Natürlich ist sie komplett frei programmierbar. Es steht dir frei einen kompletten Rasterizer in CUDA, OpenCL oder DirectCompute zu schreiben. Wird halt nicht wirklich schnell sein.Ja, die heutigen GPUs sind ja nach wie vor vor allem GPUs, optimiert für Abarbeitung von Shadern.

[Fetza]

wenn die neue xbox auf DX11 basiert behaupte ich mal dass da laaange laaange nix kommen wird.

Meinst du mit neuer x-box jetzt die version für 2010? Die wird ja nur natal als neuerung an bord haben.

Die echte neue x-box wird bestimmt nicht vor 2012-13 rauskommen.

[The Jackal]

Es dauert nicht mehr lange dann haben wir eine frei programierbare Grafikkarte.

Dann lassen wir den genzen Mist mit DX 1 2 3 4 5 6 7 8 9 10 10.1 11 12 hinter uns.

Einfach wie eine CPU, Leistung da alle Detail da mit 30FPS min. Keine Leistung da alle Details Diashow. Egal welche neuen 3D Features, alle Karenen können es darstellen, sind aber nicht alle gleich schnell.

Meine große Hoffnung ist immer noch Larrabee. Frei von allen Restriktionen.

Wenn wir schon den Überwachnungsstaat kreigen, dann will ich wenigstens in meinem Rechner eine frei programierbare Grafikkarte haben. :-) Und bis dahin muß die 4870 X2 reichen.

[Demirug]

Es dauert nicht mehr lange dann haben wir eine frei programierbare Grafikkarte.

Dann lassen wir den genzen Mist mit DX 1 2 3 4 5 6 7 8 9 10 10.1 11 12 hinter uns.

Einfach wie eine CPU, Leistung da alle Detail da mit 30FPS min. Keine Leistung da alle Details Diashow. Egal welche neuen 3D Features, alle Karenen können es darstellen, sind aber nicht alle gleich schnell.

Selbst dann wird man noch eine API brauchen welche die unterschiedlichen ISAs durch einen gemeinsamen Bytecode vereint und ansprechbar macht. Und ähnlich wie es bei den CPUs immer wieder ISA Erweiterungen gibt wird man auch nicht umhin kommen den Bytecode anzupassen.

Desweiteren wollen die meisten Graphics engineers sich gar nicht auf diesem Detaillevel mit den GPUs rumschlagen.

Meine große Hoffnung ist immer noch Larrabee. Frei von allen Restriktionen.

Zum einen hat Larrabee immer noch fixed function Textureinheiten. Zum anderen wird der Chip wenn er endlich mal fertig ist sehr schön zeigen wie weit man aktuell mit einem frei programmierbaren Multicoredesign kommt. Nicht sehr weit.

[The Jackal]

@Demirug

Mein Utopia bröckelt. Du bist ja richtig böse.

[aths]

Zum einen hat Larrabee immer noch fixed function Textureinheiten. Zum anderen wird der Chip wenn er endlich mal fertig ist sehr schön zeigen wie weit man aktuell mit einem frei programmierbaren Multicoredesign kommt. Nicht sehr weit.Welchen großen Unterschied gibt es zwischen GT300 und Larrabee? So wie ich das bisher verstanden habe, kontert Nvidia Intel aus, bevor Intel ein halbwegs vorzeigbares Silizium hat.

[Coda]

GT300 hat vor allem noch kompletten Support für Rasterisierung in Hardware, also Rasterizer und ROPs.

Von der programmierbarkeit abgesehen von virtueller Speicherverwaltung sind sie wohl gleich, wobei sich das Modell wie man sie programmieren sollte um maximale Performance zu erzielen doch ein wenig unterscheidet.

[Tigerchen]

Ich bin recht unzufrieden mit D3D11. Es gibt ein paar neue Shadertypen, neue Datenformate und man kann flexibler auf den Speicher zugreifen. Dafür gleich eine komplett neue Version? Warum heißt das nicht D3D 10.2?

Schon D3D10 war relativ enttäuschend: Geometry-Shader, Validierung der Ressourcen nicht mehr pro Frame sondern nur bei der Erstellung, zwei neue Formate für HDR-Daten, stärkere Vereinheitlichung des Befehlssatzes: Es bleibt Feintuning. Immerhin machten die GPU-Entwickler hier den Sprung zur Unified-Shader-Technik, so dass die Rechenwerke gleichmäßiger ausgelastet werden können.

DX8 bot einen Sprung, weniger in den Fähigkeiten, dafür in der Standardisierung. DX9 SM2 litt noch unter der Beschränkung dass man nicht beliebig oft zwischen Textur-Sampling und arithmetischen Optionen wechseln kann. SM3 erlaubt endlich relativ freie Shader-Programmierung mit meistens ausreichender Programm-Länge. Seitdem bleiben die großen Fortschritte aus.
Brauchen wir denn noch viel Veränderung?

Mir wäre es lieber wenn der Fokus auf einer massiven Verbilligung der vorhandenen Möglichkeiten und Features liegen würde. Das ist der einzige Weg um die Konsolen obsolet werden zu lassen. Der PC als Spieleplattform muß billiger werden.

[Gast]

Das ist er doch jetzt schon. Einen zu einer PS3 gleichwertigen PC kann man sich für 300,- locker zusammenbauen. Und dann ist teilweise dennoch mehr drin als nur 720p

[LovesuckZ]

Die Konsolen werden subventioniert. Was eine Konsole leistet, wenn man sie nicht subventionieren und trotzdem "billig" anbieten würde, zeigt die Wii.

[aths]

Die Wii ist wahrscheinlich die beste Konsole derzeit, ich möchte hier aber keine Konsolendiskussionen führen.

GT300 hat vor allem noch kompletten Support für Rasterisierung in Hardware, also Rasterizer und ROPs.

Von der programmierbarkeit abgesehen von virtueller Speicherverwaltung sind sie wohl gleich, wobei sich das Modell wie man sie programmieren sollte um maximale Performance zu erzielen doch ein wenig unterscheidet.Insofern könnte eine Larrabee-Architektur (inkl. Rasterizer und ROPs) bei vergleichbarem Transistor-Count durchaus mit einer aktuellen GPU mithalten. Mir gehts aber mehr um die API: Hier ein Pixel-Shader, da ein Vertexshader – ich will einfach nur Shader.

[Coda]

Es gibt "einfach nur Shader" ab D3D11. Nennt sich ComputeShader. Aber solange es Rasterizer in HW gibt braucht man die Pipeline-Stages.

Die Wii ist wahrscheinlich die beste Konsole derzeit, ich möchte hier aber keine Konsolendiskussionen führen.
Hardwaretechnisch ist sie trotzdem lachhaft veraltet.

[Demirug]

Insofern könnte eine Larrabee-Architektur (inkl. Rasterizer und ROPs) bei vergleichbarem Transistor-Count durchaus mit einer aktuellen GPU mithalten.

Larrabee ist vom Grunddesign her ein Multicore CPU. Daher ist jeder Core mehr oder minder eine getrennte Einheit. Beim GT300 haben wir es dagegen mit einer Zentrallen Steuerlogik zu tun welche die Kernels auf die Teileinheiten verteilt. Daraus ergibt sich das man beim Larrabee einen Kontext pro Kern hat dagegen gibt es beim GT300 nur einen Kontext für den ganzen Chip. Auch bei den Kernen selbst gehen klassische GPUs her mehr auf eine große Anzahl von Threads in Flight während Larrabee hier mehr auf ein einfaches Hyperthreading setzt.

Larrabee kann gegen eine klassische GPU gewinnen wenn eine kleine Anzahl von komplexen Instanzen ausgeführt werden muss. Bei einer großen Anzahl von Instanzen mit relativ einfachen Programmen (Pixelshader) kann das Larrabee Design einfach nicht gewinnen.

Mir gehts aber mehr um die API: Hier ein Pixel-Shader, da ein Vertexshader – ich will einfach nur Shader.

Dann schreib mal einen Rasterizershader welcher die vom Vertexshader gelieferten Daten in Pixelshader aufrufe umsetzt. Dabei müssen aber verschiedenen MSAA Modies berücksichtigt werden. Die Reihenfolge der Pixelshader aufrufe sollte natürlich Cachefreundlich sein. Desweiteren brauchen wir natürlich auch noch Culling und Early-Z. Gerade in diesem Punkt kannst du dedizierte Hardware nicht schlagen. Das gleiche gilt für die ROPs. Hier sind die Kompression und das korrekte Timing mit dem Speicher immer noch wesentlich effektiver als Hardware zu realisieren.

[ScottManDeath]

Was spricht gegen einen Compute Shader vor dem Rasterizer, der als Superset von VS,TS,GS den Rasterizer mit Dreiecken fuettert. Dann kommt der FF Rasterizer, und dann kommt ein "PS" Compute Shader, der den ROP fuettert.

[Demirug]

Was spricht gegen einen Compute Shader vor dem Rasterizer, der als Superset von VS,TS,GS den Rasterizer mit Dreiecken fuettert. Dann kommt der FF Rasterizer, und dann kommt ein "PS" Compute Shader, der den ROP fuettert.

Der TS besteht aus einem Hull Shader und einem Domain Shader mit einer weiteren Fixed Funktion Einheit dazwischen. Genau genommen besteht der Hull shader wiederum aus zwei Shadern. Einer der pro Stützpunkt und einer der pro Patch ausgeführt wird.

Die ganzen Shader haben ja primär nur noch feste Namen um zu definieren an welcher Stelle der Pipeline sie sitzen. Vom Funktionsumfang sind sie fast identisch. Manche Funktionen ergeben nach wie vor nur für Pixel Sinn.

Da die Mehrheit der Grafikprogrammierer eigentlich nicht auf die Pipeline verzichten will ist der nächste logische Schritt die Pipeline selbst konfigurierbar zu machen. Wer schon mal DirectShow Konfigurationen gesehen hat weiß was ich meine.

[ScottManDeath]

Sowas in der Art? http://graphics.stanford.edu/papers/gramps-tog/gramps-tog08.pdf

[Demirug]

Ja, das geht durchaus in die Richtung in der ich denke. Im Detail scheint mir aber die Abstraktion der Hardware noch nicht hoch genug. So sollte die Zuordnung der Rechenleistung an die einzelnen Stages durch den Treiber/Hardware erfolgen. Entsprechend sollte es auch nicht nötig sein einzelne Stages mehrfach parallel in den Graph einzubauen.

[Coda]

Was spricht gegen einen Compute Shader vor dem Rasterizer, der als Superset von VS,TS,GS den Rasterizer mit Dreiecken fuettert. Dann kommt der FF Rasterizer, und dann kommt ein "PS" Compute Shader, der den ROP fuettert.
Fermi führt das Tesselationszeug wahrscheinlich tatsächlich so aus.