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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
