Skip to content
Snippets Groups Projects

WIP: GLX Extension to control GLXVND dispatching for PRIME GPU offloading

Closed Kyle Brenneman requested to merge kbrenneman/xserver:GLX_EXT_server_vendor_select into master
3 unresolved threads

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

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Kyle Brenneman added 311 commits

    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.

    Compare with previous version

  • Kyle Brenneman added 7 commits

    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.

    Compare with previous version

  • I'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.

  • Aaron Plattner
    Aaron Plattner @aplattner started a thread on commit e7000c6b
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
  • What actually breaks the ABI in this series, if we don't include the pieces that add the extension? For clarity, it might be nice for the ABI version bump to be squashed into the commit that actually breaks the ABI.

  • 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.

  • Please register or sign in to reply
  • Kyle Brenneman mentioned in merge request !194 (closed)

    mentioned in merge request !194 (closed)

  • Adam Jackson changed milestone to %xserver-21.1

    changed milestone to %xserver-21.1

  • Aaron Plattner removed milestone

    removed milestone

  • 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.

  • do we have an estimate on which version of xserver this will be released or at all ?

  • Please register or sign in to reply
    Loading