[Mesa-maintainers] Recommendations for building Mesa with LIBGLVND support

[Kyle Brenneman]

On 06/04/2018 08:53 AM, Stefan Dirsch wrote:
> On Thu, May 11, 2017 at 11:44:09AM +0100, Emil Velikov wrote:
>> On 11 May 2017 at 09:24, Timo Aaltonen <tjaalton at ubuntu.com> wrote:
>>> On 17.04.2017 21:31, Emil Velikov wrote:
>>>> On 23 March 2017 at 15:00, Stefan Dirsch <sndirsch at suse.de> wrote:
>>>>> On Tue, Mar 21, 2017 at 12:16:48PM -0600, Kyle Brenneman wrote:
>>>>>> Ah, I'd forgotten to address libGLES* in my EGL patch.
>>>>>>
>>>>>> As far as I can tell, the libGLES libraries in Mesa are just dispatch stubs,
>>>>>> and nothing within Mesa depends on them. That is, if an application looked
>>>>>> up every GLES function using eglGetProcAddress, then you could remove the
>>>>>> libGLES*.so libraries entirely and it would still run fine.
>>>>>>
>>>>>> If that's true, then a libglvnd-based build of Mesa could just skip building
>>>>>> the libGLES*.so libraries, because libglvnd basically does look up every
>>>>>> GLES function through the vendor library's eglGetProcAddress.
>>>>> Thanks, Kyle! This explains a lot! I have done this now (removed Mesa's GLES
>>>>> libs and reqplaced them with RPM requires to libglvnd's GLES libs; the same as
>>>>> Fedora is doing) and it just works. :-)
>>>>>
>>>> In case you've missed it - I've pulled Kyle's work [with a small bit
>>>> of polish] for Mesa 17.1.0-rc1.
>>>>
>>>> Note that there's still loose ends - the biggest one in the GLVND
>>>> library itself. I've got some local WIP that I'll try to test and
>>>> upstream this week.
>>> Hi, what's the status of this work?
>>>
>>> We're preparing GLVND in Debian experimental now that 17.1.0 is out, and
>>> my plan is to get it in Ubuntu Artful some time this summer.
>>>
>> TL;DR; if you can live with broken IGLX and eglGetDisplay + GBM things
>> are safe to use with Mesa 17.1.0.
>>
>> A more comprehensive TODO on the topic of libglvnd is below.
>>
>> - DONE - mesa: merge the EGL libglvnd implementation
>> - DONE - mesa: investigate if linking the DRI modules against
>> libglapi.so is safe
>> - WIP - mesa: do not install GLES libraries/headers/pkg-config files
>> when libglvnd is enabled
>> Depends on the header/pkg-config bits below
>> - TODO - libglvnd: broke indirect GLX, should be fixed once libglvnd
>> provides libglapi.so.
>> - WIP - libglvnd: eglGetDisplay has broken GBM support
>> - TODO - libglvnd: install the pkg-config files
>> - TODO - libglvnd: (or Khronos) should provide the headers - depends
>> on the next two items
>> - TODO - libglvnd: tests to ensure we don't break the ABI
>> - WIP - Khronos: correctly manage different EGL platforms
>> Patches are on mesa-dev@, need to push through Khronos
>> - TODO - Khronos: upstream/ratify the Wayland EGL extensions
>>
>> The topics involving [upstream] libglvnd do take a while since I'm not
>> good at selling it to the upstream maintainer :-\
> Understood! Do you happen to have an update on these topics? Although many
> Linux distributions already switched to libglvnd I believe. I've found a
> v1.0.0 tag in libglnvnd and that's what (open)SUSE currently is/will be using
> in their latest products. Together with Mesa 18.0.2.
>
> Thanks,
> Stefan
>
As far as I know, GBM does work in libglvnd's implementation of 
eglGetDisplay. There's also an optional function that a vendor library 
can provide to add to libglvnd's platform detection, so you can add new 
platform types to eglGetDisplay without having to update libglvnd itself.

Indirect GLX, if I've read the code correctly (and please let me know if 
I haven't), is broken because the libglx.so server module tries to use 
glXGetProcAddress in libGL,.so to get at OpenGL entrypoints, and then 
sets the current context directly in Mesa's driver layer. Whether that's 
something to fix in libglvnd itself is an open question. If the server 
module expects to be talking to Mesa specifically, then another option 
would be to provide something in Mesa to let the two talk directly 
without going through libglvnd.