RFC - GLX Extension to control GLXVND dispatching for PRIME GPU offloading
Kyle Brenneman
kbrenneman at nvidia.com
Wed Apr 24 15:26:56 UTC 2019
On 4/23/19 4:28 PM, Aaron Plattner wrote:
> 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.
Not a bad idea. I've posted a merge request with the patches here, and
attached the extension spec:
https://gitlab.freedesktop.org/xorg/xserver/merge_requests/179
-Kyle
>> 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