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

[richard.purdie at linuxfoundation.org]

On Fri, 2019-06-14 at 14:34 +0200, Marco Felsch wrote:
> On 19-06-14 13:11, richard.purdie at linuxfoundation.org wrote:
> > On Fri, 2019-06-14 at 14:04 +0200, Marco Felsch wrote:
> > >  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.

Alternatively, if swrast is available the system is more usable and you
can then have a more usable system to track down the problem and fix
it?

My point is you can argue that both ways.

I did read your commit message.

> > 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.

As things stand this patch will likely break a significant number of
BSPs. This isn't acceptable.

> > 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?

I understand why you're doing it however I don't like the implications
of the change which mean breakage for a significant number of BSPs, and
the fact it breaks the way distros would use this recipe from a
packaging perspective as its not marked as machine specific, nor should
it be.

Cheers,

Richard