Consider how to use GL_EXT_spirv_intrinsics to define future extensions

[Tobski]

Now that https://github.com/KhronosGroup/glslang/pull/2625 has landed, we'd like to be able to use it to define GLSL extensions in GLSLang without having to actually change the underlying code. As demonstrated in the registry PR (https://github.com/KhronosGroup/GLSL/pull/157), some extensions can be entirely defined using a "header" file with a bunch of #defines and typedefs. It would be good if we could figure out how to modify GLSLang to make including these headers as simple as possible.

A few options we've considered while bringing this up:

• Hardcoding the headers into glslang and making it look at them during initial parsing
• Implementing the GL_GOOGLE_include_directive directly in GLSLang
• Adding include directories as command line arguments to glslang

Other open questions:

• How should this interact with the existing "#extension" directive - should enabling an extension include its header?
• Should we get any existing extensions ported to this new way of working?
  • Trying to go back and tackle all of them might be overkill, but we likely at least want to do some to test the new interfaces
• Should we try to get "partial" headers working, where some parts can be done as headers, but others can't?
  • e.g. Memory model or ray tracing

[Tobski]

CC @amdrexu @greg-lunarg

[amdrexu]

A few options we've considered while bringing this up:

Hardcoding the headers into glslang and making it look at them during initial parsing Implementing the GL_GOOGLE_include_directive directly in GLSLang Adding include directories as command line arguments to glslang

I would like to vote for adding the GLSL headers in a directory of GLSLang with the release of new extensions and conditionally loading them into the parser during initialization for further token scanning.

How should this interact with the existing "#extension" directive - should enabling an extension include its header?

The header will be included unless we declare #extension GL_EXT_spirv_intrinsics in the shader.

Should we get any existing extensions ported to this new way of working?

This depends on the complexity of the existing extensions. Some simple extensions could be good candidates. But I think such porting is just to find latent issues of implementation. Actually, there is no enough motivation for existing users to rewrite their shaders that use those extensions with this new usage style.

Should we try to get "partial" headers working, where some parts can be done as headers, but others can't?

This could be a solution for complex extensions. But also bring some disorder of the usages.

[greg-lunarg]

FWIW, I am generally open to utilizing this new mechanism to actually implement extensions.

I am also open to additional tool options to allow for easier prototyping.

I am not familiar with GL_GOOGLE_include_directive and, ironically, googling it didn't find the definition. I would like to know a little more about this before anyone did any implementation.

I am not sure I am interested in re-implementing extensions that are already implemented, unless there is a real compelling justification.