On Fri, May 3, 2019 at 1:58 AM Mathias Fröhlich <mathias.froehl...@gmx.net> wrote:
> Good Morning, > > On Wednesday, 1 May 2019 21:43:08 CEST Marek Olšák wrote: > > BTW, swrast doesn't have to exist on the system. It's not uncommon for me > > to have no swrast on my development system. > > Ok. I see. I use swrast regularly to test changes with different backend > drivers. > Also especially classic swrast as something that is close to the good old > swtnl > drivers - to catch bad interactions with those. > > Anyhow, with a very old swrast I think you will get test failures. > But else if the system swrast is found in the hopefully not so distant > future > the tests should even pass - well depends on what Emil now does to get a > better overall swrast behavior. > On a production system with a full set of driver packages I do expect to > find swrast, right? At least on a workstation grade linux distribution. > > I start to see the actual problem for AMD there. > Not your test system at home, but the pro driver that needs to ship > and QA swrast then. > > Anyhow, I do not actually understand the way how we walk all > installed egl driver implementations - including closed drivers - finally > and present all those devices. In a perfect world *for the customer* > I could enumerate all devices - including oss i965 and the closed nvidia > bumblebee device - on my laptop for example. > > Means - if that works fine AMD could hook into that mechanism and > provide further devices. Well - in the long term. > We include libGL and libEGL along with radeonsi in our binary driver installer. We probably don't include swrast, but I'm not 100% sure. Marek
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
