Ref: https://github.com/KhronosGroup/glslang/issues/2872
Ref: https://github.com/KhronosGroup/glslang/commit/81cc10a498b25a90147cccd6e8939493c1e9e20e
After discussions with the glslang developers, it appears that the
parameters in glslang's setEnvInput() function are a bit more geared
towards SPIRV that the documentation implied.
After the glslang commit above, and discussions with the developer, it
seems that the 3rd parameter to setEnvInput() should only be set to
EShClientOpenGL if you want to enable the ARB_gl_spirv extension.
The 4th parameter to setEnvInput() is version, but it is used to
indicate the version of either the KHR_vulkan_glsl extention for
vulkan, or the ARB_gl_spirv extension for OpenGL with SPIR-V.
So, if the shader type is neither ShaderType::Vulkan, nor
ShaderType::GLSPIRV, we should specify glslang::EShClientNone for the
3rd parameter and 0 for the 4th parameter of setEnvInput().
This doesn't actually impact renderdoc with the currently bundled
glslang 8.13.3743, because they failed to pass the environment through
during pre-processing.
But, this changed in this glslang commit in 11.2.0:
* 6274ec5c ("Pass environment through PreprocessDeferred")
* https://github.com/KhronosGroup/glslang/commit/6274ec5c
After this change, renderdoc passes the environment through to the
pre-processor, and with the current parameters to setEnvInput(),
glslang will start to define GL_SPIRV in the shaders during
pre-processing.
Then, in renderdoc's glsl_globals.h, GL_SPIRV causes the pre-processor
to set:
* #define IO_LOCATION(l) layout(location = l)
which then causes Mesa to produce this error when compiling the shader:
* GL_VERTEX_SHADER compile error: 0:239(2): error: shader output
explicit location requires GL_ARB_separate_shader_objects extension
or GLSL 4.20
Signed-off-by: Jordan Justen <jljusten@gmail.com>
* Device layers are deprecated and should not be enabled, if the application
does so then we may think different extensions are available. Instead just
explicitly use the list of layers from the instance.
* If the application supports >= SM6.6 then we would previously unconditionally
just clamp to SM6.6. However we also need to let the driver clamp in case it
only supports SM6.5 or older
* Fastest replay optimisations mean applying all optimisations but we can't
break the ability to debug - without patching this, using DONT_CARE on store
might mean we can't inspect renderpass contents from part-way through. Even
partially replayed they can be discarded by the driver if the store op is
still DONT_CARE
* Buffers are always treated as 'read' even if they're written because only
sparse buffers have initial states and become dirty. The memory behind the
buffer is instead the thing that is treated as written.
* When we see a descriptor copy during a frame capture we force the source
descriptor set to be included since it may never be bound to a command buffer,
but it may also be deleted so instead we AddRef the record to keep it alive
and store the id & record directly.
* This means if you're closing multiple connections and click 'no to all' when
prompting save of instead of discarding just the captures in that connection
then going on to prompt for the next, it discards all remaining captures.
* This is perfectly legal, the spec constant data provided in the pipeline is
just ignored. It's only a problem if this indicates some RenderDoc bug
matching up the constant IDs.
Jordan Justen