VK-GL-CTS
VK-GL-CTS copied to clipboard
KhronosGroup
glcts depends on non-ABI symbols
This is similar to #141, but for GL. And I've dug further.
The glcts binary depends on functions not part of the "old" linux OpenGL ABI (pre GLVND). This manifests as a missing symbol glGetInternalformativ, but fixing that one probably reveals more. The reason this happens is a bit intricate.
First of all, the code tries to get this right, by using a GL wrapper that can load the entry-points from a shared-object, as is required for correctness.
However, there's one code-path that loads this from global symbols; the initES30Direct function in framework/opengl/wrapper/glwInitES30Direct.cpp. That function didn't use to do any harm, because we were saved by the linker culling unused code; a normal OpenGL build would not reference any code that called this.
But this all changed in 0e94e01a42e51498efc714634e2ad050ede9f3ec, where the DEQP_SUPPORT_EGL-condition for linking to eglutil was removed, always linking in this static library. RenderContext::create in egluGLContextFactory.cpp calls glw::initES30Direct if DEQP_GLES3_DIRECT_LINK is set.
...And DEQP_GLES3_DIRECT_LINK is set in the default target if the GLESv2 library as well as GLES3/gl3.h was found... Ugh.
So the result is that unless GLVND is used, we can't run the CTS for OpenGL applications. That's unfortunate.
Yeah, fix the code to no longer break the ABI...? This all seems to lead to 0e94e01a42e51498efc714634e2ad050ede9f3ec, which makes the incorrect assumption that we can link to eglutil on desktop GL. That just doesn't work, because that library requires non-standard symbols. So perhaps the right thing would be to revert that change?
It's really problematic if the OpenGL CTS doesn't work on all OpenGL implementations.
So perhaps the right thing would be to revert that change?
Reverting a 5 year old change does not look like to be the right thing.
Reverting a 5 year old change does not look like to be the right thing.
I'm not sure why not? I don't think the age matters as long as this was incorrect all along...?
Just to be clear, when I say "revert that change", I don't mean "execute git revert 0e94e01a42e51498efc714634e2ad050ede9f3ec on your terminal", as that clearly won't work due to the changes that has happened since. I mean to undo the logical change.
After 9d40bd7aee42a6dbe7da8e348d8582217917ae55 you can use -DGLES_ALLOW_DIRECT_LINK=0 when configuring CTS, which forces GLES symbols to be loaded dynamically.
I can confirm that this works around the issue. Perhaps it should be the default?
Yes, I think so. I wanted to get my foot in the door first with the change above. I'll keep this issue open to propose another change in the future to make this the default behavior.
@rg3igalia: Seems the GLES_ALLOW_DIRECT_LINK-flag is not included in the latest GLCTS release. I guess this only went to the main-branch, and not to branches such as opengl-cts-4.6.3... ?
Ah, yes. :facepalm: I'll propose a cherry-pick to the 4.6.3 branch. By the way, the change to make it the default behavior is currently under review (also for main, will have to be cherry-picked later).
The new behavior has been made default in main with d37edb1a141fd1da0dd74c3c12f8612732057c9a. @kusma can you confirm this fixes the issue for you by default with no drawbacks?
Sorry for the late reply.
I'm unable to reproduce the issue in the first place now, not really sure what I've messed up. But I think everything is fine from what I can see! So I guess we can close this?
No problem! The change to make this the default behavior has not been backported to any release branch. What about submitting a cherry-pick for 4.6.3 and then closing the issue?
I doubt we need to backport the default, TBH. Being able to configure it is fine, and having the default for future releases is great!