[OE-core] [PATCH 1/2] mesa: make gallium swrast target optional

[Marco Felsch]

On 19-06-14 13:11, richard.purdie at linuxfoundation.org wrote:
> On Fri, 2019-06-14 at 14:04 +0200, Marco Felsch wrote:
> > On 19-06-14 11:55, Richard Purdie wrote:
> > > On Thu, 2019-06-13 at 19:54 +0200, Marco Felsch wrote:
> > > > Most of the time we are compiling for embedded targets which have
> > > > dedicated hardware combinations. Enabling swrast by default isn't
> > > > a
> > > > good
> > > > solution for such devices because if the hardware render node has
> > > > an
> > > > issue or doesn't support a special format/request Mesa will
> > > > fallback
> > > > to
> > > > the software renderer. This will make it harder to debug
> > > > performance
> > > > issues.
> > > > 
> > > > A better way is to let the user decide if a software renderer is
> > > > needed e.g. if the system has no hardware renderer or to have
> > > > such a
> > > > fallback device. This way the user knows that the software
> > > > renderer
> > > > is
> > > > enabled.
> > > > 
> > > > Signed-off-by: Marco Felsch <m.felsch at pengutronix.de>
> > > > ---
> > > > v3
> > > > - rebased on current master-next branch
> > > 
> > > I think this breaks the autobuilder:
> > > 
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/57/builds/694
> > 
> > thanks for covering that. Why didn't I get a email?
> 
> The patchtest emails come from quick tests. This is a test of full
> builds on the autobuilder with batched together patches. The system has
> no real knowledge of which patch causes which failure so its a manual
> process. We don't have the infrastructure to run all patches through
> the full autobuilder tests individually.
> 
> >  Anyway thats
> > interessting. IMHO it isn't a good solution to rely on that fact that
> > the package have some 'random' default enabled drivers. Should we fix
> > the qemu configs or should I add:
> > 
> > PACKAGECONFIG_append_qemuall = " swrast"
> 
> The assumption is that swrast makes a good fallback and would be
> available in most cases.

No I don't think that it is a good fallback, following my patch
description. If you are on a embedded device you want the hw-renderer
and not the sw one. A good example: After I updated my kernel, my
hw-renderer wasn't available anymore and my application didn't start.
Thats a very good indication that something went bad. With the swrast
enabled I wouldn't see that immediately.

> I suspect qemuall might not fix beaglebone-yocto or some of the
> hardware BSPs.

As I discribed in the patch description if you want that fallback you
have to enable it. IMHO this is the better way instead of to be a
'smart' package.

> Its also assumed these packages are shared amongst multiple machines
> which may need different drivers.
> 
> I suspect this means the defaults should be on but I am happy to have
> more PACKAGECONFIG options to control things for people who want to
> customise/micro-optimise.

Optimising wasn't my main motivation. Avoiding 'random' performace
issues after a upgrade (kernel, mesa) was my main motivation. Do you get
me?

Regards,
  Marco

> Cheers,
> 
> Richard
> 
> 
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |