* If the pixel store parameters are relatively simple we go through a
fast path that's about the same as it was before, otherwise we manually
unpack to a tightly packed buffer for serialising. Hopefully this should
rarely happen.
* glPixelStore parameters are only serialised when capturing a frame, and
the pixel store parameters at frame start form part of the initial state
vector.
* The real implementation can do more if it wants, and align to a larger
alignment, but we just return 64 to the program and align to that, which
satisfies the extension minimum requirements (and chances are no program
takes advantage of wider alignment anyway).
* Many debug messages are completely useless without context, so to track
down bugs in crashdumps with logs, etc, it would be very useful to add
a little snippet to show what function call the message was fired from
and what the parameters were.
* I'll just add these as/when necessary for tracking bugs.
* Eventually I'll add a wrapper layer so that if EXT_dsa isn't present then
it just gets emulated, but for now we require it to be present even if
the captured program didn't use it.
* Also added handling for dirty buffer textures - there are no contents to
copy, those are handled with the buffer, so instead we just grab the few
parameters that are valid to re-specify the buffer texture.
* We pick up the properties of VAO 0 on frame capture as dirty state, and
then replay it into the fake VAO we were already creating for VAO 0.
* Eventually this record will be entirely trimmed/ignored for programs that
don't use VAO 0 by frame references, but for now we fetch it needlessly.
It doesn't seem to fire any errors.
* I emulate luminance textures as either GL_RED or GL_RG textures of
appropriate size, and use the built-in texture swizzling to shunt the
channels around.
* At the moment, I don't handle further swizzling of the textures (which
would break the fake layer) as I assume legacy code using luminance texs
wouldn't use swizzling also, but instead would just update and use the
appropriate formats themselves.
* The same applies for render buffers, texture views, texture buffers and
glTexStorage* calls - not handled at the moment, but wouldn't be hard to.
* We can't pass GL_COMPUTE_SHADER to glGetProgramPipelineiv in some cases,
but if we have a program (not pipeline) and want to query, we need the
enum intact even if the AMD bug workaround is active.
* If the 'context shared' VAOs/FBOs hack is on, their context is set to
NULL (so any context will match the resource), but this also means we
shouldn't try and bind that context to fetch data.
* GL won't let you define too many texture uniforms, and currently the tex
sampling code blows it for the texture display shader. So we split it
by float/uint/sint and pick the right compiled version.
* If there's only one device/equivalent around, then allow specifying a
NULL window for frame capturing and that lone device is the one used.
* This allows for capturing completely headless applications, perhaps doing
compute or something offline. It also allows capturing applications where
the rendering happens by sharing textures off to some other API that
isn't hooked.
* Binding VAO 0 is invalid in core GL, but it's common for programs to do
so we want to support it - we can show an API error/warning to indicate
that it's wrong.
* Fixes a fairly serious regression where any capture relying on setting
NULL as one of several state objects would instead just get the previous
state left over.
* This was a bug introduced with 7aee40f7a4
where we checked for whether resources were present in the replay - but
it didn't account for ResourceIds being 0 in some cases - which is valid
and corresponds ot setting NULL, but returns false from HasLiveResource.
* To remove renderdoc (e.g. if the API version doesn't match what is
expected), user code can call RENDERDOC_Shutdown() to remove the running
thread and undo any library hooks, then unload the dynamic library.
* This still isn't recommended as there could be unexpected side-effects,
and it will definitely break if this happens after any APIs have been
initialised, but it's an option.
* There are a handful of ARB and EXT extensions left that aren't in either
the list of supported, or will-never support. These are ones that I want
to support but haven't written the code for.
* We don't try and detect duplicate markers between GREMEDY and KHR_debug,
just assume the program is smart enough to detect that both are available
and pick only one to use.
* For each context on first activation we fetch the extensions supported by
the implementation, and intersect that with the list of extensions that
renderdoc itself supports, so we return to the application the subset
of 'real' supported extensions that we can support ourselves.
* This list includes all extensions that we support all the entry points,
tokens, etc for. It still needs to be unioned with the extensions that
the implementation supports to determine what to return to the program.
* A couple of extensions are a little hazy as we implement everything in
them that 'modern' GL includes, but the extension itself also specifies
some old/outdated functions. Any extensions that are entirely old
functions are omitted from this list.
* I will assume for now that any wgl functions I don't explicitly hook have
no effect on the captured frame and we can safely just let them straight
through to the real function.
* Now instead of returning NULL for entry points that we don't support and
hoping the application will handle that or error out, instead we return
a function that will log an error if it is ever called, and then pass
through to the real function. In most cases, the capture will probably be
broken as whichever function isn't saved.
* hookset.pl is much faster too, it outputs the whole gl_hookset_defs.h
file and doesn't do multiple searches over the whole set of headers in
official/ for each function.
baldurk