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

[Kyle Brenneman]

On 12/15/2016 10:53 AM, Hans de Goede wrote:
> Hi,
>
> On 15-12-16 17:08, Emil Velikov wrote:
>> On 15 December 2016 at 08:15, Michel Dänzer <michel at daenzer.net> 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.
>>>
>> The "xfree86: Extend OutputClass config sections" series from Hans 
>> just landed.
>> With it one can correctly attribute/select the correct libglx.so,
>> which should tackle the issue ;-)
>
> Not if you want to run some apps one GPU and other apps on the other
> GPU ...
>
> Regards,
>
> Hans

More specifically, to allow different drivers on different screens, 
we'll need to define some interface that would dispatch each GLX request 
to the appropriate driver. Basically, a server-side counterpart to 
libglvnd's libGLX.so.

A server interface should be a lot simpler than the client interface, 
though. Everything runs on one thread, we only have to care about 
mapping based on XID's and context tags, we don't have to worry about 
multiple servers with different sets of vendors, we can ignore basically 
everything that libGLdispatch.so is needed for in the client, and the 
opcodes nicely define a dispatch table for us.

Using EGL might work, although I don't know my way around the server 
well enough to comment on what that would take. The biggest problem that 
I see is that if you've got a single, common library that translates GLX 
requests to EGL calls, then how would a vendor library define a new GLX 
extension?

Also note that they may or may not be mutually exclusive. If you can use 
libEGL.so to draw to a surface within the server, then I'd expect you 
could implement a vendor library that works by calling into EGL. Mind 
you, if you had two vendors trying to do that, then things would get hairy.

-Kyle