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

[Daniel Kurtz]

On Thu, Nov 20, 2014 at 10:34 AM, Chad Versace <chad.versace at intel.com> wrote:
> +Frank
>
>
> On Wed 19 Nov 2014, Chad Versace wrote:
>>
>> On Mali EGL 1.4, you can't obtain non-extension functions (including
>> OpenGL ES 3.0 functions) with eglGetProcAddress. You must use dlsym.
>>
>> This patch carefully avoids breaking glGetStringi on other platforms,
>> which may expose glGetStringi dynamically (as in eglGetProcAddress) but
>> not statically (as in dlsym).
>>
>> Fixes #20: https://github.com/waffle-gl/waffle/pull/20
>> Fixes: chromium:428061
>> [https://code.google.com/p/chromium/issues/detail?id=428061]
>> See: https://github.com/anholt/libepoxy/issues/21
>> Reported-by: Frank Henigman <fjhenigman at chromium.org>
>> Cc: Daniel Kurtz <djkurtz at chromium.org>
>> Signed-off-by: Chad Versace <chad.versace at linux.intel.com>
>> ---
>>
>> Frank or Daniel, could you please validate this patch on Mali? I tested on
>> Fedora with Mesa i965.
>>
>>
>>
>>
>> src/utils/wflinfo.c | 23 ++++++++++++++++++++++-
>> 1 file changed, 22 insertions(+), 1 deletion(-)
>>
>> 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.

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

>> +    //   - 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... 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()?


>> +    //   - Windows requires that glGetStringi be exposed dynamically from
>> +    //     wglGetProcAddress. Exposing statically from GetProcAddress
>> (Window's
>> +    //     dlsym equivalent) is optional.
>> +    //   - Mesa drivers expose glGetStringi statically from libGL and
>> libGLESv2
>> +    //     and dynamically from eglGetProcAddress and glxGetProcAddress.
>> +    //   - Mac exposes glGetStringi only statically.
>> +    //
>> +    // Try waffle_dl_sym before waffle_get_proc_address because
>> +    // (1) egl/glXProcAddress can return invalid non-null pointers for
>> +    // unsupported functions and (2) dlsym returns non-null if and only
>> if the
>> +    // library exposes the symbol.
>> +    glGetStringi = waffle_dl_sym(opts.dl, "glGetStringi");
>> +    if (!glGetStringi) {
>> +        glGetStringi = waffle_get_proc_address("glGetStringi");
>> +    }
>>
>>     const struct wflinfo_config_attrs config_attrs = {
>>         .api = opts.context_api,
>> --
>> 2.1.2.1.g5433a3e
>>
>