On Sun, Jan 16, 2011 at 10:42 AM, Chia-I Wu <olva...@gmail.com> wrote:
> On Fri, Dec 31, 2010 at 5:38 PM, Chia-I Wu <olva...@gmail.com> wrote:
>> On Wed, Dec 29, 2010 at 3:50 AM, Chia-I Wu <olva...@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.
Cheers Jakob.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
