It works this way:
The GameEngine stored the original shader blob on disk.
Than we add the path to that file to the D3D_BLOB_PRIVATE_DATA section of the shader blob.
After that we can strip the Debug information with D3DCOMPILER_STRIP_DEBUG_INFO.
Renderdoc will first check if the shader already has debug information.
If it cannot find the PDB in the shader blob it will try to look for a PrivateDataSection.
If there is a valid file path in the PrivateDataSection it will search for debug information in there.
If it finds valid debug information it will replace the entire shader blob with the one loaded from disk.
* For e.g. the text rendering we only actually use a subset of the
buffer range each time - just enough for the characters we are
rendering. But we need to be careful that the range specified by the
descriptor set (256 float4s) is always valid, so wrap around on that
size and not on the parameter size
* This fixes a problem where removing "redundant" glUseProgramStages
chunks actually removed other chunks that were legitimate.
* It's kind of hacky, but it's better than the other alternatives.
* When I went to explain to someone why the target was named Profile and
not Debug as you might expect, I realised the reasons were entirely
opaque and historical. So instead, rename it to Development since that
is really what it's for - any profiling would be done in Release mode.
* The main motivation for this is because it's convenient to be able
to just assert a simple expression rather than print a proper error
message, but then after the fact you want to know what the value was
(e.g. a return code, or similar).
* On balance I think this does more harm than good. The idea was to make
sure errors don't get ignored when running in profile, but really all
it did was mean people trying to debug renderdoc without much
familiarity got confused as to why things crashed suddenly.
* Based on renderdoc branch with local modifications from upstream:
https://github.com/baldurk/glslang/tree/renderdoc
* hash bba704293106428f6063ba0a3fa7802e8f413def on renderdoc from
5184353326ae52d63a1d7c7fccd66269aab768f7 on master
* It's legal to free memory while still mapped and this should be
handled, so here we clean up any mapped state that's present when
destroying a memory resource record.
* Based on renderdoc branch with local modifications from upstream:
https://github.com/baldurk/glslang/tree/renderdoc
* hash 0011d911d67ea3c029a11010ba6f20bbe5149ebc on renderdoc from
103bef9d74d768f0690ed53f52681baead384d1e on master
