GLSL language integration
Download this extension from the VS Gallery
or get the CI build.
VSIX Project that provides GLSL language integration.
Includes syntax highlighting, code completion (OpenGL 4.6 + identifiers in shader file), error tagging with squiggles and in error list (error list support is very alpha). As a default for error tagging a separate OpenGL thread is used for shader compiling on the primary graphics card. In the options menu you can select an external compiler executable to use for shader compilation.
See the change log for changes and road map.
- Syntax highlighting (default file extensions:
rcall) Set color under Options (Fonts and Colors)
- Code completion (OpenGL 4.6 keywords + all identifiers in shader file)
- Error tagging with squiggles and in error list (error list support is very alpha)
- For the file extension
glsl the extension tries to auto detect the type of shader you use based on reserved words used in the shader code.
- Note that
GLSL_NV_ray_tracing shader types support for error tagging is currently only provided via an external compiler (like
- Note that support for Vulkan shader types is currently only provided via an external compiler (like
- Auto-detection of shader stage: If you use the
glsl file extension the source code is searched for keywords only used in certain shader stages.
- Configurable (file extensions, code compilation, highlighting style, compiler)
- Controlling the extension with comments (see below)
Configuration (extension options)
- Options of the extension can be found via the Visual Studio options dialog (
glsl language integration).
- Configure Fonts and Colors via "Environment" -> "Fonts and Colors"). All "Display Items" of the extension start with GLSL.
The original idea is from Clocktown. The discussion can be found under #15.
When developing shaders, it is common to split one shader into multiple files, reuse files, and generally generate some parts of code in the application in order to make things easier.
Unfortunately, this does not go well with extensions like this that compile these files without any knowledge about what happens on the side of the application. One way around this are special comments
//? that are transformed into code before compiling.
//! #version 430
//! #define WORK_GROUP_SIZE 32
#include "/utils.glsl" //! #include "../include/utils.glsl"
#define WORK_GROUP_SIZE 32
Everything in the line in front of the
//! is removed and replaced by the code in the comment.
//! is always expanded to code, while
//? is only expanded if the file being compiled has not been included, e.g.:
//? #version 430 // Only expanded if this file is compiled directly, not when included in B.glsl
// Lots of utility functions
//! #version 430
#include "/utils.glsl" //! #include "A.glsl"
In the option menu you can set a file path and arguments to an external compiler. If an existing path is given compilations will be executed by starting the given executable. You can use environment variables, like
%SystemDrive% in your arguments and path. The shader code (including include code and all substitutions) will be written into a temporary file named "shader.vert|frag|comp|..." (extensions follow glslangValidator standard) in the current users temp path. This temporary shader file is then used as the first argument to the external compiler executable.
Errors and questions
Please us the GitHub Issue function to report errors or ask questions.
Check out the contribution guidelines
if you want to contribute to this project.
For cloning and building this project yourself, make sure to install the
Extensibility Tools 2015
extension for Visual Studio which enables some features used by this project.