Xorg glx module: GLVND, EGL, or ... ?

[Adam Jackson]

On Thu, 2016-12-15 at 17:15 +0900, Michel Dänzer wrote:
> Hi Adam, Andy, Kyle,
> 
> 
> even with GLVND in place and used by Mesa and other GL implementations,
> one remaining issue preventing peaceful coexistence of Mesa based and
> other GLX implementations is that other GLX implementations tend to ship
> their own, mutually incompatible versions of the Xorg glx module. I'm
> not sure about all the reasons for this, but an important one is that
> the glx module in the xserver tree has been using the DRI driver
> interface directly, which can only work with Mesa.
> 
> Adam, IIRC you previously mentioned the possibility of making the
> xserver glx module use EGL instead of the DRI driver interface. Another
> possibility might be to make it use GLVND. Is my understanding correct
> that those are basically two mutually exclusive approaches for
> addressing this issue? Maybe there's even more options I'm not aware of?

They are not mutually exclusive. Complementary if anything.

Apologies for the long reply.

Currently xserver's glx "knows about" the DRI interface in several
ways. One is that we query the DRI driver for the list of fbconfigs at
server initialization. We could just as easily ask for it from the EGL
implementation, assuming we know how to map from the current GLX screen
to the corresponding EGL device. (Yes, the correspondence with
EGLConfigs is not perfect, but not I suspect in ways that matter.)

We also know about the DRI extension interface and wire up certain GLX
extensions based on their presence. These are in two classes: features
we could infer from equivalent EGL existing features, or features that
only apply to actual indirect contexts (EXT_texture_from_pixmap for
example). For the latter, I'd imagine another small loadable driver -
or perhaps part of the ddx driver in xfree86 - would simply register
protocol dispatch functions and the libglx core would handle
dispatching to them based on the context tag.

Finally, for actual indirect contexts, we use the DRI interface to
create and manage them. Clearly we can use eglCreateContext to mirror
the context state. The glx driver would supply a callback for drawable
creation, to bind window system surfaces in a way that's visible to the
proxy context. There'd be another callback for SwapBuffers. I think
that's all you'd need to hook from core GLX 1.4, anything else would
necessarily be extension requests as above.

I think the above would all be an improvement even if we were only
considering Mesa on only one screen (although it would necessarily
spell doom for DRI1, which Mesa has no EGL backend for nor could it
really). Adding glvnd means we could support different vendors' mostly-
EGL backends on different screens. Future work could include supporting
different vendors' backends on the _same_ screen, for heterogeneous GPU
models where each has a disjoint set of outputs and you'd like to swap
buffers "near" their output.

- ajax