* This reports the struct vartype now, ensures that struct sizes are always
reported and alignments are respected, along with some other fixes to more
accurately report memory layouts of structs.
* Newly written shaders and any updated shaders can now use pre-defined macros
to abstract away binding differences between APIs, so custom shaders will be
more portable in particular shaders written in HLSL for D3D or GLSL on OpenGL
won't break on vulkan because they refer to incorrect binds.
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>
* Previously the vertex picking was always being done in NDC space, but now for
perspective projections we unproject into world space and raycast there for
more reliable results with unsual projections.
* When using VS In we want to ignore the W component, but that already happens
explicitly for vulkan/GL in the shader. Mirror that same solution to D3D
instead of trying to force a 3-component format which may not be supported
(e.g. on AMD R16G16B16_*)
* When displaying mip 0 of a texture at less than 100% zoom we linear sampling,
but we don't want to linear sample across slices. Adding a half pixel offset
in z ensures we sample precisely on the slice itself.
* This helps catches cases where a discarded image is accidentally used and in
many cases may still have valid data. Particularly on Vulkan this is relevant
for DONT_CARE renderpass load and store ops.
* This is needed because D3D12 requires all shaders in a pipeline to use DXIL if
any do.
* We try to bake the couple of DXIL shaders that we will mix-and-match with
application shaders at build time, in case we aren't able to find a working
dxcompiler at runtime to build them. But this can only happen if we find a
working dxc.exe in one of the windows 10 SDKs.
- Separate the pixel history copy pixel shader into two separate
shaders, one for colour copy and one for depth
- Allocate and update descriptor sets on demand
- Add another compute shader for pixel history depth copy
* We change to use VarType instead of CompType for signature parameters which
allows us to represent different types of variables beyond just
unsigned/signed integer and float.
Use a separate compute shader module for MSAA copy, and output
directly into the destination buffer instead of creating
staging resources.
Support case where there is no depth stencil attachment to get post mod
values in per fragment reporting. Previously used the original
framebuffer that might not have had depth/stencil view, so couldn't
count the fragments. Now use the sub image.
To get the post mod color, we need to blend with the premod color, so
we use vkCmdCopyImage to copy from the original image.
Colour only, depth/stencil copy not supported.
This means that we only report pre-mod and post-mod colour values for
events. Since stencil copy is not supported, number of fragments is
not reported, and shader output is not queried.
- Refactor to use common funcs
- Add per fragment depth data
- Rename pixelhistory.frag to pixelhistory_primid.frag
- Fix how some per fragment pipelines are created
For per fragment data we create 3 pipelines
1) Post modification pipeline
changes the stencil state and scissors around the target pixel
2) Shader output pipeline
in addition to above, disables rasterization discard, depth bounds test,
culling and turns off blending
3) Primitive ID pipe
in addition to above, disables depth test and depth write, and changes
the fragment shader to only output primitive ID
* We instead always have 3rdparty/ in the relevant include search paths and rely
on that. Each library still has its own unique base dir within 3rdparty to
clarify where the include is coming from.
baldurk