On 09/08/2016 04:30 AM, Emil Velikov wrote:
On 7 September 2016 at 19:54, James Jones <jajo...@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.froehl...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
