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

Chad Versace chad.versace at linux.intel.com
Tue Feb 26 13:19:57 PST 2013

On 02/26/2013 06:23 AM, Jakob Bornecrantz wrote:
> [SNIP]
>>> 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.
> I assume that Mesa does not follow this rule?

Yuk. `nm libEGL` reveals that Mesa exports a lot of symbols, not only EGL
extension symbols. On the list are functions like dri2_load_driver_swrast()
and dri2_add_config().

Hopefully no app statically links to the exported EGL extension symbols.

>> 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.
> I don't see this as driver extension and something that would need to be
> implemented by the libEGL provider, since the selected platform might have
> different set of drivers associated with them.
>>> 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.
> If memory serves me correct getProc can not return null for any string starting
> with egl/gl/vg.

The spec does not require implementations return non-null for unsupported
function strings, but the spec does permit it.

Mesa must do so for "gl" strings because of our driver/loader interface. If I
recall correctly, I think Mesa does return null for "egl" strings that it
doesn't support, but I could be wrong.

Anyway, I don't understand how this impacts the discussion. Other than that
``if (eglGetProcAddress("eglGetPlatformDisplayEXT") != NULL)`` is not a valid
method of checking for 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.
> That might include setting up a connection to a X server which is quite a
> heavy handed thing to do. Less then optimal, also the extension might not
> be supported by the loaded driver for the default platform but supported
> by other drivers for other platforms.

This should be addressed in the specs issue section. Despite that the EGL extension
string is a property of EGLDisplay, this extension is independent of display
and instead a property of libEGL. If libEGL supports the extension, then
all displays, regardless of platform, should advertise this extension.

Yeah, I agree. Connecting to X only to discover if Wayland is available is not
ideal. But I don't see any other way to get the extension string.

Luckily, I discussed all this krh today, and it looks like we might be able
to abandon this extension entirely. The void* given to eglGetDisplay(),
Mesa's libEGL is able to autodetect to which platform the void* belongs. This
mechanism relies on the ABI of struct wl_display and struct gbm_device. As long
as other vendors can be persuaded to take the same approach as Mesa here, then
the extension will be unnecessary.

> Just throwing crazy ideas out there, maybe we should just call the function
> xeglGetPlatformDisplay allowing implementation to return null if not
> supported and as such being able to detection with eglGetProcAddress.

Yes! That's what everyone wants.

We should consider the "xegl" prefix as reserved by Khronos; it's too close
to the "egl" prefix. However, I'd like to see someone take this approach in
Mesa someday.

Thanks for the feedback.

More information about the mesa-dev mailing list