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

[Emil Velikov]

Hi all,

On 4 June 2018 at 16:10, Kyle Brenneman <kbrenneman at nvidia.com> wrote:
> 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.
>>
Handful of them are still open, I'm afraid. That said, libglvnd 1.0.0
is feature complete, from runtime POV.
As always there are things to pick on, but that's true for everything.

I'd suggest switching to it and reporting bugs. As said before
indirect GLX has the odd bug and a proper solution is really
elaborate.
I've been working on it on and off for a few months. Fingers crossed I
will have something cool to show soon (tm).


>> 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.
>
Indeed, GBM _does_ work with eglGetDisplay (after I've fixed it in
libglvnd) and the optional entrypoints are really nice.
Sadly, I cannot see a reason to use them (in Mesa) just yet.

> 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.
You're spot on.

> Whether that's
> something to fix in libglvnd itself is an open question.
A proper fix plus one that results in xxx lines of code deleted covers
xserver, mesa and libglvnd.
I won't spoil it too much until I have something working ;-)

-Emil