* For the most part we implement this as a thin pass-through layer. Where we
care about things (image barriers for layout transitions and queue
submissions) we do two different things:
- For image barriers, we "downcast" to plain VkImageMemoryBarrier. Currently
the only thing that's unique to VkImageMemoryBarrier2KHR is extra access
flags and pipeline stages, which we don't care about. This keeps a lot of
code from having to either handle two paths or handle the new path and then
do lots of conversions back to VkImageMemoryBarrier when running on older
drivers.
- For queue submissions we do the opposite. We promote old VkSubmitInfo to
VkSubmitInfo2KHR and process that in a common function, then if necessary
we decay back to VkSubmitInfo before sending to the driver.
* We can't yet whitelist this for shader debugging because we don't properly
support the aliasing behaviour - each workgroup variable has its own separate
storage, we need to treat them like SSBO pointers into the same buffer and
automatically size it large enough for all of them.
* Note the sync2 structs aren't properly sorted in vk_next_chains.cpp because
I'm about to implement it and I'm too lazy to insert them in the right places
only to go find them all again to remove them.
* DXGI sometimes seems to return DXGI_INVALID_CALL when retrieving backbuffers.
In this case we want to gracefully handle it instead of crashing and hope it
will fix itself next time we try.
* This isn't something we generally want to support (@123 should be a separate
word) and it can come up with shader names like `shader@0x12345` as well as
with icon@2x.png
They're now drawn as CE_StyledFrame controls, with either HLine or VLine
shape as appropriate for the orientation of the line. This will go into
RDStyle when the light or dark UI theme is selected, allowing appropriate
colors to be used.
* We use ptrace to detect child processes reliably, but that makes us look like
a debugger to the child. * There isn't a reliable and simple way to pass down
a PID to ignore (environment variables are the only simple option I can see,
and they can't be reliably inherited, ptrace to poke data would require lots
of work to figure out _where_ to poke that data).
* So instead we use a semi-heuristic - if the debugger PID is found but it
contains executable pages mapped from librenderdoc.so assume we're still being
ptrace setup'd, and check again next time we want to know if a debugger is
connected.
sebastianpick
