On 8 September 2016 at 08:19, Mathias Fröhlich
<mathias.froehl...@gmx.net> wrote:
> Hi Emil,
>
> Thanks for taking care so far.
>
> On Wednesday, 7 September 2016 12:18:24 CEST Emil Velikov wrote:
>> 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.
>
> I am under the impression that we are not talking about the same things:
> I believe that everything talking about EXT*_output_* is covering a completely
> different use case. The intent of what I am talking about is either a head-
> and outputless pbuffer or a context that is aimed to be used with
> EXT_KRH_surfaceless_context. There is not output required! And there is even
> no (sensible) output available. Also no remote output or virtualization
> output. This is just to produce offline image data.
> If I could not motivate the use case so far, there is a nice reference
> https://devblogs.nvidia.com/parallelforall/egl-eye-opengl-visualization-without-x-server/
> explaining the use case.
>
> Given this is all headless a restricted and to be authenticated main node is
> of not so much use for this purpose. So to make the above usage work and under
> the assumption that render nodes were designed for this kind of use case there
> must be at least render nodes available in the device enumeration.
> May be device enumeration should just enumerate both, the main nodes that you
> may need to attach monitor outputs and the render nodes to get offline
> contexts?
>
I'm aware of your interest, yet the goal I'm aiming for here is to
tackle something that's "lower level", despite that
EGL_EXT_platform_device and EGL_EXT_device_drm are not (directly)
related.
Since people like pointing to the particular article can we work on
get it fixed. Here's a few things that come to mind, in order of
severity (high to low):
- None of the *EXT_PROTOTYPES macros (that includes
EGL_EGLEXT_PROTOTYPES) should be used if you want portable
applications, period.
- Justifying the ^^ define cause we're using an extension is a fallacy.
- Missing (pseudo) code for that queries for the client extension(s)
EGL_EXT_device_base and device extension EGL_EXT_platform_device.
- Naming the eglGetProcAddress retrieved symbols exactly as the entry
point name can lead to a number of issues depending on platform
specifics and *GL implementation.
Thanks
Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
