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

[Ian Romanick]

On 06/24/2016 09:30 AM, Emil Velikov wrote:
> 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 ?

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. :)

> 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
>>
> _______________________________________________
> mesa-stable mailing list
> mesa-stable at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-stable
>