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.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
