* 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.
* Seen on Metro 2033 - if a single FBO is used for many cases, with
attachments added and removed repeatedly. We just give up and fall back
to fetching them as frame initial state for that framebuffer.
* Seen in Metro Redux, glTexImage was used to upload a 1920x1080 32bpp
image over and over, and each chunk faithfully recorded the data. Instead
we detect when glTexImage is called with the same size parameters, no
resizing/recreation effectively occurs, so we drop the chunk and just
mark the texture as dirty to fetch the data later.
* There is still a small race condition, but worst case if it's hit then
we load a library and free it, and the only way to protect it is to lock
around FreeLibrary which is quite scary.
* When a compatibility context is created (via the old CreateContext, or
via an appropriate CreateContextAttribs call), we can still do the vendor
checks but we want to make sure we perform them again if we ever create a
core profile context. Note that actually *using* a compatibility context
isn't supported at the moment, but this won't explicitly break that.
* These values are used to show the current pipeline state (as it's
convenient to show this data with the rest of the 'state', even if it's
not state. That means they need to be set every time when executing, not
just once when reading.
* It seems like there's some buggy behaviour when mixing and matching 'old'
style vertex attrib pointer/offset functions, and the new attrib/vertex
buffer binding style (which we use in VAO initial state since it's a
superset of functionality).
* Fortunately, the spec defines exactly how VertexAttribPointer is defined
in terms of the new system, so just do the replacement ourselves.
* e.g. if the 'wrong' VAO was bound at the time we replayed a
bind-to-create chunk, then we'd trample that VAO state (and it might not
ever be restored). So when reading, not executing, save and restore the
buffer binding.
baldurk