[Mesa-dev] [Bug 32285] Check OpenGL and OpenGL ES2.0 renderer info in one process

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32285

--- Comment #1 from Chia-I Wu <olvaffe at gmail.com> 2010-12-09 23:09:37 PST ---
Created an attachment (id=40980)
 View: https://bugs.freedesktop.org/attachment.cgi?id=40980
 Review: https://bugs.freedesktop.org/review?bug=32285&attachment=40980

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.

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.

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.