Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/2 v4] package/mesa3d: make it aware of libglvnd and support it when present
Date: Mon, 27 Jul 2020 19:35:24 +0200	[thread overview]
Message-ID: <20200727173524.GG19818@scaer> (raw)
In-Reply-To: <20200727173844.2ac2945f@windsurf.home>

Thomas, All,

On 2020-07-27 17:38 +0200, Thomas Petazzoni spake thusly:
> On Mon, 27 Jul 2020 10:47:02 +0200
> "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> > From: Jakub Skrzypnik <jskrzypnik@novomatic-tech.com>
> > 
> > When libglvnd is enabled, mesa3d must be told so, so as it installs its
> > libraries with the vendor suffix (e.g. libEGL_mesa.so instead of
> > libEGL.so).
> > 
> > Additionally, the provider (in Buildroot parlance) is libglvnd, not mesa3d.
[--SNIP--]
> >  config BR2_PACKAGE_MESA3D_OPENGL_GLX
> >  	bool "OpenGL GLX"
> >  	depends on BR2_PACKAGE_XORG7
> > -	select BR2_PACKAGE_HAS_LIBGL
> > +	select BR2_PACKAGE_HAS_LIBGL if !BR2_PACKAGE_LIBGLVND
> > +	select BR2_PACKAGE_LIBGLVND_DISPATCH_GL if BR2_PACKAGE_LIBGLVND
> 
> I don't immediately see a good solution for this, but I find that
> solution to be quite annoying :-/

At first, I though so too, and I also looked for a better approach,
but...

> Indeed, I understand that once libglvnd is enabled, the GL-provider is
> libglvnd, which in the background is using mesa3d. The dance to handle
> libglvnd in mesa3d is already not nice, and we would have to have the
> same dance in other GL providers that support libglvnd.

Well, it is not _so_ bad. We could maybe make it a bit simpler, with:

    config BR2_PACKAGE_MESA3D_OPENGL_GLX
        bool "OpenGL GLX"
        select BR2_PACKAGE_HAS_LIBGL

We still need to declare emsa3d as providing libgl depending on whether
libglvnd is enabled, but we can make it a bit more "compact":

    if !BR2_PACKAGE_LIBGLVND

    config BR2_PACKAGE_PROVIDES_LIBGL
        default "mesa3d" if BR2_PACKAGE_MESA3D_OPENGL_GLX

    [EGL and GLES too here]

    endif

And in mesa3d.mk too:

    ifeq ($(BR2_PACKAGE_MESA3D_OPENGL_GLX),y)
    MESA3D_PROVIDES += $(if $(BR2_PACKAGE_LIBGLVND),,libgl)
    [...]
    endif

But now, in libglvnd, we don't need any extra symbol, we can just re-use
BR2_PACKAGE_PROVIDES_LIBGL et al.:

    config BR2_PACKAGE_LIBGLVND
        bool "libglvnd"
        select BR2_PACKAGE_XLIB_LIBX11 if BR2_PACKAGE_PROVIDES_LIBGL
        select BR2_PACKAGE_XLIB_LIBXEXT if BR2_PACKAGE_PROVIDES_LIBGL
        select BR2_PACKAGE_XLIB_XORGPROTO if BR2_PACKAGE_PROVIDES_LIBGL
        select BR2_PACKAGE_HAS_LIBGL if BR2_PACKAGE_PROVIDES_LIBGL

    if BR2_PACKAGE_LIBGLVND

    config BR2_PACKAGE_PROVIDES_LIBGL
        default "libglvnd" if BR2_PACKAGE_HAS_LIBGL

    endif

and in libglvnd.mk:

    ifeq ($(BR2_PACKAGE_PROVIDES_LIBGL),y)
    LIBGLVND_DEPENDENCIES += xlib_libXext xorgproto
    LIBGLVND_CONF_OPTS += -Dglx=enabled
    LIBGLVND_PROVIDES += libgl
    else
    LIBGLVND_CONF_OPTS += -Dglx=disabled
    endif

> OK, here is some vague idea for a possible solution:
>  - We introduce an intermediate "layer" between libgl and GL providers.
[--SNIP--]
> I *think* this would perhaps avoid that complexity in mesa3d...
> obviously for additional complexity in terms of how the virtual
> packages in GL world all work together.

You are reinventing libglvnd in between libglvnd and actual providers, no?

Also, remember that individual GL providers will still have to function
as providers without libglvnd, which is not required.

But I would like we progress on the topic, and when we have a second
candidate for libglvnd use, we can revisit the topic and see if we can
over-engineer the thing.

Usually, we wait for three or four cases before trying to solve the
problem in a generic fashion, and so I'd like to do here as well.
Because so far, only two providers are known to work with libglvnd:
mewsa3d and nvidia. ATI might be a third one, but I have no clue about
it. And in the SoC land, there is not much that is libglvnd compatible
so far, if at all.

So, in the short-to-medium term, we'd at best have three providers. Is
that enough to delve into a generic infra so far? Not sure...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2020-07-27 17:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-27  8:46 [Buildroot] [PATCH 0/2 v4] package/libglvnd: introduce the GL vendor-neutral proxy (branch yem/libglvnd) Yann E. MORIN
2020-07-27  8:47 ` [Buildroot] [PATCH 1/2 v4] package/libglvnd: new package Yann E. MORIN
2020-07-27  8:47 ` [Buildroot] [PATCH 2/2 v4] package/mesa3d: make it aware of libglvnd and support it when present Yann E. MORIN
2020-07-27 15:38   ` Thomas Petazzoni
2020-07-27 17:35     ` Yann E. MORIN [this message]
2022-01-03 21:20       ` Romain Naour
2022-01-03 21:25         ` Romain Naour
2022-01-09 16:50 ` [Buildroot] [PATCH 0/2 v4] package/libglvnd: introduce the GL vendor-neutral proxy (branch yem/libglvnd) Arnout Vandecappelle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200727173524.GG19818@scaer \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox