Shader (historisch): Unterschied zwischen den Versionen

Aus DGL Wiki
Wechseln zu: Navigation, Suche
K (Ausserdem -> Außerdem)
 
(33 dazwischenliegende Versionen von 12 Benutzern werden nicht angezeigt)
Zeile 2: Zeile 2:
  
 
== Konzept ==
 
== Konzept ==
−
----
+
Die traditionelle [[Feste Funktionspipeline|Funktionspipeline]] der [[OpenGL]] ist eine feste Pipeline, auf die man nur beschränkt Einfluß nehmen kann (durch Statechanges), man hat also an sehr vielen Stellen starre Vorgaben die nur minimal anpassbar sind. So sind z.B. Farbberechnungen oder die Beleuchtung fest definiert und nur wenige ihrer Attribute können variiert werden. Zurückzuführen war/ist dieser Umstand v.a. darauf dass Grafikkarten bis vor kurzem nur feste Berechnungseinheiten besaßen, die man auch nicht programmieren konnte. (siehe z.B. die fest verdrahtete T&L-Einheit der ersten nVidia GeForce-Karten)
−
Die traditionelle Funktionspipeline der OpenGL ist eine feste Pipeline, auf die man nur beschränkt Einfluß nehmen kann (durch Statechanges), man hat also an sehr vielen Stellen starre Vorgaben die nur minimal anpassbar sind. So sind z.B. Farbberechnungen oder die Beleuchtung fest definiert und nur wenige ihrere Attribute können variiert werden. Zurückzuführen war/ist dieser Umstand v.a. darauf dass Grafikkarten bis vor kurzem nur feste Berechnungseinheiten besaßen, die man auch nicht programmieren konnte. (siehe z.B. die fest verdrahtete T&L-Einheit der ersten GeForce-Karten)
 
  
−
Allerdings haben vor einigen Jahren Grafikkarten mit teilweise programmierbaren Einheiten (erst waren dies recht eingeschränkt programmierbare Vertexeinheiten, inzwsichen sind selbst die Fragmentprozessoren recht frei programmierbar, siehe z.B. VS/PS3.0) Einzug in den Consumermarkt gefunden, und so war es nötig OpenGL auch um programmierbare Pipeline-Teile zu erweitern, und die neuste Inkarnation sind dabei Shader.
+
Allerdings haben vor einigen Jahren Grafikkarten mit teilweise programmierbaren Einheiten (erst waren dies recht eingeschränkt programmierbare Vertexeinheiten, inzwischen sind selbst die Fragmentprozessoren recht frei programmierbar, siehe z.B. VS/PS3.0) Einzug in den Consumermarkt gefunden, und so war es nötig OpenGL auch um programmierbare Pipeline-Teile zu erweitern, und die neuste Inkarnation sind dabei Shader.
 +
 
 +
Seit neuestem gibt es neben den herstellerabhängigen Funktionen zum Programmieren der Vertex- und Fragmentprozessoren auch standardisierte Erweiterungen. Zuerst waren dies GL_VERTEX_PROGRAM_ARB/GL_FRAGMENT_PROGRAM_ARB, mit denen man diese beiden Prozessoren (sofern auf der Grafikkarte vorhanden) in einer an Assembler (recht primitiv, mit nur wenigen Befehlen, alle auf Grafikprogrammierung ausgelegt) angelehnten Sprache programmieren konnte. Man schreibt dazu also ein Programm dass den entsprechenden Teil der festen Funktionspipeline ersetzt und führt dieses dann auf der Grafikkarte aus. So kann man für Vertices und Fragmente komplett eigene Berechnungen durchführen. Allerdings ist eine solche Assemblersprache nicht nur recht eingeschränkt, sondern auch recht kryptisch und daher nicht zuletzt (besonders bei großen Programmen) schlecht zu warten. Also hat OpenGL hier genau wie die normalen Programmiersprachen als nächste Iteration (OpenGL 2.0) für programmierbare Teile der Pipeline eine ''Hochsprache'' verpasst bekommen, namentlich als '''[[GLSlang]]''' bekannt.
 +
 
 +
Hießen die Programme unter der Assemblersprache noch Vertexprogramm bzw. Fragmentprogramm, so hat man sich unter [[GLSlang]] etwas angepasst (an D3D) und nennt diese nun '''[[Vertexshader]]''' bzw. '''[[Fragmentshader]]''' (Shader bedeutet "schattieren", stimmt also nicht 100%ig).
 +
 
 +
Diese Shader kann man wie angesprochen nun in einer '''an C angelehnten Hochsprache''' schreiben, was zur Folge hat dass sich die Programmierung der entsprechenden Grafikprozessoren reichlich vereinfacht hat, und außerdem hat man glSlang um recht viele Dinge erweitert die in der Assemblersprache nicht (oder nicht gerade einfach) möglich waren. Darunter Schleifen, Funktionen, uvm.
  
−
Seit neustem gibt es neben den herstellerabhängigen Funktionen zum Programmieren der Vertex- und Fragmentprozessoren auch standardisierte Erweiterungen. Zuerst waren dies GL_VERTEX_PROGRAM_ARB/GL_FRAGMENT_PROGRAM_ARB, mit denen man diese beiden Prozessoren (sofern auf der Grafikkarte vorhanden) in einer an Assembler (recht primitiv, mit nur wenigen Befehlen, alle auf Grafikprogrammierung ausgelegt) angelehnten Sprache programmieren konnte. Man schreibt dazu also ein Programm dass den entsprechenden Teil der festen Funktionspipeline ersetzt und führt dieses dann auf der Grafikkarte aus. So kann man für Vertices und Fragmente komplett eigene Berechnungen durchführen. Allerdings ist eine solche Assemblersprache nicht nur recht eingeschränkt, sondern auch recht kryptisch und daher nicht zuletzt (besonders bei großen Programmen) schlecht zu warten. Also hat OpenGL hier genau wie die normalen Programmiersprachen als nächste Iteration für programmierbare Teile der Pipeline eine ''Hochsprache'' verpasst bekommen, namentlich als '''glSlang''' bekannt.
 
  
−
Hiessen die Programme unter der Assemblersprache noch (passen) Vertexprogramm bzw. Fragmentprogramm, so hat man sich unter glSlang etwas angepasst (an D3D) und nennt diese nun '''Vertexshader''' bzw. '''Fragmentshader''' (Shader bedeutet "schattieren", stimmt also nicht 100%ig).
 
  
−
Diese Shader kann man wie angesprochen nun in einer '''an C angelehnten Hochsprache''' schreiben, was zur Folge hat dass sich die Programmierung der entsprechenden Grafikprozessoren reichlich vereinfacht hat, und ausserdem hat man glSlang um recht viele Dinge erweitert die in der Assemblersprache nicht (oder nicht gerade einfach) möglich waren. Darunter Schleifen, Funktionen, uvm.
 
  
−
<br>
 
 
== Voraussetzungen ==
 
== Voraussetzungen ==
−
----
 
 
Shader sind ein recht neues Konzept unter OpenGL und mit glSlang wollte man eine reichlich zukunftsorientierte Hochsprache für Shader schaffen. Deshalb hat man gleich auf alte Shaderversionen verzichtet und setzt '''Vertexshader und Pixelshader in der Version 2.0''' voraus, die bei ATI ab der Radeon 9500 und bei NVidia ab der Geforce FX zur Verfügung stehen.  
 
Shader sind ein recht neues Konzept unter OpenGL und mit glSlang wollte man eine reichlich zukunftsorientierte Hochsprache für Shader schaffen. Deshalb hat man gleich auf alte Shaderversionen verzichtet und setzt '''Vertexshader und Pixelshader in der Version 2.0''' voraus, die bei ATI ab der Radeon 9500 und bei NVidia ab der Geforce FX zur Verfügung stehen.  
  
 
Momentan stellt glSlang eine Erweiterung zur OpenGL-Version 1.5 dar, also benötigt man neben der oben erwähnten Hardware auch noch passende Treiber und OpenGL-Header. Für Delphi bietet die DGL einen eigenen Header an, der diese Funktionalität mitbringt ([http://www.delphigl.com/do_download.php?f=12000 Download]).
 
Momentan stellt glSlang eine Erweiterung zur OpenGL-Version 1.5 dar, also benötigt man neben der oben erwähnten Hardware auch noch passende Treiber und OpenGL-Header. Für Delphi bietet die DGL einen eigenen Header an, der diese Funktionalität mitbringt ([http://www.delphigl.com/do_download.php?f=12000 Download]).
  
−
<br>
+
 
 +
 
 
== Extensions ==
 
== Extensions ==
−
----
 
 
<ul>
 
<ul>
−
<li>[[GL_ARB_Shader_Objects]]</li>
+
<li>[[GL_ARB_shader_objects]]</li>
 
Definiert die API-Aufrufe die zum Erstellen, Kompilieren, Linken, Anhängen und Aktivieren von Shader- und Programmobjekten nötig sind.  
 
Definiert die API-Aufrufe die zum Erstellen, Kompilieren, Linken, Anhängen und Aktivieren von Shader- und Programmobjekten nötig sind.  
−
<li>[[GL_ARB_Vertex_Shader]]</li>
+
<li>[[GL_ARB_vertex_shader]]</li>
 
Fügt der OpenGL Programmierbarkeit auf Vertexebene hinzu.  
 
Fügt der OpenGL Programmierbarkeit auf Vertexebene hinzu.  
−
<li>[[GL_ARB_Fragment_Shader]]</li>
+
<li>[[GL_ARB_fragment_shader]]</li>
 
Fügt der OpenGL Programmierbarkeit auf Fragmentebene hinzu.  
 
Fügt der OpenGL Programmierbarkeit auf Fragmentebene hinzu.  
−
<li>[[GL_ARB_Shading_Language_100]]</li>
+
<li>[[GL_ARB_shading_language_100]]</li>
 
Gibt die unterstützte Version von glSlang an, momentan 1.00.
 
Gibt die unterstützte Version von glSlang an, momentan 1.00.
 
</ul>
 
</ul>
  
−
<br>
+
 
 +
 
 +
== Alternativen ==
 +
=== Vertex- und Fragmentprogramme ===
 +
Die Erweiterungen [[GL_ARB_vertex_program]] und [[GL_ARB_fragment_program]] ermöglichen die Programmierung von Programmen ("andere" Bezeichnung für Shader) auf VS/PS2.0-Hardware in einer Assembler-Sprache. Die Erweiterungen sind herstellerunabhängig, werden aber wohl aufgrund von glSlang nicht mehr (oder nur marginal) weiterentwickelt.
 +
 
 +
=== Vertex- und Fragmentprogramme (NVidia) ===
 +
Ähnlich wie oben erwähnte, herstellerunabhängige, Erweiterungen für Vertex- und Fragmentprogramme bietet NVidia ein Äquivalent (auch Assembler, aber mit anderen Mnemonics, Befehlen und Syntax) dazu an. Diese Erweiterungen werden mit jeder neuen Hardwaregeneration weiterentwickelt, um deren Shaderfähigkeiten nutzbar machen zu können, ohne dabei auf eine vom ARB abgesegnete Erweiterung warten zu müssen. Je nach Hardware stehen dann [[GL_NV_vertex_program]], [[GL_NV_vertex_program1_1]], [[GL_NV_vertex_program2]] und [[GL_NV_vertex_program3]] bzw. [[GL_NV_fragment_program]] und [[GL_NV_fragment_program2]] zur Verfügung.
 +
 
 +
=== Vertex- und Fragmentshader (ATI) ===
 +
Mit Einführung der Radeon 8500-Reihe, die Pixelshader und Vertexshader in Version 1.4 beherschte, führte ATI (in Ermangelung passender GL-Funktionalität) eigene Erweiterungen ein mit denen man (jedoch recht undynamisch) VS/PS1.4 in OpenGL nutzen kann, und zwar in Form von [[GL_ATI_vertex_shader]], [[GL_ATI_fragment_shader]] und [[GL_ATI_text_fragment_shader]]. Trotz der Namensverwandschaft haben diese Extensions in Sachen Programmierung so gut wie nichts mit glSlang gemein.
 +
 
 +
=== Registercombiner und Textureshader (NVidia) ===
 +
Seit der GeForce2-Reihe gibt es von NVidia sog. Registercombiner und Textureshader, die man in etwa mit recht eingeschränkten Shadern vergleichen kann. Da neure NVidia Hardware VS/PS2.0+ kann, werden diese Erweiterungen nicht mehr weiterentwickelt. Je nach verwendeter Hardware sind die nutzbaren Erweiterungen [[GL_NV_register_combiners]] und [[GL_NV_register_combiners2]] bzw. [[GL_NV_texture_shader]], [[GL_NV_texture_shader2]] und [[GL_NV_texture_shader3]].
 +
 
 +
 
 +
 
 
== Funktionen ==
 
== Funktionen ==
−
----
+
*[[glAttachObjectARB]]
−
<ul>
+
*[[glBindAttribLocationARB]]
−
<li>[[glCreateProgramObjectARB]]</li>
+
*[[glCompileShaderARB]]
−
<li>[[glCreateShaderObjectARB]]</li>
+
*[[glCreateProgramObjectARB]]
−
<li>[[glShaderSourceARB]]</li>
+
*[[glCreateShaderObjectARB]]
−
<li>[[glCompileShaderARB]]</li>
+
*[[glDeleteObjectARB]]
−
<li>[[glLinkProgramARB]]</li>
+
*[[glDetachObjectARB]]
−
<li>[[glGetInfoLogARB]]</li>
+
*[[glEnableVertexAttribArrayARB]]
−
<li>[[glUseProgramObjectARB]]</li>
+
*[[glGetActiveAttribARB]]
−
<li>[[glGetObjectParameterARB]]</li>
+
*[[glGetActiveUniformARB]]
−
<li>[[glUniformARB]]</li>
+
*[[glGetAttachedObjectsARB]]
−
<li>[[glGetUnifromLocationARB]]</li>
+
*[[glGetAttribLocationARB]]
−
</ul>
+
*[[glGetHandleARB]]
 +
*[[glGetInfoLogARB]]
 +
*[[glGetObjectParameterARB]]
 +
*[[glGetShaderSourceARB]]
 +
*[[glGetUniformARB]]
 +
*[[glGetUniformLocationARB]]
 +
*[[glGetVertexAttribARB]]
 +
*[[glGetVertexAttribPointervARB]]
 +
*[[glLinkProgramARB]]
 +
*[[glShaderSourceARB]]
 +
*[[glUniformARB]]
 +
*[[glUseProgramObjectARB]]
 +
*[[glValidateProgramARB]]
 +
*[[glVertexAttribARB]]
 +
*[[glVertexAttribPointerARB]]
 +
 
 +
 
 +
 
 +
 
  
−
<br>
 
 
== Ressourcen ==
 
== Ressourcen ==
−
----
+
=== Informationen ===
−
<ul>
+
*[http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf Official OpenGL 2.0 Specifications] (Englisch)
−
<li>[http://www.delphigl.com/do_download.php?f=12000 OpenGL1.5-Header für Delphi (mit glSlang-Extensions)]</li>
+
*[http://www.opengl.org/documentation/oglsl.html Offizielle GlSlang-Dokumentation] (Englisch)
−
<li>[http://www.delphigl.com/script/do_show.php?name=glslang&action=2 glSlang-Tutorial auf DGL] (Deutsch)</li>
+
*[http://developer.3dlabs.com/openGL2/index.htm Offizielle OpenGL2/OpenGL HLSL-Seiten] (Englisch)
−
<li>[http://www.opengl.org/documentation/oglsl.html Offizielle glSlang-Dokumentation] (Englisch)</li>
+
*[[DGLOpenGL.pas|OpenGL-Header für Delphi (mit GlSlang-Extensions)]]
−
<li>[http://developer.3dlabs.com/openGL2/index.htm Offizielle OpenGL2/OpenGL HLSL-Seiten] (Englisch)</li>
+
*[[Tutorial glsl|GLSlang-Tutorial auf DGL]] (Deutsch)
−
</ul>
+
*[http://www.clockworkcoders.com/oglsl GlSlang Tutorials] (Englisch)
 +
*[http://www.shadertech.com/ ShaderTech - GPU Programming] (Englisch)
 +
*[http://nehe.gamedev.net/data/articles/article.asp?article=21 NeHe GLSL Introduction] (Englisch)
 +
*[http://www.3ddrome.com/articles/cgshaders.php Cg Pixel Shaders in OpenGL] (Englisch)
 +
 
 +
 
 +
 
 +
=== Programme/Tools ===
 +
*[http://www.typhoonlabs.com/ OpenGL-Shaderdesigner von Typhoon Labs]
 +
*[http://www.weeselsoftware.tgaraas.com/shaderNinja.html Shader Ninja von Weesel Software]
 +
*[http://mirror.ati.com/developer/sdk/radeonSDK/html/Tools/RenderMonkey.html ATIs RenderMonkey]
 +
*[http://developer.nvidia.com/object/sdk_home.html nVidias SDK] (Beinhaltet diverse GlSlang-Beispielanwendungen/Shader)
 +
*[http://www.gpgpu.org/ GPGPU - General-Purpose Computation Using Graphics Hardware]

Aktuelle Version vom 21. März 2012, 15:41 Uhr

Shader

Konzept

Die traditionelle Funktionspipeline der OpenGL ist eine feste Pipeline, auf die man nur beschränkt Einfluß nehmen kann (durch Statechanges), man hat also an sehr vielen Stellen starre Vorgaben die nur minimal anpassbar sind. So sind z.B. Farbberechnungen oder die Beleuchtung fest definiert und nur wenige ihrer Attribute können variiert werden. Zurückzuführen war/ist dieser Umstand v.a. darauf dass Grafikkarten bis vor kurzem nur feste Berechnungseinheiten besaßen, die man auch nicht programmieren konnte. (siehe z.B. die fest verdrahtete T&L-Einheit der ersten nVidia GeForce-Karten)

Allerdings haben vor einigen Jahren Grafikkarten mit teilweise programmierbaren Einheiten (erst waren dies recht eingeschränkt programmierbare Vertexeinheiten, inzwischen sind selbst die Fragmentprozessoren recht frei programmierbar, siehe z.B. VS/PS3.0) Einzug in den Consumermarkt gefunden, und so war es nötig OpenGL auch um programmierbare Pipeline-Teile zu erweitern, und die neuste Inkarnation sind dabei Shader.

Seit neuestem gibt es neben den herstellerabhängigen Funktionen zum Programmieren der Vertex- und Fragmentprozessoren auch standardisierte Erweiterungen. Zuerst waren dies GL_VERTEX_PROGRAM_ARB/GL_FRAGMENT_PROGRAM_ARB, mit denen man diese beiden Prozessoren (sofern auf der Grafikkarte vorhanden) in einer an Assembler (recht primitiv, mit nur wenigen Befehlen, alle auf Grafikprogrammierung ausgelegt) angelehnten Sprache programmieren konnte. Man schreibt dazu also ein Programm dass den entsprechenden Teil der festen Funktionspipeline ersetzt und führt dieses dann auf der Grafikkarte aus. So kann man für Vertices und Fragmente komplett eigene Berechnungen durchführen. Allerdings ist eine solche Assemblersprache nicht nur recht eingeschränkt, sondern auch recht kryptisch und daher nicht zuletzt (besonders bei großen Programmen) schlecht zu warten. Also hat OpenGL hier genau wie die normalen Programmiersprachen als nächste Iteration (OpenGL 2.0) für programmierbare Teile der Pipeline eine Hochsprache verpasst bekommen, namentlich als GLSlang bekannt.

Hießen die Programme unter der Assemblersprache noch Vertexprogramm bzw. Fragmentprogramm, so hat man sich unter GLSlang etwas angepasst (an D3D) und nennt diese nun Vertexshader bzw. Fragmentshader (Shader bedeutet "schattieren", stimmt also nicht 100%ig).

Diese Shader kann man wie angesprochen nun in einer an C angelehnten Hochsprache schreiben, was zur Folge hat dass sich die Programmierung der entsprechenden Grafikprozessoren reichlich vereinfacht hat, und außerdem hat man glSlang um recht viele Dinge erweitert die in der Assemblersprache nicht (oder nicht gerade einfach) möglich waren. Darunter Schleifen, Funktionen, uvm.



Voraussetzungen

Shader sind ein recht neues Konzept unter OpenGL und mit glSlang wollte man eine reichlich zukunftsorientierte Hochsprache für Shader schaffen. Deshalb hat man gleich auf alte Shaderversionen verzichtet und setzt Vertexshader und Pixelshader in der Version 2.0 voraus, die bei ATI ab der Radeon 9500 und bei NVidia ab der Geforce FX zur Verfügung stehen.

Momentan stellt glSlang eine Erweiterung zur OpenGL-Version 1.5 dar, also benötigt man neben der oben erwähnten Hardware auch noch passende Treiber und OpenGL-Header. Für Delphi bietet die DGL einen eigenen Header an, der diese Funktionalität mitbringt (Download).


Extensions


Alternativen

Vertex- und Fragmentprogramme

Die Erweiterungen GL_ARB_vertex_program und GL_ARB_fragment_program ermöglichen die Programmierung von Programmen ("andere" Bezeichnung für Shader) auf VS/PS2.0-Hardware in einer Assembler-Sprache. Die Erweiterungen sind herstellerunabhängig, werden aber wohl aufgrund von glSlang nicht mehr (oder nur marginal) weiterentwickelt.

Vertex- und Fragmentprogramme (NVidia)

Ähnlich wie oben erwähnte, herstellerunabhängige, Erweiterungen für Vertex- und Fragmentprogramme bietet NVidia ein Äquivalent (auch Assembler, aber mit anderen Mnemonics, Befehlen und Syntax) dazu an. Diese Erweiterungen werden mit jeder neuen Hardwaregeneration weiterentwickelt, um deren Shaderfähigkeiten nutzbar machen zu können, ohne dabei auf eine vom ARB abgesegnete Erweiterung warten zu müssen. Je nach Hardware stehen dann GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_NV_vertex_program2 und GL_NV_vertex_program3 bzw. GL_NV_fragment_program und GL_NV_fragment_program2 zur Verfügung.

Vertex- und Fragmentshader (ATI)

Mit Einführung der Radeon 8500-Reihe, die Pixelshader und Vertexshader in Version 1.4 beherschte, führte ATI (in Ermangelung passender GL-Funktionalität) eigene Erweiterungen ein mit denen man (jedoch recht undynamisch) VS/PS1.4 in OpenGL nutzen kann, und zwar in Form von GL_ATI_vertex_shader, GL_ATI_fragment_shader und GL_ATI_text_fragment_shader. Trotz der Namensverwandschaft haben diese Extensions in Sachen Programmierung so gut wie nichts mit glSlang gemein.

Registercombiner und Textureshader (NVidia)

Seit der GeForce2-Reihe gibt es von NVidia sog. Registercombiner und Textureshader, die man in etwa mit recht eingeschränkten Shadern vergleichen kann. Da neure NVidia Hardware VS/PS2.0+ kann, werden diese Erweiterungen nicht mehr weiterentwickelt. Je nach verwendeter Hardware sind die nutzbaren Erweiterungen GL_NV_register_combiners und GL_NV_register_combiners2 bzw. GL_NV_texture_shader, GL_NV_texture_shader2 und GL_NV_texture_shader3.


Funktionen



Ressourcen

Informationen


Programme/Tools

Abgerufen von „https://wiki.delphigl.com/index.php?title=Shader_(historisch)&oldid=25631“