Shader (historisch) - Versionsgeschichte

Openglerf: Ausserdem -> Außerdem

2012-03-21T14:41:53Z

Ausserdem -> Außerdem

Thoronador: Wikisyntax; Links korrigiert

2011-07-20T07:56:09Z

Wikisyntax; Links korrigiert

Flash: hat „Shader“ nach „Shader (historisch)“ verschoben: platz machen für aktualisierte Version von Coolcat.

2009-02-03T20:34:07Z

hat „Shader“ nach „Shader (historisch)“ verschoben: platz machen für aktualisierte Version von Coolcat.

I0n0s: /* Programme/Tools */

2007-05-28T21:04:51Z

‎Programme/Tools

DGLBot: Bot: konvertiere/korrigiere

2006-04-22T18:16:05Z

Bot: konvertiere/korrigiere <BR>

Flash: /* Informationen */

2006-03-01T00:18:55Z

‎Informationen

La Boda: /* Funktionen */

2005-11-12T13:30:24Z

‎Funktionen

129.206.104.235: /* Konzept */

2005-06-14T14:42:13Z

‎Konzept

147.172.19.249: /* Konzept */

2005-05-26T09:11:18Z

‎Konzept

Flash: /* Konzept */

2005-02-20T11:35:38Z

‎Konzept

← Nächstältere Version		Version vom 21. März 2012, 14:41 Uhr
Zeile 10:		Zeile 10:
	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).		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 ~~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.	+	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.

@@ Zeile 6: / Zeile 6: @@
 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.
+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.
-Hiessen 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).
+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 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.
@@ Zeile 24: / Zeile 24: @@
 == Extensions ==
 <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.
-<li>[[GL_ARB_Vertex_Shader]]</li>
+<li>[[GL_ARB_vertex_shader]]</li>
 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.
-<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.
 </ul>
@@ Zeile 52: / Zeile 52: @@
 == Funktionen ==
-<ul>
+*[[glAttachObjectARB]]
-<li>[[glAttachObjectARB]]</li>
+*[[glBindAttribLocationARB]]
-<li>[[glBindAttribLocationARB]]</li>
+*[[glCompileShaderARB]]
-<li>[[glCompileShaderARB]]</li>
+*[[glCreateProgramObjectARB]]
-<li>[[glCreateProgramObjectARB]]</li>
+*[[glCreateShaderObjectARB]]
-<li>[[glCreateShaderObjectARB]]</li>
+*[[glDeleteObjectARB]]
-<li>[[glDeleteObjectARB]]</li>
+*[[glDetachObjectARB]]
-<li>[[glDetachObjectARB]]</li>
+*[[glEnableVertexAttribArrayARB]]
-<li>[[glEnableVertexAttribArrayARB]]</li>
+*[[glGetActiveAttribARB]]
-<li>[[glGetActiveAttribARB]]</li>
+*[[glGetActiveUniformARB]]
-<li>[[glGetActiveUniformARB]]</li>
+*[[glGetAttachedObjectsARB]]
-<li>[[glGetAttachedObjectsARB]]</li>
+*[[glGetAttribLocationARB]]
-<li>[[glGetAttribLocationARB]]</li>
+*[[glGetHandleARB]]
-<li>[[glGetHandleARB]]</li>
+*[[glGetInfoLogARB]]
-<li>[[glGetInfoLogARB]]</li>
+*[[glGetObjectParameterARB]]
-<li>[[glGetObjectParameterARB]]</li>
+*[[glGetShaderSourceARB]]
-<li>[[glGetShaderSourceARB]]</li>
+*[[glGetUniformARB]]
-<li>[[glGetUniformARB]]</li>
+*[[glGetUniformLocationARB]]
-<li>[[glGetUniformLocationARB]]</li>
+*[[glGetVertexAttribARB]]
-<li>[[glGetVertexAttribARB]]</li>
+*[[glGetVertexAttribPointervARB]]
-<li>[[glGetVertexAttribPointervARB]]</li>
+*[[glLinkProgramARB]]
-<li>[[glLinkProgramARB]]</li>
+*[[glShaderSourceARB]]
-<li>[[glShaderSourceARB]]</li>
+*[[glUniformARB]]
-<li>[[glUniformARB]]</li>
+*[[glUseProgramObjectARB]]
-<li>[[glUseProgramObjectARB]]</li>
+*[[glValidateProgramARB]]
-<li>[[glValidateProgramARB]]</li>
+*[[glVertexAttribARB]]
-<li>[[glVertexAttribARB]]</li>
+*[[glVertexAttribPointerARB]]
-<li>[[glVertexAttribPointerARB]]</li>
@@ Zeile 87: / Zeile 86: @@
 == Ressourcen ==
 === Informationen ===
-<ul>
+*[http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf Official OpenGL 2.0 Specifications] (Englisch)
-<li>[http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf Official OpenGL 2.0 Specifications] (Englisch)</li>
+*[http://www.opengl.org/documentation/oglsl.html Offizielle GlSlang-Dokumentation] (Englisch)
-<li>[http://www.opengl.org/documentation/oglsl.html Offizielle GlSlang-Dokumentation] (Englisch)</li>
+*[http://developer.3dlabs.com/openGL2/index.htm Offizielle OpenGL2/OpenGL HLSL-Seiten] (Englisch)
-<li>[http://developer.3dlabs.com/openGL2/index.htm Offizielle OpenGL2/OpenGL HLSL-Seiten] (Englisch)</li>
+*[[DGLOpenGL.pas|OpenGL-Header für Delphi (mit GlSlang-Extensions)]]
-<li>[[DGLOpenGL.pas|OpenGL-Header für Delphi (mit GlSlang-Extensions)]]</li>
+*[[Tutorial glsl|GLSlang-Tutorial auf DGL]] (Deutsch)
-<li>[[Tutorial glsl|GlSlang-Tutorial auf DGL]] (Deutsch)</li>
+*[http://www.clockworkcoders.com/oglsl GlSlang Tutorials] (Englisch)
-<li>[http://www.clockworkcoders.com/oglsl GlSlang Tutorials] (Englisch)</li>
+*[http://www.shadertech.com/ ShaderTech - GPU Programming] (Englisch)
-<li>[http://www.shadertech.com/ ShaderTech - GPU Programming] (Englisch)</li>
+*[http://nehe.gamedev.net/data/articles/article.asp?article=21 NeHe GLSL Introduction] (Englisch)
-<li>[http://nehe.gamedev.net/data/articles/article.asp?article=21 NeHe GLSL Introduction] (Englisch)</li>
+*[http://www.3ddrome.com/articles/cgshaders.php Cg Pixel Shaders in OpenGL] (Englisch)
-<li>[http://www.3ddrome.com/articles/cgshaders.php Cg Pixel Shaders in OpenGL] (Englisch)</li>
-</ul>
 === Programme/Tools ===

@@ Zeile 100: / Zeile 100: @@
 === Programme/Tools ===
-<ul>
+*[http://www.typhoonlabs.com/ OpenGL-Shaderdesigner von Typhoon Labs]
-<li>[http://www.typhoonlabs.com/ OpenGL-Shaderdesigner von Typhoon Labs]</li>
+*[http://www.weeselsoftware.tgaraas.com/shaderNinja.html Shader Ninja von Weesel Software]
-<li>[http://www.weeselsoftware.tgaraas.com/shaderNinja.html Shader Ninja von Weesel Software]</li>
+*[http://mirror.ati.com/developer/sdk/radeonSDK/html/Tools/RenderMonkey.html ATIs RenderMonkey]
-<li>[http://mirror.ati.com/developer/sdk/radeonSDK/html/Tools/RenderMonkey.html ATis RenderMonkey] (OpenGL-Version momentan noch nicht öffentlich zugänglich)</li>
+*[http://developer.nvidia.com/object/sdk_home.html nVidias SDK] (Beinhaltet diverse GlSlang-Beispielanwendungen/Shader)
-<li>[http://developer.nvidia.com/object/sdk_home.html nVidias SDK] (Beinhaltet diverse GlSlang-Beispielanwendungen/Shader)</li>
+*[http://www.gpgpu.org/ GPGPU - General-Purpose Computation Using Graphics Hardware]

@@ Zeile 12: / Zeile 12: @@
 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 ==
@@ Zeile 19: / Zeile 20: @@
 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 ==
 <ul>
@@ Zeile 32: / Zeile 34: @@
 </ul>
-<br>
 == Alternativen ==
 === Vertex- und Fragmentprogramme ===
@@ Zeile 46: / Zeile 49: @@
 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]].
-<br>
 == Funktionen ==
 <ul>
@@ Zeile 78: / Zeile 82: @@
 </ul>
-<br>
 == Ressourcen ==

@@ Zeile 86: / Zeile 86: @@
 <li>[http://www.opengl.org/documentation/oglsl.html Offizielle GlSlang-Dokumentation] (Englisch)</li>
 <li>[http://developer.3dlabs.com/openGL2/index.htm Offizielle OpenGL2/OpenGL HLSL-Seiten] (Englisch)</li>
-<li>[http://www.delphigl.com/do_download.php?f=12000 OpenGL1.5-Header für Delphi (mit GlSlang-Extensions)]</li>
+<li>[[DGLOpenGL.pas|OpenGL-Header für Delphi (mit GlSlang-Extensions)]]</li>
-<li>[http://www.delphigl.com/script/do_show.php?name=glslang&action=2 GlSlang-Tutorial auf DGL] (Deutsch)</li>
+<li>[[Tutorial glsl|GlSlang-Tutorial auf DGL]] (Deutsch)</li>
 <li>[http://www.clockworkcoders.com/oglsl GlSlang Tutorials] (Englisch)</li>
 <li>[http://www.shadertech.com/ ShaderTech - GPU Programming] (Englisch)</li>

← Nächstältere Version	Version vom 3. Februar 2009, 20:34 Uhr
(kein Unterschied)

@@ Zeile 2: / Zeile 2: @@
 == 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 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 nVidia GeForce-Karten)
+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)
 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.