Shader (historisch): Unterschied zwischen den Versionen

Aus DGL Wiki
Wechseln zu: Navigation, Suche
K (=Konzept=)
K (=Konzept=)
Zeile 3: Zeile 3:
 
== 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 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)
+
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 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, 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.
Zeile 9: Zeile 9:
 
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.
 
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).  
+
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.
 
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.

Version vom 13. Juli 2004, 19:14 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 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.

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.


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


Funktionen


Ressourcen

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