* 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.
* This is better than testing by platform/platform version, because we can check
specifically for extensions and avoid running a test we know will fail because
extensions aren't supported.
* Instead of only doing a very lightweight check to see if the API is available
up-front, we now share the API initialisation among all API tests far enough
to determine availability of extensions, features, etc. Then we can precisely
determine which tests are available and which aren't before running.
* This is required because we add MAP_READ_BIT and the spec doesn't allow maps
that are both unsynchronized and reading.
* Also add a test for unsynchronised persistent maps, and update the
GL_Buffer_Updates test to not require a reference image but check each quad
individually for the expected colour.
* This is primarily for the benefit of GL/VK where we need to feature-detect for
some extensions or functionality that requires selecting a device, e.g. D3D12
can be more easily detected with a quick check.
* We'll run this once and cache the results when running tests from python so we
can do a better job of filtering out tests that the current machine doesn't
support.
* This is primarily around initial states - either a resource which is from a
previous frame and maybe wasn't dirtied and needs initial states created for
it when it's modified mid-frame, or a resource that's created and destroyed
all within one frame.
baldurk