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.
Using "1" here was very specific to the build system, as noted by the comment.
When run on systems with older APIs install, it resulted in java compile errors.
* 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.
* For VS output we can statically determine how much space is needed and
allocate more if we need to.
* For tessellation/geometry shader output, we need to run a query to see
if there was enough output space, then reallocate and run it again.
* On GL there isn't a built-in xfb query, only as an extension with poor
support, so we just resize to allow the maximum expansion.
* I'm not clear on if this is safe or sensible - somehow the source
program can report multiple outputs bound to the same index (e.g. 0)
but that's illegal to set explicitly ourselves. So we just ignore the
subsequent variables and hope the first one we find is the valid one.
* The other alternative is to set the subsequent variables to some bind
higher than all of the rest, or fill in holes (e.g. if we see 0, 0, 1
then bind the second 0 to 2).
Peter Gal