[Mesa-stable] [PATCH] mapi: Export all GLES 3.1 functions in libGLESv2.so

[Emil Velikov]

On 17 June 2016 at 18:20, Ian Romanick <idr at freedesktop.org> wrote:
> From: Ian Romanick <ian.d.romanick at intel.com>
>
> Khronos recommends that the GLES 3.1 library also be called libGLESv2.
> It also requires that functions be statically linkable from that
> library.
>
> NOTE: Mesa has supported the EGL_KHR_get_all_proc_addresses extension
> since at least Mesa 10.5, so applications targeting Linux should use
> eglGetProcAddress to avoid problems running binaries on systems with
> older, non-GLES 3.1 libGLESv2 libraries.
>
Fwiw I'm inclined that we should go the "opposite direction". Namely:
don't expose new symbols and stick to a predefined version (3.0 being
the personal favour of choice).

Why, you might ask - for a couple of reasons:
 - If the list continues to grow programs will have unstable ABI -
sort of how libGL ended up. Applications are going to link against 3.1
or later symbols [1], even if they only optionally use them. Thus
things will quite hairy and fragile.
 - The other desktop GLES* provider NVIDIA does not export even a
single GLES 3.1/3.2 entry point (still going through the 3.0 list) in
their libGLESv2.so.2 binary.

So what to do with GLES (3.0?)/3.1 and later:
 - tweak the spec so that said version of the API is only supported if
the implementation can get core symbols via eglGetProcAddress. Be that
props to the EGL_KHR_get_all_proc_addresses extension or EGL 1.5 [2].

How does this sound ? I guess the best way would be to check with
other implementations (note Catalyst still seems to be missing
libGLES*) and choose the more common route ?


Regards,
Emil

[1] Yes, in practise they should use libepoxy or a similar library,
but from practise we all know that even those tend to have bugs. Sadly
libepoxy in particular hasn't seen much action in a while.

[2] https://github.com/anholt/libepoxy/issues/21