JLI Spieleprogrammierung

[xardias]

Thread abgespaltet von:
http://www.jliforum.de/board/viewtopic.php?t=5515&postdays=0&postorder=asc&start=0

[RebornX]

Ich fänd ein Buch über DirectX 10 voll cool...
Mit Dx 9 will ich nix mehr zu tun haben ...

Allerdings lohnt es sich glaubich auch nicht mehr ein Dx 10 Buch zu schreiben, da in einem Jahr eh Windows 7 + DirectX 11 rauskommt....

Aba falls doch eins rauskommen würde, dann würde ich es mir holen und wär dann auch wieder in der Spieleprogrammierung aktiv.

Oder wenigstens ein deutschsprachiges Tutorial zu directX 10 ... hmm...
_________________
Besucht meine Seite:
www.cpparchiv.dl.am

[Jones]

Warum willst du mit DirectX 9 nix mehr zu tun haben?
also mal ganz ehrlich dieser ganze DirectX 10 Hype find ich total sinnlos...

[RebornX]

[Dragon]

[RebornX]

[Dr. Best]

Ich habe auch noch nicht mit Direct3D 10 gearbeitet, aber mir doch schon recht genau angeschaut wie die Dinge da laufen. Und auch über die Neuerungen bei Direct3D 11 hab ich mich schon informiert. Insgesamt habe ich den Eindruck gewonnen, dass das alles nicht so innovativ ist wie es auf den ersten Blick scheint. Also um das mal zu konkretisieren ist hier ein grober Vergleich von Direct3D 9 und 10:
1) Begrenzungen bei Shadern (z.B. Behlsanzahl, Zahl der verschiedenen Register, anzahl der Texturen) wurden erhöht oder komplett entfernt.
2) Es wurden Möglichkeiten hinzugefügt um die notwendige Kommunikation zwischen CPU und GPU zu minimieren (z.B. diese Konstantenpakete).
3) Es gibt Geometry-Shader. Mit denen kann man zwar einiges an Berechnungen, die bei D3D9 nur auf dem CPU möglich waren, auf den GPU verschieben, ich habe aber den Eindruck gewonnen, dass die Dinger ziemliche Rechenzeitfresser sind.
4) Der Befehlssatz in Shadern wurde erweitert und man kann Daten aus Texturen auf abstrakterem Niveau behandeln.
5) HLSL wurde erweitert und ASM abgeschafft. Ist eigentlich aber kein wirkliches D3D10 Feature sondern eher ein D3DX Feature.
6) Die Interfaces und die zugrundeliegende Softwarearchitektur wurde/n neu gemacht, was die XP-Inkompatibilität legitimierte. Die Interfaces, die teilweise locker ein Jahrzehnt auf dem Buckel hatten zu erneuern macht sicher sinn, aber die mangelnde Unterstützung auf XP ist meiner Meinung nach das mit Abstand größte Manko von D3D10 und höher. Hinzu kommt dass viele Grafikkarten D3D10 nicht unterstützen.

Die Punkte 1), 2), 4) und 5) sind recht lineare Weiterentwicklungen, da ist nicht viel Innovatives bei. Punkt 3) klingt innovativer als er ist und ist selten wirklich von Nutzen. Mit den Neuerungen bei D3D11 ist es das Gleiche. Sinnvolle Neuerungen, aber keine wirklichen Innovationen. Um eins klarzustellen: Ich finde nicht, dass Direct3D 10 schlechter ist als Direct3D 9, aber um mit Direct3D 9 (und Shader Model 3.0) an Grenzen zu stoßen muss man schon recht weit gehen und Direct3D 10 läuft nunmal auf sehr wenig Systemen (erfordert neue Hardware und Vista). Deswegen sollte man Verwendung von D3D10 (oder 10.1 oder 11) eigentlich in jeder Engine optional machen, d.h. um D3D9 kommt man eh nicht rum. Daher verwende ich momentan ausschließlich D3D9.

Meiner Meinung nach wird es Zeit, dass man Grafikkarten als das verwenden kann was sie inzwischen eigentlich eh schon sind: Multi-Purpose Prozessoren mit stark paralleler Architektur. CUDA und Larrabee sind Entwicklungen, die zeigen, dass es bereits in diese Richtung geht. Wenn das erstmal eingetreten ist dann werden OGL und D3D praktisch sterben. Man wird sie noch verwenden können, aber man wird nicht mehr an sie gebunden sein. Stattdessen schreibt man sich eine Art Softwarerenderer für den GCPU. Damit ist man nicht mehr an Dreiecke und ähnliches gebunden, sondern kann alle möglichen Renderingtechniken verwenden. Dann wird D3D11 ganzschön alt aussehen .

P.S.: Das führt Off-topic is aber eigentlich ganz interessant. Evtl. könnte ein Moderator aus den Posts mal ein neues Topic aufmachen.
_________________

Ich bin da, wer noch?

[Fallen]

Gute Idee der Thread, war kurz davor das selbst zu erledigen

Ich habe beruflich schon mit DX10 zu tun gehabt, kann daher also meine Meinung ebenso gut wieder geben. Dr. Best scheint sich mit dem Thema ja auch schon auseinander gesetzt zu haben.

Verbreitung von DX10
Da gebe ich dir recht, DX10 ist leider nicht so verbreitet wie es sein könnte. Die Entscheidung von MS dies aber nur für Vista und höher anzubieten hat, aber seine Berechtigung welche mMn ganz beim neuen Treibermodell liegt. Dadurch gibt es für den Programmierer sehr schöne Dinge, wie zB das er sich nicht mehr wirklich um den Resourcenpool gedanken machen muss. Dies wird nun alles intern verwaltet.

Geometrieshader
Diese sind wirklich sehr langsam wenn man sich nur die ersten DX10 Kartengeneration ansieht, neuere Karten haben damit weniger Probleme. Das gleiche gilt aber für CUDA, hier variiert die CUDA Version sehr stark je nach Karte, viele Fähigkeiten sind hier in der ersten DX10 Kartengeneration nicht vorhanden welche CUDA wirklich schnell machen würden, wie zB die ganzen atomic Funktionen.

Softwarerenderer
Das Rad neu erfinden und so Aber den kann man sich auch heute schon selbst schreiben genauso wie früher, ob es Sinn macht naja, aus Lernzwecken evtl aber so..

Die bekannten Rendertechniken werden noch eine lange Zeit weiter so existieren, hybride Entwicklungen werden aber noch stark mitmischen. Wieso auch nicht, aktuelle technologien sind nunmal sehr stark darauf ausgelegt. Dies alles auf die "neueren" (neu für den Realtime Bereich) auszuweiten kann daher wieder sehr lange dauern.

DX11

Bietet für mich sehr viele interessante Änderungen, für die DX9 Freunde wird wohl noch interessant sein das hier ein DX9 Fallback geplant sein soll wo die CPU einen teil der Arbeiten übernehmen kann, inwiefern das nun wirklich funktioniert und ob es schnell ist oder mit XP zusammenarbeitet.. darüber habe ich mich bisher noch nicht informiert. Der Schritt wurde aber als Keyfeature angekündigt und hat mit WARP nichts zu tun, von daher..

So neue DX11 Features, da wäre erstmal die Entsorgung der UberShader welche nun dank stark erweiterten OOP für HLSL überflüssig werden dürften (Ich persönlich zähle HLSL und das FX Framework mal zu DX dazu es wird sicher nicht umsonst als Kernpart gehandelt seit DX10 ).

Also Klassen, Methoden, etc, hurra \o/

Dann kommen noch ein par weitere API Zweige hinzu DirectWrite zum anständigen Rendern von Fonts (was wenn man es korrekt ausführen möchte schonmal ein Megaprojekt für sich darstellt). Direct2D welches wie der Name schon sagt unseren 2D Freunden zugute kommt.

---

Mich persönlich hat DX10 umgarnt allein das Devicerecovery ein Traum. Aber auch hier ist bei weitem nicht alles Perfekt:

Auch wenn man per se nichts von einem Devicerecovery mitbekommt, es gibt negative Effekte. zB muss man viele States erneut setzen, etwas was zB ein Statemanager erledigen sollte, nur bekommt man nicht mit was denn nun gesetzt werden muss oder wann ein Recover statt fand (wenns doch geht sagts mir ).

Resourceviews erfordern eine andere herangehensweise an Resourcen, machen aber durchaus Sinn (Resourceviews sind unterschiedliche Repräsentationformen von ein und der selben Resource.).

Meshbuffer brauchen für jeden Shaderpass eine seperate Darstellungsform (wenn die Pässe denn unterschiedliche VS Signaturen haben). Sollte die Form falsch sein (weil man zb immer die selbe Form verwenden möchte) gibt es Fehler.

Auch so was die Fehlerverarbeitung von DX10 angeht würde ich da eher einen Rückschritt sehen, da vieles nun nicht mehr wie in DX9 als Warnung durchgeht sondern sofort als Fehler gebrandmarkt wird, welche man leider nicht mehr so gut im Callstack backtracen kann, da der Breakpoint zumindest bei mir oft in einem anderen Thread kam. Tja Fehler finden leicht gemacht.

[Dr. Best]

Jo, wie gesagt, ich habe noch nicht mit D3D10 gearbeitet, nur immer wieder mal einige Artikel und Example angeschaut. Du bist da sicherlich deutlich besser informiert. Was ich mit Softwarerenderern meinte ist, dass ich es einfach ärgerlich finde immernoch durch D3D und OGL an Rasterizing mit Dreiecken gebunden zu sein. Ursprünglich sind Grafikkarten und damit auch OGL und D3D eingeführt wurden, weil für 3D Grafik sehr oft die immer wieder gleichen Rechenoperationen durchgeführt werden mussten. Aber inzwischen können Grafikkarten eigentlich jede Berechnung durchführen, die CPUs durchführen können und sie sind ähnlich flexibel. Auch was die Parallelität der Berechnung angeht gehen Multi-Core Prozessoren in Richtung der Grafikkarten. Wie CPU und GPU sich aufeinander zu entwickeln kommt ganz gut in dieser Grafik zu Larrabee aus der Wikipedia raus.

Wegen dieser Vielseitigkeit moderner Grafikkarten finde ich es unsinnvoll, dass sie immernoch so stark auf Rasterizing mit Dreiecken ausgelegt sind. Wenn man irgendeine andere Technik unter Verwendung der Grafikkarte nutzen will, dann muss man die Implementierung immer irgendwie auf Vertex, evtl. Geometrie und Pixel Shader runterbrechen. Das ist meistens durchaus machbar, aber ich finde es ärgerlich, dass es notwendig ist. Vieles ließe sich deutlich besser, realistischer und effektiver darstellen, wenn man direkt andere Techniken verwenden könnte. Zum Rendern volumetrischer Wolken in Flugsimulationen dürften z.B. bestimmte Ray-Tracing Techniken gut geeignet sein. Für Terrains sind Voxel eine bewährte Technik. Rasterizing finde ich grundsätzlich schon gut, aber ich möchte nicht darauf beschränkt sein. Es ist ja nicht so, dass man nicht mehrere Techniken in der gleichen Szene vereinen könnte.

Was das Thema "Rad neu erfinden" angeht: Ohne D3D und OGL wäre der Entwicklungsaufwand natürlich höher, aber im Prinzip erfindet man auch jetzt schon große Teile des Rads immer wieder neu. Wenn man mit Shadern arbeitet übernimmt die Pipeline ja schließlich garnichtmal mehr so viele Berechnungsschritte. Die Vertices werden vom Projection Space in Bildschirmkoordinaten übersetzt, die Dreiecke werden gerastert, Z-Buffer, Stencil-Buffer und Clipping planes werden angewendet, die Inputwerte für den Pixel Shader werden interpoliert und hinterher kommt dann noch das Blending (ist natürlich etwas vereinfacht, aber grob trifft es das schon). Dazu kommt dann natürlich noch massig Verwaltung der Daten und der Rechenkapazitäten aber mit einer guten Softwaregrundlage zur Kommunikation mit der Grafikkarte wäre der Aufwand um das in einem Softwarerenderer ans laufen zu kriegen sicherlich vertretbar.

Ich habe mir schon bevor ich von CUDA und Larrabee gehört habe gedacht, dass GPU und CPU wieder zu einer Recheneinheit verschmelzen werden. In Anbetracht von Larrabee sieht es eher so aus als würden sie für's Erste noch getrennt bleiben, aber zunehmend ähnlicher werden. Auf längere Sicht (so 5-10 Jahre) denke ich aber auf jeden Fall, dass Grafikkarten wie wir sie kennen und die zugehörigen APIs wieder verschwinden werden. Das gute daran ist, dass dann viele schlaue Köpfe gebraucht werden um die neuen hochflexiblen und stark parallelen Rechenmonster zu meistern und mit ihnen "lange vergessene" Renderingtechniken zu implementieren .

Falls es dich interessiert solltest du mal dieses Interview mit Tim Sweeney lesen.
_________________

Ich bin da, wer noch?