Quo vadis Direct3D 9?

[Exxtreme]

Bisher hiess es ja, daß Direct3D ggü. OpenGL den Vorteil hat, daß man keine Extrawürstchen für diverse IHVs machen muss und alles viel problemloser voranstatten gehen soll. Nun ja... das real existierende Beispiel Farcry zeigt aber, daß es vielleicht doch nicht so problemlos ist wie einst behauptet.

Wie aktiviert man Shadermodell 2_B für die neuen Radeons? Man braucht eine gehackte DX-Version + (zurückgezogenen) FC-Patch 1.2 + speziellen Aufrufparameter.

Und wie aktiviert man SM3.0 bei einer GF6800? Gehackte DX-Version + GraKa-Treiber mit modifizierter Ini installieren + FC-Patch 1.2 + Parameter "-DevMode "r_sm30path 1" verwenden...

Einfach nicht? :freak:

Klar geht das meiste auf die Kappe von Crytek. Aber es scheint selbst gestandene Entwickler verwirrt zu haben diese ganze Shadermodell-Thematik.

Was meint ihr dazu?

[Demirug]

Ich kann dir nicht ganz folgen.

1. Von welcher gehackten DX-Version sprichst du?

2. Um neue Techniken zu nutzen sind nun mal in der Regel Patches notwendig. War beim SM2 Support von AN2 ja auch nicht anders.

3. Crytek traut iheren Schöpfungen wohl selbst nicht und macht sie nur im DevMode mit einem speziellen Parameter zugänglich. Was hat das mit DX zu tun?

In Summe zeichnet hier Crytek ein völlig falsches Bild das sich aber merketingtechnisch gut verkaufen lässt.

[avalanche]

Original geschrieben von Demirug
Ich kann dir nicht ganz folgen.

1. Von welcher gehackten DX-Version sprichst du?
Ich tippe mal auf 9.0c, auch wenn die eher "erhackt" als "gehackt" ist ;)
Original geschrieben von Demirug
3. Crytek traut iheren Schöpfungen wohl selbst nicht und macht sie nur im DevMode mit einem speziellen Parameter zugänglich. Was hat das mit DX zu tun?
Ich tippe mal drauf, dass Crytek den SM3-Support ziemlich flott "offiziell" und auch ohne extra Parameter zugänglich machen würde, wenn's selbigen auch in einer offiziellen DirectX-Version geben würde.

Was das Ganze aber mit 'nem Vorteil von DirectX gegenüber OpenGL, den es nun nicht mehr gibt, zutun hat, raff ich auch noch nicht so ganz...

[Corrail]

Meiner Meinung nach ist es zur Zeit ziehmlich egal, ob mal OpenGL oder DirectX für die Spieleprogrammierung nimmt. Wenn man so viel wie möglich aus einer Grafikkarte rausholen will, so muss man sowieso für die meisten Karten einen eigenen Rendering-Pfad schreiben. Siehe als Beispiel Far Cry: Kaum bringen NV und ATI ihre neuen Karten auf den Markt so gibt es schon wieder 2 neue Rendering-Pfade.
Das wäre mit OpenGL nicht wirklich anders, und somit verstehe ich das Argument "Bei OpenGL muss man doch SSSOOO viel mehr programmieren." nicht ganz. Ok, ein OpenGL Rendering-Pfad ist weniger aufwendig zu implementieren, aber trotzdem. Wenn man viel aus der Engine raus holen will so kommt man um mehrere Rendering-Pfade kaum herum.

[Exxtreme]

Original geschrieben von Demirug
Ich kann dir nicht ganz folgen.

1. Von welcher gehackten DX-Version sprichst du?

Kann DX9.b SM3.0?
Original geschrieben von Demirug
In Summe zeichnet hier Crytek ein völlig falsches Bild das sich aber merketingtechnisch gut verkaufen lässt.
Naja, bei dem jetzigen DX9-Vorzeigespiel ist offensichtlich das Chaos ausgebrochen. Und bei den derzeit verfügbaren Shaderprofilen scheint es auch kaum noch einen Unterschied zu OpenGL zu geben. :)

[Demirug]

Corrail, Bei DX gibt es programmtechnisch nur einen Satz von API Funktionen für alle Shader von 1.1 - 3.0. Die Unterschiede liegen also nur im Shadercode und der ist dank HLSL auch wieder einheitlich.

Das was Crytek da gemacht hat ist ein gutes Beispiel dafür wie man es nicht unbedingt machen sollte.

Da diese Lichtshader ja scheinbar einer der Angelpunkte der Engine ist hätte man da einen kleinen Scriptgenerator gebraucht dem man die Anzahl und Typen der Lichtquellen sowie das verfügbare Shaderprofil gibt und dieser hätte dann die benötigen Shader erzeugt. Wenn möglich als Singlepass falls nötig als Multipass.

Aber wenn man für jeden Hersteller was einiges kocht lässt sich das ja besser verkaufen. ;)

[Demirug]

Original geschrieben von Exxtreme
Kann DX9.b SM3.0?

Im Prinzip ja. Allerdings wurde es gespert. Die Entwickler hatten aber frühzeitig eine 9.0c Version.


Naja, bei dem jetzigen DX9-Vorzeigespiel ist offensichtlich das Chaos ausgebrochen. Und bei den derzeit verfügbaren Shaderprofilen scheint es auch kaum noch einen Unterschied zu OpenGL zu geben. :)

Richtig bei Farcry ist das Chaos ausgebrochen das hat sich Crytek aber selbst gebaut.

Es gibt noch wie vor einen grossen Unterschied zu OpenGL. Das Shaderhandling ist für alle Shader ab 1.1 identisch. Bei OpenGL gibt es für unterschiedliche "Shaderversionen" auch jeweils eignen extension die unterschiedlichen Code erfordern.

Wenn mein neuer Rechner komplett aufgesetzt ist werde ich mal was bezüglich der Unterschiede zwischen dem 20B und 30 Pfad posten was direkt aus dem Shaderscripten von Farcry kommt. Vorab schon mal dies. Es ist eigentlich nur eine Datei die sich zwischen 2.0, 2.B und 3.0 unterscheidet.

[Corrail]

Original geschrieben von Demirug
Es gibt noch wie vor einen grossen Unterschied zu OpenGL. Das Shaderhandling ist für alle Shader ab 1.1 identisch. Bei OpenGL gibt es für unterschiedliche "Shaderversionen" auch jeweils eignen extension die unterschiedlichen Code erfordern.

Original geschrieben von Demirug
Corrail, Bei DX gibt es programmtechnisch nur einen Satz von API Funktionen für alle Shader von 1.1 - 3.0. Die Unterschiede liegen also nur im Shadercode und der ist dank HLSL auch wieder einheitlich.

Ist bei OpenGL seit GLSL 1.1 auch nicht wirklich anders. Ok, GLSL 1.1 ist vor gut einem Monat releast worden und es gibt AFAIK noch keinen Treiber, der es unterstützt. Also ist das ganze noch sehr neu.

Was ich hier eher mehr ansprechen wollte ist weniger die Zeit und die Resourcen die man braucht um den eigenen Rendering-Pfad zu schreiben oder um eine Shader-API zu abstrahieren. In dieser Hinsicht stimmt es sehr wohl, dass es bei OpenGL derzeit um einiges aufweniger ist. Ich muss ehrlich sagen, dass ich wenig Ahnung von großer Spieleentwicklung habe, aber ich sehe hier mehr das Problem in der Shader- und Skriptprogrammierung und beim Testen. Und da ist es eigentlich egal, ob man das für OpenGL oder für DirectX macht.

Original geschrieben von Demirug
Da diese Lichtshader ja scheinbar einer der Angelpunkte der Engine ist hätte man da einen kleinen Scriptgenerator gebraucht dem man die Anzahl und Typen der Lichtquellen sowie das verfügbare Shaderprofil gibt und dieser hätte dann die benötigen Shader erzeugt. Wenn möglich als Singlepass falls nötig als Multipass.

Das ist eine sehr gute eine Möglichkeit um das ganze zu umgehen, aber die ginge sowohl in DirectX als auch in OpenGL (unter der Bedinung die verschiedenen Shader-APIs abstrahiert sind).

Ich will hier nur sagen, dass es meiner Meinung nach nicht so viel Mehr-Aufwand sein kann das ganze in OpenGL zu programmieren. Man muss das ganze natürlich richtig angehen. Weil der große Zeit-Aufwand, der in diesem Teil des Spiele-Projektes reingesteckt wird fällt IMHO auf das Testen. Und da ist es eigentlich egal, mit welcher API man programmiert hat, man muss (naja, man sollte ;)) sowieso alle Karten und Möglichkeiten durchtesten.

[Demirug]

Corrail, genau bei den Shadern ist doch das Problem. Die Funktionen für das Laden der Shaderprogramme sowieso das konfigurieren dieser lässt sich sicherlich noch leicht abstrahieren. DX kann das halt schon mit Boardmitteln ohne zusätzlichen Code. Das Problem sehe ich aber beide den Shadern selbst. Bei DX kann ich ab 1.1 aufwärst durchgängig HLSL nutzen und wenn man es darauf anlegt kann man sogar die DX7 Pipeline mit HLSL programmieren(dafür ist aber etas zusatzcode erforderlich). Bei OpenGL hat man eine einheitliche Sprache erst ab dem DX9 Level. Beim DX8 Level klaft ein Loch. Sobald man auf diese Karten keine Rücksicht mehr nehmen muss sehe ich DX und OpenGL als gleichwertig an. Nur fehlt OpenGL dann immer noch jemand der Lobbyarbeit betreibt.

[Demirug]

Mal schnell die Sicherungs-CD mit dem Farcry Zeug rausgeholt.

Shadertechnisch unterscheiden sich 2B und 30 in den Dateien "CGRCLightTempl_PS2B.crycg" und "CGRCLightTempl_PS30.crycg".

Beide Dateien enthalten etwas über 450 Zeilen HLSL Code mit zusätzlichen Precompileranweisungen.

8 Zeilen unterscheiden sich dabei.

zwei davon sind Kommentare
eine zeile gibt an das dieser Shader nur auf 2B bzw 30 Hardware benutzt wereden kann.

Bei zwei weiteren wird der Bindungstyp von Color (3.0) auf Texcoord (2.b) geändert. Eigentlich hätte das bei 3.0 auch texcoord sein müssen weil dort eine Vektor übergeben wird. Bei 3.0 ist Color und Texcoord aber gleichwertig. Bei 2.B nicht. deswegen musste es geändert werden.

Die letzten 3 Zeilen unterscheiden sich dann noch darin das bei 3.0 die Fog-Berechnung im Shader gemacht wird und bei 2.B nicht weil es dort die Fixed Funktions machen.

Das ist alles.

[avalanche]

Das klingt jetzt ja eigentlich nicht so, als ob man da so ein riesen Tamtam drum machen müsste, wie das, welches es aktuell um FarCry gibt.
Original geschrieben von Demirug
Die letzten 3 Zeilen unterscheiden sich dann noch darin das bei 3.0 die Fog-Berechnung im Shader gemacht wird und bei 2.B nicht weil es dort die Fixed Funktions machen.
Welche Vorteile hat das (und welche Nachteile)?

[Demirug]

Original geschrieben von avalanche
Das klingt jetzt ja eigentlich nicht so, als ob man da so ein riesen Tamtam drum machen müsste, wie das, welches es aktuell um FarCry gibt.
Welche Vorteile hat das (und welche Nachteile)?

Es ist einfach notwendig. Bei SM3 ist es vorgeschrieben das man die Fogberechnung im Pixelshader macht.

[Stebs]

Original geschrieben von Demirug
Bei OpenGL hat man eine einheitliche Sprache erst ab dem DX9 Level. Beim DX8 Level klaft ein Loch. Sobald man auf diese Karten keine Rücksicht mehr nehmen muss sehe ich DX und OpenGL als gleichwertig an.
Das ist ja allgemein bekannt aber irgendwie will mir das nicht so richtig in den Kopf gehen. Wieso in aller Welt können sich die IHV's nicht auf gemeinsame "DX8-Level"-Extensions einigen wenn sie es beim DX9-Level auch geschafft haben.

Gerade der DX8-Level sollte doch auf modernen DX9-Karten relativ einfach per neuer einheitlichen Extensions ansprechbar sein, oder? -hmm ok, DX8-Karten müssen logischerweise diese neue Extensions dann auch können...

Hat das wirklich einen technischen Grund oder fehlt einfach der richtige Wille das zu vereinheitlichen (z.B."politisch"- unsere Extension ist eh besser, oder zu teuer, zuviel Aufwand etc.)
Könnte es sein dass dieses Loch doch noch irgendwann gestopft wird und man per GLSL dann sämtliche Shader schreiben kann, oder ist es schon zu 99% beschlossene Sache dass es so bleibt?
Wenn es so bleibt ist das tatsächlich ein Nachteil für Opengl solange Spieleentwickler noch DX8-Level-Karten unterstützen müssen.

[Demirug]

GLSL wurde so definiert das die Karten FP Genauigkeit haben müssen. Das können DX8 Karten nicht.

Das man sich bei DX8 nicht auf was einheitliches einigen kann/will hängt wohl damit zusammen das die Karten von nVidia und ATI da sehr unterschiedlich aufgebaut sind.

Bei DX waren sie halt gezwungen sich einig zu werden.

[Stebs]

@Demirug
Ah, danke für die Info!
Das mit der notwendigen FP Genauigkeit war mir neu.

Noch eine OT-Frage an dich (hoffentlich nicht zu persönlich):
Da du zur Zeit ja schon fast den Job von Crytek machst (Programm schreiben das deren 2.0b Shader automatisch in 2.0 Shader aufteilt, Optimierungsmöglichkeiten siehst etc.), wie würdest du reagieren wenn sie auf dich aufmerksam werden und "anklopfen" :D
Wenn ich richtig informiert bin, arbeitest du Hauptberuflich als Programmierer, aber nicht an 3D-Grafik (Games). Soll das auf jeden Fall "nur" dein Hobby bleiben oder würdest du dich sogar auf eine Art Nebenjob einlassen? -Eine Ehre währe es aber so oder so, oder? =)

[Demirug]

Original geschrieben von Stebs
Noch eine OT-Frage an dich (hoffentlich nicht zu persönlich):
Da du zur Zeit ja schon fast den Job von Crytek machst (Programm schreiben das deren 2.0b Shader automatisch in 2.0 Shader aufteilt, Optimierungsmöglichkeiten siehst etc.), wie würdest du reagieren wenn sie auf dich aufmerksam werden und "anklopfen" :D

Wie sollte ich denn reagieren?

Wenn ich richtig informiert bin, arbeitest du Hauptberuflich als Programmierer, aber nicht an 3D-Grafik (Games). Soll das auf jeden Fall "nur" dein Hobby bleiben oder würdest du dich sogar auf eine Art Nebenjob einlassen? -Eine Ehre währe es aber so oder so, oder? =)

Da bist du nicht ganz richtig Informiert. Ich habe mit zweierlei Sachen zu tun. 3D-Programmierung und Industriesoftware für Leitwarten. Wobei ich beim letzteren ironischer weise überhaupt nichts mit der Grafik zu tun haben.

[Stebs]

Original geschrieben von Demirug
Wie sollte ich denn reagieren?
Naja ich weiss ja nicht wie verlockend ein Jobangebot von denen für dich wäre. Also irgendwas zwischen "Nö danke, hab schon einen besseren Job" und "Wow echt?, Super!" ;)
Da bist du nicht ganz richtig Informiert. Ich habe mit zweierlei Sachen zu tun. 3D-Programmierung und Industriesoftware für Leitwarten. Wobei ich beim letzteren ironischer weise überhaupt nichts mit der Grafik zu tun haben.
Das mit der Industriesoftware hatte ich gemeint, wusste aber nicht dass 3D-Programmierung doch mehr als ein Hoppy (sic) ist. (Aber eigentlich kein Wunder bei deinen Kenntnissen in der Materie...)

PS. Ein Kumpel von mir hat auch schon seit Jahren mit Industriesoftware zu tun, Prozessteuerung und so glaub ich. Aber für den ist 3D-Programmierung schon fast "Teufelszeug" ;)

[Corrail]

Original geschrieben von Demirug
GLSL wurde so definiert das die Karten FP Genauigkeit haben müssen. Das können DX8 Karten nicht.

Das sollte theoretisch das geringste Problem sein. Mir fallen auf die schnelle 2 Möglichkeiten ein, wie man das ganze mit Extensions erweitert, ohne aber die GLSL API zu verändern. Das eine wäre über das neue "#extension" Pre-Processor Feature in GLSL 1.1. Hier müsste man vor dem Source des Shaders nur die entsprechende Extension "freischalten". Oder über ein neues Shader-Target. GL_HIGH_LEVEL_TEXT_FRAGMENT_SHADER_ATI oder sowas in der Art. Hier müsste man nur statt einem GL_FRAGMENT_SHADER_ARB einen anderen Shader verlangen. Ist nur eine geringfügige Änderung im Source-Code.

Original geschrieben von Stebs
Könnte es sein dass dieses Loch doch noch irgendwann gestopft wird und man per GLSL dann sämtliche Shader schreiben kann, oder ist es schon zu 99% beschlossene Sache dass es so bleibt?

Theoretisch ist das überhaupt kein Problem! Nur ich bezweifle, dass da noch was kommt.
ATI hätte sogar für ihre DX8 API eine ARB_*_program-konforme Extension, GL_ATI_text_fragment_shader. Nur diese gibt es nur für den Mac OS Treiber und was ich im Internet so gelesen habe wird es diese Extensions nicht für Windows/Linux geben. Somit glaube ich nicht, dass von ATI noch irgendwas in dieser Richtung kommt.
Bei NV bin ich mir nicht so sicher. NV hat mit CG einiges an Vorarbeit geliefert und es wäre IMHO für NV nicht viel Aufwand auch für DX8 Shader eine eigene GLSL API konforme Extension zu implementieren. Es gibt ja auch die Extension GL_EXT_Cg_shader, welche was ich weiß auf der GLSL API aufbaut. Ich weiß aber ehrlich nicht, ob man damit auch DX8 Shader verwenden kann... Ich habe aber soeben zu meiner Verwunderung gesehen, dass GL_EXT_Cg_shader auch von einem NV25 unterstützt wird (http://www.delphi3d.net/hardware/extsupport.php?extension=GL_EXT_Cg_shader). Habe das auch bei mir probiert, es stimmt. Mit dem neuen 61.67 Treiber wird GL_EXT_Cg_shader angeboten. Wenn man damit auch DX8 Pixel Shader programmieren könnte wäre IMHO der Schritt zu (einem schwächeren) GLSL nicht mehr weit. Werde mal ein Mail an NV schicken...

[Stebs]

Habs zwar auch schon hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=2061936#post2061936) gepostet aber es passt eigentlich gut in diesen Thread:
DirectX9c scheint nun offiziell draussen zu sein:
Link (http://www.microsoft.com/downloads/details.aspx?FamilyID=9226a611-62fe-4f61-aba1-914185249413&DisplayLang=en)

[Stebs]

Danke Corrail, hab zwar nicht alles verstanden aber es scheint ja doch prinzipiell nicht unmöglich zu sein, sondern es eher am Willen zu mangeln.
Wenn Carmack da mal ein Machtwort gesprochen hätte währe es vielleicht anders gekommen. Aber da seine Doom3-Engine anscheinend auch so ganz gut DirectX8-Level Hardware unterstützt, oder besser gesagt wenigstens das vorhandene Potential ausnützen kann, und andere wirklich moderne OpenGL-Spiele nicht in Sicht sind (oder hab ich was verpasst) ...
Also laut OpenGL-Viewer unterstützt meine NV20 (GF3Ti200) mit dem 61.76 Treiber auch die GL_EXT_Cg_shader Extension.

[Jesus]

ich will glide wieder haben :)

[deekey777]

Frage:
DX9.0c ist jetzt draussen, die kommenden R500- und NV50-Chips werden wohl beim SM 3.0 hängen bleiben. War's das jetzt mit 2.0, 2.X aka 2.0a, 2.0b, oder wird es von vorn wieder gehen mit 3.0 (der aktuelle NV40), 3.0a (Profil der einen), 3.0b(Profil der anderen)...

[Stebs]

Original geschrieben von Jesus
ich will glide wieder haben :)
Kein Problem: http://www.volarigamers.com/viewtopic.php?t=438 ;)

[Demirug]

Original geschrieben von deekey777
Frage:
DX9.0c ist jetzt draussen, die kommenden R500- und NV50-Chips werden wohl beim SM 3.0 hängen bleiben. War's das jetzt mit 2.0, 2.X aka 2.0a, 2.0b, oder wird es von vorn wieder gehen mit 3.0 (der aktuelle NV40), 3.0a (Profil der einen), 3.0b(Profil der anderen)...

Der Compiler gehort ja zum SDK und nicht zur Runtime. Es ist also durchaus denkabr das es noch neue Compilerprofile geben wird.