On Mon, May 6, 2019 at 11:19 AM Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On Sat, 4 May 2019 at 04:18, Marek Olšák <mar...@gmail.com> wrote: > > > > 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. > > > The series I just sent out covers everything but the "don't expose the > software device". It does include a hack which can be toggled to > achieve that though ;-) > > My line of thinking is as follows: > > Preamble: > A software device is only listed when the user requests the full > device list via QueryDevices and even then, it's the last one in the > list. > Thus it's close to impossible to get it "by mistake". > > Case A - average Joe: > Getting Mesa from their distribution - swrast is build and shipped. > > Case B - tailored solution like AMDGPU-PRO, Yocto builders or others: > People doing the platform integration know if swrast will be > built/available. If listing the software device is not something > they're interested, the trivial hack can be applied locally. > > This seems like a perfectly good middle-ground, don't you agree? > Yes, it's OK. Marek
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
