Message ID | 20180913194410.24077-1-bernd.kuhls@t-online.de |
---|---|
State | Changes Requested |
Headers | show |
Series | [1/2] package/opengl/libgbm: new virtual package | expand |
Hello all, +in Cc, Einar (for ti-sgx-libgbm), Maxime Ripard (for sunxi-mali-mainline) and Paul Kocialkowski (general libgbm knowledge) On Thu, 13 Sep 2018 21:44:09 +0200, Bernd Kuhls wrote: > Kodi 18.0-Leia will implement stand-alone gbm support alongside x11 & > wayland. To enable building libgbm in mesa3d without x11 & wayland we > need to create a virtual package for libgbm. > > Also other packages besides mesa3d may provide libgbm.so, see > http://patchwork.ozlabs.org/patch/647235/ > http://patchwork.ozlabs.org/patch/939703/ > > Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> During the Buildroot Developers meeting and last week, I worked on the libgbm virtual package, in order to hopefully be able to merge the patches from Bernd (https://patchwork.ozlabs.org/project/buildroot/list/?series=65595) and Einar (https://patchwork.ozlabs.org/project/buildroot/list/?series=53824). Unfortunately, it seems like the "libgbm" API is not very well defined, and each OpenGL implementation has a different view of what libgbm is. I am wondering how users of libgbm can work with such a situation. I have put together at https://git.bootlin.com/users/thomas-petazzoni/buildroot/log/?h=gbm a branch that gathers Bernd and Einar patches, plus some additional fixes on top, and three demo defconfigs. My goal was to be able to: - build kmscube with Mesa3D as libgbm provider (this is already possible) - build kmscube with TI SGX as libgbm provider - build kmscube with Sunxi Mali as libgbm provider It turns out that while kmscube with Mesa3D builds (obviously), neither kmscube with TI SGX or Sunxi Mali build properly: - TI SGX libgbm is named libgbm.so.2, while other libgbm implementations, including the one in Mesa3D is named libgbm.so.1. Not a big issue by itself, but it hints at the two things being different. Anyway, it fails to build because the libgbm API is not what kmscube expects: http://code.bulix.org/cot991-494068 - With Sunxi Mali, same issue, it fails to build with libgbm API issues: http://code.bulix.org/rulyvo-494069 So I'm really wondering if libgbm has a proper standardized API like OpenGL has. Another hint is that the recent version of kmscube now require gbm >= 13.0, and 13.0 is basically a Mesa3D version. Anybody has some hints/ideas about this ? How is the libgbm from TI SGX or Sunxi Mali being used ? What will build against it ? Best regards, Thomas
Hi I'm not much help here. My only concern was building QT5 on an embedded AM335x with ti-sgx-* libraries and update the kernel to 4.9 (bumping TI SDK from 2.0 to 4.0). There is now a kernel 4.14 (TI SDK 5.0), with only minor changes to the ti-sgx-* libraries (support gbm_bo and GCC7). http://www.ti.com/tool/PROCESSOR-SDK-AM335X kmscube seems to depend heavily on the mesa3d implementation, so I don't think it's easy to make it work with the other libgbm versions. Would building a working QT be a valid test of the libgbm build? On Mon, 5 Nov 2018 at 13:47, Maxime Ripard <maxime.ripard@bootlin.com> wrote: > > On Tue, Oct 30, 2018 at 10:14:20PM +0100, Thomas Petazzoni wrote: > > Hello all, > > > > > > It turns out that while kmscube with Mesa3D builds (obviously), > > neither kmscube with TI SGX or Sunxi Mali build properly: > > > > - TI SGX libgbm is named libgbm.so.2, while other libgbm > > implementations, including the one in Mesa3D is named > > libgbm.so.1. Not a big issue by itself, but it hints at the two > > things being different. > > > > Anyway, it fails to build because the libgbm API is not what > > kmscube expects: http://code.bulix.org/cot991-494068 > > > > - With Sunxi Mali, same issue, it fails to build with libgbm API > > issues: http://code.bulix.org/rulyvo-494069 > > > > So I'm really wondering if libgbm has a proper standardized API like > > OpenGL has. Another hint is that the recent version of kmscube now > > require gbm >= 13.0, and 13.0 is basically a Mesa3D version. > > > > Anybody has some hints/ideas about this ? Note that ti-sgx-um depends on wayland, due to a library dependency on libwayland-server.so.0 and libwayland-client.so.0 (see ldd libpvrs_WAYLAND.so) So the dropped dependency to wayland in ti-sgx-libgbm should have been on ti-sgx-um. Without it, QT5 will not find any EGL backend. So the ti-sgx-um should be adding select BR2_PACKAGE_WAYLAND select BR2_PACKAGE_HAS_LIBEGL_WAYLAND That way Qt5 can build with a valid EGL backend, using ti-sgx instead of the ancient ti-gfx. But this does nothing to help build kmscube. -- Regards Einar Jón
Hello, On Mon, 5 Nov 2018 16:35:02 +0100, Einar Jón wrote: > I'm not much help here. > My only concern was building QT5 on an embedded AM335x with ti-sgx-* > libraries and update the kernel to 4.9 (bumping TI SDK from 2.0 to > 4.0). > There is now a kernel 4.14 (TI SDK 5.0), with only minor changes to > the ti-sgx-* libraries (support gbm_bo and GCC7). > http://www.ti.com/tool/PROCESSOR-SDK-AM335X > > kmscube seems to depend heavily on the mesa3d implementation, so I > don't think it's easy to make it work with the other libgbm versions. > Would building a working QT be a valid test of the libgbm build? Yes, it would be. So what you're saying is that the libgbm implementation provided by TI SGX mimics well enough the libgbm implementation of Mesa3D that QT5 is happy with TI SGX libgbm implementation ? > Note that ti-sgx-um depends on wayland, due to a library dependency on > libwayland-server.so.0 and libwayland-client.so.0 (see ldd libpvrs_WAYLAND.so) > So the dropped dependency to wayland in ti-sgx-libgbm should have been > on ti-sgx-um. > Without it, QT5 will not find any EGL backend. > > So the ti-sgx-um should be adding > select BR2_PACKAGE_WAYLAND > select BR2_PACKAGE_HAS_LIBEGL_WAYLAND ACK. > That way Qt5 can build with a valid EGL backend, using ti-sgx instead > of the ancient ti-gfx. > But this does nothing to help build kmscube. Right. I'm still confused by this libgbm thing though, where everyone seems to have its own implementation, but there is no common API implemented by everybody. Thomas
On Mon, 5 Nov 2018 at 16:43, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > Hello, > > On Mon, 5 Nov 2018 16:35:02 +0100, Einar Jón wrote: > > > I'm not much help here. > > My only concern was building QT5 on an embedded AM335x with ti-sgx-* > > libraries and update the kernel to 4.9 (bumping TI SDK from 2.0 to > > 4.0). > > There is now a kernel 4.14 (TI SDK 5.0), with only minor changes to > > the ti-sgx-* libraries (support gbm_bo and GCC7). > > http://www.ti.com/tool/PROCESSOR-SDK-AM335X > > > > kmscube seems to depend heavily on the mesa3d implementation, so I > > don't think it's easy to make it work with the other libgbm versions. > > Would building a working QT be a valid test of the libgbm build? > > Yes, it would be. So what you're saying is that the libgbm > implementation provided by TI SGX mimics well enough the libgbm > implementation of Mesa3D that QT5 is happy with TI SGX libgbm > implementation ? That's exactly what I'm saying, but currently only with a big fat "works for me" caveat. My company has the same CPU as the beaglebone, but our boards have considerable HW changes. We're using an older 3.x kernel with ti-gfx, but I have a working build with QT 5.9 on kernel 4.9/4.14 and ti-sgx. I'll try to throw together a minimal working set with QT tomorrow, but I'm not sure how useful it is without a rootfs (busybox/kernel/udev/etc). > > Note that ti-sgx-um depends on wayland, due to a library dependency on > > libwayland-server.so.0 and libwayland-client.so.0 (see ldd libpvrs_WAYLAND.so) > > So the dropped dependency to wayland in ti-sgx-libgbm should have been > > on ti-sgx-um. > > Without it, QT5 will not find any EGL backend. > > > > So the ti-sgx-um should be adding > > select BR2_PACKAGE_WAYLAND > > select BR2_PACKAGE_HAS_LIBEGL_WAYLAND > > ACK. > > > That way Qt5 can build with a valid EGL backend, using ti-sgx instead > > of the ancient ti-gfx. > > But this does nothing to help build kmscube. > > Right. I'm still confused by this libgbm thing though, where everyone > seems to have its own implementation, but there is no common API > implemented by everybody. So am I. The ti-sgx-libgbm repo seems to be maintained by ti.com, but there seems to be no real effort into making it more than just the bare minimum to use ti-sgx-um.
Hi Thomas, I finally had time to play with the gbm branch on https://git.bootlin.com/users/thomas-petazzoni/buildroot/log/ I made 5 commits that add QT with EGLFS-GBM for all 2 setups. Can I make a pull request, or how do I share them with you? Overview of comments: * ca32516 - configs: libgbm defconfigs build qt5 (2018-11-30)<Einar Jon Gunnarsson>| | configs/libgbm_mesa3d_defconfig | 5 +++++ | configs/libgbm_sunxi_mali_defconfig | 8 +++++++- | configs/libgbm_ti_sgx_defconfig | 9 +++++---- | 3 files changed, 17 insertions(+), 5 deletions(-) * f9fc93c - package/sunxi-mali-mainline: Fix QT5 build for EGLFS (2018-11-30)<Einar Jon Gunnarsson>| | configs/libgbm_sunxi_mali_defconfig | 1 - | package/sunxi-mali-mainline/Config.in | 3 ++- | package/sunxi-mali-mainline/sunxi-mali-mainline.mk | 5 +++++ | 3 files changed, 7 insertions(+), 2 deletions(-) * 4d7f6fb - package/qt5: fix EGLFS for embedded boards (2018-11-30)<Einar Jon Gunnarsson>| | package/qt5/qt5base/qt5base.mk | 3 +++ | 1 file changed, 3 insertions(+) * a7943f1 - package/qt5: Use any libgbm provider (2018-11-28)<Einar Jon Gunnarsson>| | package/qt5/qt5base/qt5base.mk | 6 +++--- | 1 file changed, 3 insertions(+), 3 deletions(-) * d964c09 - package/ti-sgx-um: Add dependency on wayland (2018-11-28)<Einar Jon Gunnarsson>| | package/ti-sgx-um/Config.in | 2 ++ | package/ti-sgx-um/ti-sgx-um.mk | 1 + | 2 files changed, 3 insertions(+) On Tue, 6 Nov 2018 at 14:48, Einar Jón <tolvupostur@gmail.com> wrote: > > On Mon, 5 Nov 2018 at 16:43, Thomas Petazzoni > <thomas.petazzoni@bootlin.com> wrote: > > > > Hello, > > > > On Mon, 5 Nov 2018 16:35:02 +0100, Einar Jón wrote: > > > > > I'm not much help here. > > > My only concern was building QT5 on an embedded AM335x with ti-sgx-* > > > libraries and update the kernel to 4.9 (bumping TI SDK from 2.0 to > > > 4.0). > > > There is now a kernel 4.14 (TI SDK 5.0), with only minor changes to > > > the ti-sgx-* libraries (support gbm_bo and GCC7). > > > http://www.ti.com/tool/PROCESSOR-SDK-AM335X > > > > > > kmscube seems to depend heavily on the mesa3d implementation, so I > > > don't think it's easy to make it work with the other libgbm versions. > > > Would building a working QT be a valid test of the libgbm build? > > > > Yes, it would be. So what you're saying is that the libgbm > > implementation provided by TI SGX mimics well enough the libgbm > > implementation of Mesa3D that QT5 is happy with TI SGX libgbm > > implementation ? > > That's exactly what I'm saying, but currently only with a big fat > "works for me" caveat. > My company has the same CPU as the beaglebone, but our boards have > considerable HW changes. > We're using an older 3.x kernel with ti-gfx, but I have a working > build with QT 5.9 on kernel 4.9/4.14 and ti-sgx. > > I'll try to throw together a minimal working set with QT tomorrow, but > I'm not sure how useful it is without a rootfs > (busybox/kernel/udev/etc). > > > > Note that ti-sgx-um depends on wayland, due to a library dependency on > > > libwayland-server.so.0 and libwayland-client.so.0 (see ldd libpvrs_WAYLAND.so) > > > So the dropped dependency to wayland in ti-sgx-libgbm should have been > > > on ti-sgx-um. > > > Without it, QT5 will not find any EGL backend. > > > > > > So the ti-sgx-um should be adding > > > select BR2_PACKAGE_WAYLAND > > > select BR2_PACKAGE_HAS_LIBEGL_WAYLAND > > > > ACK. > > > > > That way Qt5 can build with a valid EGL backend, using ti-sgx instead > > > of the ancient ti-gfx. > > > But this does nothing to help build kmscube. > > > > Right. I'm still confused by this libgbm thing though, where everyone > > seems to have its own implementation, but there is no common API > > implemented by everybody. > > So am I. The ti-sgx-libgbm repo seems to be maintained by ti.com, but > there seems to be no real effort into making it more than just the > bare minimum to use ti-sgx-um. > > -- > Regards > Einar Jón
Hello Einar, On Fri, 30 Nov 2018 11:05:11 +0100, Einar Jón wrote: > I finally had time to play with the gbm branch on > https://git.bootlin.com/users/thomas-petazzoni/buildroot/log/ > I made 5 commits that add QT with EGLFS-GBM for all 2 setups. Cool! What are the results ? Can you build Qt with all eglfs/gbm implementations (mesa3d, ti and mali) ? > Can I make a pull request, or how do I share them with you? You can either push your branch somewhere (on Github or elsewhere) or otherwise post the patches on the mailing list, making it clear in the cover letter that they depend on another set of patches. Thanks, Thomas
On Fri, 30 Nov 2018 at 11:46, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote: > > Hello Einar, > > On Fri, 30 Nov 2018 11:05:11 +0100, Einar Jón wrote: > > > I finally had time to play with the gbm branch on > > https://git.bootlin.com/users/thomas-petazzoni/buildroot/log/ > > I made 5 commits that add QT with EGLFS-GBM for all 2 setups. > > Cool! What are the results ? Can you build Qt with all eglfs/gbm > implementations (mesa3d, ti and mali) ? Build: Yes Run: ???? I don't have the hardware to test any of the setups (Maybe I can test ti-sgx in December, but since "tomorrow" took me over 3 weeks, I'm not going to promise anything). But I do have QT with EGLFS on all 3 platforms. I disabled kmscube on the 2 that are not MESA. > You can either push your branch somewhere (on Github or elsewhere) or > otherwise post the patches on the mailing list, making it clear in the > cover letter that they depend on another set of patches. I'll just push them to the mailing list. See cover letter for details
Hi Einar, Bernd, On 30/11/2018 13:02, Einar Jón wrote: > On Fri, 30 Nov 2018 at 11:46, Thomas Petazzoni > <thomas.petazzoni@bootlin.com> wrote: >> >> Hello Einar, >> >> On Fri, 30 Nov 2018 11:05:11 +0100, Einar Jón wrote: >> >>> I finally had time to play with the gbm branch on >>> https://git.bootlin.com/users/thomas-petazzoni/buildroot/log/ >>> I made 5 commits that add QT with EGLFS-GBM for all 2 setups. >> >> Cool! What are the results ? Can you build Qt with all eglfs/gbm >> implementations (mesa3d, ti and mali) ? > > Build: Yes > Run: ???? > > I don't have the hardware to test any of the setups (Maybe I can test > ti-sgx in December, > but since "tomorrow" took me over 3 weeks, I'm not going to promise anything). > But I do have QT with EGLFS on all 3 platforms. I disabled kmscube on > the 2 that are not MESA. I think the conclusion from that series is that it does not make sense to make a virtual package of libgbm: kmscube only works with mesa, and even qt5 requires some provider-specific fixups to make it work. So the proposal would be to (for now) drop the virtual package, and instead keep them as separate packages (which are mutually exclusive, of course). All these patches are marked as Changes Requested in patchwork. Regards, Arnout > >> You can either push your branch somewhere (on Github or elsewhere) or >> otherwise post the patches on the mailing list, making it clear in the >> cover letter that they depend on another set of patches. > > I'll just push them to the mailing list. See cover letter for details >
diff --git a/package/opengl/Config.in b/package/opengl/Config.in index 20ee28b06e..fe85bd8e1a 100644 --- a/package/opengl/Config.in +++ b/package/opengl/Config.in @@ -1,5 +1,6 @@ source "package/opengl/libgl/Config.in" source "package/opengl/libegl/Config.in" +source "package/opengl/libgbm/Config.in" source "package/opengl/libgles/Config.in" source "package/opengl/libopenvg/Config.in" source "package/opengl/libopenmax/Config.in" diff --git a/package/opengl/libgbm/Config.in b/package/opengl/libgbm/Config.in new file mode 100644 index 0000000000..ee18c4e6cb --- /dev/null +++ b/package/opengl/libgbm/Config.in @@ -0,0 +1,6 @@ +config BR2_PACKAGE_HAS_LIBGBM + bool + +config BR2_PACKAGE_PROVIDES_LIBGBM + string + depends on BR2_PACKAGE_HAS_LIBGBM diff --git a/package/opengl/libgbm/libgbm.mk b/package/opengl/libgbm/libgbm.mk new file mode 100644 index 0000000000..5b3d8262a5 --- /dev/null +++ b/package/opengl/libgbm/libgbm.mk @@ -0,0 +1,7 @@ +################################################################################ +# +# libgbm +# +################################################################################ + +$(eval $(virtual-package))
Kodi 18.0-Leia will implement stand-alone gbm support alongside x11 & wayland. To enable building libgbm in mesa3d without x11 & wayland we need to create a virtual package for libgbm. Also other packages besides mesa3d may provide libgbm.so, see http://patchwork.ozlabs.org/patch/647235/ http://patchwork.ozlabs.org/patch/939703/ Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> --- package/opengl/Config.in | 1 + package/opengl/libgbm/Config.in | 6 ++++++ package/opengl/libgbm/libgbm.mk | 7 +++++++ 3 files changed, 14 insertions(+) create mode 100644 package/opengl/libgbm/Config.in create mode 100644 package/opengl/libgbm/libgbm.mk