* D3D12 math shader was already precompiled, but on D3D11 we now allocate
everything up front and on D3D12 we also up-front compile sampling.
* The only exception is const offsets which can't be variable, so we cache these
(likely we'll only see a few variants per shader/capture) and create them on
demand.
* Most of the main entry points that can fail with relevant reasons now has a
way of specifying a message to return with it. This message can be displayed
to the user to give more information or context about an error.
* 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.
* The UI will become non-functional and the backend will be replaced with a do-
nothing one that keeps things alive without needing error bulletproofing
everywhere in the real backend.
* This prevents unnecessary conversions back and forth between rdcstr and const
char * when going through interfaces. In the OS specific layer this is rarely
an issue because most of the implementations don't convert to rdcstr, but it
is convenient to be able to pass in an rdcstr directly. The few cases where
there's an unecessary construction of an rdcstr is acceptable.
* A couple of places in the public API need to return a string from a global
function, so can't return an rdcstr due to C ABI, so they still return a const
char *.
* Similarly const char * is kept for logging, to avoid a dependency on rdcstr
and because that's one place where unnecessary conversions/constructions may
be impactful.
* For certain very large arrays it can be nice to defer generation of structured
data until it's needed, since often maybe only a handful of elements may be
needed (or commonly none at all).
* 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
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.
* Using <Copy> forcibly copied every build which means if the program is running
a build will fail. Using <Content> will only copy if the file doesn't exist
(so after the first build, it won't try to copy and fail).
- 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
* This allows persistent config storage and registering tweak variables that
works independent of the UI's configuration.
* Config vars can be debug only, which means they will be compiled out in stable
version releases. This allows for debug-logging tweaks that are available in
all builds (including nightly builds) for diagnostic purposes, but have zero
overhead in stable releases.
* Variables have a loose hierarchy defined with _ or . to separate nodes.
* Mostly moving includes from common headers to cpp where possible, and removing
includes of the whole thing where only enums or rdcstr etc are needed.
* rdcstr no longer inherits from rdcarray, it implements all functionality
itself.
* There are now three representations:
- Heap-allocated, same as how rdcarray behaves.
- Local-allocated, for small strings we store them in a union array.
- Compile-time literal, only created from user-defined literals.
* The main observation is that a lot of RenderDoc's strings are compile-time
literals either from struct names, member names, or stringified enum values.
Storing these directly and allowing them to be moved and copied quickly saves
on allocations and time. When the string is modified, it's copied to one of the other formats.
* Split up old uber-cbuffers used for unrelated shaders into shader-specific
cbuffers (DebugPixelCBufferData -> TexDisplayPSCBuffer / CheckerboardCBuffer /
MeshPixelCBuffer).
* Split up HLSL files so not everything is lumped into 'debugdisplay.hlsl' but
has separate files as appropriate.
* Use #include in GLSL and HLSL to better organise shader code together rather
than relying on lumping files together on the C++ side.
* Renamed files like 'debugcbuffers.h' to 'hlsl_cbuffers.h'.
* Trimmed out some extensions/cruft that isn't needed in the GLSL side since we
no longer use separable shaders.
* Combine some shaders like Outline/Checkerboard that were similar into central
place.
baldurk