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

[Emil Velikov]

On 20 June 2016 at 19:14, Ian Romanick <idr at freedesktop.org> wrote:
> On 06/17/2016 11:15 AM, Emil Velikov 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.
>
> 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-stable at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
>