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

[Emil Velikov]

[Trimming the EGL device spec authors]

On 6 September 2016 at 17:16, Kyle Brenneman <kyle.brenneman at gmail.com> wrote:
>
> 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.
>
Hmm you're right - IntersectionExtensionStrings has this optional
'behaviour' which is less than obvious.
We ought to give it a better name and/or comment.

That said, it's completely irrelevant to the actual 'issue' at hand.

Thanks for the clarification Kyle,
Emil