[PATCH 00/54] extmod, again (and XAA)

[Michel Dänzer]

On Die, 2012-07-10 at 18:29 +0800, Zhigang Gong wrote: 
> > -----Original Message-----
> > From: xorg-devel-bounces+zhigang.gong=linux.intel.com at lists.x.org
> > [mailto:xorg-devel-bounces+zhigang.gong=linux.intel.com at lists.x.org] On
> > Behalf Of Michel D?nzer
> > Sent: Tuesday, July 10, 2012 4:30 PM
> > To: Keith Packard
> > Cc: xorg-devel at lists.x.org; Daniel Stone; glamor at lists.freedesktop.org
> > Subject: Re: [PATCH 00/54] extmod, again (and XAA)
> > 
> > On Die, 2012-07-10 at 01:04 -0700, Keith Packard wrote:
> > > Daniel Stone <daniel at fooishbar.org> writes:
> > >
> > > > This should hopefully be the very totally final version of the
> > > > extmod patches.  These have all had to be rebased, and some have
> > had
> > > > to have minor tweaks, so I've sent them out again.
> > >
> > > Wow. Ok, fixed up for alanc's changes and merged to master.
> > >    ad4092c..532fbc2  master -> master
> > 
> > This breaks glamor. Looks like loading the glamoregl module from
> > xorg.conf is no longer sufficient to ensure it picks up the GL dispatch
> table
> > from libGL(ESv2) instead of from the X server.
> > 
> > Glamor developers, have you looked into options for not requiring the
> > glamoregl module to be loaded early, e.g. by using the X server's GLX code
> > instead of libGL?
> Thanks for the reminder. 
> 
> To use the GLX code rather than libGL seems a little difficult for glamor.
> There are two problems need to be solved here:
> 1. glamor is using egl, and egl load libglapi.so directly and use the
> libgl's dispatch
> table rather than glx's. As in general libgl's dispatch table and the glx's
> dispatch table
> are not the same. So when we get gl functions' entry point by using
> eglGetProcAddress,
> we may get incorrect function pointer. For example, take current git master
> version of
> mesa and X. glGenBuffers's index at libgl's 513, but GLX's 513 is
> glDeleteBuffers
> 
> 2. Glamor can be configured using GLESv2, GLX's code only has GL API and
> doesn't
> support GLESv2.
> 
> As the major target of glamor is still GL not GLESv2, we can ignore the
> second problem
> currently. But I don't have a good idea of how to solve the problem 1.
> 
> Any suggestions?

I was wondering if, as an alternative to using libEGL and libGL(ESv2),
it might be possible for glamor to hook into the xserver GLX code
directly. That would probably require some extensions / modifications to
the xserver GLX code. But it would eliminate the weird module loading /
initialization ordering requirement of the current solution, which no
longer works at all with current xserver master, and didn't work for me
for GLX indirect rendering before either.


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer