DirectX 9 Specs

[Fragman]

gibts irgendwo schon ein white paper zu dx9, wo man die specs ablesen
kann ? daraus kann man ja schon ablesen, was die neuen graphikchips
koennen muessen. mich interessiert vor allem, wie nah dx9 an der geforderten low level shading language dran ist, oder ob alles wieder so zusammengestutzt ist wie in dx8, ob der pixel shader in dx9 flexibler ist, oder wieder so starr.

gruss, fragman

[nggalai]

Hi fragman,

ein öffentliches white paper zu DX9 ist meines Wissens nach noch nicht draussen--es sind allerdings einige RFC-Dokumente bei Entwicklern im Umlauf (und stehen daher unter einem NDA), also kann's nicht mehr lange dauern, bis was "offizielles" veröffentlicht wird.

Bisher gibt es eine öffentlich-zugängliche PP-Präsentation von der Meltdown 2001, in welcher u.a. ausgiebig PS V2.0 präsentiert werden: http://www.microsoft.com/mscorp/corpevents/meltdown2001/ppt/DXG9.ppt

PS V2.0 werden einiges mächtiger als noch V1.4 sein, sind aber noch immer nicht im Bereich einer "höheren" Shader Sprache angesiedelt.

Hope this helps,

ta,
.rb

[Fragman]

danke, bin jetzt 'n bisserl schlauer, obwohl wieder die frage bleibt, warum man sich mit dx9 soviel muehe gibt anstatt gleich zu dx10 ueber zu gehen. die erweiterungen klingen teilweise nicht schlecht, werden aber wohl nicht mit dx9 genutzt werden. allein schon displacement mapping wird man wohl so schnell nicht sehen, genauso wie catmull clark subdivision surfaces, da muessten die beschleuniger doch enorm an leistung zulegen. also doch auf opengl 2.0 setzen, was sicher bzw hoffentlich von den beschleunigern unterstuetzt wird (dort wird dann wohl low level shading angeboten werden).

gruss, fragman

[aths]

Ich halte DX8 für einen eher zaghaften Versucht, was die Programmierbarkeit von Pipelines angeht. DX9 sollte, als "richtiger" Anlauf, brauchbarere Ergebnisse liefern.

Empfiehlt DX8 nicht schon 48 Bit Rechengenauigkeit? Insofern gibts noch nicht mal "echte" DX8 Hardware.

[HiddenGhost]

Originally posted by aths
Ich halte DX8 für einen eher zaghaften Versucht, was die Programmierbarkeit von Pipelines angeht. DX9 sollte, als "richtiger" Anlauf, brauchbarere Ergebnisse liefern.

Empfiehlt DX8 nicht schon 48 Bit Rechengenauigkeit? Insofern gibts noch nicht mal "echte" DX8 Hardware.

Id@Carmack haben doch 64bit (Flotingpoint) Rendering gefordert. Warscheinlich werden DX9 Karten zwingend diese Features haben müssen um DX9 Compliend sein zu können.
Anbei: Irgendwie erinnert mich "Clark Catmulls Oberflaechen Unterteilungs"-Methode (http://symbolcraft.com/pjl/graphics/subdivision/subdivision_german.html) stark an das was Truform abliefert. Arbeiten die wirklich nach ähnlichen Prinzipen zu arbeiten, zumal die Endergebnisw wohl einer sehr hohen Truformrender-Konfig nahe kommen.

MfG PCg

[ow]

Originally posted by PCgenius


Id@Carmack haben doch 64bit (Flotingpoint) Rendering gefordert. Warscheinlich werden DX9 Karten zwingend diese Features haben müssen um DX9 Compliend sein zu können.

MfG PCg


Schwer zu sagen (ob´s für DX9 Pflicht wird), aber auf jeden Fall hat Carmack mit DX0..100 :) absolut nichts am Hut. Den interessiert nur OGL (und das ist auch gut so;)).

[Legolas]

Originally posted by ow



Schwer zu sagen (ob´s für DX9 Pflicht wird), aber auf jeden Fall hat Carmack mit DX0..100 :) absolut nichts am Hut. Den interessiert nur OGL (und das ist auch gut so;)).

Wobei er mal zum Ausdruck gebracht hat, daß ihm die jüngste Entwicklung bei DX ziemlich gut gefällt...

[HiddenGhost]

Originally posted by Legolas


Wobei er mal zum Ausdruck gebracht hat, daß ihm die jüngste Entwicklung bei DX ziemlich gut gefällt...

Warum sollten ihm die Features auch nicht gefallen. DirectX setzt nun mal die Standarts ,für die die Grakas spezifiziert werden,welche Features er in Zukunft benutzen wird usw.
Mir kommt es in erster Linie nicht auf die Schnittstelle an ,sondern DX als Industriestandart,wenn man das überhaupt so nennen kann.

MfG PCg

[Legolas]

Also John Carmack hat gemeint, daß ihm die Art wie man DX 8 programmiert ziemlich gut gefällt.

Features werden nicht allein von DX8 vorgegeben, auch OGL unterstützt dank Extensions alle neuen Features, oft sogar noch mehr wie DX wegen der herstellerspezifischen Extensions

[Xmas]

Originally posted by PCgenius
Anbei: Irgendwie erinnert mich "Clark Catmulls Oberflaechen Unterteilungs"-Methode (http://symbolcraft.com/pjl/graphics/subdivision/subdivision_german.html) stark an das was Truform abliefert. Arbeiten die wirklich nach ähnlichen Prinzipen zu arbeiten, zumal die Endergebnisw wohl einer sehr hohen Truformrender-Konfig nahe kommen.
"Ähnlliche Prinzipien" liegen dem in gewissem Maße schon zugrunde, aber es gibt auch deutliche Unterschiede. Beides ist natürlich dazu da, Gegenstände runder erscheinen zu lassen.
Aber Truform ist z.B. interpolierend (die Eckpunkte bleiben erhalten), Catmull-Clark Subdivision Surfaces nicht. CCSS bezieht sich auf ein "Objekt", während TruForm für jedes Dreieck einzeln funktioniert. Catmull-Clark sind B-Splines, Bei TruForm kommen "normale" kubische Kurven zum Einsatz.

[Fragman]

carmack wartet auf dx10, weils wohl ne low level shading language bietet soll, das heisst, es gibt in der programmierung keine grenzen mehr, nur die limitierung der hardwareleistung spielt noch eine rolle. dann gibts auch kein ".. meine nv graka kann das und deine ati karte kann das nicht..." usw; er findet den ansatz von dx8 nicht schlecht, besonders die struktur soll ja besser sein, aber die limitierungen innerhalb der pipeline ist ihm immer noch zu stark, besonders die des pixel shaders. doom3 wird deshalb das beste aus dx und opengl rausnehmen und direkt auf die jeweiligen graphikchips programmiert werden (auf die wichtigen, die mit der doom3 engine einigermassen klar kommen, also kein ati rage oder sowas).

gruss, fragman

[nggalai]

Fragman,

ich habe eine Frage zum "low level", welches Du auch schon weiter vorn im Thread verwendest.

Meinst Du nicht "higher level" Programmiersprache, i.e. mit HÖHEREM Abstraktionsgrad? "low level" würde in dem Zusammenhang ja "näher an der Hardware" bedeuten. i.e. das Ziel wäre doch eher eine C-ähnliche Shadersprache als eine Assembler-mässige, nicht?

Wäre um Klärung deiner Nomenklatur froh,

ta,
.rb

[ow]

Originally posted by Fragman
doom3 wird deshalb das beste aus dx und opengl rausnehmen und direkt auf die jeweiligen graphikchips programmiert werden (auf die wichtigen, die mit der doom3 engine einigermassen klar kommen, also kein ati rage oder sowas).

gruss, fragman


???
Könntest ud deine Vorstellung hierzu näher erläutern? Ich versteh nicht ganz was du meinst.

Ich denke Doom3 ist reines OpenGL.
Es sei denn, JC will es auf die XBox portieren.

[Fragman]

@nggalai:
stimmt natuerlich, sorry meine fehler, soll natuerlich high level shading language heissen, auch nachzulesen auf

http://www.3dlabs.com/support/developer/ogl2/index.htm

das ziel ist ja auch renderman shader in echtzeit, die sind ja auch in c. danke fuer die korrektur.

@ow:
wie carmack das genau macht, hat er nicht weiter ausgefuehrt, er meinte nur, das er sich nicht auf eine api festlegt und die besten funktionen aus beiden "rausnimmt" und direkt fuer die jeweilige hardware programmiert, damit man aus dem jeweiligen graphikchip das
beste ergebnis rausholen kann. hat wohl auch damit zu tun, das er sich immer darueber beschwert, das der eine chip das besser kann und der andere das. er fuehrt solche beispiele ja immer detailliert auf, weshalb er sich wohl entschlossen hat, gleich direkt fuer die hardware zu programmieren. ausserdem ist ihm der funktionsumfang in ogl nicht ausreichend, und ogl 2.0 ist ja immer noch nicht fertig. er muesste fuer doom3 ja sowieso die herstellerspezifischen extentions nutzen, also gleich direkt auf hardware programmieren.


gruss, fragman

[Andre]

Originally posted by Legolas
Also John Carmack hat gemeint, daß ihm die Art wie man DX 8 programmiert ziemlich gut gefällt.

Features werden nicht allein von DX8 vorgegeben, auch OGL unterstützt dank Extensions alle neuen Features, oft sogar noch mehr wie DX wegen der herstellerspezifischen Extensions

Legolas,

also wenn ich richtig informiert bin, dann ist OpenGL (zumindest in der Version 1.3) featuremäßig DX 8.1 unterlegen.
Erst mit OpenGL 2.0, dem ein "Pure" OpenGL 2.0 folgen soll, welches nicht abwärtskompatibel zu den jetzigen Versionen ist, kommen neue Features hinzu, wie z.B. ein transparentes Memory Managament, Pixel-Packer/Unpacker und Einbeziehung von zukünftigen Vertex- und Fragment-Prozessoren.
Dennoch fehlen bei auch bei dem Vorschlag zu OpenGL 2.0 von 3DLabs weiterhin kontinuierliches LOD, Subdivision Surfaces, automatisches Front-to-Back-Buffering, etc., welche meinem Kenntnisstand in DX 8.1 resp. DX 9.0 enthalten sind/sein werden.

Korrigiere mich, wenn mein Kenntnisstand nicht mehr aktuell ist.

[Xmas]

Fragman,
John Carmack KANN gar nicht "direkt" für die jeweilige Hardware programmieren. Dazu hat er weder die Zeit noch die nötigen Informationen von den Herstellern noch die technischen Möglichkeiten. Deswegen gibt es ja APIs, um eine einheitliche Schnittstelle zu haben.
JC nutzt für Doom3 OpenGL und herstellerspezifische Extensions.

[Xmas]

Andre,
OpenGL 1.3 ist in seiner Grundfunktionalität DX8.1 unterlegen, aber das wird durch die Extensions (herstellerspezifisch oder auch offen) mehr als ausgeglichen. In OpenGL können die Hersteller die gesamte Hardwarefunktionalität uneingeschränkt zugänglich machen, anders als bei DX. Der Nachteil ist, dass die Entwickler auch für verschiedene Extensions programmieren müssen und damit natürlich der Aufwand ansteigt.

[Legolas]

Originally posted by Xmas
Andre,
OpenGL 1.3 ist in seiner Grundfunktionalität DX8.1 unterlegen, aber das wird durch die Extensions (herstellerspezifisch oder auch offen) mehr als ausgeglichen. In OpenGL können die Hersteller die gesamte Hardwarefunktionalität uneingeschränkt zugänglich machen, anders als bei DX. Der Nachteil ist, dass die Entwickler auch für verschiedene Extensions programmieren müssen und damit natürlich der Aufwand ansteigt.

So in etwa dachte ich das auch..

[Fragman]

@xmas:
jc hat das nach einfuehrung des g3 gesagt, das er direkt fuer die graphikchips programmieren will. das war ungefaehr 2 monate vor einfuehrung des readon 8500, wo er sich schon ueber diesen chip geaeussert hat. er wird das nicht fuer alle chips machen, nur fuer die wichtigen, ab geforce 1 und hoeher, und auch nur da, wo er mittels tricks effekte aehnlich darstellen kann und natuerlich die chips, die die mindestleistung sprich mindestfuellrate bringen.

zum thema er kann es nicht: beim readon2 will er sich mit den treiberprogrammierern kurzschliessen, da er selber mit den treibern rumprogrammiert hat (da er probleme mit ein paar sachen hatte) und bei seinen tests selbst bessere ergebnisse geliefert bekam als es mit den ati treibern moeglich war, soviel dazu er hat fuer sowas keine zeit. es muesste eigentlich bekannt sein, das jc sehr viel zeit mit programmieren verbringt, und das er davon auch sehr viel ahnung hat.
der beruehmte satz: "jc progrmmiert eine engine an einem wochende" kommt ja nicht von ungefaehr.

gruss, fragman

[Xmas]

fragman,
JC programmiert schon für die einzelnen Grafikchips, allerdings via herstellerspezifischer OpenGL-Extension. Was sollte er denn noch mehr machen? Die Extensions sind schon so entworfen, dass sie optimal die Hardwarefunktionalität abbilden.

Ich weiß dass er für 3dfx den ersten MiniGL-Treiber geschrieben hat, und ich bezweifle auch nicht dass er bei der Treiberentwicklung gerne mal gefragt wird. Aber dass er mit den Treibern etwas herumexperimentiert hat, heißt noch lange nicht dass er seine Engine so schreiben kann dass sie im Graka-Treiber herumwerkelt oder gar direkt auf die Hardware zugreifen kann.

[tb]

Originally posted by PCgenius


Id@Carmack haben doch 64bit (Flotingpoint) Rendering gefordert. Warscheinlich werden DX9 Karten zwingend diese Features haben müssen um DX9 Compliend sein zu können.
Anbei: Irgendwie erinnert mich "Clark Catmulls Oberflaechen Unterteilungs"-Methode (http://symbolcraft.com/pjl/graphics/subdivision/subdivision_german.html) stark an das was Truform abliefert. Arbeiten die wirklich nach ähnlichen Prinzipen zu arbeiten, zumal die Endergebnisw wohl einer sehr hohen Truformrender-Konfig nahe kommen.

MfG PCg

DX9 wird das "floating point" Format für den Pixel Shader ermöglichen. Ob dies allerdings schon 64 Bit betragen wird, bezweifle ich. Zur Zeit rchnet er ja mit einem "fixed point" Format, wobei die Nachkommastelle mit 8 Bit Genauigkeit angegeben wird.