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

richard.purdie at linuxfoundation.org richard.purdie at linuxfoundation.org
Fri Jun 14 12:11:04 UTC 2019


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.

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

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.

Cheers,

Richard





More information about the Openembedded-core mailing list