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

2022-10-28 Thread 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  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

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

2022-10-28 Thread 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  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  wrote:
> >>
> >> On Wed, Oct 26, 2022 at 12:21 PM Mark Hatle
> >>  wrote:
> >>>
> >>>
> >>>
> >>> On 10/26/22 11:03 AM, Alexander Kanavin wrote:
>  On Wed, 26 Oct 2022 at 16:35, Mark Hatle 
>   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

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

2022-10-26 Thread 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  wrote:


On Wed, Oct 26, 2022 at 12:21 PM Mark Hatle
 wrote:




On 10/26/22 11:03 AM, Alexander Kanavin wrote:

On Wed, 26 Oct 2022 at 16:35, Mark Hatle  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

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

2022-10-26 Thread Mark Hatle 



On 10/26/22 12:48 PM, Joshua Watt wrote:

On Wed, Oct 26, 2022 at 12:21 PM Mark Hatle
 wrote:




On 10/26/22 11:03 AM, Alexander Kanavin wrote:

On Wed, 26 Oct 2022 at 16:35, Mark Hatle  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 (#172173): 
https://lists.openembedded.org/g/openembedded-core/message/172173
Mute This Topic: https://lists.openembedded.org/mt/94420106/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2022-10-26 Thread 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  wrote:
>
> On Wed, Oct 26, 2022 at 12:21 PM Mark Hatle
>  wrote:
> >
> >
> >
> > On 10/26/22 11:03 AM, Alexander Kanavin wrote:
> > > On Wed, 26 Oct 2022 at 16:35, Mark Hatle  
> > > 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/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2022-10-26 Thread Joshua Watt 
On Wed, Oct 26, 2022 at 12:21 PM Mark Hatle
 wrote:
>
>
>
> On 10/26/22 11:03 AM, Alexander Kanavin wrote:
> > On Wed, 26 Oct 2022 at 16:35, Mark Hatle  
> > 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 (#172167): 
https://lists.openembedded.org/g/openembedded-core/message/172167
Mute This Topic: https://lists.openembedded.org/mt/94420106/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2022-10-26 Thread Mark Hatle 



On 10/26/22 11:03 AM, Alexander Kanavin wrote:

On Wed, 26 Oct 2022 at 16:35, Mark Hatle  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

-=-=-=-=-=-=-=-=-=-=-=-
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/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2022-10-26 Thread Alexander Kanavin 
On Wed, 26 Oct 2022 at 16:35, Mark Hatle  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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172162): 
https://lists.openembedded.org/g/openembedded-core/message/172162
Mute This Topic: https://lists.openembedded.org/mt/94420106/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2022-10-26 Thread 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=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 
wrote:


On Wed, 19 Oct 2022 at 08:34, Khem Raj  wrote:


On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin
 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 (#172160): 
https://lists.openembedded.org/g/openembedded-core/message/172160
Mute This Topic: https://lists.openembedded.org/mt/94420106/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2022-10-26 Thread 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




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172159): 
https://lists.openembedded.org/g/openembedded-core/message/172159
Mute This Topic: https://lists.openembedded.org/mt/94420106/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2022-10-21 Thread Khem Raj 
On Wed, Oct 19, 2022 at 8:29 AM Ross Burton  wrote:
>
> On 19 Oct 2022, at 07:34, Khem Raj via lists.openembedded.org 
>  wrote:
> >
> > On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin
> >  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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#172047): 
https://lists.openembedded.org/g/openembedded-core/message/172047
Mute This Topic: https://lists.openembedded.org/mt/94420106/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2022-10-19 Thread Martin Jansa 
On Wed, Oct 19, 2022 at 5:29 PM Ross Burton  wrote:

> On 19 Oct 2022, at 07:34, Khem Raj via lists.openembedded.org  gmail@lists.openembedded.org> wrote:
> >
> > On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin
> >  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,

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171974): 
https://lists.openembedded.org/g/openembedded-core/message/171974
Mute This Topic: https://lists.openembedded.org/mt/94420106/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2022-10-19 Thread 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  wrote:
>
> On 19 Oct 2022, at 07:34, Khem Raj via lists.openembedded.org 
>  wrote:
> >
> > On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin
> >  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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171973): 
https://lists.openembedded.org/g/openembedded-core/message/171973
Mute This Topic: https://lists.openembedded.org/mt/94420106/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2022-10-19 Thread Ross Burton 
On 19 Oct 2022, at 07:34, Khem Raj via lists.openembedded.org 
 wrote:
> 
> On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin
>  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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171970): 
https://lists.openembedded.org/g/openembedded-core/message/171970
Mute This Topic: https://lists.openembedded.org/mt/94420106/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2022-10-19 Thread Khem Raj 
On Tue, Oct 18, 2022 at 11:54 PM Alexander Kanavin
 wrote:
>
> On Wed, 19 Oct 2022 at 08:34, Khem Raj  wrote:
> >
> > On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin
> >  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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171969): 
https://lists.openembedded.org/g/openembedded-core/message/171969
Mute This Topic: https://lists.openembedded.org/mt/94420106/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2022-10-19 Thread 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=015cb13

Alex

On Wed, 19 Oct 2022 at 08:54, Alexander Kanavin via
lists.openembedded.org 
wrote:
>
> On Wed, 19 Oct 2022 at 08:34, Khem Raj  wrote:
> >
> > On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin
> >  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/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2022-10-19 Thread Alexander Kanavin 
On Wed, 19 Oct 2022 at 08:34, Khem Raj  wrote:
>
> On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin
>  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/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2022-10-19 Thread Khem Raj 
On Tue, Oct 18, 2022 at 10:42 PM Alexander Kanavin
 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  wrote:
>>
>> This helps override the SRC_URI in entirety if needed by
>> and overriding recipe
>>
>> Signed-off-by: Khem Raj 
>> Cc: Kai Kang 
>> ---
>> 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 (#171958): 
https://lists.openembedded.org/g/openembedded-core/message/171958
Mute This Topic: https://lists.openembedded.org/mt/94420106/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2022-10-18 Thread Martin Jansa 
On Wed, Oct 19, 2022 at 7:51 AM 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?
>

Yes, it causes build to fail when DEBUG_BUILD is enabled.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171957): 
https://lists.openembedded.org/g/openembedded-core/message/171957
Mute This Topic: https://lists.openembedded.org/mt/94420106/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2022-10-18 Thread kai 

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 
 
 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  wrote:

This helps override the SRC_URI in entirety if needed by
and overriding recipe

Signed-off-by: Khem Raj 
Cc: Kai Kang 
---
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










--
Kai Kang
Wind River Linux

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171956): 
https://lists.openembedded.org/g/openembedded-core/message/171956
Mute This Topic: https://lists.openembedded.org/mt/94420106/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2022-10-18 Thread Alexander Kanavin 
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
 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  wrote:
>
>> This helps override the SRC_URI in entirety if needed by
>> and overriding recipe
>>
>> Signed-off-by: Khem Raj 
>> Cc: Kai Kang 
>> ---
>> 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 (#171955): 
https://lists.openembedded.org/g/openembedded-core/message/171955
Mute This Topic: https://lists.openembedded.org/mt/94420106/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2022-10-18 Thread Alexander Kanavin 
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  wrote:

> This helps override the SRC_URI in entirety if needed by
> and overriding recipe
>
> Signed-off-by: Khem Raj 
> Cc: Kai Kang 
> ---
> 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/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

2022-10-18 Thread Khem Raj 
This helps override the SRC_URI in entirety if needed by
and overriding recipe

Signed-off-by: Khem Raj 
Cc: Kai Kang 
---
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/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-