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