On Thu, Nov 20, 2014 at 10:34 AM, Chad Versace <[email protected]> wrote: > +Frank > > > On Wed 19 Nov 2014, Chad Versace wrote: >> >> On Mali EGL 1.4, you can't obtain non-extension functions (including >> OpenGL ES 3.0 functions) with eglGetProcAddress. You must use dlsym. >> >> This patch carefully avoids breaking glGetStringi on other platforms, >> which may expose glGetStringi dynamically (as in eglGetProcAddress) but >> not statically (as in dlsym). >> >> Fixes #20: https://github.com/waffle-gl/waffle/pull/20 >> Fixes: chromium:428061 >> [https://code.google.com/p/chromium/issues/detail?id=428061] >> See: https://github.com/anholt/libepoxy/issues/21 >> Reported-by: Frank Henigman <[email protected]> >> Cc: Daniel Kurtz <[email protected]> >> Signed-off-by: Chad Versace <[email protected]> >> --- >> >> Frank or Daniel, could you please validate this patch on Mali? I tested on >> Fedora with Mesa i965. >> >> >> >> >> src/utils/wflinfo.c | 23 ++++++++++++++++++++++- >> 1 file changed, 22 insertions(+), 1 deletion(-) >> >> diff --git a/src/utils/wflinfo.c b/src/utils/wflinfo.c >> index 0b03e55..0907b4b 100644 >> --- a/src/utils/wflinfo.c >> +++ b/src/utils/wflinfo.c >> @@ -1037,7 +1037,28 @@ main(int argc, char **argv) >> if (!glGetString) >> error_get_gl_symbol("glGetString"); >> >> - glGetStringi = waffle_get_proc_address("glGetStringi"); >> + // Retrieving GL functions is tricky. When glGetStringi is supported, >> here >> + // are some boggling variations as of 2014-11-19: >> + // - Mali drivers on EGL 1.4 expose glGetStringi statically from >> + // libGLESv2 but not dynamically from eglGetProcAddress. The EGL >> 1.4 spec >> + // permits this behavior.
In fact, AFAICT, EGL <= 1.4 mandates this behavior, since glGetStringi is an OpenGL ES 3.0 "non-extension" function. That is, unless your EGL has EGL_KHR_get_all_proc_addresses [0]: [0] https://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_get_all_proc_addresses.txt >> + // - EGL 1.5 requires that eglGetStringi be exposed dynamically >> through >> + // eglGetProcAddress. Exposing statically with dlsym is optional. EGL 1.5 essentially makes EGL_KHR_get_all_proc_addresses part of the standard. So perhaps the check is something crazy like: if (extension-function(function) || EGL >=1.5 || (is_display_init() && EGL_has_extension("EGL_KHR_get_all_proc_addresses")) || (EGL_supports_client_extensions() && EGL_has_client_ extension("EGL_KHR_client_get_all_proc_addresses")) { use eglGetProcAddress(function); } else { use platform-specific-lookup(function); } Do you agree with this? But... couldn't we avoid this whole mess by just always using glGetString() in wflinfo instead of jumping through hoops just to try to use glGetStringi()? >> + // - Windows requires that glGetStringi be exposed dynamically from >> + // wglGetProcAddress. Exposing statically from GetProcAddress >> (Window's >> + // dlsym equivalent) is optional. >> + // - Mesa drivers expose glGetStringi statically from libGL and >> libGLESv2 >> + // and dynamically from eglGetProcAddress and glxGetProcAddress. >> + // - Mac exposes glGetStringi only statically. >> + // >> + // Try waffle_dl_sym before waffle_get_proc_address because >> + // (1) egl/glXProcAddress can return invalid non-null pointers for >> + // unsupported functions and (2) dlsym returns non-null if and only >> if the >> + // library exposes the symbol. >> + glGetStringi = waffle_dl_sym(opts.dl, "glGetStringi"); >> + if (!glGetStringi) { >> + glGetStringi = waffle_get_proc_address("glGetStringi"); >> + } >> >> const struct wflinfo_config_attrs config_attrs = { >> .api = opts.context_api, >> -- >> 2.1.2.1.g5433a3e >> > _______________________________________________ waffle mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/waffle
