interessante "Direct3D Next" Details von der WinHEC 2004 [Archiv]

2004-05-18, 22:55:06

Windows Graphics Foundation (http://download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893d-a6f2295b40c8/TW04079_WINHEC2004.ppt)

Windows Longhorn Display Driver Model - Details and Requirements (http://download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893d-a6f2295b40c8/DW04018_WINHEC2004.ppt)

Hier gibs mehr
WinHEC 2004 (http://www.microsoft.com/whdc/winhec/pres04-drv.mspx)

Vorschau:
http://www.tommti-systems.de/main-Dateien/MISC/l/image8.gif
http://www.tommti-systems.de/main-Dateien/MISC/l/image9.gif
http://www.tommti-systems.de/main-Dateien/MISC/l/image10.gif
http://www.tommti-systems.de/main-Dateien/MISC/l/image11.gif
http://www.tommti-systems.de/main-Dateien/MISC/l/image12.gif
http://www.tommti-systems.de/main-Dateien/MISC/l/image13.gif
http://www.tommti-systems.de/main-Dateien/MISC/l/image14.gif

Thomas

Corrail

2004-05-18, 23:40:53

*JUHU*
OpenGL ist fix dabei! ;D

Aber...
omg... Die programmieren ein KOMPLETT neues Betriebssystem und dann geben die nur GL1.2 rein? *grml* Typisch M$!

Sind aber interessante Folien! Vorallem der Geometry Shader. Bin gespannt, wie der genau ausschauen wird!

2004-05-18, 23:44:16

Das standard OGL 1.2 wird von nem OGL->D3D Wrapper übernommen. Alles was darüber hinaus geht, müssen die IHV per OpenGL ICD bereitstellen. Damit kann ich durchaus leben...

Thomas

Corrail

2004-05-18, 23:46:47

Original geschrieben von tb
Das standard OGL 1.2 wird von nem OGL->D3D Wrapper übernommen. Alles was darüber hinaus geht, müssen die IHV per OpenGL ICD bereitstellen. Damit kann ich durchaus leben...

Thomas

Es ist ja jetzt auch nicht anders. Nur derzeit wird in Windows nur OpenGL 1.1 unterstützt. Ich finds nur komisch warum M$ nicht gleich GL 1.5 reingegeben hat.

2004-05-18, 23:56:55

Denk mal im aktuellen Workstationbereich(worum es Microsoft wohl geht) ist 1.2 noch sehr weit verbreitet. Alles was mehr Features/Leistung braucht ist dann wohl IHV Sache, oder die steigen auf DirectX um, was durchaus auch ein Grund sein könnte....

Thomas

Corrail

2004-05-19, 00:03:50

Ja, ich weiß schon, dass mit GL1.2 viel abgedeckt ist. Ich finde es aber trotzdem lächerlich warum M$ nicht gleich GL1.5 integriert, aber das sind wohl eher Kleinigkeiten. Und das GL1.5 ohne Hardwareunterstütztung wenig hergibt, ist glaub ich auch klar :D

Gil-galad

2004-05-19, 00:21:47

"Normal Map Compression"

Ist das sowas wie ATis 3Dc?

2004-05-19, 00:28:43

Original geschrieben von AiS|Gil-galad
"Normal Map Compression"

Ist das sowas wie ATis 3Dc?

Jap.

Gil-galad

2004-05-19, 00:50:57

Original geschrieben von tb
Jap.

Cool. Dann hat ATi ja wieder mal richtig gelegen, mit 3Dc.

Gast

2004-05-19, 09:04:14

Original geschrieben von AiS|Gil-galad
Cool. Dann hat ATi ja wieder mal richtig gelegen, mit 3Dc.

Ich sehe es eher anders rum ;D

aths

2004-05-19, 09:12:54

Original geschrieben von AiS|Gil-galad
Cool. Dann hat ATi ja wieder mal richtig gelegen, mit 3Dc. D3D richtet sich (auch) nach dem, was die Hersteller machen.

Xmas

2004-05-19, 16:42:46

Großartige Aussichten für DX. Mal sehen ob es auch in eine saubere Spec umgesetzt wird...

MegaManX4

2004-05-20, 11:41:48

Ist mit "GPU Sharing" vielleicht eine Art Dual-Graka Unterstützung gemeint (2 eigene Karten) oder soll hiermit die Unterstützung von DualChip Grafikkarten erleichtert werden?

Corrail

2004-05-20, 11:46:12

Ich glaube das hier mehrere Grafikkarten voll angesteuert werden können.

Demirug

2004-05-20, 11:51:24

Original geschrieben von MegaManX4
Ist mit "GPU Sharing" vielleicht eine Art Dual-Graka Unterstützung gemeint (2 eigene Karten) oder soll hiermit die Unterstützung von DualChip Grafikkarten erleichtert werden?

GPU-Sharing ist wenn sich mehrere Anwendungen (oder auch Threads) die GPU Teilen. Es geht dabei zum Beispiel darum irgendwelche Bildfilter in der Grafikkarte zu rechnen lassen während ein anderes Programm vielleicht irgendwelche Physiksimulationen durchrechnet und zu guter letzt ist ja der neue Desktop von Longhorn auch eine DX-Anwendung.

Die gleichzeitige Verwendung von mehr als einer Grafikkarte wird von DirectX schon lange unterstützt. Bei Multichip karten bringt das aber nichts weil diese ja aufgrund des Treibers nur ale eine einzige Karte zu sehen sind.

MegaManX4

2004-05-20, 11:53:25

Original geschrieben von Demirug
GPU-Sharing ist wenn sich mehrere Anwendungen (oder auch Threads) die GPU Teilen. Es geht dabei zum Beispiel darum irgendwelche Bildfilter in der Grafikkarte zu rechnen lassen während ein anderes Programm vielleicht irgendwelche Physiksimulationen durchrechnet und zu guter letzt ist ja der neue Desktop von Longhorn auch eine DX-Anwendung.

Die gleichzeitige Verwendung von mehr als einer Grafikkarte wird von DirectX schon lange unterstützt. Bei Multichip karten bringt das aber nichts weil diese ja aufgrund des Treibers nur ale eine einzige Karte zu sehen sind.

Guck an, so kann man sich irren.

Pitchfork

2004-05-20, 13:00:52

Was ich allerdings aus diesen Folien rausgelesen habe, und was mir eigentlich nicht wirklich gefällt:

alle coolen neuen Hardware und API features werden NICHT mehr Bestandteil von Direct3D, sondern von einem völlig neuem API (Windows Graphics Foundation), das allerdings auch völlig neue Hardware voraussetzt.

Ich bin mir ja über die Zeitpläne nicht so ganz im klaren, aber Longhorn kommt wohl 06/07. Wenn also gleichzeitig die neue Hardwaregeneration kommt (wir reden ja wohl anscheinend eher über die übernächste Generation bei dem Featureset), dann hätten nur Longhorn Kunden was davon. Und der Entwickler müßte zwei Versionen seiner Engine pflegen (D3D und WGF). Ups.

2004-05-20, 14:48:06

Sieht wohl so aus, für andere Betriebssysteme bleibt dann nur OpenGL oder DirectX 9.0...

P.S. Eigentlich alles kein Problem, solange Longhorn relativ preiswert ist...

Thomas

Pitchfork

2004-05-21, 14:28:55

Der Übergang von DX9 zu WGF wird viel heftiger werden als der Übergang von DX8 zu DX9:

- Die Kunden brauchen WGF Hardware
- Die Kunden brauchen WGF Betriebssystem (Longhorn)
- Spiele müssen in der Übergangsphase zwei Ausprägungen ihrer Engine unterstützen (DX9+WGF)

Falls meine Annahmen stimmen, wird der Übergang 2 lustige Jahre lang dauern vom Erscheinen der Soft+Hardware bis zur breiten Nutzung. Beschleunigt könnte es werden, wenn Xbox2 WGF als API und Hardware Platform hat, was ich irgendwie nicht glauben kann.

Demirug

2004-05-21, 14:54:45

Das muss durchaus alles nicht so schlimm werden wie es sich jetzt anhört. Microsoft hat ja bei Longhorn schon die Tendenz gezeigt das man viele kleinere APIs unter einen neuen Begriff zusammenfast.

DX7 Hardware dürfte hinten runterfallen aber ab DX8 Hardware aufwärts sollte es eigentlich möglich sein. Alles andere würde IMHO zuviele Entwickler verägern.

Wenn ich mir dann noch anschaue wie das Treiberinterface von Longhorn aufgebaut ist macht es IMHO noch weniger Sinn das man die neue API nur noch mit neuer Hardware nutzen kann.

marco42

2004-05-21, 15:32:00

Sehe ich das eigentlich richtig und der OpenGL ICD greift nicht mehr direkt auf die Hardware zu sondern geht ueber einen extra layer, den auch D3D benutzt?

Corrail

2004-05-21, 15:51:56

Das ist mir auch schon aufgefallen, aber geht das überhaupt? Wie soll das dann mit den Extensions funktionieren?

Außerdem hab ich das Gefühl, dass sich da folgende 2 Folien ein wenig widersprechen:

"Longhorn" Display Drivers
Basic Model "Longhorn" display model
Seite 8, DW04018_WINHEC2004.ppt

Block Diagram Of Windows Longhorn Graphics
Seite 3, DW04079_WINHEC2004.ppt

Oder durchblick ich die einfach nicht? ?(

Demirug

2004-05-21, 16:20:11

Ja der OpenGL ICD hat jetzt auch über den DXGkrnl zu gehen. Extension sind da ber kein Problem weil der DXGkrnl nur ein Packetmanager ist. Er schiebt also jedes Packt das vom ICD oder von der D3D-Runtime kommt weiter. Diese Packte enthalten bereits Hardware spezifische Daten in einem vom IHV bestimmten Format.

Microsoft hat im Prinzip das ganze Grafiktreiber system umgestellt. IMHO zum besseren.

Corrail

2004-05-21, 16:35:45

Was macht dieser DXGkrnl genau? Muss D3D bzw. WGF auch drüber gehen?
Meine Befürchtung dabei ist, dass es OpenGL daruch langsamer wird. Ist die Befürchtung berechtigt?

2004-05-21, 16:44:54

-One IHV-provided kernel mode driver in global kernel space
-One IHV-provided user mode driver loaded per process
-Kernel mode driver performs systems-level work, UMD performs graphics-level work
-DXG becomes DXGkrnl, Videoport becomes DispLdr
-W32k.sys is abstracted away, DXGkrnl and Displdr call KMD
-Many elements simplified
--Mode switches
--Session switches
--No more DP2 parsing
--Drivers only support one DX interface

Am DXGkrnl kommt keiner vorbei, weder DX9, OpenGL noch WGF...
Somit dürfte DXGkrnl einfach nur ein einheitliches Interface sein, anstatt wie heute (bei OGL) über die W32k.sys zu gehen und bei DX über DXG. Die GPU muss ja bei Longhorn für mehrere Anwendungen zur Verfügung stehen, somit sind sog. "Context Switches" sicher irgendwie mit dem DXGkrnl verbunden...

Thomas

Corrail

2004-05-21, 18:43:33

Ok, danke.
Also wenns es "weiter nichts ist", bin ich beruhigt.

Bin aber wirklich schon gespannt, wie M$ die WGF Schnittstelle realisiert und inwiefern sie sich von DX unterscheidet.

BTW, gibt es schon irgend genaueres zum Geometry Shader?

Pitchfork

2004-05-21, 18:47:50

Original geschrieben von Demirug
Das muss durchaus alles nicht so schlimm werden wie es sich jetzt anhört. Microsoft hat ja bei Longhorn schon die Tendenz gezeigt das man viele kleinere APIs unter einen neuen Begriff zusammenfast.

DX7 Hardware dürfte hinten runterfallen aber ab DX8 Hardware aufwärts sollte es eigentlich möglich sein. Alles andere würde IMHO zuviele Entwickler verägern.

Wenn ich mir dann noch anschaue wie das Treiberinterface von Longhorn aufgebaut ist macht es IMHO noch weniger Sinn das man die neue API nur noch mit neuer Hardware nutzen kann.

Microsoft Folie
Windows Graphics Foundation
* Will ship exclusively on Longhorn
* Will only target hardware that has been designed for it

Hmmm, eine einheitliche Treiberschicht, aber neue Hardware geht nur über neues API, das nur unter Longhorn läuft. WinXP bekommt kein API Update jenseits von D3D9.

Wahrscheinlich ist WGF sehr ähnlich zu D3D9, aber der Wechsel ist trotzdem heftiger als der von D3D8 zu D3D9, da ein Spiel, das WGF unterstützen will, auch D3D9 unterstützen muß. Das ist ein Novum in DirectX.

Aus den paar Folien kann das natürlich auch alles falsch verstanden werden, aber das lese ich mal da raus....

Pitchfork

Demirug

2004-05-21, 19:06:17

Komplizierter als von DX8 zu DX9 wird es bestimmt. Das geht wohl eher in die Richtung DX7 zu DX8.

Die Frage ist eben in wie weit DX9 und WGF noch irgendwie zusammen gehören oder zwei völlig unterschiedliche Sachen sind.

Wenn es zwei komplett getrennte Dinge sind stimme ich dir zu.

Unter Umständen gibt es ja vielleicht auch noch einen Framework der beides vereinnt.

marco42

2004-05-21, 22:26:48

Original geschrieben von Demirug
Komplizierter als von DX8 zu DX9 wird es bestimmt. Das geht wohl eher in die Richtung DX7 zu DX8.

Die Frage ist eben in wie weit DX9 und WGF noch irgendwie zusammen gehören oder zwei völlig unterschiedliche Sachen sind.

Wenn es zwei komplett getrennte Dinge sind stimme ich dir zu.

Unter Umständen gibt es ja vielleicht auch noch einen Framework der beides vereinnt.

Aber wird es dann fuer die Anwendungsportierung nicht wieder einen riesigen Aufwand geben? Ich meine jetzt nicht Spiele.

2004-05-21, 22:33:10

Original geschrieben von marco42
Aber wird es dann fuer die Anwendungsportierung nicht wieder einen riesigen Aufwand geben? Ich meine jetzt nicht Spiele.

Maximal muss ein neuer Treiber für die 3D-Engine her, wie z.B. bei FarCry oder 3D-Studio MAX.

Thomas

marco42

2004-05-22, 04:28:50

Original geschrieben von tb
Maximal muss ein neuer Treiber für die 3D-Engine her, wie z.B. bei FarCry oder 3D-Studio MAX.

Aha, und wenn es keinen solchen Abstraktionslayer gibt, unter OpenGL habe ich das oft genug gesehen.

2004-05-22, 19:14:37

Original geschrieben von marco42
Aha, und wenn es keinen solchen Abstraktionslayer gibt, unter OpenGL habe ich das oft genug gesehen.

Dann ist dies der Faulheit der Entwickler zuzuschreiben. Die grossen DirectX Game-Engines(Lithtech, FarCry Enngine, Doom 3 Engine, Unreal Engine, Source Engine) haben alle solch einen Abstraktionslayer.
Wer nur auf OpenGL setzt, der muss unter Longhorn wohl auch nix umschreiben, deshalb kann dies z.B. der Doom 3 Engine egal sein. Prof. 3D-Anwendungen basieren entweder auf OpenGL und/oder haben verschiedene Renderer(Software/Hardware), wie z.B. 3DSMAX....

Thomas

marco42

2004-05-23, 17:38:53

Original geschrieben von tb
Dann ist dies der Faulheit der Entwickler zuzuschreiben. Die grossen DirectX Game-Engines(Lithtech, FarCry Enngine, Doom 3 Engine, Unreal Engine, Source Engine) haben alle solch einen Abstraktionslayer.

Doom 3 hat einen? Wo steht das? Das hat uebrigens nichts mit Faulheit zu tun, sondern mit Wartbarkeit, um so mehr Code du hast, um so mehr musst du warten, um so mehr Fehler koennen auftreten und um o komplexer ist der Code. Scene Graphen fuer anderes als Spiele haben meistens keinen Layer, um die 3D Schnittstelle zu abstrahieren, zB Inventor, Performer etc..

2004-05-23, 19:07:37

Ups, Doom 3 sollte da nicht mit rein, steht ja auch DirectX Engines davor. Jedoch verwendet Doom 3 verschiedene Backends, was auch schon einer Abstrahierung zum puren OpenGL entspricht. Inventor und Performer nutzen OpenGL, wer nur auf OpenGL setzt, dem kann Longhorn egal sein.

um so mehr Code du hast, um so mehr musst du warten

Eigentlich nicht. Ein Sinn von Abstrahierung soll es ja sein, ein Programm wartbarer zu machen. So braucht man dann z.B. nur den Renderer auszutauschen und nicht in der gesamten Grafikpipeline bzw. dem gesamten Source Code rumzufurwerken, weil man eben klare Trennungen hat. Dies vermeidet Fehler und ist wesentlich effizienter, aber man muss halt mehr Zeit in die Designphase investieren.

Thomas

marco42

2004-05-23, 19:31:05

Original geschrieben von tb
Eigentlich nicht. Ein Sinn von Abstrahierung soll es ja sein, ein Programm wartbarer zu machen. So braucht man dann z.B. nur den Renderer auszutauschen und nicht in der gesamten Grafikpipeline bzw. dem gesamten Source Code rumzufurwerken, weil man eben klare Trennungen hat. Dies vermeidet Fehler und ist wesentlich effizienter, aber man muss halt mehr Zeit in die Designphase investieren.

Schnittstellen sind was gutes, aber die ergeben sich oft erst waehrend der Entwicklung, sowas nutzen ja auch agile Entwicklungsprozesse. Ich glaube du verwechselst hier Flexibilitaet mit Wahrtbarkeit. Du musst auf jeden Fall dass Backend umschreiben und das wird nicht viel weniger Aufwand sein, kommt darauf an. Wenn du mehrere Renderer unterstuetyen willst erhoeht das auf jeden Fall die Komplexitaet. Es gibt da einfach keinen Konigsweg, deshalb setzen viele Applicationen, von denen es nicht nur Prototypen gibt, meist auf eine Schnittstelle.

marco42

2004-05-23, 19:31:05

Ailuros

2004-06-01, 05:29:55

Fragen:

hat sich was am I/O Model, das in den DX-Next Previews erwaehnt wurde, geaendert?

ich bin sehr froh ueber den Geometry Shader ("pflicht-feature"); warum ist die Tesselations-Einheit dann "optional"?

Demirug

2004-06-01, 07:09:17

Original geschrieben von Ailuros
Fragen:

hat sich was am I/O Model, das in den DX-Next Previews erwaehnt wurde, geaendert?

ich bin sehr froh ueber den Geometry Shader ("pflicht-feature"); warum ist die Tesselations-Einheit dann "optional"?

Das I/O Model scheint immer noch dem zu entsprechen was in den alten DX-Next Folien beschrieben wurde.

Tesselation ist aus dem gleichen Grund optional aus dem all die anderen Sachen in DX auch schon optional waren. Irgend ein IHV will oder kann das nicht einbauen.

Ailuros

2004-06-02, 01:10:05

Enstpricht dann der Geometry Shader tatsaechlich einem PPP? Ich hatte den Eindruck dass mit dem letzteren Topology und Tesselation behandelt werden koennte.

Demirug

2004-06-02, 10:32:31

Original geschrieben von Ailuros
Enstpricht dann der Geometry Shader tatsaechlich einem PPP? Ich hatte den Eindruck dass mit dem letzteren Topology und Tesselation behandelt werden koennte.

Laut Beschreibung kann der Geometry Shader geometry erzeugen was einem PPP entspricht.