Wie ist das eigentlich mit den alten D3D-Interfaces?

[zeckensack]

Da ich da vor kurzem wohl ziemlichen Dünnsinn verzapft habe ... :D

Was läuft auf einer DX9-Runtime (und einem DX9-fähigen Treiber) eigentlich ab, wenn ein DX6/7/8-Spiel läuft?

[mapel110]

afaik enthält dx9 für jeden vorgänger noch die entsprechende runtime.

[zeckensack]

Originally posted by mapel110
afaik enthält dx9 für jeden vorgänger noch die entsprechende runtime.Die DX-Runtime ist ja nur ein Vermittler zwischen Applikation und Treiber.
Schleppt der Graka-Treiber zB jetzt auch komplette DX8/7/6/5-Implementierung mit sich rum? Also NVIDIA 4in1 sozusagen? :D

IMO müssen entweder alle Versionen komplett (ie unabhängig) vorhanden sein, oder an irgendeinem Punkt muß eine Emulation bzw Umsetzung neuer auf alte Kommandos erfolgen.

[Demirug]

DirectX (bzw. D3D um genau zu sein) benutzt ein 3 Schichten Model.

1. Schicht: Der Treiber (vom IHV)
2. Schicht: Treiber Thunk (von MS) (alle DX Versionen teilen sich diese Schicht)
3. Schicht: Die Runtime (Jede DX-Version hat eine eigene)

Die 2. Schicht hat lediglich die Aufgabe die Runtime mit dem Treiber zu verbinden. Technisch ist das ganze aus zwei Gründen notwendig.
a. Der Treiber und die Runtime laufen auf unterschiedlichen Sicherheitsebenen des Prozessors damit denoch eine Kommunikation möglich ist gibt es diese Schicht
b. Sollte der Treiber nicht alle Funktionsaufrufe der installierten DX-Version (DX9 Installiert aber nur einen DX8) kennen werden durch den Thunk entsprechende Dummy Funktionen zur verfügung gestellt welche sich so verhalten das die Runtime denkt sie hätte einen entsprechenden Treiber aber die Hardware beherscht die entsprechenden Dinge eben nicht.

Das Geheimniss der Kompatibilität liegt nun darin wie die Runtime mit dem Treiber kommuniziert. D3D benutzt dazu Anweisungslisten in die Eingetragen wird was die Karte tun soll. Das Format dieser Listen bleibt dabei von DX zu DX Version identisch es kommen lediglich neue Anweisungen hinzu. Für den Treiber ist deshalb nicht direkt ersichtlich von welcher Runtime eine Anweisungsliste kommt.

Ebenfalls immer gleich bleibt das Format einer Anweisung. Schaltet man die Karte mit DX7 in den Wireframemodus so enthält die Liste genau die gleichen daten wie wenn man das ganze mit DX9 getan hätte.

Da DX9 es ja nach wie vor erlaubt auch DX7 Funktionen (HT&L, Pixelprocessing) zu nutzen übergibt die DX9 Runtime die entsprechenden Anweisungen dafür in der exact gleichen Art wie es die DX7 Runtime getan hat. Das ist auch notwendig den ein DX7 Treiber (mit dem DX9 ja auch läuft) würde eine andere Art zur übergabe von DX7 Einstellungen auch gar nicht verstehen.

Aus diesen Gründen ist es für einen IHV auch nicht notwendig einen komplett neuen Treiber zu schreiben wenn es eine neue DX Version gibt. Er nimmt den vorhandenen Treiber und implementiert die neuen Funktionen und Anweisungen die er unterstützt. Als die IHVs also aus ihren DX8 Treibern DX9 Treiber gemacht haben mussten sie die Bereiche die sich um Dinge kümmern die es schon bei den Versionen vor DX9 gab gar nicht anfassen sondern nur die neuen DX9 Features implementieren.

Im Gegenzug funktioniert das ganze natürlich auch. Die DX7 Runtime und der Thunk-Layer kommen auch mit einem DX9-Treiber ohne Probleme zurecht weil sie die zusätzlichen Funktionen und Anweisungen ja gar nicht kennen.

Noch eine kleine Anmerkung zur Historie. Diese Anweisungslisten hat man in der ersten D3D Versionen noch selbst erstellt und übergeben. Das war das von vielen Entwicklern gehasste (weil sie es nicht verstanden haben) Executionbuffer Verfahren. Die neuen DX Runtimes machen im Prinzip nichts anderes als dem Entwickler das ausfüllen dieser Listen abzunehmen.

Ich hoffe es war einigermassen verständlich. Ansonsten bitte rückfragen.

[mapel110]

hm, wo ist demirug ? :D

/edit
wenn man vom teufel spricht ;D

[ow]

Eine Rückfrage::D

Wodurch kommt es, dass ein für eine bestimmte DX-Version geschriebener Treiber nur von den beiden nächst höheren Runtime-Versionen noch als HW-Device erkannt wird?
Ein DX5 Treiber funzt zB. unter DX8 jedenfalls überhaupt nicht.

[Demirug]

Originally posted by ow
Eine Rückfrage::D

Wodurch kommt es, dass ein für eine bestimmte DX-Version geschriebener Treiber nur von den beiden nächst höheren Runtime-Versionen noch als HW-Device erkannt wird?
Ein DX5 Treiber funzt zB. unter DX8 jedenfalls überhaupt nicht.

Im wesentlichen ist das eine Entscheidung von MS. Man macht das aber einfach aus dem Grund weil sonst die Einschränkungen in bestimmten Bereichen einfach zu gross werden.

Gutes Beispiel hierzu ist zum Beispiel die in DX9 eingeführten "vertex stream declarations". Im Prinzip eine reine Treibersache. Da aber DX7 und DX8.x Treiber dafür keine Schnittstellen haben muss die Runtime da ein bischen nachhelfen was aber dazu führt das bestimmte Sachen bezüglich "vertex stream declarations" mit pre DX9 Treibern einfach nicht funktionieren. Und so gibt es immer ein paar Stellen wo es mit alten Treiber nicht möglich ist die Features einer "alter" Hardware zu nutzen. Aus diesem Grund wird dann in der Regel der Support von älteren Treibern irgendwann eingestellt auch um den Testaufwand und mögliche Fehlerquellen auszuschliessen. Denn wenn ein IHV für eine Hardware nicht mehr bereit ist die minimalen Änderungen die notwendig sind am Treiber vorzunehmen kann man auch nicht davon ausgehen das er Fehler welche in Verbindung mit der neuen Runtime auftreten könnten beseitigt.

DX9 braucht wie ich ja schonmal gesagt habe mindestens einen DX7 Treiber. Das ist aber eine einprogrammierte Spere. Die erste Beta funktionierte auch noch mit DX6 Treibern.

[ow]

thx:)

[mapel110]

@z-bag

wenn du opengl proggst, dann müsstest du doch auch dx kenntnisse haben. zb für sound oder direkt input und sowas, oder ?!
ergo müsstest du sowas wie den aufbau von dx im groben kennen. oder machst du was ganz anderes ? :)

[StefanV]

Originally posted by mapel110
@z-bag

wenn du opengl proggst, dann müsstest du doch auch dx kenntnisse haben. zb für sound oder direkt input und sowas, oder ?!
ergo müsstest du sowas wie den aufbau von dx im groben kennen. oder machst du was ganz anderes ? :)

Das braucht man 1. nur wenn man spiele Proggt und 2. muss man das nicht unbedingt nutzen :|

[Demirug]

Originally posted by mapel110
@z-bag

wenn du opengl proggst, dann müsstest du doch auch dx kenntnisse haben. zb für sound oder direkt input und sowas, oder ?!
ergo müsstest du sowas wie den aufbau von dx im groben kennen. oder machst du was ganz anderes ? :)

DirectSound und DirectInput sind etwas anders aufgebaut. Das hängt damit zusammen das sich da nicht ständig was ändert. Bei DX9 wurde in diesen Bereichen im vergleich zu DX8 eigentlich nur an der Performance gearbeitet.

[zeckensack]

Erstmal riesen Thx an Demirug :)

Originally posted by mapel110
@z-bag

wenn du opengl proggst, dann müsstest du doch auch dx kenntnisse haben. zb für sound oder direkt input und sowas, oder ?!
ergo müsstest du sowas wie den aufbau von dx im groben kennen. oder machst du was ganz anderes ? :) DSound/DInput habe ich auch schon benutzt, nur hatte ich in den beiden Bereichen bisher kein Bedürfnis, etwas höheres als die DX5-Interfaces zu benutzen :D

Low-Level rult alles weg :lol: :|

[Demirug]

Originally posted by zeckensack
Erstmal riesen Thx an Demirug :)

DSound/DInput habe ich auch schon benutzt, nur hatte ich in den beiden Bereichen bisher kein Bedürfnis, etwas höheres als die DX5-Interfaces zu benutzen :D

Low-Level rult alles weg :lol: :|

Intern benutzt DirectInput auch immer noch das Treiberinterface von DX5. :D

Wenn du wirklich Lowlevel willst musst du direkt auf den D3D Treiber Thunk Layer programmieren.

[zeckensack]

Originally posted by Demirug
Intern benutzt DirectInput auch immer noch das Treiberinterface von DX5. :DDann habe ich ja die richtige Entscheidung getroffen :D
Wenn du wirklich Lowlevel willst musst du direkt auf den D3D Treiber Thunk Layer programmieren. Braucht man dazu nicht Informationen, die MS nur 'guten Freunden' zuteil werden lässt :|

Oder anders gefragt: wenn man den thunk layer direkt programmieren kann (und 'darf'), wofür gibt's dann das 'normale' DXG (die ganzen Utility-Gschichtn laufen doch unter eigenem Namen, IIRC)?

[Demirug]

Originally posted by zeckensack
Oder anders gefragt: wenn man den thunk layer direkt programmieren kann (und 'darf'), wofür gibt's dann das 'normale' DXG (die ganzen Utility-Gschichtn laufen doch unter eigenem Namen, IIRC)?

ob man es darf weiss ich nicht, aber wirklich verhindern kann es MS nicht.

Das Problem ist das es natürlich offiziel keine Header und auch kein Lib file für den Thunklayer gibt. Da es sich aber um normale C-Funktionen handelt kann man diese alle dynamisch binden.

Kompliziert wird es mit den Headern. Da die Thunk Funktionen aber im Prinzip nur die Funktionen des Treibers in den Usermode spiegelt kann man sich für die meisten Funktionen den Aufbau aus dem DDK besorgen.

Das man das aber nicht wirklich macht hat ein paar einfache Gründe. Die DLL mit dem Thunk darf von Release zu Release und von OS zu OS den Namen wechseln. Der Treiber geht davon aus das DXG nur validierte Daten übergibt wenn man also mist baut killt man ganz schnell den Treiber.

Und was natürlich auch noch dazu kommt ist das heute nur noch ein Wahnsinniger direkt die Anweisungslisten schreiben will. Ich erinnere mich da noch an die erste D3D Version. Wer damals schlau war hat sich einen Framework programmiert mit dem man die Anweisungslisten mit einfachen Funktionsaufrufen füllen konnte.