Core Language (GLSL)

From OpenGL.org
Revision as of 14:28, 19 March 2011 by Alfonse (Talk | contribs) (Partial update.)

Jump to: navigation, search

The OpenGL Shading Language is a C-style language, so it covers most of the features you would expect with such a language. Control structures (for-loops, if-else statements, etc) exist in GLSL, including the switch statement. This section will not cover the entire language in detail; the GLSL specification can handle that. This page will will note the differences between GLSL and C.

Compilation settings

The OpenGL Shading Language requires certain information to be presented early in a shader object's compilation. In a command-line-based compiler, these would be compiler settings. GLSL's compilation model instead requires them to be part of the language.

These should be in the first lines of the first string associated with a shader object. If you want to globally apply these, then you should put them in a string that you then put at the beginning of every shader object's string block.

Version

The OpenGL Shading Language has gone though a number of revisions, some of them quite substantial. As part of the OpenGL Specification, a version of OpenGL is required to support one or more specific versions of GLSL. It may optionally support more.

To specify which version of GLSL should be used, use this directive:

 #version 1.50

This would tell the compiler to compile for version 1.50, or error if that version is not available.

The version number can be followed by the profile name. This can be core or compatibility. If this is not specified, the default is core.

The #version directive must appear before anything else in a shader, save for whitespace and comments.

Extensions

Many OpenGL Extensions modify GLSL's behavior and functionality as well. Unlike regular OpenGL, where extensions are implicitly always there whether you use it or not, GLSL extensions must explicitly be specified in the particular shader string being compiled.

Similar to the #version directive, the user can activate specific extensions with the "#extension" directive. The syntax is as follows:

 #extension extension_name : behavior

The "extension_name" can also be the string "all". This means it works for all extensions. The available behaviors are:

  • enable: Causes the named extension to work; if the implementation does not support the extension, it only gives a warning. Fails if used with "all".
  • require: Causes the named extension to work; if the implementation does not support the extension, it fails. It also fails if used with "all".
  • warn: Causes the named extension to work; however, using the extension will emit warnings. If used with "all", then the use of any extensions will emit warnings.
  • disable: Prevents the named extension from working at all. Thus, any use of it will be seen as undefined syntax and cause an error. If used with "all", then this prevents any extensions from working.

You should put these definitions before any other language features, but before .

Preprocessor directives

All of the keywords beginning with # are preprocessor directives, much like with C. GLSL provides most of the standard C set of preprocessor directives (#define, #if, etc), in addition to the ones listed above. The most notable omission is #include.

Macro expansion does not work on #version and #extension directives.

Standard macros

GLSL defines a number of macros. __FILE__ is not a filename; it is a decimal integer representing which string in the list of strings given to the shader. __LINE__ is the line number. __VERSION__ is a decimal integer representing the GLSL version being compiled. If the version is 3.30, then __VERSION__ will be "330".

The macro GL_core_profile is always defined to be "1". The macro GL_compatibility_profile is only defined to be "1" if the version for this shader was set to be compatibility.