[RFC] Server side glvnd

[Aaron Plattner]

Adding Kyle to To -- he's been working on something similar.

On 07/18/2017 08:43 AM, Adam Jackson wrote:
> I've been thinking about how to get multiple GL stacks to coexist
> within the server, along the lines of libglvnd on the client side. This
> is a bit of a brain dump, the intrepid can find some work in progress
> along these lines here:
> 
> https://cgit.freedesktop.org/~ajax/xserver/log/?h=glxfe
> 
> The basic approach I've been taking is: how little does the GLX
> provider's dispatch code need to be modified?
> 
> For QueryVersion, we can just return 1.4. For the ClientInfo requests,
> we have to dispatch them to every backend. For every other request, we
> need to inspect some key element of the request and use that to map to
> a backend. There are only three kinds of objects for this purpose:
> screen numbers (sigh), XIDs, and context tags. The screen mapping is
> straightforward. For XIDs we can set up a mapping on creation:
> GLXCreateWindow is dispatched to a backend (by screen number), on
> success we create a shadow resource with the same XID whose value
> points to the backend that created it.
> 
> Tags are uglier because tags are ugly [1]. The code I currently have
> for this simply treats tags as XIDs because in Xorg's GLX they are. But
> tags are assigned by the backend, not the client: they're in the reply
> to MakeCurrent. So the backend's MakeCurrent hook will need to be
> different from a non-glvnded version, allocating the tag from the
> frontend.
> 
> The other quirk with MakeCurrent is, when switching between contexts on
> different backends, one must first detach the old context and then
> attach the new. But that's two backend calls, and MakeCurrent as a
> protocol request wants to emit a reply, and libGL is absolutely not
> prepared to hear two replies to a single request. So the backend vtable
> probably also needs a LoseCurrent hook. (I tried to hide this detail in
> the frontend via ReplyCallback, and I was not very pleased with myself
> afterwards.)
> 
> SwapBuffers has to dispatch based on the drawable, not the context tag,
> because the tag may be None. Thanks SGI.
> 
> GLX requests with opcode >= 101 are "single" requests corresponding to
> GL API calls that don't fit in a Render request; they are dispatched
> relative to a context tag, so the backend vfunc can simply be int
> (*Single)(ClientPtr client). Requests from 1 to 35 are GLX API calls,
> and have a mostly static dispatch setup. The exceptions are
> VendorPrivate and VendorPrivateWithReply. For these I imagine the
> backend will register a list of { vop, object, offset, error } tuples
> for each request it supports.
> 
> VendorPrivate requests are also tricky because, being GLX API, they can
> also create and destroy objects. The shadow resource trick (above)
> makes destruction lifetime simple, but the frontend will need to expose
> methods to allow e.g. glXCreateGLXPbufferSGIX to register its XID. (In
> principle GLX extensions could also create named objects on which one
> should dispatch that are not XIDs. I'm not aware of any extensions like
> that at the moment, and I kind of want not to support anyone making
> that mistake.)
> 
> In principle, the above is enough in a Zaphod Xorg configuration to
> have heterogeneous GLX providers on different ScreenRecs. It would also
> make it easy, in a single ScreenRec case, to determine the GLX provider
> based on the DDX driver in use (e.g., I updated my kernel but not my
> NVIDIA driver, nouveau wants Xorg's GLX not NVIDIA's). For homogeneous
> Xinerama-enabled GLX this should not lose any functionality, since the
> backend can simply be the same for all objects.
> 
> Open questions:
> 
> - What more is needed for Prime setups? For direct contexts, I don't
> think much. For indirect contexts presumably you'd want a way to
> communicate the desired GPU when you create the GLX drawable and have
> that determine the screen you dispatch to.
> 
> - What more is needed for Xinerama+GLX with the open driver stack? We
> have some flexibility here, GLX_EXT_glvnd lets us name whatever client-
> side library we want, so we can ask for a new Mesa target that knows
> how to be multi-GPU aware.
> 
> - What more is needed for credible GLX on non-xfree86 servers, in
> particular Xwayland? I think, if the pig is given enough thrust, it
> would be possible to build accelerated GLX atop just about arbitrary
> EGL stacks; in that sense it'd be cool if Xwayland could do reasonable
> amounts of GLX accel with the stock backend. But I don't think that's
> going to get feature or performance parity with xfree86 on its own, if
> nothing else the open stack doesn't have stereo support.
> 
> - What else am I missing?
> 
> [1] - The GLX spec describes context tags as _not_ being the same as
> the context XID, with the explanation that the context may be destroyed
> but still be current to a client. Yes, and? You can prevent the client
> from reusing the XID by simply not freeing it, the client is going to
> ask XC-MISC for free IDs when it needs to start reusing them. I _think_
> this is because GLX 1.0 predates XC-MISC, but 1994 was a long time ago
> so maybe we can assume it's there now.
> 
> - ajax