[Mesa-dev] EGL_EXT_*_drm - primary vs render node (Was Re: [Piglit] [PATCH 1/2] egl: Add sanity test for EGL_EXT_device_query (v3))

[James Jones]

On 09/08/2016 04:30 AM, Emil Velikov wrote:
> On 7 September 2016 at 19:54, James Jones <jajones at nvidia.com> wrote:
>> On 09/07/2016 04:18 AM, Emil Velikov wrote:
>>>
>>> Hi Mathias,
>>>
>>> On 6 September 2016 at 18:32, Mathias Fröhlich
>>> <Mathias.Froehlich at gmx.net> wrote:
>>>
>>>>>  ** EGL_EXT_output_drm
>>>
>>> Correction - the above should read: EGL_EXT_{device,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.
>>>>
>>> That's precisely what, where and why we want to clarify, correct the
>>> spec or add a new one.
>>>
>>> James, Daniel, can we hear your input on the following ?
>>>
>>> The way I read the spec(s) EGL_EXT_device_drm can effectively be
>>> either the card/primary or render node, while EGL_EXT_output_drm must
>>> be the card one.
>>> Can/should we restrict the former to render only, do you see any
>>> implications that will bring ?
>>> Or should we just roll out another spec for the "render only" case ?
>>
>>
>> I had assumed EGL_EXT_device_drm's queries refer to the card/primary, and an
>> additional extension could add a token to query the render node. When we
>> initially started drafting the extensions, render nodes were just being
>> introduced, and I considered adding them as a separate query later, but we
>> had no need to identify the render nodes, so I demurred.
>>
> From a quick look at the EGL world (both desktop and embedded), looks
> like the Nvidia drivers are the only ones implementing the extension.
> Thus one can 'retrofit' the extension to target the render node. If
> anyone is using EGL_EXT_device_drm yet relying on it to provide KMS
> device then they're just doing/using it wrong ;-)

I'm not sure what you're implying here.  Is it:

1) Changing the behavior of the extension from what was intended, such 
that the existing query returns the render node path.

2) Making a backwards-compatible modification to the existing extension 
by adding an additional EGL token (e.g., EGL_DRM_RENDER_DEVICE_FILE_EXT) 
to query the render node path.

(1) won't work.  Even though we're the only one's shipping it, there's a 
lot of code (ours and customers') using it that relies on the current 
behavior, where EGL_DRM_DEVICE_FILE_EXT refers to the 
modesetting/primary file.

(2) could be done, but I prefer to avoid it whenever possible.  It 
leaves applications in the situation that they can never be sure the new 
functionality is present, since there is no query in EGL to 
differentiate between extension versions.  When running on older 
drivers, using the new query would fail.

Re-reading your email, I'm a bit worried I might have misunderstood what 
you were referring to, given you said "queries" (plural).  We are 
talking about the single query, EGL_DRM_DEVICE_FILE_EXT, right?  Or were 
you referring to something else [as well]?

>> If that interpretation sounds OK, we can add corresponding clarifications to
>> the specifications.
>>
> That said, if the above is not possible (please check before throwing
> the towel) the extra text sounds OK.

Let me know what you think given the above.

Thanks,
-James

> Thanks
> Emil
>