Warum schreibt MS keine DX Features vor? (Split: Kein Displacement Mapping ....) [Archiv]

AlfredENeumann

2002-11-22, 12:25:15

Das hier ist noch vom Tommti-Systems. So als kleine Anmerkung.

"
DirectX 9 Support der GeForce FX
Ich muss hier mal etwas klarstellen. Die GeForce FX unterstützt DirectX 9. Es gibt von Microsoft nur eine einzige Bedingung (man muss ein DX9 Device erstellen können!), soblad diese erfüllt ist, können Hersteller schreiben/sagen ihre Karte wäre DirectX 9 fähig! Vertex / Pixel Shader Support odere andere Features wie Displacement Mapping sind nur Zugaben! Kein Hersteller dürfte schreiben, "Full DX9 Support" - dann müsste die VPU Pixel und Vertex Shader bis Version 3.0 fähig sein, selbst die GeForce FX bietet nur Support für die Shader der Version "2.0 Extended".
"

Quasar

2002-11-22, 12:35:36

Dann wird's bei allen wieder auf ein "comprehensive" hinauslaufen....

Demirug

2002-11-22, 12:44:51

Das stand doch schon vorher fest, oder?. Auch wenn ATI behauptet: "Complete DirectX® 9.0 support for unprecedented realism and sophisticated visual effects"

Quasar

2002-11-22, 12:52:48

Naja, aber ich finde, ein paar Keyfeatures sollte MS doch schon vorschreiben, um bestimmt Logos oder Bezeichnungen nutzen zu dürfen.

Nur neue Treiber für alte Chips: "supports DX9"
Funktionalität über Treiber abgebildet: "DX9 compatible"
Volle HW-Funktionalität der Keyfeatures: "DX9 compliant"

oder so ähnlich....

Demirug

2002-11-22, 13:15:00

Originally posted by Quasar
Naja, aber ich finde, ein paar Keyfeatures sollte MS doch schon vorschreiben, um bestimmt Logos oder Bezeichnungen nutzen zu dürfen.

Nur neue Treiber für alte Chips: "supports DX9"
Funktionalität über Treiber abgebildet: "DX9 compatible"
Volle HW-Funktionalität der Keyfeatures: "DX9 compliant"

oder so ähnlich....

Die support Schwelle ist genau festgelegt. Bei DX9 wird mindestens ein Treiber mit der DX7-Schnittstelle abgebildet sein. Mit neuen Treiber kann die Karte in der Regel auch nicht mehr. OK bei DX9 gibt es ein paar neue Sachen die möglicherweise auch schon von älteren Karten beherscht werden.

Aber mit dem Vorschreiben von Keyfeatures will sich MS nicht die Finger verbrennen. Da wie ich schon mehrfach gesagt habe DX von der Mitarbeit der Chiphersteller lebt würden die natürlich auch bei den Keyfeatures mitreden wollen. Der einzige für alle annehmbare kompromiss wäre das als Keyfeature nur etwas zugelassen wird was sowieso alle können. Wenn MS einfach so bestimmen würde wäre am schluss wahrscheinlich keine Karte "compliant" weil irgendwas doch immer fehlt. Wir haben jetzt also zwei extreme alle oder keine. Wenn der dritte Fall das es ein Chip doch schafft eintritt wird doch gleich wieder geschriehen: "MS bevorzugt .....".

StefanV

2002-11-22, 13:42:13

Quasar

2002-11-22, 13:47:37

Man könnte das Ganze wie bei einer Ausschreibung handhaben: Die Hersteller geben ihre Wünsche (am besten anonym) in einem versiegelten Umschlag ab, MS entscheidet noch dem GGN-Prinzip, im Zweifel mit der Mehrheit der Wünsche.

Wie dem auch sei: So wie es jetzt läuft, scheint DX ein Wischiwaschi-Standard zu sein, an dessen nomineller Erfüllung (bei neu vorgestellten Chips) man nichts und wieder nichts festmachen kann. Wenn dieser Trend anhält, wird sich DX15 wahrscheinlich auf Point-Sampling in Hardware beschränken und alles andere als optional ausgeben....

Quasar

2002-11-22, 13:49:48

BTW, (sry 4 new Post), aber eine "fully DirectX9-kompatible" Karte á la R9700pro ist auch wieder so eine Sache.

Man könnte gerade diese Formulierung auch so lesen, dass alle Features, die die Karte bzw. der Chip bietet, von DX9 unterstützt werden. :kotz:

edit:
Bevor ich hier wieder zum größten nVidiot aller Zeiten mutiere:
Das war ein BEISPIEL, welches man genauso auf die GF4MX münzen könnte, oder GF4Ti oder Parhelia oder Xabre oder SavageXP oder alle IGPs, oder XP4 oder sonstwas!

Demirug

2002-11-22, 14:02:51

Quasar: Das mit dem Vorschlägen läuft ja im Prinzip jetzt schon so ab. Die Hersteller sagen was sie gerne hätte, dann versucht man die gemeinsamkeiten zu finden und dann eine Schnittstelle zu definieren mit der jeder der das Feature unterstützen will klarkommt.

DX ist schon immer ein "Wischiwaschi-Standard" wobei das zu DX7 zeiten ganz schlimm war. Es ist inzwischen etwas besser geworden.

PS: Alles ausser Point-Sampling ist bei den Filtern wirklich optional :D

2002-11-22, 14:13:08

Originally posted by Demirug

PS: Alles ausser Point-Sampling ist bei den Filtern wirklich optional :D

Das dachte ich mir.:D

Zum Thema:
Macht es ueberhaupt Sinn, zu erfuellende Vorgaben seitens MS zu machen??
Im Endeffekt laeuft es fuer die Progger doch immer auf die Abfrage der 'caps bits' raus, um festzustellen, was eine HW (bzw. deren Treiber!) denn an Funktionen bereitstellt. Und diese caps bits sind doch seit jeher Bestandteil von DX, oder nicht?

Demirug

2002-11-22, 14:42:43

Ja die Caps Bits (und teilweise sind es auch Werte) gibt es schon immer.

Wenn man es genau nimmt geben sich da OpenGL und DX in diesem Punkt nicht viel. Bei OpenGL prüft man ob die Extension vorhanden ist bei DX werden die Caps geprüft. Der Vorteil von DX ist eben nur das es für das gleiche Feature nicht von jedem Hersteller einen eigene Extension geben kann.

Pitchfork

2002-11-22, 15:11:28

Wobei MS in der Zwischenzeit wohl die Meinung leicht revidiert. Um PS3 und VS3 überhaupt im Treiber freischalten zu können, müssen ein paar sonstige Features - die nicht direkt mit dem Shaderlevel zu tun haben - auf jeden Fall unterstützt werden. Welche das sind, weiß ich noch nicht.

aths

2002-11-22, 16:02:17

Originally posted by Quasar
Man könnte das Ganze wie bei einer Ausschreibung handhaben: Die Hersteller geben ihre Wünsche (am besten anonym) in einem versiegelten Umschlag ab, MS entscheidet noch dem GGN-Prinzip, im Zweifel mit der Mehrheit der Wünsche.GGN? Ich kenne nur KGV und GGT.

aths

2002-11-22, 16:04:11

Quasar

2002-11-22, 16:13:34

"GGN" ist eine Zusammenfassung des mathematischen Begriffes "GGT" und der Redewendung "auf einen Nenner bringen". ;)

2002-11-22, 16:32:24

Originally posted by aths
Das würde imo der Transparenz für den Kunden dienen und wäre sehr zu begrüßen.

Und was hat der Kunde davon??

Steht auf der Spielpackung: "this game requires a DX9 d3d accelerator.......":D

IMO bringt das nichts.

/edit: versucht's doch mal wie OGL zu sehen.
Soll da jede genutzte extension irgendwo auf der Kartenverpackung und den Spielen vermerkt sein??

aths

2002-11-22, 16:45:55

Originally posted by ow
/edit: versucht's doch mal wie OGL zu sehen.
Soll da jede genutzte extension irgendwo auf der Kartenverpackung und den Spielen vermerkt sein?? Da sollte konkret stehen, welche Karten die Mindestvoraussetzung darstellen und bis zu welcher Karte man mit zusätzlichen Effekten rechnen darf.

Was bringt denn die Vereinheitlichung auf DX-"soundso", wenn ein solches Wirrwarr besteht?

Demirug

2002-11-22, 16:57:40

"Was bringt denn die Vereinheitlichung auf DX-"soundso", wenn ein solches Wirrwarr besteht?"

Gar nichts und das war auch nie der Sinn und Zweg von DX.

aths

2002-11-22, 17:42:28

Originally posted by Demirug
"Was bringt denn die Vereinheitlichung auf DX-"soundso", wenn ein solches Wirrwarr besteht?"

Gar nichts und das war auch nie der Sinn und Zweg von DX. Man könnte es ja trotzdem jetzt noch so gestalten, dass mehr Transparenz für den Kunden entstünde.

Demirug

2002-11-22, 18:12:31

Originally posted by aths
Man könnte es ja trotzdem jetzt noch so gestalten, dass mehr Transparenz für den Kunden entstünde.

jetzt??? Für DX9 ist der Zug wohl schon definitive abgefahren.

Und IMO würde ein solcher Versuch von MS dazu führen das sich die Chip hersteller einfach weigern werden bei der Weiterentwicklung von DX noch mitzuarbeiten. Das beste was in diesem Fall noch passieren könnte wäre das sich die Hersteller auf eine neue API einigen können. Aber ich denke mal eher das dann jeder Hersteller bei den Entwicklern seine OpenGL Extensions anpreisen wird. Und die folgen davon kann man sich wohl leicht vorstellen.

Vorschlag:
Warum richten wir keine Datenbank ein in der wir das Featureset von jeder Karte/Treiber speichern. Dann können wir ja über einen schlüssel ermitteln wie weit eine Karte den Standard abdeckt. Und wenn die Spielehersteller mitspielen können wir noch eine Tabelle anlegen die speichert welche Features ein Spiel auf jeden Fall braucht und welche als option verbesserungen bringen.

aths

2002-11-22, 21:16:12

Originally posted by Demirug
Vorschlag:
Warum richten wir keine Datenbank ein in der wir das Featureset von jeder Karte/Treiber speichern. Das müsste man dann noch entsprechend pflegen, aber ich behalte den Vorschlag im Hinterkopf. So etwas in ungefähr dieser Art schwebt mir ohnehin schon länger vor...

Demirug

2002-11-22, 21:40:53

Originally posted by aths
Das müsste man dann noch entsprechend pflegen, aber ich behalte den Vorschlag im Hinterkopf. So etwas in ungefähr dieser Art schwebt mir ohnehin schon länger vor...

Wenn man ein kleines Programm schreibt welches das Featureset erfasst und an die Datenbank schickt dürfte die Pflege recht einfach sein wenn sich genügend Forumsmitglieder beteiligen.

Das erfassen welches Spiel auf welcher Karte was nutzt wird da schon aufwendiger.

Unregistered

2002-11-26, 16:31:19

Also ich finde es auf jeden fall sehr seltsam wie wenig das DX9-Label auf Grakas aussagt. Ich finde auch, dass es zwei Labels geben sollte. Z.B. DX9-light, DX9-partial Support, für ünterstützung der Kernfeatures, wie VS und PS in Hardware (gilt ja nur für VS) und DX9-full Support, für volle Ünterstützung aller Features in Hardware.
Wo wäre, dass Problem? Spiele erscheinen so und so nicht kurze Zeit nach dem Erscheinen von neuen DX Versionen. Dann brauchen manche Hersteller halt 1 oder 2 Chipgenerationen bis sie das DX9-Full-Support Label bekommen. Vorher ist wäre doch auch nicht mit DX9 Games zu rechenen.

betasilie

2002-11-26, 16:35:06

... war ich

nggalai

2002-11-26, 16:40:02

Das mitm "Full-Support" wird eher schwierig--in der Vergangenheit hat keine "DX(y)-Karte" alle Features der (y)-Version unterstützt. NV z.B. unterstützt erst seit GF3 alle DX6-Features . . . ;)

ta,
-Sascha.rb

betasilie

2002-11-26, 17:31:37

Originally posted by nggalai
Das mitm "Full-Support" wird eher schwierig--in der Vergangenheit hat keine "DX(y)-Karte" alle Features der (y)-Version unterstützt. NV z.B. unterstützt erst seit GF3 alle DX6-Features . . . ;)

ta,
-Sascha.rb

Was man hier nicht alles lernt. :O

2002-11-26, 18:50:28

nggalai

2002-11-26, 20:36:16

Originally posted by ow

Nö. Es dürfte kein derzeit käuflicher Chip ALLE DX6 Features unterstützen.:D Hehe. NOCH SCHLIMMER !!!!11111111111111

;)

Ich hab' eigentlich nur aufs EMBM angespielt. Aber eben: solche "ist voll DX(y)-Kompatibel" Sachen machen nur wenig Sinn . . .

ta,
-Sascha.rb

Pitchfork

2002-11-26, 23:53:34

Originally posted by Unregistered
Also ich finde es auf jeden fall sehr seltsam wie wenig das DX9-Label auf Grakas aussagt. Ich finde auch, dass es zwei Labels geben sollte. Z.B. DX9-light, DX9-partial Support, für ünterstützung der Kernfeatures, wie VS und PS in Hardware (gilt ja nur für VS) und DX9-full Support, für volle Ünterstützung aller Features in Hardware.
Wo wäre, dass Problem? Spiele erscheinen so und so nicht kurze Zeit nach dem Erscheinen von neuen DX Versionen. Dann brauchen manche Hersteller halt 1 oder 2 Chipgenerationen bis sie das DX9-Full-Support Label bekommen. Vorher ist wäre doch auch nicht mit DX9 Games zu rechenen.

Das ganze läuft doch darauf hinaus, daß es ein DX9-nach-nvidia-auffassung und ein DX9-nach-ati-auffassung und ein DX9-nach-3dlabs-auffassung und ein dx9-nach-matrox-auffassung gibt und eine Sortierung doch recht schwer fällt, abgesehen von den einfachen Klassen:

- partial: Matrox, 3dlabs
- more partial: nv, ati

Das einzig wirklich interessante ist PS2_0 oder PS2_X. Alles andere ist für Spieleentwicklung nicht wirklich wichtig. Und das kleine _X hinter der 2 beim PS ist auch nicht wichtig.
Das nächste interessante Feature ist VS3_0.

Ailuros

2002-12-02, 20:22:33

Das nächste interessante Feature ist VS3_0.

Genau. Da VS3.0 Displacement mapping eine Vertex texturing Kapazitaet einschliesst.

Displacement Mapping wird wohl hoechstwahrscheinlich dass gleiche Schicksal wie EMBM haben, wo viele glaubten dass es nur bump mapping ist, wobei es im Gegenteil ein "full dependant texture read" war. Nur weil ein gewisses Feature den gleichen oder aehnlichen Namen hat, heisst es bei weitem nicht dass es sich auch um die gleiche Sache handelt.

Displacement Mapping ohne adaptive Tesselation, muesste eigentlich sehr unattraktiv fuer Spiel-Entwickler sein.

Demirug

2002-12-02, 20:33:17

Originally posted by Ailuros
Genau. Da VS3.0 Displacement mapping eine Vertex texturing Kapazitaet einschliesst.

Ja VS 3.0 sind eine sehr interesante sache, weil man damit wieder einen schritt mehr auf eine normale CPU zugeht. Ich hätte aber gerne noch einen Geometrie Prozessor auf dem Chip.

Displacement Mapping wird wohl hoechstwahrscheinlich dass gleiche Schicksal wie EMBM haben, wo viele glaubten dass es nur bump mapping ist, wobei es im Gegenteil ein "full dependant texture read" war. Nur weil ein gewisses Feature den gleichen oder aehnlichen Namen hat, heisst es bei weitem nicht dass es sich auch um die gleiche Sache handelt.

Ja das ist zu befürchten. Denn bis es genügend Chips beherschen ist hat sich Technik wohl schon so weiterentwickelt das es eine viel flexiblere Lösung dafür gibt.

Displacement Mapping ohne adaptive Tesselation, muesste eigentlich sehr unattraktiv fuer Spiel-Entwickler sein.

Ja das ist es auch.

zeckensack

2002-12-02, 20:38:56

Originally posted by Demirug
Ja VS 3.0 sind eine sehr interesante sache, weil man damit wieder einen schritt mehr auf eine normale CPU zugeht. Ich hätte aber gerne noch einen Geometrie Prozessor auf dem Chip.Vertippt? :)
Meintest du vielleicht einen 'primitive processor'?

Demirug

2002-12-02, 20:45:34

Originally posted by zeckensack
Vertippt? :)
Meintest du vielleicht einen 'primitive processor'?

Ja hatte in dem moment gerade an prozeduale Geometrie gedacht und deswegen "Geometrie Prozessor" geschrieben. Ein Primitive Processor ist aber das was ich eigentlich meinte.

Pitchfork

2002-12-02, 23:51:39

Genau. Ich hatte vor 12-18 Monaten ja schon auf DX9 Timeframe getippt für den Primitive Assembler oder Primitive Shader (alberner Name *g*), aber die Jungs lassen sich anscheinend noch 2 Jahre Zeit. Naja, soooo leistungsfähig sind die mit ihren bis zu 300 Millionen Verts pro Sek ja auch noch nicht, daß sich ein Primitive Processor so richtig lohnen würde ;D

Ailuros

2002-12-03, 07:30:46

Ja VS 3.0 sind eine sehr interesante sache, weil man damit wieder einen schritt mehr auf eine normale CPU zugeht. Ich hätte aber gerne noch einen Geometrie Prozessor auf dem Chip.

Ich kann mir vorstellen wie albern das folgende klingt und auch was die negativen Aspekte dabei sind, aber ich hab irgendwie das Gefuehl dass es vielleicht gar nicht so schlecht waere wenn in zukuenftigen CPU's der ganze programmierbare Wirrwarr integriert wird (CPU's werden ja schneller auf kleinere Prozesse rutschen, sehe .9um usw.), so dass IHV's die space und Transistoren-Anzahl fuer andere Optimierungen sparen koennten.

Entweder dass oder IHV's werden sich einig in der Zukunft Entwickler fortschrittliche Emulatoren zu schicken und dem End-Verbraucher nur dass zu verkaufen was er wirklich braucht. Waere z.B. der NV30 nur dx8.1 Kompliant, aber wuerde trotz allem die selben 125M transistoren wiegen, muesste ich als Kaeufer mehr fuer mein Geld bekommen.

Na ja ich traeume mal wieder.....;)