* We don't create any objects with the ID that the original name was
applied to, we create a buffer for each baked version of that handle.
* So on replay we need to apply the name down from the original object,
and this also means temporarily storing the name in the original ID
instead of as a live ID (since there is no live ID for the original
command buffer object).
In #598 the alias glMapBufferOES and glUnmapBufferOES macros
were added for the gl_hookset_defs.h but the alias
entries in the gl_hookset.h was missed.
Also expose the glGetBufferPointervOES as part of the
GL_OES_mapbuffer extension.
* When creating a program with glCreateShaderProgramv it implicitly acts
as if the shaders are detached and deleted after linking. This means
it cannot be relinked again.
* However the only time we need to relink a program is when we are
copying across fragdata and vertex attrib bindings in case they were
changed from creation - but for the same reason that we can't relink
a program to apply them, the application can't either - which means
the data must be unchanged from creation, and so the copy is not
needed.
* Originally when I added the EXT_dsa emuluation, I targeted it
specifically to only those functions that I call outside of the replay
loop, for internal analysis purposes. For that reason the emulation
was only applied to a separate hookset, and only during replay (not
during capture).
* However this doesn't account for some of the streamlined serialisation
of functions like glBufferStorage, glBufferData, etc. To simplify
code paths, I 'promote' all variants of these types of functions to
the EXT_dsa variant (except ARB_dsa for texture functions which is
actually different by not requiring the texture target parameter).
* Note: most of these functions were emulated already (except three -
glNamedBufferStorageEXT, glTextureBufferEXT and
glTextureBufferRangeEXT) but on replay we didn't use the internal
hookset, just the normal one, which was not emulated.
* Rather than try to decide when these should use the internal hookset
and when the regular one, or switch them all over to the internal
hookset, instead re-evaluate the reason for a separate hookset in the
first place: Emulating functions separately means the original func
pointers are returned during capture time, for unsupported extensions.
* However mesa has proven that unsupported extensions don't have to
return NULL, as it's undefined what they return - they should not be
called if the extension isn't available. So in actual fact there's
little harm to be done by emulating in-place and returning some
different pointers to the application. In the worst case, they get a
bit of EXT_dsa emulation themselves.
* There's a minor conflict over GL_ACTIVE_PROGRAM_EXT being defined to
different values in GLES and GL extension headers. Since in the GL
extension header it's defined to the value that eventually became
GL_CURRENT_PROGRAM we remove that define.
* It seems like even running the simple check to see if we need our
workarounds can completely break intel's driver and lead to infinite
hangs later. So instead we just assume these hacks are always on for
intel drivers.
* In CMake this is easy as we're already passing it through sed, but
in msbuild it's a little more complex as we need to write a little
in-line C# code to read out the version number and replace the
* We also update the JSON generation for layer registration on linux.
* By default VS creates a huge section of properties copy-pasted for
every Configuration|Platform combination, which is almost all the
same for each one.
* We instead create a common section with most of the properties that
are fixed, and then override/add to them for the few that vary (e.g.
optimisation settings for release, preprocessor macros).
* We used to ignore C4512 but we no longer need to.
C4100: 'identifier' : unreferenced formal parameter
C4512: 'class' : assignment operator could not be generated
Previously the allowed extension list was set when the
WrappedOpenGL driver was created. However at that point it is not always
clear if we are in GL or GL ES mode.
* Tacking -official onto the git hash was a hack only needed on windows,
and since we want more information it doesn't scale.
* Instead we track anything we need to know about the version in
separate variables, like whether it's a stable build or a nightly/
local build. Or if it's built by a downstream distribution then the
version number for the downstream build.
* The suffix is superfluous in the string name - it can be reconstructed
using the array size data. It just confuses things when trying to
replicate a variable declaration. E.g. int indices[4]; shouldn't be
listed as int[4] indices[4];
* Our function to get texture data requests a single mip and a single
array slice at a time. However this interacts badly with the GL get
function that returns array data all at once.
* Worst case, we end up fetching N array slices N times, meaning we do
N^2 work, and allocate way more memory than is required. There was
also a bug that caused the allocated memory for compressed arrays to
return all array slices instead of returning one slice, offsetted.
* Now instead we cache the returned array data and look it up for
subsequent requests, since it's very likely that we're going to ask
for the other array slices.
* If an app only relies on reflection to set up its VAO, then its VAO
will morph to match the built-in implementation defined initial
locations of attribs and fragdata.
* Then when replaying on another implementation the VAO will no longer
match the changed locations.
* So instead we save the locations (whether they're user set or still
implementation defined) and restore them explicitly.
* We need to relink programs to update attrib bindings, which means the
shaders need to be still attached. There doesn't seem to be any harm
in leaving a shader attached to a program that should be detached -
it can still be used just fine in other programs.
baldurk