[Mesa-dev] [PATCH 2/2] egl: add EGL_platform_device support

Emil Velikov emil.l.velikov at gmail.com
Mon May 6 15:18:15 UTC 2019


On Sat, 4 May 2019 at 04:18, Marek Olšák <maraeo at gmail.com> wrote:
>
> On Fri, May 3, 2019 at 1:58 AM Mathias Fröhlich <Mathias.Froehlich at 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?

HTH
Emil


More information about the mesa-dev mailing list