Not sure what I thought here, but using GL_IMPLEMENTATION_COLOR_READ_*
with glGetFramebufferParameteriv() is possible only since GL 4.5
(there's no extension adding it) and there's no equivalent for it in
GLES 3.1. I assumed that since the entry point is defined in 3.1 then it
would also accept the same enum, but apparently not -- and this
inconsistency is not fixed in 3.2 either.
Funnily enough, all drivers I tried (Mesa ES, SwiftShader, ANGLE) were
accepting this. The first driver that complained was ARM Mali on Huawei
P10 and there I assumed a driver bug -- but on the contrary, this is the
only driver following the spec properly :)
Now the glGetFramebufferParameteriv() API (and the DSA equivalent) is
used only on GL 4.5 contexts and up, everywhere else it's done using
the old-style glGetInteger(). I also renamed the implementations to not
misleadingly mention ES 3.1, since it has nothing to do with this. The
code path dispatch code is a bit entangled due to all the workarounds,
hopefully not breaking any behavior that worked before.
Interesting that I didn't run into this until testing on Mesa AMD
drivers. So far it worked for NV, Mesa Intel, Intel Windows, Android and
many more. Heh. Also improved the test to actually verify the user
pointer gets passed through correctly and updated the docs to reflect
this behavior.
Would fail on an incomplete framebuffer error on framebuffer-less
windowless contexts. Didn't happen before, I think it's because of a new
check in a new Mesa.
This code path is not run there due to the newly added
"intel-windows-broken-dsa-for-cubemaps" workaround, but in case someone
disables it for testing purposes the code should not randomly blow up on
an assertion in compressedPixelFormatPack().
The image() queries were using getCubeLevelParameterivImplementation()
but the subImage() were inherited from AbstractTexture, using a slightly
different implementation. Since we'll need to apply workarounds to all
cubemap APIs, this needs to be consistent.
These tests need to use MagnumGLTestLib, however the Application library
they're using is linked agaist MagnumGL. This causes problems at least
on Windows with GL::Context::current(), where the affected two tests
(GLMeshGLTest and GLBufferImageGLTest) failed with current() having no
context.
Deprecated for 2018.04, it's been almost a year since. Whoever is using
Magnum regularly updated already, and who not can always upgrade
gradually (2018.02, 2018.04, 2018.10, 2019.01 etc.).
Fixing the new (and now failing test) from the previous commit. In
setIndexBuffer(), I was resetting the state tracker to a VAO state that
was about to be set in the very next step, and then, when doing that
next step the state tracker "optimized away" the state change because it
thought it was already done (even though it wasn't). Reordering the two
operations fixes it.
In comparison to how this was meant to be done in the original
169031fb7b, the new way should do the same
but additionally avoid a bunch of redundant state calls. Let's hope no
more bugs related to this appear.
This one crashes. Turns out the 169031fb7b
contained a random temporary test state instead of the real solution
(and so the comment didn't even match the code, it should have been
resetting that to 0). That also made some tests fail with DSA disabled,
but none of the tests were actual Mesh tests, just accidentally hitting
the problematic code path.
I took the opportunity to look at this more closely and investigate
*why* this failed -- turns out, in setIndexBuffer(), I was resetting
the state tracker to a VAO state that was about to be set in the very
next step, and then, when doing that next step the state tracker
"optimized away" the state change because it thought it was already done
(even though it wasn't). The new test in MeshGLTest covers this
particular case.
Vladimír Vondruš