WIP: GLX Extension to control GLXVND dispatching for PRIME GPU offloading
For GPU offloading in libglvnd, where individual clients can run with an alternate GPU and client-side vendor library, we'd need some way for that alternate vendor library to communicate with its server-side counterpart. Normally, the server's GLXVND layer would dispatch any GLX requests to whichever driver is running an X screen. This is a GLX extension that allows a client to tell the server to send GLX requests to a different driver instead.
The basic idea is that the server keeps a separate (screen -> GLXServerVendor) mapping for each client. The current global mapping is used as the default for each new client, but the client can send a request to change its own mapping. That way, if the client uses a different vendor library, then the client-side vendor can arrange for any GLX requests to go to the matching server-side driver.
The extension uses Atoms as an ID to identify each GLXServerVendor, using a string provided by the driver. That way, the client-side driver can know which Atom it needs to use without having to define an extra query. The client can send a request with a screen number and a vendor ID to tell the server to dispatch any GLX requests for that screen to the specified vendor. A client can also send None as a vendor ID to revert to whatever GLXServerVendor would handle that screen by default.
I also added a GLXVendorPrivate/GLXVendorPrivateWithReply-style request, which sends a request to a specific vendor based on a vendor ID, without having to worry about which vendor is assigned to a screen at the moment. Strictly speaking, a vendor library could get the same result by adding a regular GLXVendorPrivate request, and providing a dispatch function that always routes the request to itself, but that seems like it's more of an implementation detail of GLXVND.
Also, this extension doesn't define any errors or queries to check whether a GLXServerVendor can support a given screen. These requests would be sent by a client-side vendor library (not by libglvnd or an application), so each driver would be responsible for figuring out on its own which screens it can support.
This is a rough draft of the extension spec: GLX_EXT_server_vendor_select.txt
Merge request reports
Activity
added 311 commits
-
6d8bf40c...836f93de - 303 commits from branch
xorg:master
- b6a49966 - GLX: Add a per-client vendor mapping.
- e767b45d - GLX: Use the sending client for looking up XID's
- ac9d68ea - GLX: Handle GLXQueryServer/ExtensionsString requests in GLXVND.
- ac316ab3 - GLX HACK: Define structs for GLX_EXT_server_vendor_select
- 82d3e476 - GLX: Assign a name to each GlxServerVendor.
- 88aa38bd - GLX: Implement GLX_EXT_server_vendor_select
- c312c36d - GLX: Append GLX_EXT_server_vendor_select to the GLX_EXTENSIONS string.
- 30c7fd18 - GLX: Bump the GLXVND major version number.
Toggle commit list-
6d8bf40c...836f93de - 303 commits from branch
added 7 commits
- 0607b5e7 - GLX: Add a function to change a clients vendor list.
- 22648d91 - GLX: Handle GLXQueryServer/ExtensionsString requests in GLXVND.
- 726de86e - GLX HACK: Define structs for GLX_EXT_server_vendor_select
- f19ac73f - GLX: Assign a name to each GlxServerVendor.
- 228b0521 - GLX: Implement GLX_EXT_server_vendor_select
- ca863c00 - GLX: Append GLX_EXT_server_vendor_select to the GLX_EXTENSIONS string.
- e7000c6b - GLX: Bump the GLXVND major version number.
Toggle commit listI've added a new version of this based on Andy's suggestion of just exporting a function in the server to control a per-client vendor list, rather than defining a whole GLX extension for it.
With this, everything up through 0607b5e7 adds the per-client vendor list to the server, and adds a function to GlxServerExports that lets a driver update that mapping. That would be enough to let a driver assign itself to a screen for a specific client for GPU offloading.
The commits after that add the same GLX_EXT_server_vendor_select extension. The only thing that the extension adds at this point is a standard interface to clients, so that individual drivers don't have to define their own protocol for it.
74 74 * number is incremented when there's a change but existing vendor libraries 75 75 * will still work. 76 76 */ 77 #define GLXSERVER_VENDOR_ABI_MAJOR_VERSION 0 77 #define GLXSERVER_VENDOR_ABI_MAJOR_VERSION 1 Without the extension, the breaking change is to add a ClientPtr parameter to
GlxServerExports::getXIDMap
, so that it can look up a window XID from the correct client's map.I've added an alternate version in !194 (closed) that leaves getXIDMap unchanged, and instead stores the ClientPtr in a global variable. That's a bit more verbose, but it keeps the ABI backward-compatible.
mentioned in merge request !194 (closed)
changed milestone to %xserver-21.1
I removed this series from %"xserver-1.21" in favor of !194 (closed), which doesn't require adding a new GLX extension. We can revisit this extension later if it turns out to be useful for other GLX vendors.
This change specifically probably won't get checked in at all, since !194 (closed) got checked in instead. I just forgot to close this merge request -- sorry about that.
Note that !194 (closed) doesn't include the GLX extension, since there didn't seem to be much interest in it, and adding it added more complexity (and broke ABI compatibility). The same internal functionality is available, but a driver would need to define its own protocol to use it.
If there's interest in that GLX extension, though, then I could update these changes on top of !194 (closed).
Perfect. I see !194 (closed) got merged with master. So we just have to wait for NVIDIA/any other gpu manufacturer to release a driver update to support GPU-offloading, is that correct?
It got merged to server-1.20-branch with !212 (merged) so it'll be in xserver 1.20.6.
I don't think so. The milestone for it is %xserver-1.20.6 but there's no date set there. I don't think GitLab's milestones are really being used yet to track releases.