[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 #4 from Jammy Zhou <jammy.zhou at 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.