On Mon, 25 Feb 2013 09:09:22 -0800 Chad Versace <chad.vers...@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.vers...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
