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

[Mathias Fröhlich]

Hi Emil,

On Tuesday, 6 September 2016 12:29:01 CEST Emil Velikov wrote:
>  * SW EGL implementations - do we have any vendors/implementations
> apart from Mesa ?
I dont think so.
But lets put that beside. The reason for me talking about swrast here was to 
fulfill that part of the EGL_EXT_device_enumeration spec that says that there 
is always at least a single EGLDeviceEXT returned. But see below.

>  * Interaction of ^^ with EGL device extension(s) - update existing
> extensions/introduce new ones
>  ** Should EGL_EXT_device_enumeration expose one/multiple SW devices
>  - no: we need alternative glvnd EGL interface for such cases
>  - yes: implementing EGL_EXT_output_drm on EGL implementations
> supporting both HW and SW devices is close to impossible barring spec
> update
> 
>  ** EGL_EXT_output_drm
>  *** Using/exposing the card or render node
>  - Extension is designed with EGL streams in mind (using the
> primary/card node) while people expect to use to select the rendering
> device.
>  - Elaborate on the spec and/or introduce EGL_EXT_output{,_drm}_render ?
>  *** Exposing EGL_EXT_output{,_drm}{,_render} on EGL implementations
> supporting both SW and HW devices
>  - Elaborate on the spec(s), add new one for SW devices and/or error
> type to distinguish between the current errors and SW devices
I do not care about anything built on top of EGL_EXT_output_base or 
EGL_*_stream_*. From my point of view this is beside.


What I do care about is EGL_EXT_platform_device.

>  * Systems with fb only, disabled render nodes and/or alike.
> EGL implementations (in our case the libdrm API provides all the info
> about available DRM devices) can effectively detect the presence of
> HW/SW devices and expose relevant extensions.
> Note: The presence does not and _cannot_ imply that one will always
> succeed using each device.
So you are saying, on a system without drm device we should return a more or 
less dead single EGLDeviceEXT from eglQueryDevicesEXT(...).
Then after that in the call to
eglGetPlatformDisplayEXT(EGL_PLATFORM_DEVICE_EXT, EGLDeviceEXT,...)
we just return EGL_NO_DISPLAY.
Which should be ok because of EGL_EXT_platform_base.txt:

--
Additions to the EGL 1.4 Specification
[...]
eglGetPlatformDisplayEXT(platform, native_display, ...)
[...]
If  is valid but no display matching  is
available, then EGL_NO_DISPLAY is returned; no error condition is raised
in this case.
--

That seems to work without the need to play with a software rasterizer to 
fulfill the spec.
And yes, I was under the impression that once I have an EGLDeviceEXT in my 
hands I should get a valid EGLDisplay via eglGetPlatformDisplayEXT - which is 
obviously not the case. Of course all that with the presence of the required 
extensions.

Thanks

Mathias
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Kyle Brenneman]

On 09/06/2016 05:29 AM, Emil Velikov wrote:

* Interaction of ^^ with EGL device extension(s) - update existing
extensions/introduce new ones
  ** Should EGL_EXT_device_enumeration expose one/multiple SW devices
  - no: we need alternative glvnd EGL interface for such cases
  - yes: implementing EGL_EXT_output_drm on EGL implementations
supporting both HW and SW devices is close to impossible barring spec
update


(Trimming other bullet points for readability)

GLVND itself can support EGL_EXT_device_enumeration, but it doesn't 
require any vendor library to support it. It'll advertise 
EGL_EXT_device_enumeration to the application if and only if at least 
one vendor advertises it, and then for eglQueryDevicesEXT, it will just 
call into each vendor library that supports it and concatenate the 
vendor's lists together. If a vendor doesn't support 
EGL_EXT_device_enumeration, then GLVND will just skip it and it won't be 
included in the eglQueryDevicesEXT list.


From a driver's perspective, the only requirement that GLVND adds is 
that the EGLDeviceEXT handles have to be pointers to some address that 
the vendor library somehow controls. That's only to ensure that the 
handles are unique between vendors, so GLVND doesn't care what (if 
anything) it actually points to. Other than that, the same 
implementation of eglQueryDevicesEXT should work with or without GLVND.


-Kyle

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

[Emil Velikov]

[moving to mesa-dev, adding the EGL device spec authors for their input]

On 5 September 2016 at 08:48, Mathias Fröhlich
 wrote:
> On Friday, 2 September 2016 14:02:07 CEST Emil Velikov wrote:
>
>> On 2 September 2016 at 07:15, Mathias Fröhlich
>
>>  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.
>
> Well, how are you getting this single (drm) device when you are on a board
> with a pure framebuffer console on some simple VGA hardware just sufficient
> to bring up the boot screen?
>
>
> This situation is very common on some sort of modern systems. See below.
>

>> > 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.
>
> Now I am confused, what do you mean with 'your (my) work'?
>
>
>
> What I mean here - putting together what I read in the branch:
>
> On compile time of mesa, libdrm is there and usable, so lib EGL announces
> EGL_EXT_device_enumeration so eglQueryDevicesEXT shall be there and return
> at least one device. Now put that mesa libraries onto a fresh installed
> cluster system (just by installing a linux distribution that contains the
> mentioned precompield mesa package). That cluster node I mean has nothing
> drm capable as its head never faces a console user appart from the operator
> seeing the boot screen at most once, if not even that is automated away with
> a kickstart install via network.
>
> How are you going to handle this situation?
>
>
>
> Of course a typical installation out there has selected nodes installed with
> a/several GPU(s) each. This gpu is supposed to be used for producing
> visualization results of your simulation. No monitors attached, just to
> reduce the usually huge amount of simulation data (up to several terrabytes
> or even more) to something that you can actually download to your computer
> which is several thousand pictures (well more similar use cases but all
> share the property that you do not want to copy the simulatoin data but you
> can copy picture data in some sense). Sure on this node you expect
> EGL_EXT_device_enumeration to deliver a gpu and I would hope that we
> (mesa/oss graphics stack) also want to deliver EGL_EXT_platform_device where
> you can make use of that single EGLDevice to grab an EGLDisplay.
>
>
>
> In reality today, such cluster nodes are equipped exclusively with nvidia
> cards and the binary blob. VirtualGL is installed running a totally open X
> server that delivers the application local gl contexts via the binary blob
> through virtualgl. So having EGL_EXT_platform_device together with
> EGL_EXT_device_query is what those software vendors that have understood the
> security implications with VirtualGL will use in the future. Those vendors
> who do not (want to) think about security implications will probably
> continue to use the above virtualgl setup as this does not require any
> invest for changes in their software.
>

>> > 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
>>