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

[Emil Velikov]

On Mon, 29 Apr 2019 at 22:50, Marek Olšák <maraeo at gmail.com> wrote:
>
> On Mon, Apr 29, 2019 at 4:00 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
>>
>> On Sat, 27 Apr 2019 09:38:27 -0400
>> Marek Olšák <maraeo at gmail.com> wrote:
>>
>> > Those are all valid reasons, but I don't wanna expose swrast for AMD's
>> > customers.
>>
>> Hi Marek,
>>
>> is you objection that you will never want to see any software renderer
>> in the list, or that you don't want to see a software renderer only as
>> long as it doesn't actually work?
>>
>> Why do you not "wanna expose swrast for AMD's customers"?
>>
>> Are you talking about swrast specifically or all the software renderers
>> in Mesa?
>>
>> I'm not an AMD customer if you mean someone paying for support rather
>> than just buying their hardware, so I cannot speak for them. However, I
>> would be very happy to have a software renderer available to be picked
>> the same way as any other hardware renderer, so that I can use it in
>> graphical test suites (a point from Anholt) testing also the EGL glue
>> in addition to the pixels produced.
>>
>> The thing will be run on boxes with AMD GPUs, and in those cases there
>> must be a way to *not* use the AMD GPU, and use the software renderer
>> instead when wanted. Not by environment variables or anything hacky
>> like that, but by deliberately choosing the software renderer in the
>> program. It will need an EGLSurface too.
>>
>> How would this be made to work in the future?
>
>
> A software renderer could be exposed by adding a new EGL function on top of EGL_EXT_device_base, for example:
>
> // EGL_MESA_device_software
>
> EGLBoolean eglQuerySoftwareDeviceMESA(EGLDeviceEXT *swdevice);
>
>
> You would get the swrast device from that function instead of eglQueryDevicesEXT. It clearly separates hw and sw devices but keeps everything else the same.
>
IMHO the current EGL_MESA_device_software approach is perfectly valid.
The Query API provides the devices and one can query their
capabilities/device extensions.

As far as I can see you have valid concerns:
 - HW devices should be the first/default
 - the SW device should work, if exposed
 - one may want to omit the SW one all together

At the same time:
 - the device_base extension is explicit that at least one device must
be present
 - manipulating the EGL client extension string, before we determine
the driver is a PITA

How about:
 - whip a quick (admittedly gross) hack that makes SW work
 - flip the order so SW is always the last one in the list
 - add a hack that disables SW all-together?

The first two should be OK to upstream, although I'd suggest keeping
the last one in AMDGPU-PRO.
Reason being is that the pro packaging can enforce that radeonsi is
always present. While we cannot do that for distributions :-\

/me starts working on the patches

-Emil