[Glamor] glamor with current xserver Git

[He Junyan]

Hi:

I think we need to discuss this problem.

I trace this problem and find that this problem caused by the glx 
extension of xserver.
In the code of glx extension, it re-defines the symbols:

PUBLIC void _glapi_set_context(void *context)
PUBLIC void *_glapi_get_context(void)
PUBLIC void _glapi_set_dispatch(struct _glapi_table *dispatch)
PUBLIC struct _glapi_table *_glapi_get_dispatch(void)
PUBLIC int _glapi_add_dispatch(const char *const *function_names, const 
char *parameter_signature)
....

These symbols can be found both in glx and mapi and collide with each 
other,  and which one is called
really depends on the loading sequence of libglx.so and libglapi.so .

Both glx and egl will call the APIs of  __DRIdri2Extension and 
__DRIcoreExtension of dri drivers to create
the screen and context, so the screen and context struct seems compatible.
But for the getting the gl functions' address, they are not compatible.
eglGetProcAddress will depend a gl function's stub which is established 
by _glapi_add_dispatch, and the stub
will call the really gl function in _glapi_table.  But 
_glapi_add_dispatch in glx no not do this.
glx use another manner to call functions in the _glapi_table.
So in glamor, eglGetProcAddress just get invalid function address and 
have error when call gl function.

I am creating the glx wrapper layer to fix this, but find glx define 
another the _glapi_table struct and different
from it in mapi.  This means call glx's gl function may be mapped to 
wrong really gl function in mesa, so we still
seem have some risk by this manner.





On 08/29/2012 04:47 PM, Zhigang Gong wrote:
>> -----Original Message-----
>> From: Michel Dänzer [mailto:michel at daenzer.net]
>> Sent: Wednesday, August 29, 2012 3:33 PM
>> To: Zhigang Gong
>> Cc: glamor at lists.freedesktop.org
>> Subject: Re: [Glamor] glamor with current xserver Git
>>
>> On Mit, 2012-08-29 at 11:09 +0800, Zhigang Gong wrote:
>>> Junyan is working on this now. But I don't think we have any code
>>> ready to share currently. I discussed with him about the method to fix
>>> this issue, and we haven't got a very clean solution for it.
>>>
>>> The first way is which you mentioned in mail list. We switch to use
>>> glx context rather than the EGL context. But in my mind, this way, we
>>> may have a gap here. How can we bind the framebuffer's bo to a
>> texture?
>>> In EGL context, there is a standard EGL Image API to do this. Do you
>>> have any further suggestion here?
>> I was thinking of e.g. creating thin wrappers for the DRI_IMAGE* DRI
>> extensions (which are used for the EGL image API as well) in xserver/glx/
>> for use by glamor. But I haven't looked into whether this would be
> feasible
>> at all or how much effort it would take in any detail.
> [Gong, Zhigang] Anyway, this is the clean solution for the integration with
> GLX.
> We may need to dig further into it.
>
>>
>>> The second way is to still use EGL interface in glamor. But change the
>>> way to gl function handles to get from glx's dispatch table rather
>>> than calling eglGetProcAddress. But we think this method may have
>> some
>>> risk, we need to check the egl part code we are using carefully and
>>> make sure the incompatible gl dispatch table in the standard mesa
>> library is not used.
>>> Any comments?
>> I don't really understand how that would work. :)
> [Gong, Zhigang] I don't think this way is a clean method either. I thought
> the conflict part is the dispatch table. So if we avoid to use the dispatch
> table from the egl/glapi part, we may avoid the conflicts. But I may miss
> something important, I just realize that the context management part is
> also incompatible and will used by EGL internally.
>
> One good point of this way is that we can easily to give a try. Actually,
> We already used very similar method to work with the old version xorg
> And enable indirect glx. But that's a very hacky and unstable method.
> If we can figure out how to overcome the gap of the first solution, we
> should apply that one rather than the hacky solution.
>
> Thanks for your comments.
>>
>> --
>> Earthling Michel Dänzer           |
>> http://www.amd.com
>> Libre software enthusiast         |          Debian, X and DRI
>> developer
> _______________________________________________
> Glamor mailing list
> Glamor at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/glamor
>