[Glamor] glamor with current xserver Git

[Zhigang Gong]

> -----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