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

Aaron Plattner aplattner at nvidia.com
Tue Apr 23 22:28:28 UTC 2019


On 4/17/19 8:51 AM, Kyle Brenneman wrote:
> 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:
> https://gitlab.freedesktop.org/kbrenneman/xserver/tree/GLX_EXT_server_vendor_select 

Hi Kyle,

Have you gotten any feedback on the commits there? It might help to 
create an xorg/xserver merge request for them. You can use the "WIP:" 
prefix on the MR title if you just want to request feedback without 
actually getting it merged.

-- Aaron

> Comments and questions welcome.
> 
> -Kyle Brenneman
> 
> 
> Name
> 
>      EXT_server_vendor_select
> 
> Name Strings
> 
>      GLX_EXT_server_vendor_select
> 
> Contact
> 
>      Kyle Brenneman, NVIDIA, kbrenneman at nvidia.com
> 
> Contributors
> 
>      Kyle Brenneman
> 
> Status
> 
>      XXX - Not complete yet!!!
> 
> Version
> 
>      Last Modified Date: April 11, 2019
>      Revision: 1
> 
> Number
> 
>      OpenGL Extension #???
> 
> Dependencies
> 
>      GLX version 1.2 is required.
> 
>      This specification is written against the wording of the GLX 1.3
>      Protocol Encoding Specification.
> 
> Overview
> 
>      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
> 
>      None
> 
> New Tokens
> 
>      None
> 
> 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
>      specification.
> 
> GLX Protocol
> 
>      Get a List of Server-Side Drivers
> 
>          Name: glXQueryServerVendorIDsEXT
> 
>          Description:
>              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.
> 
>          Encoding:
>              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
> 
>          Description:
>              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.
> 
>          Encoding:
>              1       CARD8       opcode (X assigned)
>              1       16          GLX opcode (glXVendorPrivate)
>              2       5           request length
>              4       1418        vendor-specific opcode 
> (glXSelectScreenServerVendorIDEXT)
>              4                   unused
>              4       CARD32      screen
>              4       ATOM        vendorID
> 
>      Vendor-Specific Private Request
>          Name: glXNamedVendorPrivateEXT
> 
>          Errors: BadValue
> 
>          Description:
>              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.
> 
>          Encoding:
>              1       CARD8       opcode (X assigned)
>              1       16          GLX opcode (glXVendorPrivate)
>              2       4+(n+p)/4   request length
>              4       1419        vendor-specific opcode 
> (glXNamedVendorPrivateEXT)
>              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
> 
>          Description:
>              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.
> 
>          Encoding:
>              1       CARD8       opcode (X assigned)
>              1       17          GLX opcode (glXVendorPrivateWithReply)
>              2       4+(n+p)/4   request length
>              4       1419        vendor-specific opcode 
> (glXNamedVendorPrivateEXT)
>              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
> 
> Errors
> 
>      None
> 
> Issues
> 
>      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
>          priori.
> 
>      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
>          GLXVND.
> 
> Revision History
> 
>      1. 11 April 2019
>          - Initial draft.
> 


More information about the xorg-devel mailing list