New error when mixing gl and gles on web service

[mcclure]

I am working with an open source project called lovr which uses glad. Its current GLAD generation link is this URL.

Sometime in the last week or three, this URL stopped working. Attempting to generate a GLAD from this URL on the web service now results in a message

Warnings/Errors: Core profile not available when selecting any gles API, automatically changed

It then generates a Compatibility profile.

When I spoke to the lovr developer, he explained that the goal was to get a Core profile when running with plain GL and whatever profile when running with gles2. This is because the code targets both desktops and on emscripten, and Desktop-OpenGL Core is more similar to gles2 than OpenGL Compatibility is.

There are two issues here:

• What would be the correct way for lovr to get its gl core + gles2-supporting headers? I don't know what it was the web service was doing before when it simply allowed "gles2 core", but it worked.
• Even if what Lovr is doing is incorrect, it is problematic for there to be URLs which previously worked on the web service but now no longer work. I maintain a fork of Lovr where I use additional extensions that Lovr master does not use. Previously I could add or remove extensions by loading Lovr's URL up and changing the extensions list to add or remove one or two extensions. However now running the URL produces a compatibility profile, which is not what Lovr targets. In other words, removing support for core+gles outputs means third party consumers of older GLAD-using projects are "stuck"— I cannot necessarily patch Lovr to migrate it away from "core+gles2" because I do not directly control the original project, but I can't generate a new core+gles2 source file either.

I am not certain what my "expected behavior" here is, but: Would it be possible to alter the web service so that generating the "illegal" core+gles2 profile either becomes a warning (ie emits the illegal profile rather than silently altering it to compatibility) or provides more useful advice about what to do?

Thanks

[Dav1dde]

The problem is a bug within glad. Glad has the problem when mixing the GL:core API with GLES1/GLES2, it doesnt generate symbols which are removed in the GL:core profile but should still exist because they are (re-)defined in the GLES API.

To make that more clear an example with the GL_LUMINANCE symbol:

    <!-- Initially defined in GL 1.0 -->
    <feature api="gl" name="GL_VERSION_1_0" number="1.0">
        <require>
            <enum name="GL_LUMINANCE"/>
        </require>
    </feature>

    <!-- GL 3.2 with a core profile removes the symbol  -->
    <feature api="gl" name="GL_VERSION_3_2" number="3.2">
        <remove profile="core" comment="Compatibility-only GL 1.1 features removed from GL 3.2">
            <enum name="GL_LUMINANCE"/>
        </remove>
    </feature>

     <!-- GLES 2.0 adds the symbol again -->
    <feature api="gles2" name="GL_ES_VERSION_2_0" number="2.0">
        <require>
            <enum name="GL_LUMINANCE"/>
        </require>
    </feature>

Glad gets confused (actually a badly implemented parser) and removes the GL_LUMINANCE symbol (generated code does not include the symbol). This is very confusing behaviour, in order to mitigate the problem for now (non trivial change to glad) I introduced this warning/behaviour you noticed.

What does that mean for you?: Basically nothing, the loader generated by glad will now contain some deprecated symbols which were removed in the core profile and are not used by GLES, but since compatibility is 100% compatible with core this is (hopefully) just a minor annoyance for you, if not please let me know.

[mcclure]

Ack, sorry, I wish I'd seen this earlier… "extra symbols" (ie compatibility mode) is actually a significant problem in my opinion… compatibility mode is not supported on Macintoshes, only Core… but I do a lot of my development on Windows… if I develop against the compatibility profile, I could accidentally develop code which works on my Windows machine, I will crash on Macintosh… removing the compatibility-only symbols on Windows provides partial protection against this outcome. I understand if this is too complicated to fix however…

[Dav1dde]

I woke up today and realized I was thinking way to complicated. I'll fix this today.

[Dav1dde]

@mcclure Sorry for all that noise, it is back to normal now and the bug that caused this is gone.

Maybe interesting to see what symbols were affected by that bug:

@@ -1069,6 +1069,7 @@
 #define GL_TESS_GEN_VERTEX_ORDER 0x8E78
 #define GL_TESS_GEN_POINT_MODE 0x8E79
 #define GL_ISOLINES 0x8E7A
+#define GL_QUADS 0x0007
 #define GL_FRACTIONAL_ODD 0x8E7B
 #define GL_FRACTIONAL_EVEN 0x8E7C
 #define GL_MAX_PATCH_VERTICES 0x8E7D
@@ -1307,6 +1308,7 @@
 #define GL_BUFFER 0x82E0
 #define GL_SHADER 0x82E1
 #define GL_PROGRAM 0x82E2
+#define GL_VERTEX_ARRAY 0x8074
 #define GL_QUERY 0x82E3
 #define GL_PROGRAM_PIPELINE 0x82E4
 #define GL_SAMPLER 0x82E6
@@ -1502,6 +1504,8 @@
 #define GL_MAX_VERTEX_ATTRIB_BINDINGS 0x82DA
 #define GL_VERTEX_BINDING_BUFFER 0x8F4F
 #define GL_DISPLAY_LIST 0x82E7
+#define GL_STACK_UNDERFLOW 0x0504
+#define GL_STACK_OVERFLOW 0x0503
 #define GL_MAX_VERTEX_ATTRIB_STRIDE 0x82E5
 #define GL_PRIMITIVE_RESTART_FOR_PATCHES_SUPPORTED 0x8221
 #define GL_TEXTURE_BUFFER_BINDING 0x8C2A
@@ -1543,6 +1547,16 @@
 #define GL_CONTEXT_FLAG_ROBUST_ACCESS_BIT 0x00000004
 #define GL_CONTEXT_RELEASE_BEHAVIOR 0x82FB
 #define GL_CONTEXT_RELEASE_BEHAVIOR_FLUSH 0x82FC
+#define GL_ALIASED_POINT_SIZE_RANGE 0x846D
+#define GL_RED_BITS 0x0D52
+#define GL_GREEN_BITS 0x0D53
+#define GL_BLUE_BITS 0x0D54
+#define GL_ALPHA_BITS 0x0D55
+#define GL_DEPTH_BITS 0x0D56
+#define GL_STENCIL_BITS 0x0D57
+#define GL_GENERATE_MIPMAP_HINT 0x8192
+#define GL_LUMINANCE 0x1909
+#define GL_LUMINANCE_ALPHA 0x190A
 #define GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS 0x8CD9
 #ifndef GL_VERSION_1_0
 #define GL_VERSION_1_0 1
@@ -3296,6 +3310,9 @@
 typedef void (APIENTRYP PFNGLGETOBJECTPTRLABELPROC)(const void *ptr, GLsizei bufSize, GLsizei *length, GLchar *label);
 GLAPI PFNGLGETOBJECTPTRLABELPROC glad_glGetObjectPtrLabel;
 #define glGetObjectPtrLabel glad_glGetObjectPtrLabel
+typedef void (APIENTRYP PFNGLGETPOINTERVPROC)(GLenum pname, void **params);
+GLAPI PFNGLGETPOINTERVPROC glad_glGetPointerv;
+#define glGetPointerv glad_glGetPointerv
 #endif
 #ifndef GL_VERSION_4_4
 #define GL_VERSION_4_4 1

[mcclure]

Thanks!!