| Message ID | 20221018230820.2385167-1-raj.khem@gmail.com |
|---|---|
| State | Accepted, archived |
| Commit | 42a0cb57503dff5ac2404f83353661fe9f987e5d |
| Headers | show |
| Series | [v2] mesa: Add native patch via a variable | expand |
Can you show examples where this is needed? Custom variable does not seem a good idea. I also worry that it’ll break automated updates (it’s bad enough with mesa-gl, this might make it worse). Alex On Wed 19. Oct 2022 at 1.08, Khem Raj <raj.khem@gmail.com> wrote: > This helps override the SRC_URI in entirety if needed by > and overriding recipe > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > Cc: Kai Kang <kai.kang@windriver.com> > --- > v2: Weakly define NATIVE_PATCHES > > meta/recipes-graphics/mesa/mesa.inc | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/meta/recipes-graphics/mesa/mesa.inc > b/meta/recipes-graphics/mesa/mesa.inc > index c94e439363..04d78a6aa5 100644 > --- a/meta/recipes-graphics/mesa/mesa.inc > +++ b/meta/recipes-graphics/mesa/mesa.inc > @@ -19,10 +19,11 @@ SRC_URI = " > https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \ > file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch > \ > > file://0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch \ > file://0001-util-format-Check-for-NEON-before-using-it.patch \ > + ${NATIVE_PATCHES} \ > " > - > +NATIVE_PATCHES ?= "" > # required by mesa-native on Ubuntu 18.04 with gcc 7.5 when DEBUG_BUILD > enabled > -SRC_URI:append:class-native = " > file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch" > +NATIVE_PATCHES:class-native = > "file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch" > > SRC_URI[sha256sum] = > "b1f9c8fd08f2cae3adf83355bef4d2398e8025f44947332880f2d0066bdafa8c" > > -- > 2.38.0 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#171948): > https://lists.openembedded.org/g/openembedded-core/message/171948 > Mute This Topic: https://lists.openembedded.org/mt/94420106/1686489 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
Come to think of it, the right thing to do is to actually not do anything at all, just adjust the patch explaining that it is needed on 18.04 hosts. Is there a problem when it is applied for the target? Alex On Wed 19. Oct 2022 at 7.42, Alexander Kanavin via lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org> wrote: > Can you show examples where this is needed? Custom variable does not seem > a good idea. I also worry that it’ll break automated updates (it’s bad > enough with mesa-gl, this might make it worse) > > Alex > > On Wed 19. Oct 2022 at 1.08, Khem Raj <raj.khem@gmail.com> wrote: > >> This helps override the SRC_URI in entirety if needed by >> and overriding recipe >> >> Signed-off-by: Khem Raj <raj.khem@gmail.com> >> Cc: Kai Kang <kai.kang@windriver.com> >> --- >> v2: Weakly define NATIVE_PATCHES >> >> meta/recipes-graphics/mesa/mesa.inc | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/meta/recipes-graphics/mesa/mesa.inc >> b/meta/recipes-graphics/mesa/mesa.inc >> index c94e439363..04d78a6aa5 100644 >> --- a/meta/recipes-graphics/mesa/mesa.inc >> +++ b/meta/recipes-graphics/mesa/mesa.inc >> @@ -19,10 +19,11 @@ SRC_URI = " >> https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \ >> >> file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \ >> >> file://0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch \ >> file://0001-util-format-Check-for-NEON-before-using-it.patch \ >> + ${NATIVE_PATCHES} \ >> " >> - >> +NATIVE_PATCHES ?= "" >> # required by mesa-native on Ubuntu 18.04 with gcc 7.5 when DEBUG_BUILD >> enabled >> -SRC_URI:append:class-native = " >> file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch" >> +NATIVE_PATCHES:class-native = >> "file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch" >> >> SRC_URI[sha256sum] = >> "b1f9c8fd08f2cae3adf83355bef4d2398e8025f44947332880f2d0066bdafa8c" >> >> -- >> 2.38.0 >> >> >> >> >> > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#171954): > https://lists.openembedded.org/g/openembedded-core/message/171954 > Mute This Topic: https://lists.openembedded.org/mt/94420106/1686489 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
On 10/19/22 13:50, Alexander Kanavin wrote: > Come to think of it, the right thing to do is to actually not do > anything at all, just adjust the patch explaining that it is needed on > 18.04 hosts. Is there a problem when it is applied for the target? It fails to compile mesa-native on 18.04 if DEBUG_BUILD enabled. But it fails to compile mesa with that patch. Kai > > Alex > > On Wed 19. Oct 2022 at 7.42, Alexander Kanavin via > lists.openembedded.org > <https://urldefense.com/v3/__http://lists.openembedded.org__;!!AjveYdw8EvQ!eZulY7DjDKYv2r3yzQn8Vn8UN9xivFvCN3petJXB1tdJL1wXemB_puMLwiTRps7xFdrrlqhC7Jmgij04C42w4jI$> > <alex.kanavin=gmail.com@lists.openembedded.org> wrote: > > Can you show examples where this is needed? Custom variable does > not seem a good idea. I also worry that it’ll break automated > updates (it’s bad enough with mesa-gl, this might make it worse) > > Alex > > On Wed 19. Oct 2022 at 1.08, Khem Raj <raj.khem@gmail.com> wrote: > > This helps override the SRC_URI in entirety if needed by > and overriding recipe > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > Cc: Kai Kang <kai.kang@windriver.com> > --- > v2: Weakly define NATIVE_PATCHES > > meta/recipes-graphics/mesa/mesa.inc | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/meta/recipes-graphics/mesa/mesa.inc > b/meta/recipes-graphics/mesa/mesa.inc > index c94e439363..04d78a6aa5 100644 > --- a/meta/recipes-graphics/mesa/mesa.inc > +++ b/meta/recipes-graphics/mesa/mesa.inc > @@ -19,10 +19,11 @@ SRC_URI = > "https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz > <https://urldefense.com/v3/__https://mesa.freedesktop.org/archive/mesa-$*7BPV*7D.tar.xz__;JSU!!AjveYdw8EvQ!eZulY7DjDKYv2r3yzQn8Vn8UN9xivFvCN3petJXB1tdJL1wXemB_puMLwiTRps7xFdrrlqhC7Jmgij04FmSFkx8$> > \ > file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \ > file://0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch \ > file://0001-util-format-Check-for-NEON-before-using-it.patch \ > + ${NATIVE_PATCHES} \ > " > - > +NATIVE_PATCHES ?= "" > # required by mesa-native on Ubuntu 18.04 with gcc 7.5 when > DEBUG_BUILD enabled > -SRC_URI:append:class-native = " > file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch" > +NATIVE_PATCHES:class-native = > "file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch" > > SRC_URI[sha256sum] = > "b1f9c8fd08f2cae3adf83355bef4d2398e8025f44947332880f2d0066bdafa8c" > > -- > 2.38.0 > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#171954): > https://lists.openembedded.org/g/openembedded-core/message/171954 > <https://urldefense.com/v3/__https://lists.openembedded.org/g/openembedded-core/message/171954__;!!AjveYdw8EvQ!eZulY7DjDKYv2r3yzQn8Vn8UN9xivFvCN3petJXB1tdJL1wXemB_puMLwiTRps7xFdrrlqhC7Jmgij04ZTM5SzE$> > Mute This Topic: > https://lists.openembedded.org/mt/94420106/1686489 > <https://urldefense.com/v3/__https://lists.openembedded.org/mt/94420106/1686489__;!!AjveYdw8EvQ!eZulY7DjDKYv2r3yzQn8Vn8UN9xivFvCN3petJXB1tdJL1wXemB_puMLwiTRps7xFdrrlqhC7Jmgij04N8vN8aQ$> > Group Owner: openembedded-core+owner@lists.openembedded.org > <mailto:openembedded-core%2Bowner@lists.openembedded.org> > Unsubscribe: > https://lists.openembedded.org/g/openembedded-core/unsub > <https://urldefense.com/v3/__https://lists.openembedded.org/g/openembedded-core/unsub__;!!AjveYdw8EvQ!eZulY7DjDKYv2r3yzQn8Vn8UN9xivFvCN3petJXB1tdJL1wXemB_puMLwiTRps7xFdrrlqhC7Jmgij047kVLbgo$> > [alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Wed, Oct 19, 2022 at 7:51 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > Come to think of it, the right thing to do is to actually not do anything > at all, just adjust the patch explaining that it is needed on 18.04 hosts. > Is there a problem when it is applied for the target? > Yes, it causes build to fail when DEBUG_BUILD is enabled.
On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > Can you show examples where this is needed? Custom variable does not seem a good idea. I also worry that it’ll break automated updates (it’s bad enough with mesa-gl, this might make it worse). https://github.com/ndechesne/meta-qcom/blob/master/recipes-graphics/mesa/mesa_git.bb > > Alex > > On Wed 19. Oct 2022 at 1.08, Khem Raj <raj.khem@gmail.com> wrote: >> >> This helps override the SRC_URI in entirety if needed by >> and overriding recipe >> >> Signed-off-by: Khem Raj <raj.khem@gmail.com> >> Cc: Kai Kang <kai.kang@windriver.com> >> --- >> v2: Weakly define NATIVE_PATCHES >> >> meta/recipes-graphics/mesa/mesa.inc | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc >> index c94e439363..04d78a6aa5 100644 >> --- a/meta/recipes-graphics/mesa/mesa.inc >> +++ b/meta/recipes-graphics/mesa/mesa.inc >> @@ -19,10 +19,11 @@ SRC_URI = "https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \ >> file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \ >> file://0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch \ >> file://0001-util-format-Check-for-NEON-before-using-it.patch \ >> + ${NATIVE_PATCHES} \ >> " >> - >> +NATIVE_PATCHES ?= "" >> # required by mesa-native on Ubuntu 18.04 with gcc 7.5 when DEBUG_BUILD enabled >> -SRC_URI:append:class-native = " file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch" >> +NATIVE_PATCHES:class-native = "file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch" >> >> SRC_URI[sha256sum] = "b1f9c8fd08f2cae3adf83355bef4d2398e8025f44947332880f2d0066bdafa8c" >> >> -- >> 2.38.0 >> >> >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> View/Reply Online (#171948): https://lists.openembedded.org/g/openembedded-core/message/171948 >> Mute This Topic: https://lists.openembedded.org/mt/94420106/1686489 >> Group Owner: openembedded-core+owner@lists.openembedded.org >> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] >> -=-=-=-=-=-=-=-=-=-=-=- >>
On Wed, 19 Oct 2022 at 08:34, Khem Raj <raj.khem@gmail.com> wrote: > > On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin > <alex.kanavin@gmail.com> wrote: > > > > Can you show examples where this is needed? Custom variable does not seem a good idea. I also worry that it’ll break automated updates (it’s bad enough with mesa-gl, this might make it worse). > > https://github.com/ndechesne/meta-qcom/blob/master/recipes-graphics/mesa/mesa_git.bb "require recipes-graphics/mesa/mesa.inc" Using recipe includes across layers like this is not a good idea. It imposes requirements on core to continue providing the .inc, and not doing anything with mesa that can 'break' users of that include. Please make it self-contained. Alex
This also begs the question if mesa-gl is actually used by anyone, and what warrants its continued inclusion in core as opposed to product/BSP layers. I'll propose dropping the recipe and merging .inc into mesa.bb once patches start flowing. The original commit was: https://git.yoctoproject.org/poky/commit/?h=master-next&id=015cb13 Alex On Wed, 19 Oct 2022 at 08:54, Alexander Kanavin via lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org> wrote: > > On Wed, 19 Oct 2022 at 08:34, Khem Raj <raj.khem@gmail.com> wrote: > > > > On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin > > <alex.kanavin@gmail.com> wrote: > > > > > > Can you show examples where this is needed? Custom variable does not seem a good idea. I also worry that it’ll break automated updates (it’s bad enough with mesa-gl, this might make it worse). > > > > https://github.com/ndechesne/meta-qcom/blob/master/recipes-graphics/mesa/mesa_git.bb > > "require recipes-graphics/mesa/mesa.inc" > > Using recipe includes across layers like this is not a good idea. It > imposes requirements on core to continue providing the .inc, and not > doing anything with mesa that can 'break' users of that include. > > Please make it self-contained. > > Alex > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#171959): https://lists.openembedded.org/g/openembedded-core/message/171959 > Mute This Topic: https://lists.openembedded.org/mt/94420106/1686489 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Tue, Oct 18, 2022 at 11:54 PM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > On Wed, 19 Oct 2022 at 08:34, Khem Raj <raj.khem@gmail.com> wrote: > > > > On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin > > <alex.kanavin@gmail.com> wrote: > > > > > > Can you show examples where this is needed? Custom variable does not seem a good idea. I also worry that it’ll break automated updates (it’s bad enough with mesa-gl, this might make it worse). > > > > https://github.com/ndechesne/meta-qcom/blob/master/recipes-graphics/mesa/mesa_git.bb > > "require recipes-graphics/mesa/mesa.inc" > > Using recipe includes across layers like this is not a good idea. It > imposes requirements on core to continue providing the .inc, and not > doing anything with mesa that can 'break' users of that include. > the reason for .inc to exist does include this usecase. oe-core metadata is extensible by these constructs, it's similar to bbclass perhaps a bit smaller in scope. Getting rid of .inc will state that we do not allow other layers to use it. These are APIs of sorts that oe-core exports and people build on them, its fine if they should be changed but there should some well understood path otherwise they just make hard things harder. The load of upgrading from one release to other is already high and it keeps going up. > Please make it self-contained. > > Alex
On 19 Oct 2022, at 07:34, Khem Raj via lists.openembedded.org <raj.khem=gmail.com@lists.openembedded.org> wrote: > > On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin > <alex.kanavin@gmail.com> wrote: >> >> Can you show examples where this is needed? Custom variable does not seem a good idea. I also worry that it’ll break automated updates (it’s bad enough with mesa-gl, this might make it worse). > > https://github.com/ndechesne/meta-qcom/blob/master/recipes-graphics/mesa/mesa_git.bb That is, well, horrible. *If* we’re going to expose a mesa.inc that people outside of core can use to package up their own random Mesa SHA then mesa.inc should just be the packaging logic. However, I don’t understand something about the patch. Why do we only need to apply it on native builds? It’s a backport from upstream, so should be the fix. If it breaks when applied to target builds, is there a bug upstream for that? Ross
Khem, sorry but no. We have well defined mechanisms for reuse, and including bits and pieces of recipes from completely different layers is not one of them. I do not want to hear even more complaints about 'breaking' things than I already do when trying to make things better, simpler and more maintainable, and I do not want to be paralysed by fear of invisible breakage in custom layers when doing so. If you *really* want to make bits of mesa recipe 'public', put them in a bbclass. Alex On Wed, 19 Oct 2022 at 17:29, Ross Burton <Ross.Burton@arm.com> wrote: > > On 19 Oct 2022, at 07:34, Khem Raj via lists.openembedded.org <raj.khem=gmail.com@lists.openembedded.org> wrote: > > > > On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin > > <alex.kanavin@gmail.com> wrote: > >> > >> Can you show examples where this is needed? Custom variable does not seem a good idea. I also worry that it’ll break automated updates (it’s bad enough with mesa-gl, this might make it worse). > > > > https://github.com/ndechesne/meta-qcom/blob/master/recipes-graphics/mesa/mesa_git.bb > > That is, well, horrible. > > *If* we’re going to expose a mesa.inc that people outside of core can use to package up their own random Mesa SHA then mesa.inc should just be the packaging logic. > > However, I don’t understand something about the patch. > > Why do we only need to apply it on native builds? It’s a backport from upstream, so should be the fix. If it breaks when applied to target builds, is there a bug upstream for that? > > Ross
On Wed, Oct 19, 2022 at 5:29 PM Ross Burton <ross.burton@arm.com> wrote: > On 19 Oct 2022, at 07:34, Khem Raj via lists.openembedded.org <raj.khem= > gmail.com@lists.openembedded.org> wrote: > > > > On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin > > <alex.kanavin@gmail.com> wrote: > >> > >> Can you show examples where this is needed? Custom variable does not > seem a good idea. I also worry that it’ll break automated updates (it’s bad > enough with mesa-gl, this might make it worse). > > > > > https://github.com/ndechesne/meta-qcom/blob/master/recipes-graphics/mesa/mesa_git.bb > > That is, well, horrible. > > *If* we’re going to expose a mesa.inc that people outside of core can use > to package up their own random Mesa SHA then mesa.inc should just be the > packaging logic. > Well I've seen many mesa/pulseaudio recipes which were using mesa.inc/pulseaudio.inc and even when they were a bit terrible, then it was still better than duplicating all of it. e.g. https://github.com/webOS-ports/meta-pine64-luneos/commits/8946d3e2350ae83fbb001ba640db59b207341481/recipes-graphics/mesa/mesa_%25.bbappend https://github.com/shr-project/meta-webosose/commits/master/meta-webos/recipes-multimedia/pulseaudio And better than some other recipes which start with "require recipes-foo/foos/foo_1.0.bb" and then set PV to 2.0 and do few other changes. I never expected .inc file to be _required_ wide range of possible versions, people who re-use it to build older or newer version need to deal with possible incompatibilities in their layer even if it sometimes might require whole .inc file to be imported into their layer, when the benefit of reusing it is much smaller than required modifications (e.g. when pulseaudio in oe-core was upgraded to use meson while our old version was still built with autotools or even this small change, but in :prepend https://git.openembedded.org/openembedded-core/commit/?id=e5399a09bf44700f97607b283379172dac0cf9c7 . > > However, I don’t understand something about the patch. > > Why do we only need to apply it on native builds? It’s a backport from > upstream, so should be the fix. If it breaks when applied to target > builds, is there a bug upstream for that? FWIW: I've reported that it breaks builds with DEBUG_BUILD instead of fixing them in: https://lists.openembedded.org/g/openembedded-core/message/169002 but Kai replied that it still works for him until it didn't which probably lead to this change to apply it only in master. I've reported the same in upstream MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17439#note_1499443 but I didn't create new ticket about it (as it was supposed to work for others). Cheers,
On Wed, Oct 19, 2022 at 8:29 AM Ross Burton <Ross.Burton@arm.com> wrote: > > On 19 Oct 2022, at 07:34, Khem Raj via lists.openembedded.org <raj.khem=gmail.com@lists.openembedded.org> wrote: > > > > On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin > > <alex.kanavin@gmail.com> wrote: > >> > >> Can you show examples where this is needed? Custom variable does not seem a good idea. I also worry that it’ll break automated updates (it’s bad enough with mesa-gl, this might make it worse). > > > > https://github.com/ndechesne/meta-qcom/blob/master/recipes-graphics/mesa/mesa_git.bb > > That is, well, horrible. > > *If* we’re going to expose a mesa.inc that people outside of core can use to package up their own random Mesa SHA then mesa.inc should just be the packaging logic. Right, and it will be an improvement for end users, since it helps in deploying the mesa forks easy, We should be cognizant of the fact that people are doing their own distributions since that is what OE makes it easy and is its USP. Making it too rigid a policy also results in harder forks. > > However, I don’t understand something about the patch. > > Why do we only need to apply it on native builds? It’s a backport from upstream, so should be the fix. If it breaks when applied to target builds, is there a bug upstream for that? > This is to provide a crutch to compile it with ubuntu 18.04 gcc. > Ross
On Wed, 2022-10-19 at 18:04 +0200, Alexander Kanavin wrote: > Khem, sorry but no. We have well defined mechanisms for reuse, and > including bits and pieces of recipes from completely different layers > is not one of them. I do not want to hear even more complaints about > 'breaking' things than I already do when trying to make things better, > simpler and more maintainable, and I do not want to be paralysed by > fear of invisible breakage in custom layers when doing so. > > If you *really* want to make bits of mesa recipe 'public', put them in > a bbclass. I disagree with this a bit. The .inc files are there to allow this in some cases. It used to be something which happened a lot as there were many versions of things. Thankfully we don't have so many versions now. Removing .inc files which aren't needed is fine, but removing them where there is BSP usage seems a bit unfair. We should try and ensure the .inc files really only include the common packaging code. Obviously those using the .inc files do so knowing they can change from under them. Cheers, Richard
On 10/19/22 5:35 AM, Alexander Kanavin wrote: > This also begs the question if mesa-gl is actually used by anyone, and > what warrants its continued inclusion in core as opposed to > product/BSP layers. I'll propose dropping the recipe and merging .inc > into mesa.bb once patches start flowing. > > The original commit was: > https://git.yoctoproject.org/poky/commit/?h=master-next&id=015cb13 (I just saw this, so a little late on the reply, but..) mesa-gl is ABSOLUTELY still being used. It's needed for libmali usage. Not everyone wants to use lima support for graphics. It was broken into two separate packages so that is was VERY clear if you were using mesa for 'everything' (mesa), or mesa JUST for 'gl' (not gles). --Mark > Alex > > On Wed, 19 Oct 2022 at 08:54, Alexander Kanavin via > lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org> > wrote: >> >> On Wed, 19 Oct 2022 at 08:34, Khem Raj <raj.khem@gmail.com> wrote: >>> >>> On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin >>> <alex.kanavin@gmail.com> wrote: >>>> >>>> Can you show examples where this is needed? Custom variable does not seem a good idea. I also worry that it’ll break automated updates (it’s bad enough with mesa-gl, this might make it worse). >>> >>> https://github.com/ndechesne/meta-qcom/blob/master/recipes-graphics/mesa/mesa_git.bb >> >> "require recipes-graphics/mesa/mesa.inc" >> >> Using recipe includes across layers like this is not a good idea. It >> imposes requirements on core to continue providing the .inc, and not >> doing anything with mesa that can 'break' users of that include. >> >> Please make it self-contained. >> >> Alex >> >> >> >> >> >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> View/Reply Online (#171964): https://lists.openembedded.org/g/openembedded-core/message/171964 >> Mute This Topic: https://lists.openembedded.org/mt/94420106/3616948 >> Group Owner: openembedded-core+owner@lists.openembedded.org >> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [mark.hatle@kernel.crashing.org] >> -=-=-=-=-=-=-=-=-=-=-=- >>
On Wed, 26 Oct 2022 at 16:35, Mark Hatle <mark.hatle@kernel.crashing.org> wrote: > (I just saw this, so a little late on the reply, but..) > > mesa-gl is ABSOLUTELY still being used. It's needed for libmali usage. Not > everyone wants to use lima support for graphics. > > It was broken into two separate packages so that is was VERY clear if you were > using mesa for 'everything' (mesa), or mesa JUST for 'gl' (not gles). Okay, I'm not going to propose this, but can you clarify, what is the current use for 'gl'? Is it just opengl 3d in standalone x server based systems (which is slowly dying), or is there something else to it? Alex
On 10/26/22 11:03 AM, Alexander Kanavin wrote: > On Wed, 26 Oct 2022 at 16:35, Mark Hatle <mark.hatle@kernel.crashing.org> wrote: >> (I just saw this, so a little late on the reply, but..) >> >> mesa-gl is ABSOLUTELY still being used. It's needed for libmali usage. Not >> everyone wants to use lima support for graphics. >> >> It was broken into two separate packages so that is was VERY clear if you were >> using mesa for 'everything' (mesa), or mesa JUST for 'gl' (not gles). > > Okay, I'm not going to propose this, but can you clarify, what is the > current use for 'gl'? Is it just opengl 3d in standalone x server > based systems (which is slowly dying), or is there something else to > it? Anything that needs "OpenGL", i.e. Wayland/Weston, X11, Chromium, etc etc etc. These all end up linking to a combination of libmali and mesa-gl. Pretty much anything that depends on 'virtual/gl' (vs virtual/libgles1,2,3). libmali provides virtual/libgles1 and virtual/libgles2 and a few other things that meta-gl doesn't. libmali also doesn't include the DRM/DRI parts. This comes from mesa-gl. --Mark > Alex
On Wed, Oct 26, 2022 at 12:21 PM Mark Hatle <mark.hatle@kernel.crashing.org> wrote: > > > > On 10/26/22 11:03 AM, Alexander Kanavin wrote: > > On Wed, 26 Oct 2022 at 16:35, Mark Hatle <mark.hatle@kernel.crashing.org> wrote: > >> (I just saw this, so a little late on the reply, but..) > >> > >> mesa-gl is ABSOLUTELY still being used. It's needed for libmali usage. Not > >> everyone wants to use lima support for graphics. > >> > >> It was broken into two separate packages so that is was VERY clear if you were > >> using mesa for 'everything' (mesa), or mesa JUST for 'gl' (not gles). > > > > Okay, I'm not going to propose this, but can you clarify, what is the > > current use for 'gl'? Is it just opengl 3d in standalone x server > > based systems (which is slowly dying), or is there something else to > > it? Are you specifically talking about libmali with the following statements? I would say that in general libmali is probably not doing things in the "normal" way if so, although I'm not trying to say that it isn't a legitimate way to do it. > > Anything that needs "OpenGL", i.e. Wayland/Weston, X11, Chromium, etc etc etc. > These all end up linking to a combination of libmali and mesa-gl. In general (maybe not for libmali) Wayland and Weston themselves don't use OpenGL, or mesa-gl. Individual clients may be able to use it, although it's rare in my (incomplete) experience. Most of the OpenGL users in Wayland/Weston are going through XWayland/X11 and using GLX. > > Pretty much anything that depends on 'virtual/gl' (vs virtual/libgles1,2,3). > libmali provides virtual/libgles1 and virtual/libgles2 and a few other things > that meta-gl doesn't. > > libmali also doesn't include the DRM/DRI parts. This comes from mesa-gl. In general, DRM/DRI doesn't come from mesa-gl. libdrm is its own recipe, and libgbm comes from mesa proper, or from some other dedicated vendor specific libgbm recipe. If this is sidetracking the discussion please ignore; I'm just a little confused by the above statements because either A) libmali is really weird B) my understanding of things is _way_ off, or C) the statements aren't quite correct. > > --Mark > > > Alex > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#172165): https://lists.openembedded.org/g/openembedded-core/message/172165 > Mute This Topic: https://lists.openembedded.org/mt/94420106/3616693 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [JPEWhacker@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
Is there a combination of libmali recipe and mesa-gl somewhere public so we could try to pick it apart and see what links to where? My (perhaps confused) understanding is similar to Joshua's: 'gl' is basically 'opengl in x11' or 'opengl rendered to memory', and if a system uses neither, then it is not needed. Alex On Wed, 26 Oct 2022 at 19:48, Joshua Watt <jpewhacker@gmail.com> wrote: > > On Wed, Oct 26, 2022 at 12:21 PM Mark Hatle > <mark.hatle@kernel.crashing.org> wrote: > > > > > > > > On 10/26/22 11:03 AM, Alexander Kanavin wrote: > > > On Wed, 26 Oct 2022 at 16:35, Mark Hatle <mark.hatle@kernel.crashing.org> wrote: > > >> (I just saw this, so a little late on the reply, but..) > > >> > > >> mesa-gl is ABSOLUTELY still being used. It's needed for libmali usage. Not > > >> everyone wants to use lima support for graphics. > > >> > > >> It was broken into two separate packages so that is was VERY clear if you were > > >> using mesa for 'everything' (mesa), or mesa JUST for 'gl' (not gles). > > > > > > Okay, I'm not going to propose this, but can you clarify, what is the > > > current use for 'gl'? Is it just opengl 3d in standalone x server > > > based systems (which is slowly dying), or is there something else to > > > it? > > Are you specifically talking about libmali with the following statements? > > I would say that in general libmali is probably not doing things in > the "normal" way if so, although I'm not trying to say that it isn't a > legitimate way to do it. > > > > > Anything that needs "OpenGL", i.e. Wayland/Weston, X11, Chromium, etc etc etc. > > These all end up linking to a combination of libmali and mesa-gl. > > In general (maybe not for libmali) Wayland and Weston themselves don't > use OpenGL, or mesa-gl. Individual clients may be able to use it, > although it's rare in my (incomplete) experience. Most of the OpenGL > users in Wayland/Weston are going through XWayland/X11 and using GLX. > > > > > Pretty much anything that depends on 'virtual/gl' (vs virtual/libgles1,2,3). > > libmali provides virtual/libgles1 and virtual/libgles2 and a few other things > > that meta-gl doesn't. > > > > libmali also doesn't include the DRM/DRI parts. This comes from mesa-gl. > > In general, DRM/DRI doesn't come from mesa-gl. libdrm is its own > recipe, and libgbm comes from mesa proper, or from some other > dedicated vendor specific libgbm recipe. > > > If this is sidetracking the discussion please ignore; I'm just a > little confused by the above statements because either A) libmali is > really weird B) my understanding of things is _way_ off, or C) the > statements aren't quite correct. > > > > > --Mark > > > > > Alex > > > > -=-=-=-=-=-=-=-=-=-=-=- > > Links: You receive all messages sent to this group. > > View/Reply Online (#172165): https://lists.openembedded.org/g/openembedded-core/message/172165 > > Mute This Topic: https://lists.openembedded.org/mt/94420106/3616693 > > Group Owner: openembedded-core+owner@lists.openembedded.org > > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [JPEWhacker@gmail.com] > > -=-=-=-=-=-=-=-=-=-=-=- > >
On 10/26/22 12:48 PM, Joshua Watt wrote: > On Wed, Oct 26, 2022 at 12:21 PM Mark Hatle > <mark.hatle@kernel.crashing.org> wrote: >> >> >> >> On 10/26/22 11:03 AM, Alexander Kanavin wrote: >>> On Wed, 26 Oct 2022 at 16:35, Mark Hatle <mark.hatle@kernel.crashing.org> wrote: >>>> (I just saw this, so a little late on the reply, but..) >>>> >>>> mesa-gl is ABSOLUTELY still being used. It's needed for libmali usage. Not >>>> everyone wants to use lima support for graphics. >>>> >>>> It was broken into two separate packages so that is was VERY clear if you were >>>> using mesa for 'everything' (mesa), or mesa JUST for 'gl' (not gles). >>> >>> Okay, I'm not going to propose this, but can you clarify, what is the >>> current use for 'gl'? Is it just opengl 3d in standalone x server >>> based systems (which is slowly dying), or is there something else to >>> it? > > Are you specifically talking about libmali with the following statements? > > I would say that in general libmali is probably not doing things in > the "normal" way if so, although I'm not trying to say that it isn't a > legitimate way to do it. https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-core/recipes-graphics/libgles/libmali-xlnx.bb libmali is providing all of the ELG/GLES/GLES2 and KHR headers. It is providing the libegl, libgles1, libgles2, libgbm. Also provides interfaces to fbdev, X11, and Wayland usage. But all of this is specific to ONLY gles 1 and 2 interfaces. >> Anything that needs "OpenGL", i.e. Wayland/Weston, X11, Chromium, etc etc etc. >> These all end up linking to a combination of libmali and mesa-gl. > > In general (maybe not for libmali) Wayland and Weston themselves don't > use OpenGL, or mesa-gl. Individual clients may be able to use it, > although it's rare in my (incomplete) experience. Most of the OpenGL > users in Wayland/Weston are going through XWayland/X11 and using GLX. Weston won't build without a functional OpenGL/libgles configuration. It errors about missing interfaces. Even with libmali, some of the items need to be disabled as they require libgles3, which libmali does not support. >> >> Pretty much anything that depends on 'virtual/gl' (vs virtual/libgles1,2,3). >> libmali provides virtual/libgles1 and virtual/libgles2 and a few other things >> that meta-gl doesn't. >> >> libmali also doesn't include the DRM/DRI parts. This comes from mesa-gl. > > In general, DRM/DRI doesn't come from mesa-gl. libdrm is its own > recipe, and libgbm comes from mesa proper, or from some other > dedicated vendor specific libgbm recipe. https://git.yoctoproject.org/poky/tree/meta/recipes-graphics/mesa/mesa-gl_22.2.0.bb This enables the packageconfig for the gallium set. Our bbappend enabled the dri3 and gallium specifically: https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-core/recipes-graphics/mesa/mesa-gl_%25.bbappend This allows the display out for any application using wayland/xwayland. > > If this is sidetracking the discussion please ignore; I'm just a > little confused by the above statements because either A) libmali is > really weird B) my understanding of things is _way_ off, or C) the > statements aren't quite correct. libmali just provides a basic set of interfaces that call the mali co-processor to perform actions. The interfaces happen to be libgles1 and 2 and defined by Kronos. It does NOT provide any way to display content, the DRI/DRM interfaces are used for this. So you end up with a configuration for a system that COULD be as simple as libmali + fbdev, where the application renders something with libmali, then uses fbdev to display it. Or you can use X11, or you can use Wayland/Weston. We have a configuration where Chromium is linked to BOTH mesa-gl and libmali in order to do it's rendering, while using Wayland as the compositor/display interfaces... which goes through the DRM system. But ultimately the openGL part is just an engine to "do something", which usually involves drawing shapes into memory. The 'display' side of things happens elsewhere.. and this elsewhere CAN be in mesa, it CAN be in wayland, it can be fbdev, etc... lots of ways, but unless you are creating all custom apps -- you need to be able to use mesa and the existing X11 or Wayland/Weston interfaces (via mesa) in order to do this. --Mark >> >> --Mark >> >>> Alex >> >> >> >> >> >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> View/Reply Online (#172167): https://lists.openembedded.org/g/openembedded-core/message/172167 >> Mute This Topic: https://lists.openembedded.org/mt/94420106/3616948 >> Group Owner: openembedded-core+owner@lists.openembedded.org >> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [mark.hatle@kernel.crashing.org] >> -=-=-=-=-=-=-=-=-=-=-=- >>
On 10/26/22 1:01 PM, Alexander Kanavin wrote: > Is there a combination of libmali recipe and mesa-gl somewhere public > so we could try to pick it apart and see what links to where? libmali is ALWAYS implementation specific. You will need to pick a vendor and build for it. What is generic is the application interface (from what I've been told.). I can give you the AMD (Xilinx) instructions. But you likely won't be able to actually execute the code without a corresponding board. (AFAIK QEMU doesn't have any mali400 emulation.) And to be clear, libmali provides the interfaces, but it is NOT a replacement to mesa, it works WITH mesa, just the 'gl' part (not the gles part). The following is an abbreviated attempt to show how the pieces interact with each other. It may not be 100% correct, I am definitely not an expert at this. (For example, I don't understand why it's "DRM" in some places but "DRI" in others. These seem to be 'generally' the same systems.) But it's how the parts and pieces appear to be put together based on a functioning system. In a 'normal' system (mesa): mesa provides: libglapi.so.0 libEGL.so.1 libGLESv2.so.2 (and others) The CONFIG_DRM_LIMA backend and whatever the display port DRM (CONFIG_DRM_XLNX) go through a dlopened backend module, which USUALLY talks to a kernel module for any hardware access through a standard (known) kernel interface. In our case the dynamic modules would be the lima_dri.so and xlnx_dri.so. glmark2-es2-wayland -> libwayland-client libwayland-cursor libwayland-egl.so.1 I believe the libwayland-egl talks to weston "somehow" for the egl interfaces, via the libwayland-client? but I'm fuzzy here. Weston has two related items: drm-backend.o -> libglapi.so.0 (dlopened) This bit uses mesa to access the DRM backend to actually display the stuff.. gl-backend.so -> libwayland-server libEGL.so.1 libGLESv2.so.2 This backend is used to render the items. So the glmark2 does it's benchmarking and renders (gl-backend) through Weston backends to the display port (drm-backend). In the above case it all comes from mesa, the drm and libELG/libGLESv2 parts. The following shows a libmali configured system as a contrasts to the above: libmali-xlnx provides: libEGL.so.1 libGLESv1_CM.so.1 libGLESv2.so.2 libmali.so.9 libgbm.so.1 (also provides specific backends for fbdev, headless, wayland and x11) It talks to a backend kernel module called 'mali.ko' mesa provides: libGL.so.1 libglapi.so.0 and also swrast dri interface glmark2-es2-wayland -> libwayland-client libwayland-cursor libwayland-egl.so.1 (same as above) drm-backend.o -> libwayland-server libdrm.so.2 libMali.so.9 gl-backend.so -> libwayland-server libMali.so.9 So in the above, libMali is providing all of the APIs of libEGL and libGLESv2, as well as (enough of) libglapi for the built in raster implementation. Compiling things like Chromium that will link directly, you move from linking to libGL.so from mesa to linking in libMali, along with libGL from mesa. The libMali will provide the core set of APIs, while the libGL will augement them with additional APIs. Cairo is another utility that similar modifies in this way. To re-iterate, it's NOT a "swap libmali" and re-use everything. You need to rebuild anything that links to libgles or libgl or even libglapi with this new configuration. It's API compatible, NOT ABI compatible! I hope this helps. As far as letting you play with it, I'm working through the final stuff and should have something I can push to langdale/master on the meta-xilinx and meta-xilinx-tools soon. --Mark > My (perhaps confused) understanding is similar to Joshua's: 'gl' is > basically 'opengl in x11' or 'opengl rendered to memory', and if a > system uses neither, then it is not needed. > > Alex > > On Wed, 26 Oct 2022 at 19:48, Joshua Watt <jpewhacker@gmail.com> wrote: >> >> On Wed, Oct 26, 2022 at 12:21 PM Mark Hatle >> <mark.hatle@kernel.crashing.org> wrote: >>> >>> >>> >>> On 10/26/22 11:03 AM, Alexander Kanavin wrote: >>>> On Wed, 26 Oct 2022 at 16:35, Mark Hatle <mark.hatle@kernel.crashing.org> wrote: >>>>> (I just saw this, so a little late on the reply, but..) >>>>> >>>>> mesa-gl is ABSOLUTELY still being used. It's needed for libmali usage. Not >>>>> everyone wants to use lima support for graphics. >>>>> >>>>> It was broken into two separate packages so that is was VERY clear if you were >>>>> using mesa for 'everything' (mesa), or mesa JUST for 'gl' (not gles). >>>> >>>> Okay, I'm not going to propose this, but can you clarify, what is the >>>> current use for 'gl'? Is it just opengl 3d in standalone x server >>>> based systems (which is slowly dying), or is there something else to >>>> it? >> >> Are you specifically talking about libmali with the following statements? >> >> I would say that in general libmali is probably not doing things in >> the "normal" way if so, although I'm not trying to say that it isn't a >> legitimate way to do it. >> >>> >>> Anything that needs "OpenGL", i.e. Wayland/Weston, X11, Chromium, etc etc etc. >>> These all end up linking to a combination of libmali and mesa-gl. >> >> In general (maybe not for libmali) Wayland and Weston themselves don't >> use OpenGL, or mesa-gl. Individual clients may be able to use it, >> although it's rare in my (incomplete) experience. Most of the OpenGL >> users in Wayland/Weston are going through XWayland/X11 and using GLX. >> >>> >>> Pretty much anything that depends on 'virtual/gl' (vs virtual/libgles1,2,3). >>> libmali provides virtual/libgles1 and virtual/libgles2 and a few other things >>> that meta-gl doesn't. >>> >>> libmali also doesn't include the DRM/DRI parts. This comes from mesa-gl. >> >> In general, DRM/DRI doesn't come from mesa-gl. libdrm is its own >> recipe, and libgbm comes from mesa proper, or from some other >> dedicated vendor specific libgbm recipe. >> >> >> If this is sidetracking the discussion please ignore; I'm just a >> little confused by the above statements because either A) libmali is >> really weird B) my understanding of things is _way_ off, or C) the >> statements aren't quite correct. >> >>> >>> --Mark >>> >>>> Alex >>> >>> >>> >>> >>> >>> -=-=-=-=-=-=-=-=-=-=-=- >>> Links: You receive all messages sent to this group. >>> View/Reply Online (#172168): https://lists.openembedded.org/g/openembedded-core/message/172168 >>> Mute This Topic: https://lists.openembedded.org/mt/94420106/3616948 >>> Group Owner: openembedded-core+owner@lists.openembedded.org >>> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [mark.hatle@kernel.crashing.org] >>> -=-=-=-=-=-=-=-=-=-=-=- >>>
Thanks. What I would want to understand is whether this arrangement should have its own MACHINE_FEATURE, e.g. 'vendor-egl' or similar, and then mesa proper would be configured accordingly to disable bits that come from the vendor. Is there a particular need for a separate recipe? Alex On Thu, 27 Oct 2022 at 02:46, Mark Hatle <mark.hatle@kernel.crashing.org> wrote: > > > > On 10/26/22 1:01 PM, Alexander Kanavin wrote: > > Is there a combination of libmali recipe and mesa-gl somewhere public > > so we could try to pick it apart and see what links to where? > > libmali is ALWAYS implementation specific. You will need to pick a vendor and > build for it. What is generic is the application interface (from what I've been > told.). I can give you the AMD (Xilinx) instructions. But you likely won't be > able to actually execute the code without a corresponding board. (AFAIK QEMU > doesn't have any mali400 emulation.) > > And to be clear, libmali provides the interfaces, but it is NOT a replacement to > mesa, it works WITH mesa, just the 'gl' part (not the gles part). > > The following is an abbreviated attempt to show how the pieces interact with > each other. It may not be 100% correct, I am definitely not an expert at this. > (For example, I don't understand why it's "DRM" in some places but "DRI" in > others. These seem to be 'generally' the same systems.) But it's how the parts > and pieces appear to be put together based on a functioning system. > > > In a 'normal' system (mesa): > > mesa provides: > libglapi.so.0 > libEGL.so.1 > libGLESv2.so.2 > (and others) > > The CONFIG_DRM_LIMA backend and whatever the display port DRM (CONFIG_DRM_XLNX) > go through a dlopened backend module, which USUALLY talks to a kernel module for > any hardware access through a standard (known) kernel interface. > > In our case the dynamic modules would be the lima_dri.so and xlnx_dri.so. > > glmark2-es2-wayland -> > libwayland-client > libwayland-cursor > libwayland-egl.so.1 > > I believe the libwayland-egl talks to weston "somehow" for the egl interfaces, > via the libwayland-client? but I'm fuzzy here. > > Weston has two related items: > > drm-backend.o -> > libglapi.so.0 (dlopened) > > This bit uses mesa to access the DRM backend to actually display the stuff.. > > gl-backend.so -> > libwayland-server > libEGL.so.1 > libGLESv2.so.2 > > This backend is used to render the items. > > > So the glmark2 does it's benchmarking and renders (gl-backend) through Weston > backends to the display port (drm-backend). > > In the above case it all comes from mesa, the drm and libELG/libGLESv2 parts. > > > > The following shows a libmali configured system as a contrasts to the above: > > libmali-xlnx provides: > > libEGL.so.1 > libGLESv1_CM.so.1 > libGLESv2.so.2 > libmali.so.9 > libgbm.so.1 > > (also provides specific backends for fbdev, headless, wayland and x11) > > > It talks to a backend kernel module called 'mali.ko' > > mesa provides: > > libGL.so.1 > libglapi.so.0 > > and also swrast dri interface > > glmark2-es2-wayland -> > libwayland-client > libwayland-cursor > libwayland-egl.so.1 > > (same as above) > > drm-backend.o -> > libwayland-server > libdrm.so.2 > libMali.so.9 > > gl-backend.so -> > libwayland-server > libMali.so.9 > > So in the above, libMali is providing all of the APIs of libEGL and libGLESv2, > as well as (enough of) libglapi for the built in raster implementation. > > > Compiling things like Chromium that will link directly, you move from linking to > libGL.so from mesa to linking in libMali, along with libGL from mesa. The > libMali will provide the core set of APIs, while the libGL will augement them > with additional APIs. > > Cairo is another utility that similar modifies in this way. > > > To re-iterate, it's NOT a "swap libmali" and re-use everything. You need to > rebuild anything that links to libgles or libgl or even libglapi with this new > configuration. It's API compatible, NOT ABI compatible! > > > I hope this helps. As far as letting you play with it, I'm working through the > final stuff and should have something I can push to langdale/master on the > meta-xilinx and meta-xilinx-tools soon. > > --Mark > > > My (perhaps confused) understanding is similar to Joshua's: 'gl' is > > basically 'opengl in x11' or 'opengl rendered to memory', and if a > > system uses neither, then it is not needed. > > > > Alex > > > > On Wed, 26 Oct 2022 at 19:48, Joshua Watt <jpewhacker@gmail.com> wrote: > >> > >> On Wed, Oct 26, 2022 at 12:21 PM Mark Hatle > >> <mark.hatle@kernel.crashing.org> wrote: > >>> > >>> > >>> > >>> On 10/26/22 11:03 AM, Alexander Kanavin wrote: > >>>> On Wed, 26 Oct 2022 at 16:35, Mark Hatle <mark.hatle@kernel.crashing.org> wrote: > >>>>> (I just saw this, so a little late on the reply, but..) > >>>>> > >>>>> mesa-gl is ABSOLUTELY still being used. It's needed for libmali usage. Not > >>>>> everyone wants to use lima support for graphics. > >>>>> > >>>>> It was broken into two separate packages so that is was VERY clear if you were > >>>>> using mesa for 'everything' (mesa), or mesa JUST for 'gl' (not gles). > >>>> > >>>> Okay, I'm not going to propose this, but can you clarify, what is the > >>>> current use for 'gl'? Is it just opengl 3d in standalone x server > >>>> based systems (which is slowly dying), or is there something else to > >>>> it? > >> > >> Are you specifically talking about libmali with the following statements? > >> > >> I would say that in general libmali is probably not doing things in > >> the "normal" way if so, although I'm not trying to say that it isn't a > >> legitimate way to do it. > >> > >>> > >>> Anything that needs "OpenGL", i.e. Wayland/Weston, X11, Chromium, etc etc etc. > >>> These all end up linking to a combination of libmali and mesa-gl. > >> > >> In general (maybe not for libmali) Wayland and Weston themselves don't > >> use OpenGL, or mesa-gl. Individual clients may be able to use it, > >> although it's rare in my (incomplete) experience. Most of the OpenGL > >> users in Wayland/Weston are going through XWayland/X11 and using GLX. > >> > >>> > >>> Pretty much anything that depends on 'virtual/gl' (vs virtual/libgles1,2,3). > >>> libmali provides virtual/libgles1 and virtual/libgles2 and a few other things > >>> that meta-gl doesn't. > >>> > >>> libmali also doesn't include the DRM/DRI parts. This comes from mesa-gl. > >> > >> In general, DRM/DRI doesn't come from mesa-gl. libdrm is its own > >> recipe, and libgbm comes from mesa proper, or from some other > >> dedicated vendor specific libgbm recipe. > >> > >> > >> If this is sidetracking the discussion please ignore; I'm just a > >> little confused by the above statements because either A) libmali is > >> really weird B) my understanding of things is _way_ off, or C) the > >> statements aren't quite correct. > >> > >>> > >>> --Mark > >>> > >>>> Alex > >>> > >>> > >>> > >>> > >>> > >>> > >>> > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#172178): https://lists.openembedded.org/g/openembedded-core/message/172178 > Mute This Topic: https://lists.openembedded.org/mt/94420106/1686489 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On 10/28/22 5:59 AM, Alexander Kanavin wrote: > Thanks. What I would want to understand is whether this arrangement > should have its own > MACHINE_FEATURE, e.g. 'vendor-egl' or similar, and then mesa proper > would be configured accordingly to > disable bits that come from the vendor. > > Is there a particular need for a separate recipe? When libmali support is enabled in our configuration we do the following: define a mali400 MACHINEOVERRIDE Then we use PREFERRED_PROVIDER to switch: https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-core/conf/machine/include/machine-xilinx-default.inc#L25 virtual/libgles1 virtual/libgles2 virtual/egl virtual/libgl virtual/mesa So the mesa-gl the PROVIDES are: virtual/libgl virtual/mesa while in mesa: PROVIDES = " \ ${@bb.utils.contains('PACKAGECONFIG', 'opengl', 'virtual/libgl', '', d)} \ ${@bb.utils.contains('PACKAGECONFIG', 'gles', 'virtual/libgles1 virtual/libgles2 virtual/libgles3', '', d)} \ ${@bb.utils.contains('PACKAGECONFIG', 'egl', 'virtual/egl', '', d)} \ ${@bb.utils.contains('PACKAGECONFIG', 'gbm', 'virtual/libgbm', '', d)} \ virtual/mesa \ " While it might be possible to switch around the PROVIDES using distibution configuration or similar, this has been difficult to get right in the past. This is why the split happened, it's one or the other based on the configuration. --Mark > Alex > > On Thu, 27 Oct 2022 at 02:46, Mark Hatle <mark.hatle@kernel.crashing.org> wrote: >> >> >> >> On 10/26/22 1:01 PM, Alexander Kanavin wrote: >>> Is there a combination of libmali recipe and mesa-gl somewhere public >>> so we could try to pick it apart and see what links to where? >> >> libmali is ALWAYS implementation specific. You will need to pick a vendor and >> build for it. What is generic is the application interface (from what I've been >> told.). I can give you the AMD (Xilinx) instructions. But you likely won't be >> able to actually execute the code without a corresponding board. (AFAIK QEMU >> doesn't have any mali400 emulation.) >> >> And to be clear, libmali provides the interfaces, but it is NOT a replacement to >> mesa, it works WITH mesa, just the 'gl' part (not the gles part). >> >> The following is an abbreviated attempt to show how the pieces interact with >> each other. It may not be 100% correct, I am definitely not an expert at this. >> (For example, I don't understand why it's "DRM" in some places but "DRI" in >> others. These seem to be 'generally' the same systems.) But it's how the parts >> and pieces appear to be put together based on a functioning system. >> >> >> In a 'normal' system (mesa): >> >> mesa provides: >> libglapi.so.0 >> libEGL.so.1 >> libGLESv2.so.2 >> (and others) >> >> The CONFIG_DRM_LIMA backend and whatever the display port DRM (CONFIG_DRM_XLNX) >> go through a dlopened backend module, which USUALLY talks to a kernel module for >> any hardware access through a standard (known) kernel interface. >> >> In our case the dynamic modules would be the lima_dri.so and xlnx_dri.so. >> >> glmark2-es2-wayland -> >> libwayland-client >> libwayland-cursor >> libwayland-egl.so.1 >> >> I believe the libwayland-egl talks to weston "somehow" for the egl interfaces, >> via the libwayland-client? but I'm fuzzy here. >> >> Weston has two related items: >> >> drm-backend.o -> >> libglapi.so.0 (dlopened) >> >> This bit uses mesa to access the DRM backend to actually display the stuff.. >> >> gl-backend.so -> >> libwayland-server >> libEGL.so.1 >> libGLESv2.so.2 >> >> This backend is used to render the items. >> >> >> So the glmark2 does it's benchmarking and renders (gl-backend) through Weston >> backends to the display port (drm-backend). >> >> In the above case it all comes from mesa, the drm and libELG/libGLESv2 parts. >> >> >> >> The following shows a libmali configured system as a contrasts to the above: >> >> libmali-xlnx provides: >> >> libEGL.so.1 >> libGLESv1_CM.so.1 >> libGLESv2.so.2 >> libmali.so.9 >> libgbm.so.1 >> >> (also provides specific backends for fbdev, headless, wayland and x11) >> >> >> It talks to a backend kernel module called 'mali.ko' >> >> mesa provides: >> >> libGL.so.1 >> libglapi.so.0 >> >> and also swrast dri interface >> >> glmark2-es2-wayland -> >> libwayland-client >> libwayland-cursor >> libwayland-egl.so.1 >> >> (same as above) >> >> drm-backend.o -> >> libwayland-server >> libdrm.so.2 >> libMali.so.9 >> >> gl-backend.so -> >> libwayland-server >> libMali.so.9 >> >> So in the above, libMali is providing all of the APIs of libEGL and libGLESv2, >> as well as (enough of) libglapi for the built in raster implementation. >> >> >> Compiling things like Chromium that will link directly, you move from linking to >> libGL.so from mesa to linking in libMali, along with libGL from mesa. The >> libMali will provide the core set of APIs, while the libGL will augement them >> with additional APIs. >> >> Cairo is another utility that similar modifies in this way. >> >> >> To re-iterate, it's NOT a "swap libmali" and re-use everything. You need to >> rebuild anything that links to libgles or libgl or even libglapi with this new >> configuration. It's API compatible, NOT ABI compatible! >> >> >> I hope this helps. As far as letting you play with it, I'm working through the >> final stuff and should have something I can push to langdale/master on the >> meta-xilinx and meta-xilinx-tools soon. >> >> --Mark >> >>> My (perhaps confused) understanding is similar to Joshua's: 'gl' is >>> basically 'opengl in x11' or 'opengl rendered to memory', and if a >>> system uses neither, then it is not needed. >>> >>> Alex >>> >>> On Wed, 26 Oct 2022 at 19:48, Joshua Watt <jpewhacker@gmail.com> wrote: >>>> >>>> On Wed, Oct 26, 2022 at 12:21 PM Mark Hatle >>>> <mark.hatle@kernel.crashing.org> wrote: >>>>> >>>>> >>>>> >>>>> On 10/26/22 11:03 AM, Alexander Kanavin wrote: >>>>>> On Wed, 26 Oct 2022 at 16:35, Mark Hatle <mark.hatle@kernel.crashing.org> wrote: >>>>>>> (I just saw this, so a little late on the reply, but..) >>>>>>> >>>>>>> mesa-gl is ABSOLUTELY still being used. It's needed for libmali usage. Not >>>>>>> everyone wants to use lima support for graphics. >>>>>>> >>>>>>> It was broken into two separate packages so that is was VERY clear if you were >>>>>>> using mesa for 'everything' (mesa), or mesa JUST for 'gl' (not gles). >>>>>> >>>>>> Okay, I'm not going to propose this, but can you clarify, what is the >>>>>> current use for 'gl'? Is it just opengl 3d in standalone x server >>>>>> based systems (which is slowly dying), or is there something else to >>>>>> it? >>>> >>>> Are you specifically talking about libmali with the following statements? >>>> >>>> I would say that in general libmali is probably not doing things in >>>> the "normal" way if so, although I'm not trying to say that it isn't a >>>> legitimate way to do it. >>>> >>>>> >>>>> Anything that needs "OpenGL", i.e. Wayland/Weston, X11, Chromium, etc etc etc. >>>>> These all end up linking to a combination of libmali and mesa-gl. >>>> >>>> In general (maybe not for libmali) Wayland and Weston themselves don't >>>> use OpenGL, or mesa-gl. Individual clients may be able to use it, >>>> although it's rare in my (incomplete) experience. Most of the OpenGL >>>> users in Wayland/Weston are going through XWayland/X11 and using GLX. >>>> >>>>> >>>>> Pretty much anything that depends on 'virtual/gl' (vs virtual/libgles1,2,3). >>>>> libmali provides virtual/libgles1 and virtual/libgles2 and a few other things >>>>> that meta-gl doesn't. >>>>> >>>>> libmali also doesn't include the DRM/DRI parts. This comes from mesa-gl. >>>> >>>> In general, DRM/DRI doesn't come from mesa-gl. libdrm is its own >>>> recipe, and libgbm comes from mesa proper, or from some other >>>> dedicated vendor specific libgbm recipe. >>>> >>>> >>>> If this is sidetracking the discussion please ignore; I'm just a >>>> little confused by the above statements because either A) libmali is >>>> really weird B) my understanding of things is _way_ off, or C) the >>>> statements aren't quite correct. >>>> >>>>> >>>>> --Mark >>>>> >>>>>> Alex >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >> >> >> >> >> >> -=-=-=-=-=-=-=-=-=-=-=- >> Links: You receive all messages sent to this group. >> View/Reply Online (#172245): https://lists.openembedded.org/g/openembedded-core/message/172245 >> Mute This Topic: https://lists.openembedded.org/mt/94420106/3616948 >> Group Owner: openembedded-core+owner@lists.openembedded.org >> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [mark.hatle@kernel.crashing.org] >> -=-=-=-=-=-=-=-=-=-=-=- >>
diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc index c94e439363..04d78a6aa5 100644 --- a/meta/recipes-graphics/mesa/mesa.inc +++ b/meta/recipes-graphics/mesa/mesa.inc @@ -19,10 +19,11 @@ SRC_URI = "https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \ file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \ file://0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch \ file://0001-util-format-Check-for-NEON-before-using-it.patch \ + ${NATIVE_PATCHES} \ " - +NATIVE_PATCHES ?= "" # required by mesa-native on Ubuntu 18.04 with gcc 7.5 when DEBUG_BUILD enabled -SRC_URI:append:class-native = " file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch" +NATIVE_PATCHES:class-native = "file://0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch" SRC_URI[sha256sum] = "b1f9c8fd08f2cae3adf83355bef4d2398e8025f44947332880f2d0066bdafa8c"
This helps override the SRC_URI in entirety if needed by and overriding recipe Signed-off-by: Khem Raj <raj.khem@gmail.com> Cc: Kai Kang <kai.kang@windriver.com> --- v2: Weakly define NATIVE_PATCHES meta/recipes-graphics/mesa/mesa.inc | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)