https://bugs.freedesktop.org/show_bug.cgi?id=32285
--- Comment #4 from Jammy Zhou <jammy.z...@linaro.org> 2010-12-10 00:21:08 PST --- (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > Thanks for the quick response and detailed explanation. > > > > > Created an attachment (id=40980) View: https://bugs.freedesktop.org/attachment.cgi?id=40980 Review: https://bugs.freedesktop.org/review?bug=32285&attachment=40980 [details] > > > hack to work > > > > > > It may depend on your setup and the dynamic linker, but this patch to > > > renderer_info.c may "fix" the issue, even with the "failed to remap ..." > > > messages. Or alternatively, you can try linking to libGL.so directly when > > > compiling and call glGetString directly. > > > > With this patch, both GL and GLESv2 renderer info can be got successfully > > now. > > But this seems a little tricky, and in this case the dispatch table of > > GLESv2 > > is also used for OpenGL/GLX context. I am curious why > > "dlclose(gles2_handle);" > > didn't clean libGLESv2.so out of the address space? > Because it is linked to by st_GLESv2.so, which is not unloaded until the app > exits. > > By the way, because I want to make my application independent of both libGL > > and > > libGLESv2, I cannot link it directly to libGL.so or libGLESv2.so. > It should also work if you dlopen with RTLD_GLOBAL. But these are all (very > bad) workarounds. It is still the best to fix the bug. I tried RTLD_GLOBAL before, but it doesn't work either. Yes, we need to fix the bug itself in mesa. ;) > > > > > > The bug here is that there are two copies of glapi: one in libGL.so and > > > the > > > other in libGLESv2.so. One of the things that glapi does is to manage the > > > dispatch table of the current context. When the OpenGL ES context is > > > first > > > made current, the dispatch table in libGLESv2.so is updated. Calling > > > glGetString from libGLESv2.so gives the correct result. > > > > > > But when the OpenGL context is made current, the dynamic linker decides to > > > update the dispatch table in libGLESv2.so again. If you call glGetString > > > from > > > libGL.so, it will be no-op since the dispatch table in libGL.so is never > > > updated. > > > > > > For the same reason, when the OpenGL context is created, the remap table > > > in > > > libGLESv2.so is updated. Since OpenGL has much more entry points than > > > libGLESv2.so can handle, you will see the "failed to remap ..." messages > > > after > > > the entry points in libGLESv2.so run out. > > > > Hmm... resonable > > > > > > > > 16ee7a55ae26 only fixed core mesa (src/mesa/). It will only work when an > > > app > > > links to either one of libGL.so or libGLESv2.so, and use > > > eglGetProcAddress to > > > get the addresses of the entry points that are not statically available. > > > > > > But when both libGL.so and libGLESv2.so are used, the app will be > > > affected by > > > this bug. A fix to glapi (src/mapi/glapi/) is required. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
