RFC - GLX Extension to control GLXVND dispatching for PRIME GPU offloading

Kyle Brenneman kbrenneman at nvidia.com
Wed Apr 17 15:51:42 UTC 2019

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.

Anyway, I've got a draft of the extension spec here, and I've written up 
a series of patches for the X server to implement it here:

Comments and questions welcome.

-Kyle Brenneman



Name Strings



     Kyle Brenneman, NVIDIA, kbrenneman at nvidia.com


     Kyle Brenneman


     XXX - Not complete yet!!!


     Last Modified Date: April 11, 2019
     Revision: 1


     OpenGL Extension #???


     GLX version 1.2 is required.

     This specification is written against the wording of the GLX 1.3
     Protocol Encoding Specification.


     In multi-GPU systems, a client may decide at runtime which device
     and driver to use for GLX, for example to choose between a
     high-performance and low-power device.

     This extension defines a set of requests that allow a client to
     specify which server-side driver should handle GLX requests from the
     sending client for a particular screen.

IP Status

     No known IP claims.

New Procedures and Functions


New Tokens


Additions to the GLX Specification

     None. These requests are intended to be used by a client-side GLX
     implementation, not by an application. Therefore, this extension
     does not define any new functions or changes to the GLX

GLX Protocol

     Get a List of Server-Side Drivers

         Name: glXQueryServerVendorIDsEXT

             This request fetches a list of available server-side
             drivers, and the current vendor ID selected for each screen.
             Each driver is identified by an Atom, with a string chosen
             by the driver.

             The reply contains a list of the currently selected vendors
             first, with one Atom for each screen. This will be the
             vendor selected with the glXSelectScreenServerVendorIDEXT
             request, or the default vendor if the client has not sent a
             glXSelectScreenServerVendorIDEXT request for a screen.

             If a screen is using the default vendor, and the vendor does
             not have a vendor ID, then the corresponding Atom in the
             reply will be None.

             After the currently selected vendors, the reply will contain
             a list of all available vendor ID's.

             Note that the list of available vendors is global, not
             per-screen. The client-side driver is responsible for
             determining which screens it can support.

             1       CARD8       opcode (X assigned)
             1       17          GLX opcode (glXVendorPrivateWithReply)
             2       3           request length
             4       1417        vendor-specific opcode
             4                   unused
             1       1           reply
             1                   unused
             2       CARD16      sequence number
             4       n+s         reply length
             4       CARD32      num_vendors
             20                  unused
             4*s     LISTofATOM  current_vendor_ids (s = ScreenCount(dpy))
             4*n     LISTofATOM  vendor_ids

     Select a Server-Side Driver For a Screen

         Name: glXSelectScreenServerVendorIDEXT

         Errors: BadValue

             This request specifies that GLX requests for a screen should
             be dispatched to a particular server-side vendor.

             This only applies to requests from the client that sends the
             glXSelectScreenServerVendorIDEXT request. Requests from
             other clients are unaffected.

             As a special case, if vendorID is None, then the server will
             revert to the default vendor for a screen. This applies even
             if the screen's default vendor does not have a vendorID.

             A BadValue error is generated if vendorID is not None or a
             valid vendor ID.

             1       CARD8       opcode (X assigned)
             1       16          GLX opcode (glXVendorPrivate)
             2       5           request length
             4       1418        vendor-specific opcode 
             4                   unused
             4       CARD32      screen
             4       ATOM        vendorID

     Vendor-Specific Private Request
         Name: glXNamedVendorPrivateEXT

         Errors: BadValue

             This request sends a vendor-specific command to a vendor
             based on its vendor ID. The named vendor need not be
             assigned to any screen.

             A BadValue error is generated if vendorID is not a valid
             vendor ID. GLX vendors may also generate other errors.

             1       CARD8       opcode (X assigned)
             1       16          GLX opcode (glXVendorPrivate)
             2       4+(n+p)/4   request length
             4       1419        vendor-specific opcode 
             4                   unused
             4       ATOM        vendorID
             n       LISTofBYTE  vendor-specific data
             p                   unused, p=pad(n)

     Vendor-Specific Private Request with Reply
         Name: glXNamedVendorPrivateWithReplyEXT

         Errors: BadValue

             This request is identical to glXNamedVendorPrivateEXT,
             except that it generates a reply.

             Note that the request is identical except for using the GLX
             opcode glXVendorPrivateWithReply.

             1       CARD8       opcode (X assigned)
             1       17          GLX opcode (glXVendorPrivateWithReply)
             2       4+(n+p)/4   request length
             4       1419        vendor-specific opcode 
             4                   unused
             4       ATOM        vendorID
             n       LISTofBYTE  vendor-specific data
             p                   unused, p=pad(n)
             1       1           reply
             1                   unused
             2       CARD16      sequence number
             4       n           reply length
             24      LISTofBYTE  returned data
             4*n     LISTofBYTE  more returned data




     1)  Should server-side drivers be identified by Atoms or XIDs?

         PROPOSED: Use an Atom. Using an XID seems somewhat cleaner, but
         it would require an additional query for the client to know
         which XID corresponded to which server-side driver.

         Using an Atom, each driver can simply define the string to use a

     2)  Should glXQueryServerVendorIDsEXT send back the currently
         selected vendor ID for each screen?

         PROPOSED: Yes. Being able to query the current screens might be
         useful for a client to restore the previous assignments in case
         of an initialization failure.

     3)  Are the glXNamedVendorPrivateEXT requests needed?

         PROPOSED: Yes. The two glXNamedVendorPrivateEXT requests provide
         a well-defined communication channel between the client and
         server sides of a driver.

         Sending a request to a specific driver would still be possible
         without these requests, but would require either defining a
         separate X11 extension or relying on implementation details of

Revision History

     1. 11 April 2019
         - Initial draft.

More information about the xorg-devel mailing list