* It's unclear exactly what happens when a different active texture is set, the
spec seems to suggest that the active texture unit is ignored for most queries
that aren't about texture-slot bindings but then it doesn't say explicitly
whether that means glBindTexture() with a non-zero active slot will then bind
the texture for querying or not.
* For safety and simplicity we always work on texture unit 0. On replay this is
most simply accomplished by pushing and popping the active slot at the same
time that we push and pop the binding for our EXT_direct_state_access
emulation.
* For the couple of cases that happen during capture when we might not be
emulating EXT_direct_state_access, we push and pop by hand.
KHR counters come in 3 different scopes (quoting the spec) :
* VK_PERFORMANCE_COUNTER_SCOPE_COMMAND_BUFFER_KHR - the performance
counter scope is a single complete command buffer.
* VK_PERFORMANCE_COUNTER_SCOPE_RENDER_PASS_KHR - the performance
counter scope is zero or more complete render passes. The
performance query containing the performance counter must begin
and end outside a render pass instance.
* VK_PERFORMANCE_COUNTER_SCOPE_COMMAND_KHR - the performance counter
scope is zero or more commands.
The way we're currently using the counters is tied to draw/dispatch
commands so we should only use the SCOPE_COMMAND type of counters.
* This better details the inclusionary community desired and has more specific
additional language on how the code of conduct will be enforced as needed.
* In addition the file is copied to the .github folder for additional
visibility.
* When we plan to return a function pointer even with no onward implementation,
wglGetProcAddress will have set PROC_NOT_FOUND or some similar error. We'll
still return our hook though so we need to unset that error code just in case
the application is looking for it.
baldurk