[waffle] [PATCH (maint-1.4)] wflinfo: Fix glGetStringi on Mali

[Chad Versace]

On Thu 20 Nov 2014, Daniel Kurtz wrote:
>On Thu, Nov 20, 2014 at 10:34 AM, Chad Versace <chad.versace at intel.com> wrote:

>>> diff --git a/src/utils/wflinfo.c b/src/utils/wflinfo.c
>>> index 0b03e55..0907b4b 100644
>>> --- a/src/utils/wflinfo.c
>>> +++ b/src/utils/wflinfo.c
>>> @@ -1037,7 +1037,28 @@ main(int argc, char **argv)
>>>     if (!glGetString)
>>>         error_get_gl_symbol("glGetString");
>>>
>>> -    glGetStringi = waffle_get_proc_address("glGetStringi");
>>> +    // Retrieving GL functions is tricky. When glGetStringi is supported,
>>> here
>>> +    // are some boggling variations as of 2014-11-19:
>>> +    //   - Mali drivers on EGL 1.4 expose glGetStringi statically from
>>> +    //     libGLESv2 but not dynamically from eglGetProcAddress. The EGL
>>> 1.4 spec
>>> +    //     permits this behavior.
>
>In fact, AFAICT, EGL <= 1.4 mandates this behavior, since glGetStringi
>is an OpenGL ES 3.0 "non-extension" function.

I think the EGL 1.4 is ambiguous on the topic of OpenGL ES 3.0 
functions. Hence the creation of EGL_KHR_get_all_proc_addresses. From 
that spec:

    With the addition of OpenGL and OpenGL ES 3 support to EGL, the
    definition of a non-extension function becomes less clear.

And the EGL 1.4 spec, page 56, 2013-12-04, made a concession to this 
ambiguity by adding footnote 21:

    eglGetProcAddress may not be queried for core (non-extension) functions 
    in EGL or client APIs [21].

    For functions that are queryable with eglGetProcAddress, 
    implementations may choose to also export those functions statically 
    from the object libraries im- plementing those functions. However, 
    portable clients cannot rely on this behavior.

    [...]

    [21] In practice, some implementations have chosen to relax this restriction.

So you're right. EGL 1.4 under one interpretation mandates Mali's 
behavior. But I believe Mesa is also right under a different 
interpretation allowed by the ambiguity.

Anyhow, I think we all agree that what *really* matters is that 
everybody's code works, not what some vague phrase in the spec claims.

>That is, unless your EGL has EGL_KHR_get_all_proc_addresses [0]:
>[0] https://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_get_all_proc_addresses.txt

I just sent a patch to mesa-dev to expose this extension, with you CC'd.

>>> +    //   - EGL 1.5 requires that eglGetStringi be exposed dynamically
>>> through
>>> +    //     eglGetProcAddress. Exposing statically with dlsym is optional.
>
>EGL 1.5 essentially makes EGL_KHR_get_all_proc_addresses part of the standard.
>
>So perhaps the check is something crazy like:
>
> if (extension-function(function) ||
>     EGL >=1.5  ||
>     (is_display_init() &&
>EGL_has_extension("EGL_KHR_get_all_proc_addresses")) ||
>     (EGL_supports_client_extensions() && EGL_has_client_
>extension("EGL_KHR_client_get_all_proc_addresses")) {
>    use eglGetProcAddress(function);
> } else {
>    use platform-specific-lookup(function);
> }
>
>Do you agree with this?

But you hide the truly crazy part! "use platform-specific-lookup" is 
where all the fun code lives, which would contain a fairly large web of
logic.

Rather than correctly implement platform-specific-lookup today, I prefer 
the below code, which non-intrusively applies to the maintenance branch:

    glGetStringi = dlsym();
    if (!glGetStringi) {
        glGetStringi = glX/wgl/eglGetProcAddress();
    }

I think the above code works for every platform.

>But... couldn't we avoid this whole mess by just always using
>glGetString() in wflinfo instead of jumping through hoops just to try
>to use  glGetStringi()?

I wish. glGetString (no i) was removed from OpenGL Core Profile. OpenGL 
ES 3.0 kept the function to retain backwards compatibility with OpenGL 
ES 2.0.