[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