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

[Emil Velikov]

On 18/08/14 22:40, Chad Versace wrote:
> 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.
>  
purely/directly = not via {W,}GL{,X}_compatibility_you_name_it_extension

>> 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.
> 
We'll get there eventually :P

> 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.
> 
I believe you are correct. Afaiu the whole idea is to preserve backwards
compatibility with ES2, and this seems like a nice way of doing it - don't
expose any new symbols to link against/dlsym.

> 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);
> 
So essentially give the middle finger to ES* under Windows ?
Note that it works with this patch - tested with the waffle demos + a couple
of piglits.

> 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?".
> 
In order to know what APIs are supported one has to know check for
glx_ext_create_context_es*_profile, which is decided/obtained/linked with a
display in mind. Thus dl* needs to have a connection to waffle_display in
order to to say "OK, I'm allowed to retrieve the symbol glHamBurger for XX API".

-Emil