* If a buffer has been marked as dirty mid-frame but wasn't dirty at the start
of the frame then it won't have initial contents. We have to treat it as if it
wasn't dirty and fall back to using our existing data for it, assuming that is
a valid way to pre-populate the map's shadow buffer.
* This seemed to cause crashes on some systems as libproxy links to libstdc++
and can then cause symbol conflicts between the static libstdc++ and the
system's libstdc++.
* libproxy itself cannot be statically linked, so the solution is either to
configure Qt without libproxy and break anyone who needs proxy support, or
stop statically linking libstdc++ and add a new dependency. At commit time
most distributions have at least g++-5's libstdc++ in their minspec so we can
require that - the main two that seem to fall short are Debian Jessie and
CentOS 7. Users on those systems will have to install a newer libstdc++ or
compile from source rather than using the binary releases.
* Even if a function isn't passed a global binding array as a parameter, we
still need to patch it in order to find any accesses it makes directly to
global resources just as we do in the entry point.
* We can't rely on the driver's reflection, since name information might be
stripped and the driver is within its rights to not reflect anything even if
we have names. Similarly queries by names etc will not work.
* Also we can't try to change bindings that are immutable on SPIR-V shaders -
UBO/SSBO bindings, transform feedback varyings, attrib and fragdata locations.
* Programs can't mix and match SPIR-V and GLSL, so when including our own
shaders in the overlay program make sure they match what the user's shaders
are.
* For mesh output, we need to patch the SPIR-V if it's a SPIR-V shader instead
of trying to use the GL XFB varyings set.
* Instead of patching e.g. PRESENT to GENERAL early, we keep the 'real' layout
even if that's UNDEFINED or PRESENT or whatever. We then do a last-second
patchup whenever we're actually transitioning images in vulkan itself, to set
the right layout.
* This requires us to do the patching in a few more places - anywhere like
texture rendering or initial states where we want to go from current state ->
custom state -> back to current state.
* This also allows us to more gracefully handle PREINITIALIZED image layouts. We
internally promote them to GENERAL as soon as possible, but keep them around
as PREINITIALIZED for display.
* We are really looking for persistent memory leaks here not fluctuations in
memory use. There are too many false positives from memory usage increasing up
high part-way through the iterations and then reducing down for the final
iteration, which could be many lazy or deferred things running and completing
over time.
* This will let us run multiple windows (and multiple threads) relatively
easily.
* The hammer is fairly big, we move some things into the window that don't need
to be there necessarily if we have multiple windows on a single thread, but it
keeps things simple.
baldurk