GL_ARB_shading_language_include not supported but GL_GOOGLE_include_directive is

[karyon]

code like this

#extension GL_ARB_shading_language_include : require

#include </foo/bar.glsl>

gives me these errors

ERROR: 0:2: '#extension' : extension not supported: GL_ARB_shading_language_include
ERROR: 0:4: '#include' : required extension not requested: GL_GOOGLE_include_directive

may i ask why the ARB extension is not supported? #37 talks about this but the reasoning was not clear to me.

[AWoloszyn]

The answer here is two-fold. The the answer to why GL_GOOGLE_include_directive is supported is because Google provided the support.

The second and perhaps more subtle is that GL_ARB_shading_language_include, as written, cannot be validated offline using glslangValidator, it is inherently a run-time extension.

    Arbitrary strings may be defined and given names. These strings can
    be included by name in shaders during compilation, allowing reuse of
    the same code segments. A string and its name are specified
    with the command

        void NamedStringARB(enum type, int namelen, const char *name,
                            int stringlen, const char *string)

There are 2 options on what could be done if an #include directive is found.

1. Provide some mechanism for resolving includes, using -I directives for example, or through a library API if this is being done online. This might work, but is arguably NOT "GL_ARB_shading_language_include", since even a shader that passes validation may not be valid at runtime (if you configure NamedStringARB differently than how glslang chose to handle paths).
2. In the presence of an #include directive assume that the entire shader after that point is valid, since the entire semantics of the language could be changed in an #include file. #define if for

[ghost]

How I can use including?

[AWoloszyn]

If you are using glslangValidator, it is not supported currently. If you are integrating the library into your own program to compile shaders on the fly, then you can provide an "Includer" to glslang during compilation, which gets callbacks when files are opened.

Another option, if either a) you want to use command-line processing, or b) you would like a much simplified interface for inclusion is to use shaderc, which is a wrapper around glslang. https://github.com/google/shaderc

The command-line tool glslc provides a gcc/clang type interface that has #include support as well as a handful of other features. "libshaderc", the library version also supports #includes with a simlified interface as well.

[ghost]

My Windows can't build any Android/Unix tools, even if declared "Windows".

[AWoloszyn]

Shaderc should build just fine on windows, (We build it regularly using both VS2015 and Mingw) the only dependency is cmake. But otherwise if building it is not feasable, there is a prebuilt version distributed with the android ndk at. https://github.com/android-ndk/ndk/wiki

[johnkslang]

The key missing functionality here is glslang implementing the ARB include extension, which could be done.

Let's keep this issue about adding that functionality to glslang.

[cleak]

Is anyone actively working on this? I'll put together a pull request assuming there's no conscious decision to avoid it. The tricky part seems to be providing a useful interface to NamedStringARB. Doing this via individual named strings like "-n < filepath >" conforms with ARB_shading_language_include, but is rather tedious for the user. Also having some sort of "-I " like @AWoloszyn mentioned seems like a good compromise.

[johnkslang]

Since all but the last comment were written, I added "normal" include to glslang proper. This includes, from the usage statement:

-I<dir>     add dir to the include search path; includer's directory

I don't think anyone is implementing GL_ARB_shading_language_include.

[enci]

Is it possible to get an example of how to use this. I keep getting: ERROR: 0:4: '#include' : Could not process include directive for header name: SomeHeader.h

My shader code is: #version 430 core #extension GL_GOOGLE_include_directive : require #include "SomeHeader.h"

I provide the search directory as such: C:\Users\username\Developer\glslang\bin\glslangValidator.exe -I"C:/Users/username/Documents/Games/Blast/Blast/Assets/Shaders/Include" AlienBlob.frag

[tatsy]

Is there any examples for the file configuration to use #include directive? I came across the same problem with @enci.

[bensmooth]

Ended up here looking to do the same thing - this works for me when targeting Vulkan:

ShaderMain.vert

#version 450
#extension GL_GOOGLE_include_directive : require
#include "MyLayout.glsl"
void main()
{
    gl_Position = vec4(Position, 0, 1);
}

MyLayout.glsl

layout(location = 0) in vec2 Position;

Then:

glslangValidator.exe ShaderMain.vert -I<Path-to-my-includes> -V -o out.spv

[ncesario-lunarg]

If this extension were to be implemented in glslang, I'm not sure how its behavior could be different (if not the same) as the way GL_GOOGLE_include_directive currently operates. What would be the desired behavior if this extension were supported in glslang? Or perhaps a better question is: does anyone still want/need support for this extension in glslang?