Umstieg von OpenGL 3 auf DirectX 11 sinnvoll? (zwecks Shader-Debugging) [Archiv]

PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Umstieg von OpenGL 3 auf DirectX 11 sinnvoll? (zwecks Shader-Debugging)

Nasenbaer

2010-03-17, 08:16:18

Hi,
ich schreibe derzeit an einer Studienarbeit und muss dazu auch recht komplexe Shader schreiben. Scheinbar gibt es aber nur einen einzigen Shader-Debugger für OpenGL (GLSLdevil), welcher aber nicht uneingeschränkt mit OpenGL 3.x zusammenarbeitet.
Für DirectX HLSL hat dagegen jeder Graka-Hersteller ein Tool, teilweise sogar mit Visual Studio-Integration. Da ich mir nicht den Aufwand machen will die Daten irgendwie per FBO wieder zurückzulesen um einigermaßen debuggen zu können, frage ich mich ob es sinnvoll ist vielleicht doch noch auf DX umzusteigen da ich noch so gut wie nichts programmiert habe.

Die Frage richtet sich vorallem an diejenigen, die beide APIs kennen und daher den Vergleich ziehen können. Falls jemand natürlich nen guten Tipp zum Shader-Debugging unter OpenGL 3 hat, bin ich auch glücklich.

Nasenbaer

2010-03-17, 13:01:40

Meine Frage ist im wesentlich wie groß der Unterschied zwischen DirectX und OpenGL 3 bei der Art der Programmierung ist. Also gibt es mehr oder minder ein 1:1 Mapping zwischen einem Großteil der Befehle für simple Anwendungen?

Im wesentlich brauche ich natürlich erstmal ein Fenster samt D3D Context und dann muss ich ein paar Texturen und ein VBO an die Graka senden und anschließend die Shader an die GPU senden und dann ein Rendering mit geometry instancing durchführen. Dass das prinzipiell ähnlich abläuft ist mir klar aber mir gehts darum ob das auch im Detail sehr ähnlich ist - sprich ähnliche Funktionsaufrufe, sodass die MSDN mehr als ausreichend ist.

Demirug

2010-03-17, 13:22:22

Nasenbaer

2010-03-17, 13:41:24

Das SDK kommt mit einem eigenen Dokumentationsfile. Die Konzepte sind hardwarebedingt natürlich ähnlich. Im Detail gibt es dann aber Unterschiede. Gerade ab 10 aufwärts hat man sich doch etwas stärker von der Tradition getrennt. Allerdings sollte es für jemanden der sich mit OpenGL auskennt nicht so schwer sein. Es gibt im SDK auch eine Reihe von ganz simplen Beispielen für die Grundlagen.
Bin grad schon am Durchstöbern der SDK-Doku. :)
Ist der Aufwand denn eher größer als bei OpenGL oder ist der Code dagegen sogar kompakter? Geht mir vorallem darum wie große der Aufwand für eine Umstellung ist um abschätzen zu können ob sich das lohnt.

Nasenbaer

2010-03-17, 18:14:42

So hab jetzt das "BasicHLSL11" Beispiel provisorisch in meine Anwendung integriert. DXUT nimmt einem ja ne ganze Menge Arbeit ab und DirectX scheint bei weitem weniger schlimm als die WinAPI zu sein (wenngleich auch hier unzählige Structs darauf warten gefüllt zu werden^^).

Gast

2010-03-18, 18:26:31

hab vor mich in nächster zeit mich in eine der beiden APIs einzuarbeiten.
nun wollte ich fragen wie es dir mit directx ergeht und mit welcher API ich beginnen sollte?

Gast

2010-03-18, 18:51:38

Nasenbaer

2010-03-18, 20:56:29

OpenGL 4.0 steht vor der Tür und hat alles was DirectX 11 auch hat und es ist Multiplattformfähig.

Wer also jetzt noch ein neues Projekt mit DirectX 11 anfängt schneidet sich selber ins Fleisch, denn später will er vielleicht das Zeug auf dem Mac haben und dann geht es nicht, weil er die falsche API gewählt hat.
Die Frage ist doch wie wichtig das einem persönlich ist - zum Einsteig für einen persönlich sicher nicht das große Problem, wenn es nicht ohne weiteres portierbar ist.
Wenn man Ahnung von Objektorientierung hat ist man auch in der Lage eine Abstraktions zwischen OpenGL und Direct3D zu basteln wodurch man dann die jeweils andere API ohne große Veränderung des bestehenden Codes integrieren kann. Dazu sollte man das aber sicher mindestens eine API einigermaßen drauf aber sonst fehlt der dafür notwendige Weitblick und erhöhten Aufwand bedeutet sowas natürlich auch.

@Gast1
Also beide API haben, schon allein wegen der gleichen anzusteuernden Hardware, natürlich große Gemeinsamkeiten bei den grundlegenden Sachen. Und beide haben zum Erlernen auch ihre Vor- und Nachteile:

OpenGL
- Ab Version 3 ist die API wirklich ziemlich schlank und relativ wenige Zeilen Code ermöglichen die Ausgabe der ersten farbigen Dreiecks mittels Vertex- und Pixelshader (wird in OGL als Fragmentshader bezeichnet).
- Für mich ganz persönlicher Vorteil: Ich habe dazu ein wirklich sehr gutes Buch gefunden: "Beginning OpenGL Game Programming - Second Edition" (ISBN-10: 159863528X ). Das Buch ist auf Englisch (hoffentlich kein Problem - sonst hat mans als Programmierer eh schwer - aber sehr leicht zu lesender Stil) Und beschreibt sehr gut den Unterschied zwischen OpenGL 3.0 und 2.0 und vermittelt einem dann auch wie man die API ab 3.0 zu nutzen hat.
- Die Hilfsbibliothek GLUT für Fenstererstellung und Eingabebehandlung ist leider nicht aktuell und für OGL ab Ver. 3 unbrauchbar.
- Für OpenGL gibts ne super Quick Reference Card (http://www.khronos.org/files/opengl-quick-reference-card.pdf) auf der zu ziemlich alle Funktionen und eine kurze Beschreibung aufgelistet sind. Zudem sind Funktionen markiert, die ab Ver. 3. veraltet sind. Enthalten ist auch jeweils der Abschnitt unter dem man in der OGL Reference genaueres findet.
- Letztere gibt's leider nur als PDF und ist damit nicht so gut zu handhaben wie die Direct3D11 Doku im HTML (CHM) Format.

Direct3D
- Die DXUT (eine Hilfsbibliothek) nimmt einem am Anfang sehr viele Aufgaben ab.
- Man sollte den Stil der WinAPI nicht hassen da es hier einige parallelen zu geben scheint aber ist ja auch beides von MS.
- Für ein einfaches Beispiel ist AFAIK etwas mehr Code notwendig (minimal) und ich finde den Stil ein bisschen unübersichtlicher was aber auch daran liegen mag, dass ich zuerst OpenGL gelernt habe und dadurch damit vertrauter bin.
- Für Direct3D gibts bessere Tools zum Debugging - nicht zu unterschätzen, wenn ein Shader mal komplexer werden sollte.

Im großen und ganzen kann man sagen, dass beide beim Einstieg sehr ähnlich zu handhaben sind - wie bei sehr komplexen Aufgaben aussieht weiß ich allerdings nicht.
Noch was: Die OpenGL Tutorials im Netz kannst du übrigens getrost vergessen. Einstiegs-Tutorials für OGL 3 hab ich noch keine gefunden - also Finger weg von Nehe und Konsorten.

malte.c

2010-03-19, 00:33:32

OpenGL 4.0 steht vor der Tür und hat alles was DirectX 11 auch hat und es ist Multiplattformfähig.

OpenGL 4 mag die Features von D3D11 haben, aber das API ist nach wie vor die gute alte State Machine. Die Folge davon ist eine gewisse Unberechenbarkeit in größeren Programmen, bei denen ich auf der einen Seite den OpenGL-State ändere und wo ganz anders auf einmal ein seltsames Verhalten auftritt. Sich mit glPushAttrib davor zu schützen ist zwar möglich, aber mit deutlichen Performance-Einbußen verbunden. Meine D3D-API-Kenntnisse mögen nicht auf dem Stand der Technik sein, aber mein täglicher Umgang mit OpenGL hat mich gelehrt, dass hier höchste Vorsicht geboten ist, weil sich unauffällig und subtil schwer zu findende Bugs einschleichen können, was ich in dieser extremen Form in D3D nicht erlebt habe.

Was die Multiplattformfähigkeit angeht, so muss ich anmerken, dass man mit OpenGL schon unter Windows mehrere Plattformen hat. In der Praxis muss ich den Code momentan auf einer Geforce 8800 GT, einer Geforce GTX 285 und einer Radeon HD4850 testen, und entdecke immer wieder Bugs, die nur auf einer oder zwei der drei Modelle auftreten. Und selbst dann melden Kollegen noch Bugs auf einer Radeon HD5770... Dabei sind die OpenGL-Treiber von Nvidia vielleicht vollständiger als die von AMD, aber auch nachlässiger, was fehlerhafte API-Calls angeht. Den Intel-Support haben wir schon vor langer Zeit eingestellt, da die OpenGL-Treiber dort zumindest 2007 eine Katastrophe waren.

Würde ich jetzt ein neues Projekt anfangen, würde ich auf jeden Fall D3D11 näher betrachten, da ich dem Hörensagen nach davon ausgehe, dass die Treiber hier deutlich verlässlicher sind.

Nasenbaer

2010-03-19, 08:22:23

Simon

2010-03-19, 09:28:13

OpenGL 4 mag die Features von D3D11 haben, aber das API ist nach wie vor die gute alte State Machine.
Naja, solange man kein DSA oder Bindless Graphics benutzt, stimmt das mit der State Machine ;)

Chris Lux

2010-03-19, 09:52:58

Zur StateMachine-Sache:
Bei einem mehr oder minder streng sequentiellem Ablauf des Renderings-Codes ist das ja unproblematisch aber wer kann heute schon auf Multithreading verzichten? :ucrazy2: Bei größeren Apps hat man da praktisch gar keine Wahl mehr.
die state machine ist einem kontext zugeordnet und pro thread kann es nur einen kontext geben und ein kontext gehoert auch nur zu einem thread.

einen multi-threaded renderer zu schreiben ist schon etwas ganz anderes als render kommandos aus verschiedenen threads schicken. diese sollten sowieso immer aus einem thread kommen! bei DX11 kann man sich ja auch ansehen, dass das multi-threading was anderes bedeutet. man kann in einem thread eine kommando-queue generieren, die jedoch wieder auf den hauptkontext abgearbeitet wird (in die sequentielle abarbeitung eingepflegt sozusagen).

p.s. nur wegen einem shader debugger zu wechseln finde ich ein wenig die falsche herangehensweise.

Nasenbaer

2010-03-19, 22:15:25

die state machine ist einem kontext zugeordnet und pro thread kann es nur einen kontext geben und ein kontext gehoert auch nur zu einem thread.

einen multi-threaded renderer zu schreiben ist schon etwas ganz anderes als render kommandos aus verschiedenen threads schicken. diese sollten sowieso immer aus einem thread kommen! bei DX11 kann man sich ja auch ansehen, dass das multi-threading was anderes bedeutet. man kann in einem thread eine kommando-queue generieren, die jedoch wieder auf den hauptkontext abgearbeitet wird (in die sequentielle abarbeitung eingepflegt sozusagen).

Ok davin hab ich nicht wirklich viel Ahnung im moment was Multi-Threading zusammen mit ner 3D-API bringt. :rolleyes:

p.s. nur wegen einem shader debugger zu wechseln finde ich ein wenig die falsche herangehensweise.
Bin jederzeit offen für bessere Vorschläge. Aber durch einige, mir unverständliche Verhaltensweisen, haben ich Stunden gebraucht um rauszufinden was das, dennoch wenig einleuchtende, Problem war.
Ich kanns ja mal kurz schildern:

Ich habe ein regurläres, trianguliertes Gitter per Instanced-DrawCall and die GPU gesendet. Im VertesShader habe ich auf eine Textur zurückgegriffen, die pro Pixel x,y,z Koordinaten der Vertices eines Objektes enthält, dass vollständig als reguläres Gittern repräsentiert wird (Stichwort Geometry Images).
Nun musste ich pro Vertex die richtigen Koordinaten auf der Texture auslesen (mittels texelFetch() weil ich keine Interpolation wollte). Das Ergebnis war ein schwarzes Bild. Toll dachte ich, nach einigen Stunden rumprobieren habe ich rausgefunden, wenn ich im Pixelshader auch einen Zugriff auf die Textur mache, auch ohne den ausgelesenen Pixelwert zu weiter zu verwenden, dann sehe ich plötzlich die gerenderte Geometrie. Klingt für mich nicht gerade logisch.
Als ich die Textur aber nicht als GL_TEXTURE_2D sondern als GL_TEXTURE_RECTANGLE and die GPU geschickt hab, so gings auch ohne den Pseudo-Texturzugriff im Pixelshader. Also mit Debugging wäre ich zumindestens sofort darauf gekommen, dass es nicht am VertexShader-Code lag (vermutete ein Problem mit texelFetch()).

Chris Lux

2010-03-20, 10:06:33

Ich habe ein regurläres, trianguliertes Gitter per Instanced-DrawCall and die GPU gesendet. Im VertesShader habe ich auf eine Textur zurückgegriffen, die pro Pixel x,y,z Koordinaten der Vertices eines Objektes enthält, dass vollständig als reguläres Gittern repräsentiert wird (Stichwort Geometry Images).
Nun musste ich pro Vertex die richtigen Koordinaten auf der Texture auslesen (mittels texelFetch() weil ich keine Interpolation wollte). Das Ergebnis war ein schwarzes Bild. Toll dachte ich, nach einigen Stunden rumprobieren habe ich rausgefunden, wenn ich im Pixelshader auch einen Zugriff auf die Textur mache, auch ohne den ausgelesenen Pixelwert zu weiter zu verwenden, dann sehe ich plötzlich die gerenderte Geometrie. Klingt für mich nicht gerade logisch.
Als ich die Textur aber nicht als GL_TEXTURE_2D sondern als GL_TEXTURE_RECTANGLE and die GPU geschickt hab, so gings auch ohne den Pseudo-Texturzugriff im Pixelshader. Also mit Debugging wäre ich zumindestens sofort darauf gekommen, dass es nicht am VertexShader-Code lag (vermutete ein Problem mit texelFetch()).
sorry, aber das war deine eigene unfähigkeit. lies nochmal nach was texelFetch macht.

normale 2d texturen werden normalisiert adressiert. texture rectangles unnormalisiert. texelFetch() nutzt integer texturkoordinaten, also warum wird wohl eine 2d textur mit der funktion probleme machen? da hätte auch ein debugger wenig geholfen.

Nasenbaer

2010-03-20, 17:45:56

sorry, aber das war deine eigene unfähigkeit. lies nochmal nach was texelFetch macht.

normale 2d texturen werden normalisiert adressiert. texture rectangles unnormalisiert. texelFetch() nutzt integer texturkoordinaten, also warum wird wohl eine 2d textur mit der funktion probleme machen? da hätte auch ein debugger wenig geholfen.
Ich weiß was texelFetch() von texture() unterscheidet - du hast mein Problem nicht verstanden vermute ich.

Weil ich einen Zugriff auf die 2D-Textur möchte aber unter Nutzung der unnormalisierten Pixelkoordinaten. Das kann man bei TEXTURE_RECTANGLE mittels texture() machen oder bei TEXTURE_2D mittels texelFetch(). Man mag argumentieren, dass ich doch dann einfach TEXTURE_RECTANGLE nehmen könnte. Da ich aber eine MipMap-Pyramide brauchen kommen die nicht in Frage (unterstützen sie nicht).
Außerdem funktioniert ja der Zugriff mittels texelFetch() und absoluten Pixelkoordinaten auf TEXTURE_2D so wie es die Reference, die ich selbstverständlich aufgrund der Probleme gelesen hatte, es auch darlegt. Aber werden nur dann die richtigen Werte ausgelesen, wenn zusätzlich ein Zugriff auf die Textur im Pixelshader stattfindet.

Ein Debugger hätte mir in sofern geholfen, dass ich gemerkt hätte was texelFetch() im VertexShader als Wert zurückliefert. Ich hatte sogar vorher mittels RenderMonkey einen einfachen Shader zur Texturierung so umgeschrieben damit im PixelShader texelFetch() statt texture() genutzt wird (wozu ich dann natürlich erst in unnormalisierte Koordinaten umrechnen musste). Das hat auch prima geklappt aber im VertexShader wollte texelFetch() dann nicht ohne weiteres - sowas wird im Standard nicht bei der texelFetch() Funktion erwähnt weshalb ich einen Fehler vermute.

ScottManDeath

2010-03-20, 19:36:12

D3D hat die Debugruntime, die die lausige glGetError Funktion in den Schatten stellt :(

Gast

2010-03-21, 09:19:13

Nasenbaer

2010-03-21, 11:19:09

Was bringt mir DirectX 10 oder 11, wenn ich es unter meinem Windows XP nicht nutzen kann?

Bei OpenGL 4.0 muß ich nur auf neue Treiber warten und ich kann OpenGL 4 unter Windows XP nutzen und bekomme damit unter Windows XP die Möglichkeiten, die es ansonsten nur ab Vista bei DirectX gegeben hätte.

Dazu kommt dann noch die Plattformunabhängigkeit.

Es gibt also schonmal 2 trifftige Gründe OpenGL anstatt DirectX zu verwenden.

Wer also jetzt noch auf DirectX setzt, der setzt auf das falsche Pferd.

Hinweis:
Wenn ich von DirectX spreche, dann ist damit hauptsächlich Direct3d gemeint.
Naja die Plattformunabhängigkeit soll ja nicht wirklich gegeben sein sagen viele, die OGL intensiver genutzt haben. Wenn man dann doch für jede Plattform noch wieder Fixes basteln muss, weil nicht alles 100% identisch abläuft, so bringt einem die Unabhängikeit auch nicht soo viel.

Tesselation unter WinXP bekommst du allerdings wirklich nur mit OGL hin aber WinXP erfährt auch nicht mehr ewig Support (also Sicherheitsupdates) und 4GB RAM Begrenzung werden auch nicht ewig halten. Außerdem, wer sich ne DX11-Karte kauft, der wird wohl auch ein aktuelles Windows haben.

@Chris Lux

Aber so wie ich das Problem beschrieben habe stimmt doch da irgendwas nicht oder hab ich da doch was übersehen? Ich meine solange nutze ich OGL ja nun noch nicht.

instinct

2010-03-21, 13:02:19

Naja die Plattformunabhängigkeit soll ja nicht wirklich gegeben sein sagen viele, die OGL intensiver genutzt haben. Wenn man dann doch für jede Plattform noch wieder Fixes basteln muss, weil nicht alles 100% identisch abläuft, so bringt einem die Unabhängikeit auch nicht soo viel.

Stimmt, unter MacOSX muss man andere Header-Files einbinden. Da sollte echt mal jemand was unternehmen ...

Tesselation unter WinXP bekommst du allerdings wirklich nur mit OGL hin aber WinXP erfährt auch nicht mehr ewig Support (also Sicherheitsupdates) und 4GB RAM Begrenzung werden auch nicht ewig halten. Außerdem, wer sich ne DX11-Karte kauft, der wird wohl auch ein aktuelles Windows haben.

Tesselation + WinXP ist doch nur ein Beispiel. In Zukunft wird es irgendeine andere Funktion und ein anderes Windows-OS sein und das Spiel ist das Gleiche.

Nasenbaer

2010-03-21, 14:08:41

Stimmt, unter MacOSX muss man andere Header-Files einbinden. Da sollte echt mal jemand was unternehmen ...

[ ] Du hast die Problematik eines fehlenden WHQL-Äquivalents verstanden.

Das habe ich gern - warscheinlich noch keine Zeile OGL genutzt aber meinen man wäre der Guru. Ich habe noch selbst noch keine Probleme mit unterschiedlichen OGL-Implementierungen festgestellt (hab meinen Code bisher auch nicht auf mehreren OGL-Impl. laufen lassen) aber ich denke Demirug ist eine seriöse Quelle was solche Aussagen angeht und er ist auch nicht der einizge, der das Problem anspricht.
Außerdem kann man auch auch gut an C Compilern sehen, wie unterschiedlich ein Standard umgesetzt wird. Nichtmal dort lässt sich der gleiche Code mit jedem Compiler ohne Probleme kompilieren.

Tesselation + WinXP ist doch nur ein Beispiel. In Zukunft wird es irgendeine andere Funktion und ein anderes Windows-OS sein und das Spiel ist das Gleiche.
Dennoch ist WinXP aufgrund vieler weitere Restriktionen keine Plattform der Zukunft. Generell ist gegen Plattformunabhängigkeit nichts zu sagen und niemand würde dies ernsthaft als Nachteil sehen aber in der Praxis ist diese nunmal nicht ohne weitere gegeben und deswegen auch nicht uneingeschränkt als Argument zu benutzen.

Gast

2010-03-23, 08:17:34

Es gibt noch einen Grund.

Denn zur Plattformunabhängigkeit Windows, OS X oder Linux gehört ja auch noch die CPU Architekturunabhängigkeit dazu.

Wenn du deine Software jemals auf einer ARM Cortex A9 CPU sehen willst, dann ist nur OpenGL die einzigste Wahl.

Nasenbaer

2010-03-23, 08:34:35

Wenn du deine Software jemals auf einer ARM Cortex A9 CPU sehen willst, dann ist nur OpenGL die einzigste Wahl.
Ist das son Emebedded System-CPU? Da läuft dann meist eh nur OpenGL ES aber sicher kein OpenGL 3.x. ;)

Versteht mich alle nicht falsch. Ich betrachte die Entwicklung bzgl. Monopolstellung auch immer mit Sorge. Für meine Studienarbeit und später im richtigen Beruf muss man aber Ergebnisse vorweisen und da führt Direct3D schneller zum Ziel -das sagen nahezu alle, die beide Schnittstellen schonmal genutzt haben. Ideologische Überlegungen kann ich mir bei meiner begrenzten Arbeitszeit nicht leisten und darum nehme ich den leichteteren Weg - wer würde ernsthaft was anderes machen?

Gast

2010-03-23, 08:51:20

Ist das son Emebedded System-CPU? Da läuft dann meist eh nur OpenGL ES aber sicher kein OpenGL 3.x. ;)

Nein, der Cortex A9 wird laut Arm in direkter Konkurrenz zu Intels ATOM aufgestellt werden.
Aber lies doch einfach mal im Cortex A9 Thread nach:
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=465708

Ideologische Überlegungen kann ich mir bei meiner begrenzten Arbeitszeit nicht leisten und darum nehme ich den leichteteren Weg - wer würde ernsthaft was anderes machen?
Idealisten!