* The converter program will be able to open old captures, but is itself
captureable in new renderdoc builds. This isn't a direct conversion
but should allow a reasonable estimation and is better than nothing.
* NOTE: The resulting converted file will have no thumbnail, and no
callstacks (if they were present before). As well as more minor things
like backbuffers no longer appearing identified as backbuffers, some
markers losing their colours, etc.
* There's a weird issue on mesa where copying between a texture with
unsized format GL_RGBA and sized format GL_RGBA8 fails. The workaround
is to promote to sized format immediately, which changes the behaviour
slightly but as ever the unsized formats are explicitly ambiguous, so
we're within our rights (as part of the GL implementation so to speak)
to change it.
* If no swapchains have been created the debug manager won't be ready,
so we need to ensure it's initialised here so we can use it during
initial state preparation.
The "files" system expects other files to be #included, which won't make
sense for GLSL sources, which are expected to be concatenated. Use the
concatenated string as a single "main.glsl" file.
* In some cases there was an unpredictable crash when starting a replay
loop, doing a full frame replay immediately after a previous replay.
There were no debug messages, and the debug layer fixed it - as did
enabling single flush validate. It seems to me some timing/overloading
issue, and doing this sync should be relatively harmless so we use
this to avoid the crash.
* Technically the resolve doesn't allow format conversion at all, so
instead of resolving directly to the swapchain image we need a middle-
man image of the same format as we use internally for the MSAA target
(RGBA8_SRGB) to resolve to, then blit from that to the actual
backbuffer.
* ARB_texture_view only works on textures allocated with
ARB_texture_storage so we have to check for both extensions and then
use texture storage to allocate space for the destination array
texture.
* For now, resource replacement implicitly means shader edits, but other
replacements could also affect the results of PostVS (e.g. buffer or
state changes). Trying to capture all this state in the cache key is
not very useful.
* The PostVS cache will be re-filled immediately after, as any
replacement does a force-refresh of the current event.
* AMD reports image required sizes with some variation even for the same
creation parameters. This can mean the same image is reported with
less required size during capture compared to replay, meaning memory
binds won't work.
* To get around this, we pad up the requirements to alignment * 4 and
fudge to try and encompass any possible variation.
* This can happen if the resource was not included in the capture, but
there was a descriptor passed (i.e. not NULL desc which is handled
separately) which specifies some parameters, but leaves the format
as UNKNOWN.
baldurk