All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Denys Dmytriyenko" <denis@denix.org>
To: Andrey Zhizhikin <andrey.z@gmail.com>
Cc: Mark Hatle <mark.hatle@kernel.crashing.org>,
	Ross Burton <ross.burton@intel.com>,
	OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH] mesa-gl: The purpose of mesa-gl is to provide for X11 usage
Date: Wed, 25 Mar 2020 17:48:12 -0400	[thread overview]
Message-ID: <20200325214812.GE1578@denix.org> (raw)
In-Reply-To: <CAHtQpK7im-SixCXD-eUF3Q6z7_GNnopeAKme7hetXca-Umd7RA@mail.gmail.com>

On Wed, Mar 25, 2020 at 10:37:55PM +0100, Andrey Zhizhikin wrote:
> On Wed, Mar 25, 2020 at 9:36 PM Mark Hatle
> <mark.hatle@kernel.crashing.org> wrote:
> >
> > > On Wed, Mar 25, 2020 at 7:15 PM Mark Hatle
> > > <mark.hatle@kernel.crashing.org> wrote:
> > >>
> > >> Trying to build mesa-gl without X11 enabled, results in numerous errors
> > >> about being incorrectly configured, such as:
> > >>
> > >>   ERROR: Problem encountered: building dri drivers require at least one
> > >> windowing system or classic osmesa
> > >
> > > I believe I was fighting similar issue in meta-freescale layer for
> > > imx8mm derivative [1], where the status of GPU support was not know at
> > > the time. What I did back then is set the default configuration to
> > > osmesa and used swrast in order to be able to use mesa on that
> > > derivative. After that, when GPU support has been added into Mesa -
> > > those modifications were reverted.
> >
> > Do you have a pointer to that anywhere?  I'm curious if any of it might
> > still apply.. but I know nothing about mesa and what configurations are
> > even possible.
> 
> I've included the link to my commit in meta-freescale layer, where the
> PACKAGECONFIG is set to use 'classic' OSMesa and adds swrast to
> DRIDRIVERS. This should turn the rendering to be performed in the SW,
> effectively working for all backends (at the obvious performance
> penalty). It took me quite some digging to figure this combination
> out, as I also cannot claim myself an expert in mesa...

FWIW, we also expect SW rendering for GL, while SGX/RGX cores in our SoCs 
accelerate EGL/GLES.

But, like Mark, I also don't know much about Mesa. Similar to what he 
mentioned about Mali, we used to require a custom libdrm years ago. But 
since then, everything has been upstreamed into main libdrm-omap driver.

-- 
Denys


> > > I guess turning to swrast in case if someone would decide _not_ to use
> > > X11 - is not a bad option here, rather than enforcing the X11 for
> > > distros which are using this recipe. Any thoughts?
> >
> > I don't know any any reasons we couldn't do this.. but like I said.. I'm a
> > newbie when it comes to mesa.
> 
> Maybe something like this could be used (warning: untested):
> PACKAGECONFIG ??= "opengl dri ${@bb.utils.contains('DISTRO_FEATURES',
> 'x11', 'x11', 'osmesa',d)}"
> DRIDRIVERS_append = "${@bb.utils.contains('DISTRO_FEATURES', 'x11',
> '', ' swrast',d)}"
> 
> >
> > --Mark
> >
> > >>
> > >> After consulting with the author of this recipe, it was clear that it
> > >> was only intended for the X11 use-case, so requring X11 should avoid the
> > >> error message above.
> > >>
> > >> Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
> > >> ---
> > >>  meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb | 6 ++++--
> > >>  1 file changed, 4 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> > >> b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> > >> index d4b1c1c454..5674c6b1fe 100644
> > >> --- a/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> > >> +++ b/meta/recipes-graphics/mesa/mesa-gl_20.0.1.bb
> > >> @@ -6,5 +6,7 @@ PROVIDES = "virtual/libgl virtual/mesa"
> > >>
> > >>  S = "${WORKDIR}/mesa-${PV}"
> > >>
> > >> -PACKAGECONFIG ??= "opengl dri ${@bb.utils.filter('DISTRO_FEATURES',
> > >> 'x11', d)}"
> > >> -PACKAGECONFIG_class-target = "opengl dri
> > >> ${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)}"
> > >> +REQUIRED_DISTRO_FEATURE = "x11"
> > >> +
> > >> +PACKAGECONFIG ??= "opengl dri x11"
> > >> +PACKAGECONFIG_class-target = "opengl dri x11"
> > >> --
> > >> 2.17.1
> > >>
> > >>
> > >
> > > --
> > > Regards,
> > > Andrey.
> > >
> > > [1]:
> > > https://github.com/Freescale/meta-freescale/commit/9a2210d9ec707531436dc4b56ce655c0bf50a8a8
> > > 
> > >
> >
> 
> 
> --
> Regards,
> Andrey.

> 


  reply	other threads:[~2020-03-25 21:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-25 18:14 [PATCH] mesa-gl: The purpose of mesa-gl is to provide for X11 usage Mark Hatle
2020-03-25 18:21 ` [OE-core] " Denys Dmytriyenko
2020-03-25 18:41   ` Mark Hatle
2020-03-25 19:04     ` Alexander Kanavin
2020-03-25 19:27       ` Mark Hatle
2020-03-26 13:11         ` Adrian Bunk
2020-03-26 14:15           ` Mark Hatle
     [not found]   ` <15FFA02F5F44ED82.23217@lists.openembedded.org>
2020-03-25 19:04     ` Mark Hatle
2020-03-25 20:02 ` Andrey Zhizhikin
2020-03-25 20:35   ` Mark Hatle
2020-03-25 21:37     ` Andrey Zhizhikin
2020-03-25 21:48       ` Denys Dmytriyenko [this message]
2020-03-25 21:58 ` Otavio Salvador
2020-03-30 12:07   ` Ross Burton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200325214812.GE1578@denix.org \
    --to=denis@denix.org \
    --cc=andrey.z@gmail.com \
    --cc=mark.hatle@kernel.crashing.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=ross.burton@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.