<div dir="ltr"><div>I tend to agree with Marco: I am not sure there is a use case for swrast anymore, not even as a fallback. About the only thing it is useful for is glxgears. On real hardware you want the real driver without fallbacks, on qemu you want virgl.</div><div><br></div><div>I would rather replace swrast with virgl in the qemu machine configs. Currently it's pulled in implicitly via the megadriver package which has virgl included because it is enabled by default in the mesa recipe. From what I can see beaglebone etc. are not affected by this.<br></div><div><br></div><div>Alex<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 14 Jun 2019 at 14:35, Marco Felsch <<a href="mailto:m.felsch@pengutronix.de">m.felsch@pengutronix.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 19-06-14 13:11, <a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a> wrote:<br>
> On Fri, 2019-06-14 at 14:04 +0200, Marco Felsch wrote:<br>
> > On 19-06-14 11:55, Richard Purdie wrote:<br>
> > > On Thu, 2019-06-13 at 19:54 +0200, Marco Felsch wrote:<br>
> > > > Most of the time we are compiling for embedded targets which have<br>
> > > > dedicated hardware combinations. Enabling swrast by default isn't<br>
> > > > a<br>
> > > > good<br>
> > > > solution for such devices because if the hardware render node has<br>
> > > > an<br>
> > > > issue or doesn't support a special format/request Mesa will<br>
> > > > fallback<br>
> > > > to<br>
> > > > the software renderer. This will make it harder to debug<br>
> > > > performance<br>
> > > > issues.<br>
> > > > <br>
> > > > A better way is to let the user decide if a software renderer is<br>
> > > > needed e.g. if the system has no hardware renderer or to have<br>
> > > > such a<br>
> > > > fallback device. This way the user knows that the software<br>
> > > > renderer<br>
> > > > is<br>
> > > > enabled.<br>
> > > > <br>
> > > > Signed-off-by: Marco Felsch <<a href="mailto:m.felsch@pengutronix.de" target="_blank">m.felsch@pengutronix.de</a>><br>
> > > > ---<br>
> > > > v3<br>
> > > > - rebased on current master-next branch<br>
> > > <br>
> > > I think this breaks the autobuilder:<br>
> > > <br>
> > > <a href="https://autobuilder.yoctoproject.org/typhoon/#/builders/57/builds/694" rel="noreferrer" target="_blank">https://autobuilder.yoctoproject.org/typhoon/#/builders/57/builds/694</a><br>
> > <br>
> > thanks for covering that. Why didn't I get a email?<br>
> <br>
> The patchtest emails come from quick tests. This is a test of full<br>
> builds on the autobuilder with batched together patches. The system has<br>
> no real knowledge of which patch causes which failure so its a manual<br>
> process. We don't have the infrastructure to run all patches through<br>
> the full autobuilder tests individually.<br>
> <br>
> > Anyway thats<br>
> > interessting. IMHO it isn't a good solution to rely on that fact that<br>
> > the package have some 'random' default enabled drivers. Should we fix<br>
> > the qemu configs or should I add:<br>
> > <br>
> > PACKAGECONFIG_append_qemuall = " swrast"<br>
> <br>
> The assumption is that swrast makes a good fallback and would be<br>
> available in most cases.<br>
<br>
No I don't think that it is a good fallback, following my patch<br>
description. If you are on a embedded device you want the hw-renderer<br>
and not the sw one. A good example: After I updated my kernel, my<br>
hw-renderer wasn't available anymore and my application didn't start.<br>
Thats a very good indication that something went bad. With the swrast<br>
enabled I wouldn't see that immediately.<br>
<br>
> I suspect qemuall might not fix beaglebone-yocto or some of the<br>
> hardware BSPs.<br>
<br>
As I discribed in the patch description if you want that fallback you<br>
have to enable it. IMHO this is the better way instead of to be a<br>
'smart' package.<br>
<br>
> Its also assumed these packages are shared amongst multiple machines<br>
> which may need different drivers.<br>
> <br>
> I suspect this means the defaults should be on but I am happy to have<br>
> more PACKAGECONFIG options to control things for people who want to<br>
> customise/micro-optimise.<br>
<br>
Optimising wasn't my main motivation. Avoiding 'random' performace<br>
issues after a upgrade (kernel, mesa) was my main motivation. Do you get<br>
me?<br>
<br>
Regards,<br>
Marco<br>
<br>
> Cheers,<br>
> <br>
> Richard<br>
> <br>
> <br>
> <br>
> <br>
<br>
-- <br>
Pengutronix e.K. | |<br>
Industrial Linux Solutions | <a href="http://www.pengutronix.de/" rel="noreferrer" target="_blank">http://www.pengutronix.de/</a> |<br>
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |<br>
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |<br>
-- <br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</blockquote></div>