On 19-06-14 13:11, richard.pur...@linuxfoundation.org wrote: > 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.fel...@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.
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. > 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. > 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? Regards, Marco > Cheers, > > Richard > > > > -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core