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

[Alexander Kanavin]

I guess the patch needs a small tweak so that swrast remains enabled, but becomes optional. Then Marco can set packageconfig exactly as he wants.

The second patch is fine as it is, I think. Only qemu implements virgl device at the moment.

Alex

> On 14 Jun 2019, at 14.50, richard.purdie at linuxfoundation.org wrote:
> 
>> 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
> 
> 
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core