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

[Mark Hatle <mark.hatle@kernel.crashing.org>]

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