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 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". I don't mind dropping the patch although I would appreciate some hints on how we can handle the "funny" Windows case. Cheers, Emil _______________________________________________ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
