* The cost of memcpy'ing data across to upload heap buffers for initial
contents and maps is significant, so for large buffers it's better to
allocate them GPU-side so we can do GPU copies.
* This also means that maps cannot happen directly, so instead while
reading we allocate a GPU-side copy of the map source data, and
perform a buffer copy instead.
* This means that even if the extension isn't reported in the string
for whatever reason, we still mark it available. It saves on checks
of (GLCoreVersion >= 43 || HasExt[foo]) all over the place.
* For some #extensions we can fallback to a lesser path (or just drop
that functionality - e.g. displaying cubemap arrays if there's no
extension for it).
* Of course if the capture used the storage functions during capture,
then they will still be used on replay. We are only removing extra
usage here for internal textures/buffers
* This is even messier than I thought - I didn't realise, but it in fact
varied depending on if the image was initialised with glTexStorage or
glTexImage (or possibly glCompressedTexImage2D).
* Either way, the query is much too unreliable to try and use and work
around, so instead we'll just use the GetCompressedByteSize function
and work out the size ourselves.
* EXT_direct_state_access emulated by pushing/popping current bind
* ARB_copy_image emulated with framebuffer blits
* ARB_clear_buffer_object emulated with Map + memset/memcpy
* ARB_internalformat_query2 emulated with a limited hardcoded database
* This is a bit of a hack. Mesa seems to return a function pointer for
functions it recognises but doesn't support. So e.g. if you query for
glBindFramebuffer you'll get the implementation, if you query for
glBindFramebufferEXT then you get a stub that errors out.
* So in this case we ensure that any EXT/ARB aliases only set their
function pointer if we don't have the core function already. This will
fix some cases but obviously doesn't help if the core function is the
error-stub and the extension is supported...
baldurk