Thanks, Kyle.
For a little more context for others on xorg-devel: NVIDIA's GLX
implementation sends GLX protocol even when direct rendering, to
coordinate between client-side and server-side components. For PRIME
render offload, we'd like those GLX protocol requests to get routed to
NVIDIA's GLX implementation, regardless of the X driver of the X screen.
I'm curious what others think about a few general questions:
(1) Does it seem reasonable to update GLXVND within the X server
to be able to dispatch to different vendors on a per-client basis?
An alternative could be for NVIDIA's implementation to just tunnel
its GLX requests through private protocol. But, dispatching in GLXVND
seems cleaner to me.
(2) Does it seem reasonable to add a GLX extension to control this?
Even though Mesa doesn't need this, we thought it would be cleanest
to control through an extension. Though, maybe it is odd to add a
GLX extension intended to only be used by GLX client-side libraries?
(Or maybe that is no different than implementation-specific X extensions
like DRI3, Present, or NV-GLX).
I suppose an alternative to a full-blown GLX extension would just
be an exported function within the server, such that server-side GLX
implementations could update GLXVND's dispatching per-client, if needed.
Anyway, I know it can be hard to get excited about GLX in 2019, but it
would be nice to hear if others think GLX_EXT_server_vendor_select is
a sane direction.
Thanks,
- Andy
On Wed, Apr 24, 2019 at 09:26:56AM -0600, Kyle Brenneman wrote:
> 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
> > >
>
