[PATCH v2] mesa: Add native patch via a variable

[PATCH v2] mesa: Add native patch via a variable

[Khem Raj]

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

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 2117 bytes --]

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]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 3385 bytes --]

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Khem Raj]

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]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Alexander Kanavin]

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

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Khem Raj]

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

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Alexander Kanavin]

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]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Mark Hatle]

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]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Alexander Kanavin]

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

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Mark Hatle]

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

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Joshua Watt]

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]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Alexander Kanavin]

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]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Mark Hatle]

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]
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Alexander Kanavin]

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]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Mark Hatle]

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]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Mark Hatle]

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]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Ross Burton]

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

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Alexander Kanavin]

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

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Richard Purdie]

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

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2771 bytes --]

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,

[-- Attachment #2: Type: text/html, Size: 4364 bytes --]

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Khem Raj]

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

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 2519 bytes --]

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]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 4284 bytes --]

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Kai]

[-- Attachment #1: Type: text/plain, Size: 4075 bytes --]

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]
>     -=-=-=-=-=-=-=-=-=-=-=-
>

-- 
Kai Kang
Wind River Linux

[-- Attachment #2: Type: text/html, Size: 8496 bytes --]

Re: [OE-core] [PATCH v2] mesa: Add native patch via a variable

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 353 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 651 bytes --]