| Message ID | c48baa11cd0c06ec5af3fd4989306c3ec581d0e9.1595839612.git.yann.morin.1998@free.fr |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [1/2,v4] package/libglvnd: new package | expand |
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. > > Signed-off-by: Jakub Skrzypnik <jskrzypnik@novomatic-tech.com> > [yann.morin.1998@free.fr: > - don't override the _PROVIDES variable, only assign when needed > ] > Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> > --- > package/mesa3d/Config.in | 15 +++++++++------ > package/mesa3d/mesa3d.mk | 15 +++++++++++---- > 2 files changed, 20 insertions(+), 10 deletions(-) > > diff --git a/package/mesa3d/Config.in b/package/mesa3d/Config.in > index 11d04b7a3f..5417aeda1a 100644 > --- a/package/mesa3d/Config.in > +++ b/package/mesa3d/Config.in > @@ -422,7 +422,8 @@ comment "gbm support needs a dri driver or a gallium driver w/ EGL support." > 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 :-/ 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. OK, here is some vague idea for a possible solution: - We introduce an intermediate "layer" between libgl and GL providers. - GL provides no longer provide directly libgl, but instead some kind of libgl-low, libgl-real (or some better name) - libgl is then provided either by libglvnd on top of libgl-low/libgl-real, *or* on top of some simple libgl-proxy package that does nothing but make libgl depend on libgl-low 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. Would this make sense ? Is it over-engineered ? Thomas
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.
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. >
Le 03/01/2022 à 22:20, Romain Naour a écrit : > 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. Actually I did a test using this series as is. Tested-by: Romain Naour <romain.naour@gmail.com> Best regards, Romain > > Best regards, > Romain > > >> >> Regards, >> Yann E. MORIN. >> >
diff --git a/package/mesa3d/Config.in b/package/mesa3d/Config.in index 11d04b7a3f..5417aeda1a 100644 --- a/package/mesa3d/Config.in +++ b/package/mesa3d/Config.in @@ -422,7 +422,8 @@ comment "gbm support needs a dri driver or a gallium driver w/ EGL support." 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 select BR2_PACKAGE_MESA3D_NEEDS_X11 help Enable GLX graphic acceleration (OpenGL + X11). @@ -432,7 +433,8 @@ comment "OpenGL GLX support needs X11" config BR2_PACKAGE_MESA3D_OPENGL_EGL bool "OpenGL EGL" - select BR2_PACKAGE_HAS_LIBEGL + select BR2_PACKAGE_HAS_LIBEGL if !BR2_PACKAGE_LIBGLVND + select BR2_PACKAGE_LIBGLVND_DISPATCH_EGL if BR2_PACKAGE_LIBGLVND select BR2_PACKAGE_HAS_LIBEGL_WAYLAND select BR2_PACKAGE_MESA3D_GBM help @@ -441,7 +443,8 @@ config BR2_PACKAGE_MESA3D_OPENGL_EGL config BR2_PACKAGE_MESA3D_OPENGL_ES bool "OpenGL ES" - select BR2_PACKAGE_HAS_LIBGLES + select BR2_PACKAGE_HAS_LIBGLES if !BR2_PACKAGE_LIBGLVND + select BR2_PACKAGE_LIBGLVND_DISPATCH_GLES if BR2_PACKAGE_LIBGLVND help Use the Khronos OpenGL ES APIs. This is commonly used on embedded systems and represents a subset of the OpenGL API. @@ -449,13 +452,13 @@ config BR2_PACKAGE_MESA3D_OPENGL_ES endif # BR2_PACKAGE_MESA3D_DRIVER config BR2_PACKAGE_PROVIDES_LIBGL - default "mesa3d" if BR2_PACKAGE_MESA3D_OPENGL_GLX + default "mesa3d" if BR2_PACKAGE_MESA3D_OPENGL_GLX && !BR2_PACKAGE_LIBGLVND config BR2_PACKAGE_PROVIDES_LIBEGL - default "mesa3d" if BR2_PACKAGE_MESA3D_OPENGL_EGL + default "mesa3d" if BR2_PACKAGE_MESA3D_OPENGL_EGL && !BR2_PACKAGE_LIBGLVND config BR2_PACKAGE_PROVIDES_LIBGLES - default "mesa3d" if BR2_PACKAGE_MESA3D_OPENGL_ES + default "mesa3d" if BR2_PACKAGE_MESA3D_OPENGL_ES && !BR2_PACKAGE_LIBGLVND config BR2_PACKAGE_PROVIDES_LIBOPENCL default "mesa3d" if BR2_PACKAGE_MESA3D_OPENCL diff --git a/package/mesa3d/mesa3d.mk b/package/mesa3d/mesa3d.mk index 4a17b2e7a2..d40e6da9c6 100644 --- a/package/mesa3d/mesa3d.mk +++ b/package/mesa3d/mesa3d.mk @@ -162,9 +162,9 @@ MESA3D_CONF_OPTS += -Dopengl=true # we do not need libva support in mesa3d, therefore disable this option MESA3D_CONF_OPTS += -Dgallium-va=false -# libGL is only provided for a full xorg stack +# libGL is only provided for a full xorg stack, without libglvnd ifeq ($(BR2_PACKAGE_MESA3D_OPENGL_GLX),y) -MESA3D_PROVIDES += libgl +MESA3D_PROVIDES += $(if $(BR2_PACKAGE_LIBGLVND),,libgl) else define MESA3D_REMOVE_OPENGL_HEADERS rm -rf $(STAGING_DIR)/usr/include/GL/ @@ -224,7 +224,7 @@ MESA3D_CONF_OPTS += \ endif ifeq ($(BR2_PACKAGE_MESA3D_OPENGL_EGL),y) -MESA3D_PROVIDES += libegl +MESA3D_PROVIDES += $(if $(BR2_PACKAGE_LIBGLVND),,libegl) MESA3D_CONF_OPTS += \ -Degl=true else @@ -233,7 +233,7 @@ MESA3D_CONF_OPTS += \ endif ifeq ($(BR2_PACKAGE_MESA3D_OPENGL_ES),y) -MESA3D_PROVIDES += libgles +MESA3D_PROVIDES += $(if $(BR2_PACKAGE_LIBGLVND),,libgles) MESA3D_CONF_OPTS += -Dgles1=true -Dgles2=true else MESA3D_CONF_OPTS += -Dgles1=false -Dgles2=false @@ -281,4 +281,11 @@ else MESA3D_CONF_OPTS += -Dzstd=false endif +ifeq ($(BR2_PACKAGE_LIBGLVND),y) +MESA3D_DEPENDENCIES += libglvnd +MESA3D_CONF_OPTS += -Dglvnd=true +else +MESA3D_CONF_OPTS += -Dglvnd=false +endif + $(eval $(meson-package))