On 17 June 2016 at 18:20, Ian Romanick <i...@freedesktop.org> wrote: > From: Ian Romanick <ian.d.roman...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
