[Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess

[Chia-I Wu]

On Thu, Jan 20, 2011 at 11:06 PM, Jakob Bornecrantz
<wallbraker at gmail.com> wrote:
> On Sun, Jan 16, 2011 at 10:42 AM, Chia-I Wu <olvaffe at gmail.com> wrote:
>> On Fri, Dec 31, 2010 at 5:38 PM, Chia-I Wu <olvaffe at gmail.com> wrote:
>>> On Wed, Dec 29, 2010 at 3:50 AM, Chia-I Wu <olvaffe at gmail.com> wrote:
>>>> Since the same-dispatch-offset-different-glx-opcodes functions are
>>>> defined in GLX, glXGetProcAddress should be a better place to handle
>>>> them specially than _glapi_get_proc_address is.  With that change, I
>>>> am quite happy with the current status of shared glapi
>>>>
>>>>  http://cgit.freedesktop.org/~olv/mesa/log/?h=shared-glapi-2
>>> I've created a diagram showing the differences between GLX and EGL in
>>> terms of libraries, and showing where libglapi is used
>>>
>>>  http://people.freedesktop.org/~olv/tmp/egl-current.png
>>>  (the image size exceeds the list limit)
>>>
>>> The diagram shows a default setup.  When --enable-shared-glapi is
>>> given, libGL no longer defines _glapi* and libglapi will be used
>>> exclusively.
>> It has been a while.  If there is no objection, I will push the
>> changes to master on Wednesday.
>
> I'm sorry that I didn't bring this up earlier but it would be
> theoretically possible with EGL to make GLES and Desktop GL current at
> the same time using dlopen and symbol mangling.
> const char* (*dglGetString)(GLenum);
> const char* (*glesGetString)(GLenum);
>
> eglMakeCurrent(gles_ctx, draw1, draw1);
> eglMakeCurrent(dgl_ctx, draw2, draw2);
>
> printf("%s", dglGetString(GL_VERSION));
> printf("%s", glesGetString(GL_VERSION));
>
> The above should be allowed since the spec says: "If the calling
> thread already has a current context of the same client API type as
> ctx, then that context is flushed and marked as no longer current."
> and that OpenGLES and Desktop GL have different API types. But since
> your changes there can only be one current of any GL type.
This is the correct behavior.  Near the beginning of section 3.7,

  Only one OpenGL or OpenGL ES context may be current to a particular
  thread, even if the implementation supports OpenGL and both OpenGL ES
  1.x and OpenGL ES 2.x in the same runtime.

> Cheers Jakob.
>



-- 
olv at LunarG.com