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

Pekka Paalanen ppaalanen at gmail.com
Mon Feb 25 23:58:42 PST 2013


On Mon, 25 Feb 2013 09:09:22 -0800
Chad Versace <chad.versace at linux.intel.com> wrote:

> 
> 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.

Thank you for the reply. Indeed, that dance to check for the extension
is non-trivial, and I think it might be good to explain somehow in the
spec, maybe in the Q&A section?

I quickly checked the EGL 1.4 spec, and could not spot any mention of
whether eglGetProcAddress needs a valid context or display or anything.
Does it require any initialization? Well, should not matter much I
guess, since in any case you have to open a display first to get the
extensions string.

Btw. what is EGL_DEFAULT_DISPLAY in Mesa, what does it give us?


Thanks,
pq


More information about the mesa-dev mailing list