tested on: AMD A9 9420 (integrated Radeon R530) using Window 10 64 bit and driver Adrenalin Edition 18.8.1 (18.30.01.01 RC5), atiglpxx.dll version 8.14.01.6564
Also reproducible on: OpenGL: 3.3.14568 Core Profile/Debug Context FireGL 24.20.12042.5, renderer=AMD FirePro W5130M
Hi,
I’ve detected a strange behavior with AMD OpenGL driver when doing:
1. Buffer (VBO) mapping/writing
2. binding/configuring VAO, activating program
3. Buffer (VBO) binding/unmapping
4. drawing
Using gl_debug_output shows the detailed error info on draw call:
GLDEBUG ERROR from 8246, TYPE=824c, ID=03e8, SEVERITY=37190, msg=glDrawElements has generated an error (GL_INVALID_OPERATION)
GLDEBUG ERROR from 8246, TYPE=824c, ID=03e8, SEVERITY=37190, msg=glDrawElements has generated an error (GL_INVALID_OPERATION)
GLDEBUG ERROR from 8246, TYPE=824c, ID=07d4, SEVERITY=37190, msg=glDrawElements failed because one or more active vertex attributes reference a vertex buffer that is mapped (GL_INVALID_OPERATION)
If I change the order to 1., 3., 2., 4. then no error is generated.
I have attached minimal example with all the sources and everything needed to build and prebuilt binaries for Windows.
In the example I will start changing 2nd VBO after 120 frames and this is when we get gl_debug_output callback first time. It might seem like a no-issue for this minimal example, but in real life the draws are actually failing and it produces “flickering” for buffer banks where something fails, during user initiated changing of ‘non streaming’ VBOs.
Reordering the steps to 1., 3., 2., 4. fixes the issue, but it takes away possibility to parallelize front renderer config steps with data writing into mapped buffers.
The same issue seems to be reported here and the workaround seems to be the same.
https://github.com/libretro/beetle-psx-libretro/issues/188
