<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 6, 2019 at 11:19 AM Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</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 Sat, 4 May 2019 at 04:18, Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>> wrote:<br>
><br>
> On Fri, May 3, 2019 at 1:58 AM Mathias Fröhlich <<a href="mailto:Mathias.Froehlich@gmx.net" target="_blank">Mathias.Froehlich@gmx.net</a>> wrote:<br>
>><br>
>> Good Morning,<br>
>><br>
>> On Wednesday, 1 May 2019 21:43:08 CEST Marek Olšák wrote:<br>
>> > BTW, swrast doesn't have to exist on the system. It's not uncommon for me<br>
>> > to have no swrast on my development system.<br>
>><br>
>> Ok. I see. I use swrast regularly to test changes with different backend drivers.<br>
>> Also especially classic swrast as something that is close to the good old swtnl<br>
>> drivers - to catch bad interactions with those.<br>
>><br>
>> Anyhow, with a very old swrast I think you will get test failures.<br>
>> But else if the system swrast is found in the hopefully not so distant future<br>
>> the tests should even pass - well depends on what Emil now does to get a<br>
>> better overall swrast behavior.<br>
>> On a production system with a full set of driver packages I do expect to<br>
>> find swrast, right? At least on a workstation grade linux distribution.<br>
>><br>
>> I start to see the actual problem for AMD there.<br>
>> Not your test system at home, but the pro driver that needs to ship<br>
>> and QA swrast then.<br>
>><br>
>> Anyhow, I do not actually understand the way how we walk all<br>
>> installed egl driver implementations - including closed drivers - finally<br>
>> and present all those devices. In a perfect world *for the customer*<br>
>> I could enumerate all devices - including oss i965 and the closed nvidia<br>
>> bumblebee device - on my laptop for example.<br>
>><br>
>> Means - if that works fine AMD could hook into that mechanism and<br>
>> provide further devices. Well - in the long term.<br>
><br>
><br>
> 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.<br>
><br>
The series I just sent out covers everything but the "don't expose the<br>
software device". It does include a hack which can be toggled to<br>
achieve that though ;-)<br>
<br>
My line of thinking is as follows:<br>
<br>
Preamble:<br>
A software device is only listed when the user requests the full<br>
device list via QueryDevices and even then, it's the last one in the<br>
list.<br>
Thus it's close to impossible to get it "by mistake".<br>
<br>
Case A - average Joe:<br>
Getting Mesa from their distribution - swrast is build and shipped.<br>
<br>
Case B - tailored solution like AMDGPU-PRO, Yocto builders or others:<br>
People doing the platform integration know if swrast will be<br>
built/available. If listing the software device is not something<br>
they're interested, the trivial hack can be applied locally.<br>
<br>
This seems like a perfectly good middle-ground, don't you agree?<br></blockquote><div><br></div><div>Yes, it's OK.</div><div><br></div><div>Marek</div></div></div>