[waffle] [PATCH 13/18] api: make dl_can_open() dl_sym() display dependent

[Chad Versace]

On 08/13/2014 03:47 PM, Emil Velikov wrote:
> On 13/08/14 23:23, Chad Versace wrote:
>> On 07/22/2014 08:31 PM, Emil Velikov wrote:
>>> This will allow us to correctly work around waffle design which
>>> allows the a library to be dl_open'ed if we support the corresponding
>>> WAFFLE_CONTEXT (via waffle_display_supports_context_api).
>>>
>>> This is required by WGL which (as implemented in this patch) can
>>> support ES contexts via EXT_create_context_es*_profile yet provides
>>> all the symbols via a single library. We should check if ES context
>>> can be create prior rather than blindly trying to retrieve the symbols.
>>>
>>> Once waffle has GL dispatch we can remove all the dl functions from
>>> the waffle API, as we'll provide every function that the user needs.
>>>
>>> Note that this breaks the API in a non-backwards compatible way.
>>>
>>> TODO:
>>>  - Add a note in the release notes.
>>>
>>> Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com>
>>> ---
>>
>> The only remaining patch without review...
>>
>> I don't agree with this patch and think it's unneeded. Perhaps I'm
>> failing to see some subtelty of Windows.
>>
>> Here's my argument. waffle_dl_can_open($LIB_FOR_API) doesn't guarantee
>> that the platform supports $API. It can't. My Linux system, the one I'm
>> typing on right now, supports the following feature matrix according to 
>> wflinfo.
>>
>> platform=gbm                           | GL  GLES1  GLES2  GLES3
>> ---------------------------------------|-----------------------------
>> waffle_dl_can_open                     |  T      T      T      T
>> waffle_display_supports_context_api    |  T      T      T      T
>> Can really create given context type   |  T      T      T      T
>>
>>
>> platform=glx                           | GL  GLES1  GLES2  GLES3
>> ---------------------------------------|-----------------------------
>> waffle_dl_can_open                     |  T      T      T      T
>> waffle_display_supports_context_api    |  T      F      T     *F
>> Can really create given context type   |  T      F      T     *T
>>
>>
>> On my system, GBM supports GLES1 but GLX doesn't. Therefore the ability to
>> obtain functions with dlsym() should be independent of the display in use.
>> This behavior intentionally differs from waffle_get_proc_address().
>>
>> (To make it weirder, waffle_display_supports_context_api(glx_dpy, gles3) returns
>> false despite that the GLX display is actually capable of creating a GLES3 context.
>> This is because Mesa fails to advertise GLX_EXT_create_context_es_profile. This is
>> a Mesa bug, and Waffle needs a workaround for it.)
>>
> Ok let me put things in a different light:
> 
> 
>    The Windows issue:
> 
> All the (GL1.0) symbols come from a single file on Windows - opengl32.dll,
> while at the same time it's the display which knows if we should provide
> symbols for the ES* APIs.
> 
> 
>    The waffle confusion:
> 
> - waffle_dl_can_open
> Handles dlopening a library based on the API requested.
> 
> - waffle_display_supports_context_api
> States what context API can be used but not what API is purely/directly available.
                                                          ^^^^^^^^^^^^^^^
I'm unsure what you mean by "directly" available.
 
> I believe the issue here is dl_can_open is about a file to open, which may not
> always map nicely to "I can get ES* context".

Correct. Just because you can dlopen the OpenGL ES x.y library and get OpenGL ES x.y
symbols does not imply that you can actually create an OpenGL ES x.y context.

> I don't mind dropping the patch although I would appreciate some hints on how
> we can handle the "funny" Windows case.

The Windows case *is* odd. In a perfect world, we should deprecate waffle_dl_can_open()
and waffle_get_proc_address(), and instead replace them with a generic
waffle_get_the_proc_address_the_correct_way_for_this_os_and_context(). Now that
Khronos has published an XML description for the API, it shouldn't be too hard to write
such a function. That's essentially step #1 for any OpenGL dispatch library.

But... we need to implement Waffle's current weird API for Windows. On Linux, Waffle maps
each API to the library that provides that API's symbols.

Linux:
WAFFLE_DL_OPENGL		-> libGL
WAFFLE_DL_OPENGL_ES1		-> libGLESv1
WAFFLE_DL_OPENGL_ES2		-> libGLESv2
WAFFLE_DL_OPENGL_ES3		-> libGLESv2 (2 not 3!)

I don't believe that any spec requires libGLESv2 to statically expose the
GLES 3.0 symbols, even if its capable of creating a GLES 3.0 context. I also am
unaware of any spec that forbids libGLESv2 from statically exposing
GLES 3.0 symbols. (Please correct me if I'm wrong). Therefore, libGLESv2 on some Linux/Android
systems may not statically expose GLES 3.0 symbols even if a given EGL/GLXDisplay is capable of
creating a GLES 3.0 context on that libGLESv2. Weird.

And the same situation holds for s/Linux/Windows/ s/libGLESv2/opengl32.dll/.

Given the above precedent on Linux, I think it makes the most sense to map things
on Windows as below:

Windows:
x = waffle_dl_can_open(WAFFLE_DL_OPENGL);
asert(x == waffle_dl_can_open(WAFFLE_DL_OPENGL_ES1);
asert(x == waffle_dl_can_open(WAFFLE_DL_OPENGL_ES2);
asert(x == waffle_dl_can_open(WAFFLE_DL_OPENGL_ES3);

This behavior feels weird, but it's consistent with the semantics 
of waffle_dl_can_open(): "Can I open the library that provides
the symbols for the desired API?".