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:
https://gitlab.freedesktop.org/kbrenneman/xserver/tree/GLX_EXT_server_vendor_select
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