On 27 June 2016 at 18:38, Ian Romanick <i...@freedesktop.org> wrote: > On 06/24/2016 09:30 AM, Emil Velikov wrote: >> 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 ? > > That ship has already sailed. OpenGL ES 3.0 and 3.1 have both been > shipping for years. I don't think changing that is how I would use my > time machine. :) > As you guys wish, I won't stir up a hornet's nest. Just a reminder that we did a similar thing on the libGL front, which, imho, was significantly more likely to have actual users that depend on such 'odd' behaviour.
A humble request - can we keep an eye open as GLES 3.3 and/or OpenGL 4.6 comes out. Would be great if with those include the proposed suggestion/fix. Namely: in order to use these with EGL, one needs to have the EGL_KHR_get_all_proc_addresses extension or EGL 1.5. I'll keep an eye open Collabora being a Khronos member, although it would be great if I'm not the only one. Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev