* This means that things will work successfully even if the 'executable' is
actually e.g. python3 in a system directory and nowhere related to where the
renderdoc library is.
* This ensures we don't serialise a pointer to client memory which is non-
deterministic. The value isn't used, we will readback the actual data at draw
time and replace with client-memory buffer updates.
* When calling the register() function there is no frame or globals, so we need
to set an internal handle external to that.
* This means functions that get wrapped know that there's a global handler for
exceptions, which just prints to the log. Otherwise they think they're running
synchronously and write to an invalid exception handling object.
* This will rarely be relevant, but it ensures if the function is decref'd and
the lambda is still alive, that we keep the python object alive until we are
done with it. The primary case for this is persistent callbacks where the
module is then reloaded.
When selecting "Quad Overdraw (Pass)" from the texture viewer, I get this warning :
Log - Got a Debug message from GL_DEBUG_SOURCE_API, type GL_DEBUG_TYPE_ERROR, ID 81, severity GL_DEBUG_SEVERITY_HIGH:
'GL_INVALID_OPERATION in glUniform1("overdrawImage"@12 is image, not uint)'
The OpExecutionMode entries were being left in place, but pointing
to functions which are no longer entry points. This caused the GPU
driver to crash (probably trying to look it up).
At this point we don't have Intel GL counters. But the current logic
assumes there is only AMD ones (and that if it's not AMD's, it must be
the generic ones).
A missing \n was triggering a compile error for example :
#extension GL_ARB_shader_storage_buffer_object : require#define SHADER_RESTYPE 1
#define UINT_TEX 0
* Someone encountered miscompiled SPIR-V such that 1.1, 2.2 etc were compiled to
1.0, 2.0. I couldn't reproduce it and I don't know how glslang would
miscompile, but this workaround is at least safe to apply.
baldurk