<div dir="ltr"><div>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 . </div>Thanks! </div><div class="gmail_extra"> <div class="gmail_quote">On Fri, Jun 17, 2016 at 2:15 PM, Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com" target="_blank">emil.l.velikov@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 17 June 2016 at 18:20, Ian Romanick <<a href="mailto:idr@freedesktop.org">idr@freedesktop.org</a>> wrote: > From: Ian Romanick <<a href="mailto:ian.d.romanick@intel.com">ian.d.romanick@intel.com</a>> > > 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] <a href="https://github.com/anholt/libepoxy/issues/21" rel="noreferrer" target="_blank">https://github.com/anholt/libepoxy/issues/21</a> </blockquote></div> </div>