From: Romain Naour <romain.naour@gmail.com>
To: "Yann E. MORIN" <yann.morin.1998@free.fr>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Jakub Skrzypnik <jskrzypnik@novomatic-tech.com>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 2/2 v4] package/mesa3d: make it aware of libglvnd and support it when present
Date: Mon, 3 Jan 2022 22:20:45 +0100 [thread overview]
Message-ID: <85de806e-39a4-ce1b-fd07-2916443dfbbf@gmail.com> (raw)
In-Reply-To: <20200727173524.GG19818@scaer>
Hello Yann, Thomas,
Le 27/07/2020 à 19:35, Yann E. MORIN a écrit :
> 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...
I had an issue with a package (ogre) that now use OPENGL_glx_LIBRARY to find the
"GLVND 'GLX' library"
https://github.com/OGRECave/ogre/commit/aa9ffa7a51e52cb714f1bf5a3a00b9ef9f5a7dc2
https://cmake.org/cmake/help/latest/module/FindOpenGL.html
I guess libglvnd will be required at some point.
Best regards,
Romain
>
> Regards,
> Yann E. MORIN.
>
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2022-01-03 21:20 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
2022-01-03 21:20 ` Romain Naour [this message]
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=85de806e-39a4-ce1b-fd07-2916443dfbbf@gmail.com \
--to=romain.naour@gmail.com \
--cc=buildroot@buildroot.org \
--cc=jskrzypnik@novomatic-tech.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=yann.morin.1998@free.fr \
/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