[Piglit] [PATCH 1/2] egl: Add sanity test for EGL_EXT_device_query (v3)

[Emil Velikov]

On 2 September 2016 at 07:15, Mathias Fröhlich
<Mathias.Froehlich at gmx.net> wrote:

>
> Great!
>
> One question that I cannot forsee from your branch:
>
> The EGL_EXT_device_enumeration spec says
>
>
>
> [...] All implementations must support
>
> at least one device.
>
> [...]
>
>
>
> Which means to me that once an application sucsessfully asked for
> EGL_EXT_device_query, this calling application can rely on recieving at
> least one usable(?) EGL device. As a last resort, that single guaranteed
> device can be a software renderer, but the application gets at least
> something that lets it render pictures in some way.
>
Yes we do need at least one device, which (modulo a few small changes)
is applicable with the above branch. There is no need for the single
guaranteed device to be software renderer.

> Sure, the intent of the extension is to privide access to hw backed
> implementations.
>
Fully agree.

>
>
> For us it means that we need to provide a software rendering context for the
> case that there is either no drm capable graphics driver.
I'm missing something here - barring the vendor neutrial EGL
requirement for EGL_EXT_device_base how is the presence or absence of
the device extensions going to affect any of your work.
Afaict all of them are simply not applicable in the software renderer case.

> Or an even more
> nasty case, when the device node is just not accessible by the user. I have
> seen distros that restrict the permissions of the render node devices to the
> user loged in the running X server. So, even if there is hardware that you
> could potentially use, you may not be able to access it.
>
The libdrm helper provides a list of devices which have at least one
node available - be that card, control or render. For the purposes of
EGL_EXT_device_drm we could consider the card or render, although the
card one is exposed in pretty much all the open-source drivers and is
independent of the kernel age.

That said if distributions restricts permissions to all of those then
... I'm inclined to go with Distribution/User Error. Then again please
poke us if you see such cases.

> ... remember, the major intent of this set of extensions is to provide
> applications with an off screen rendering context for the case where you do
> not have a local X/wayland/whatnotdisplayserver running.
>
Note: it's not display server but platform ;-) One could use
EGL_KHR_platform_gbm if their graphics card vendor implements the
extension.

>
>
> Alternatively to providing a cpu rasterizer as a fallback, we could supress
> announcing the EXT_device_enumeration extension if there is no hw backed
> driver available. And in turn EGL_EXT_device_base which depends on
> EGL_EXT_device_query.
>
As above - modulo a few small changes this is what the current branch does.

> That would at least require some infrastructure to dynamically enable client
> extensions. It would still be unclear what to do then when the render nodes
> seem accessible when initializing/enumerating but the permissions change
> until the application wants to create the display using
> eglGetPlatformDisplayEXT later.
>
I'm not currently sold whether the card or render node should be
exposed via the EGL_EXT_device_drm extension. In the case of the
latter we could easily not advertise EGL_EXT_device_base if there's no
such devices available.
That will be as a workaround the eglQueryDeviceStringEXT should return
EGL_BAD_DEVICE_EXT or EGL_BAD_PARAMETER in case of error text.

Unless we add another extension to elaborate/handle things better/differently.

>
> What are your plans?
>
So in general I'm leaning towards:
 - parties interested in using EGL device without hardware device -
we don't expose it, unless we have an extension how it should work
 - distributions explicitly restricting access to drm devices - we
don't expose it, they get what they are asking.
 - the vendor neutral EGL requirement of EGL_EXT_device_base - I'm
leaning that we should rework that so that vendor implementations
supporting software rendering will continue to work.


Thanks for bringing this up. I (un)fortunately forgot that software
rendering and EGL is a thing :-)

-Emil