On 20 June 2016 at 19:14, Ian Romanick <i...@freedesktop.org> wrote: > On 06/17/2016 11:15 AM, Emil Velikov wrote: >> 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. > > There are at least two solutions, and piglit uses both. If use of a set > of functions is optional, you can still use GetProcAddress (when > EGL_KHR_get_all_proc_addresses is available) or you can use dlsym. > > For me, piglit is where this whole problem actually started. Right now, > piglit follows the (unextended) rules and does not attempt to use > GetProcAddress on core functions. It uses dlsym. I tried to extend > shader_runner for separate shader objects on GLES. Guess what? Since > the symbols aren't exported by the library, it didn't work. So... now > piglit would need TWO code paths... one that uses dlsym and one that > uses eglGetProcAddress... or require an optional extension. > I've started looking at piglit last night. There should be some fixes for it on the list later on today.
> If an application requires GLES 3.1 symbols, it should just be able to > link with them. As far as I can tell, that's how it works on Android. > I look at the Android wrapper too closely for the following reasons: - There is libGLESv3.so which is identical copy of the v2 one. - Their libGLESv2/3.so periodically grows new symbols, including GLES extensions. - Android has tight control what and/how it's run on their platform - something that Linux distributions cannot do afaict. - Applications using GLES should annotate the version used in the manifest, which (haven't checked exactly) could serve as a first line of defence for applications e.g. using GLES 3.1 on system/drivers supporting GLES 3.0. That said, there is one very good thing: - They use dlsym and then eglGetProcAddress on all symbols. Thus mesa will just work. >> - 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]. >> Any "sounds ok" or "that's a horrible idea" input on this suggestion ? Thanks -Emil >> 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-stable mailing list >> mesa-sta...@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/mesa-stable > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
