[Mesa-dev] [RFC] New EGL extension: EGL_EXT_platform_display

[Chad Versace]

On 02/24/2013 11:46 PM, Pekka Paalanen wrote:> On Tue, 19 Feb 2013 08:20:51 -0800
> Chad Versace <chad.versace at linux.intel.com> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I'm seeking feedback on an EGL extension that I'm drafting. The ideas have
>> already been discussed at Khronos meetings to a good reception, but I want
>> feedback from Mesa developers too.
>>
>> Summary
>> - -------
>> The extension, tentatively named EGL_EXT_platform_display, enables EGL clients
>> to specify to which platform (X11, Wayland, gbm, etc) an EGL resource
>> (EGLDisplay, EGLSurface, etc) belongs when the resource is derived from
>> a platform-native type. As a corollary, the extension enables the creation of
>> EGL resources from different platforms within a single process.
>>
>>
>> Feedback
>> - --------
>> I'd like to hear feeback about the details below. Do you see any potential
>> problems? Is it lacking a feature that you believe should be present?
>>
>>
>> Details
>> - -------
>> The draft extension defines the following new functions:
>>
>>     // This is the extenion's key function.
>>     //
>>     EGLDisplay
>>     eglGetPlatformDisplayEXT(EGLenum platform, void *native_display);
>>
>>     // The two eglCreate functions below differ from their core counterparts
>>     // only in their signature. The EGLNative types are replaced with void*.
>>     // This makes the signature agnostic to which platform the native resource
>>     // belongs.
>>
>>     EGLSurface
>>     eglCreatePlatformWindowSurfaceEXT(EGLDisplay dpy,
>>                                       EGLConfig config,
>>                                       void *native_window,
>>                                       const EGLint *attrib_list);
>>
>>     EGLSurface
>>     eglCreatePlatformPixmapSurface(EGLDisplay dpy,
>>                                    EGLConfig config,
>>                                    void *native_pixmap,
>>                                    const EGLint *attrib_list);
>>
>> Valid values for `platform` are defined by layered extensions.  For
>> example, EGL_EXT_platform_x11 defines EGL_PLATFORM_X11, and
>> EGL_EXT_platform_wayland defines EGL_PLATFORM_WAYLAND.
>>
>> Also, the layered extensions specify which native types should be passed as
>> the native parameters. For example, EGL_EXT_platform_wayland specifies that,
>> when calling eglCreatePlatformWindowSurfaceEXT with a display that was derived
>> from a Wayland display, then the native_window parameter must be `struct
>> wl_egl_window*`. Analogously, EGL_EXT_platform_x11 specifies that
>> native_window must be `Window*`.
>>
>>
>> Example Code for X11
>> - --------------------
>> // The internal representation of the egl_dpy, created below, remembers that
>> // it was derived from an Xlib display.
>>
>> Display *xlib_dpy = XOpenDisplay(NULL);
>> EGLDisplay *egl_dpy = eglGetPlatformDisplayEXT(EGL_PLATFORM_X11, xlib_dpy);
>>
>> EGLConfig config;
>> eglChooseConfig(egl_dpy, &config, ...);
>>
>> // Since egl_dpy remembers that it was derived from an Xlib display, when
>> // creating the EGLSurface below libEGL internally casts the
>> // `(void*) &xlib_win` to `Window*`.
>>
>> Window xlib_win = XCreateWindow(xlib_dpy, ...);
>> EGLSurface egl_surface = eglCreatePlatformWindowSurfaceEXT(egl_dpy, config,
>>                                                            (void*) &xlib_win,
>>                                                            NULL);
>>
>> Example Code for Wayland
>> - ------------------------
>> // The internal representation of the egl_dpy, created below, remembers that
>> // it was derived from a Wayland display.
>>
>> struct wl_display *wl_dpy = wl_display_connect(NULL);
>> EGLDisplay *egl_dpy = eglGetPlatformDisplay(EGL_PLATFORM_WAYLAND, wl_dpy);
>>
>>
>> EGLConfig config;
>> eglChooseConfig(egl_dpy, &config, ...);
>>
>> // Since egl_dpy remembers that it was derived from an Wayland display, when
>> // creating the EGLSurface below libEGL internally casts the
>> // `(void*) wl_win` to `struct wl_egl_window*`.
>>
>> struct wl_egl_window *wl_win = wl_egl_window_create(...);
>> EGLSurface egl_surface = eglCreateWindowSurface(egl_dpy, config,
>>                                                (void*) wl_win, NULL);
> 
> Hi,
> 
> is it possible to build a binary, that will use this extension if it is
> present in whatever libEGL is available at runtime, and if it is not,
> fall back gracefully to using the core eglGetDisplay()?
> 
> Or is this specifically not supported, since I cannot see a way for
> runtime detection of this extension?
> 
> Or is the runtime detection left unspecified, so one could do it with
> e.g. getting eglGetPlatformDisplay via dlsym()?
> 
> Just a question that popped in my mind, since there were no comments
> toward that topic.

Thanks for asking this question. I neglected to address the topic of runtime 
detection, despite it coming it up in face-to-face conversation multiple times.

The function must be exposed with eglGetProcAddress, and must not be
exported via dlsym.

libEGL is not allowed to export new symbols until the EGL specification
version is bumped. Exporting new symbols would prevent an applications
compiled against one vendor's libEGL to load with another vendor's libEGL.

In architectures like Android, where the system provides the libEGL to which
yhe application links and the vendor supplies an EGL driver that the system libEGL
dlopens, exporting the symbol via dlsym would not expose the function
to applications. The applications' only method for obtaining vendor-provided
functions is via eglGetProcAddress.

> Or is this [runtime detection] specifically not supported, since I cannot
> see a way for runtime detection of this extension?

Since the function must be exposed by eglGetProcAddress, runtime detection
will be supported. But... it's not obvious how to advertise the extension.

I think the cleanest method by which applications could detect the extension
is to first to connect to EGL_DEFAULT_DISPLAY; inspect the extension string;
and, if the extension is available, then all with eglGetPlatformDisplay;
otherwise, fallback to eglGetDisplay if possible.  The situation isn't ideal
because it involves an initial roundtrip to the default platform's display
server, but it's the best solution that I can think of.