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

[Mike Gorchak]

Please understand me right, we are not talking about desktop hardware and
libraries, only about embedded in case of GL ES. What's common for desktop
usually uncommon for embedded and vice versa. We are currently ship
libraries from many silicon vendors: Imagination RGX, Mali, Vivante, nVidia
- all have GLES 3.1 and 3.2 functions in libGLESv2.so .

Thanks!


On Fri, Jun 17, 2016 at 2:15 PM, Emil Velikov <emil.l.velikov at gmail.com>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-stable/attachments/20160617/466dfd50/attachment.html>