Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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