GLES3 extensions unresolved symbols

[erunehtar]

When targeting GLES3 with extensions, we get these link warnings:

warning: unresolved symbol: glBindProgramPipelineEXT
warning: unresolved symbol: glClientWaitSyncAPPLE
warning: unresolved symbol: glDebugMessageCallbackKHR
warning: unresolved symbol: glDebugMessageControlKHR
warning: unresolved symbol: glDeleteProgramPipelinesEXT
warning: unresolved symbol: glDeleteSyncAPPLE
warning: unresolved symbol: glFenceSyncAPPLE
warning: unresolved symbol: glFlushMappedBufferRange
warning: unresolved symbol: glFlushMappedBufferRangeEXT
warning: unresolved symbol: glGenProgramPipelinesEXT
warning: unresolved symbol: glGetProgramBinaryOES
warning: unresolved symbol: glGetSyncivAPPLE
warning: unresolved symbol: glMapBufferOES
warning: unresolved symbol: glMapBufferRangeEXT
warning: unresolved symbol: glPopGroupMarkerEXT
warning: unresolved symbol: glProgramBinaryOES
warning: unresolved symbol: glProgramParameteriEXT
warning: unresolved symbol: glProgramUniform1fvEXT
warning: unresolved symbol: glProgramUniform1ivEXT
warning: unresolved symbol: glProgramUniform2fvEXT
warning: unresolved symbol: glProgramUniform3fvEXT
warning: unresolved symbol: glProgramUniform4fvEXT
warning: unresolved symbol: glProgramUniformMatrix4fvEXT
warning: unresolved symbol: glPushGroupMarkerEXT
warning: unresolved symbol: glUnmapBufferOES
warning: unresolved symbol: glUseProgramStagesEXT

We currently include GLES3 headers this way:

#include <GLES3/gl3.h>
#include <GLES3/gl2ext.h>

For example, in the gl2ext.h header, we see things like #define GL_OES_get_program_binary 1

Based on https://www.khronos.org/registry/gles/extensions/OES/OES_get_program_binary.txt, should we expect glGetProgramBinaryOES to exist it in the link library?

[erunehtar]

@juj just checking if you had time to check this one, thanks

[juj]

Thanks for pinging, and sorry for the delay, this fell through my attention.

Several of those headers refer to GLES2/3 extensions that Emscripten does not support. Here is a breakdown:

glBindProgramPipelineEXT
glDeleteProgramPipelinesEXT
glGenProgramPipelinesEXT
glProgramParameteriEXT
glProgramUniform1fvEXT
glProgramUniform1ivEXT
glProgramUniform2fvEXT
glProgramUniform3fvEXT
glProgramUniform4fvEXT
glProgramUniformMatrix4fvEXT
glUseProgramStagesEXT

GL_EXT_separate_shader_objects: extension on top of GLES 2.0 core, was adopted in core spec in GLES 3.1. Not part of WebGL 1 nor 2, nor is an extension for this available. This is a mighty tricky feature that can't be emulated without direct API support. Hopefully we will get this in WebGL 2.1, since this is quite a useful feature that makes GL(ES) a bit more easier and D3D-like to work with.

glClientWaitSyncAPPLE
glDeleteSyncAPPLE
glFenceSyncAPPLE
glGetSyncivAPPLE

GL_APPLE_sync: extension on top of GLES 2.0 core, was adopted in core spec in GLES 3.0. WebGL does not have an extension to enable this with WebGL 1.0, but it is available in core WebGL 2, omit the 'APPLE' suffix.

glDebugMessageCallbackKHR
glDebugMessageControlKHR

GL_KHR_debug: For some reason, the GLES spec for this refers to desktop OpenGL: https://www.khronos.org/registry/gles/extensions/KHR/debug.txt, likely operates on top of OpenGL ES 3.1 core. An equivalent doesn't exist for WebGL - hopefully/likely not in a critical path though, so can just comment out.

glGetProgramBinaryOES
glProgramBinaryOES

GL_OES_get_program_binary: extension written on top of GLES 2.0 core, added to core in OpenGL ES 3.0. This feature however is not available in WebGL, as binary programs have been deemed possibly unsecure, but above all nonportable to be useful.

glPopGroupMarkerEXT
glPushGroupMarkerEXT

GL_EXT_debug_marker: extension written on top of GLES 2.0. Couldn't find quickly when this went to core GLES. Not available on WebGL.

glMapBufferOES
glUnmapBufferOES

GL_OES_mapbuffer: extension written on top of GLES 2.0, core functionality in GLES 3.0, however this is not part of WebGL due to security concerns. If you compile with -s FULL_ES3=1, these are emulated (possibly slowly), but the entry point names are glMapBufferRange() and glUnmapBuffer() instead.

glFlushMappedBufferRangeEXT
glMapBufferRangeEXT

GL_EXT_map_buffer_range: Same as above. This is actually the extension that was adopted to core in GLES 3.0, glMapBufferOES() function was dropped.

glFlushMappedBufferRange

OpenGL ES 3.0 core function name for glFlushMappedBufferRangeEXT. This is the one we can emulate with -s FULL_ES3=1.

To improve the confusing situation where anything compiles but doesn't link, I started authoring PR #4502 to clean up the extension header from unsupported extensions.

[erunehtar]

We aren't calling these functions, so I guess it is because of the header file that we get the link warnings?

[juj]

No, the functions definitely need to be referenced somewhere for the link warnings to occur - a compiler simply seeing a declaration of a function does not yet cause a link warning. If it's a debug build, perhaps there is some code that is not called, (but doesn't get dead-code-eliminated because of debug build), that would reference those?

[bmuzzin]

(@gouletr and I work on the same codebase). We have binding generation script, and so it just tries to pull in any extension possible across all GL/ES versions, and map that to what you're trying to call. So, for example, just because we call "glClientWaitSyncAPPLE", doesn't mean we don't also call "glClientWaitSync". It also checks extensions at runtime, so, it doesn't ever actually call an extension that the runtime doesn't report, but it might be compiled in.

The issue is that the code for those extensions is compiled out based on the extensions advertised in gl2ext.h. It sounds like PR #4502 will fix this issue on our end, since it will remove the #defines for the ones Emscripten doesn't support. So, we can probably just close this issue once it gets merged.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past 2 years. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.