Okay I compiled and ran with -fsanitize=address. It's just a faster way to get basically the same stack trace. From here it's clear that the allocation in StreamBuffer.cpp is failing, i.e. GL_EXT_buffer_storage isn't working in Mesa 19.3.
But if it were that simple, this would be working already. As 6by9 said on the Pi forums the current 3.1 compliance issues are unrelated to EXT_buffer_storage, so in theory just manually forcing it on would have been sufficient. Yet these backtraces have shown that exposing EXT_buffer_storage does not result in a working implementation.
Keep in mind that 3.1 is only the minimum profile version to permit exposing GL_EXT_buffer_storage. From what I can tell, as an extension by definition it's optional for any level of GLES compliance. The Igalia team can complete their roadmap and release a Mesa V3D driver with OpenGL ES 3.2 support and buffer storage could still be unsupported.
Next, I managed to compile and run VK-GL-CTS for the intent of testing the equivalent GL_ARB_buffer_storage. I could find only one test that covers it as indicated by these lines. Apparently it only runs this case if GL_ARB_sparse_buffer is also available (which is not the case for V3D) so the functionality may not actually be tested or implemented.
(08-29-2019, 08:05 AM)bomblord Wrote: it'll probably be best just to wait for the Pi to become Mesa OpenGL 3.1 compliantYou mean OpenGL ES 3.1.
But if it were that simple, this would be working already. As 6by9 said on the Pi forums the current 3.1 compliance issues are unrelated to EXT_buffer_storage, so in theory just manually forcing it on would have been sufficient. Yet these backtraces have shown that exposing EXT_buffer_storage does not result in a working implementation.
Keep in mind that 3.1 is only the minimum profile version to permit exposing GL_EXT_buffer_storage. From what I can tell, as an extension by definition it's optional for any level of GLES compliance. The Igalia team can complete their roadmap and release a Mesa V3D driver with OpenGL ES 3.2 support and buffer storage could still be unsupported.
Next, I managed to compile and run VK-GL-CTS for the intent of testing the equivalent GL_ARB_buffer_storage. I could find only one test that covers it as indicated by these lines. Apparently it only runs this case if GL_ARB_sparse_buffer is also available (which is not the case for V3D) so the functionality may not actually be tested or implemented.
