[RFC PATCH xserver 0/5] Server-side vendor neutral dispatch for GLX

[Kyle Brenneman]

On 08/30/2017 12:58 PM, Adam Jackson wrote:
> The idea here is that the DDX creates a GLX provider during AddScreen,
> and then GlxExtensionInit walks the list of created providers and calls
> their setup functions to initialize GLX for a screen. If you have
> heterogeneous GPUs in a Zaphod setup this would let you have GLX on
> both. If you often change between drivers with different GLX stacks,
> this lets the driver ask for the right thing instead of requiring
> xorg.conf changes.
>
> That's a lie, of course, because in this series the xfree86 DDX doesn't
> implicitly register a provider for you. I'm not sure what the best way
> to handle this is. I'd like not to have to touch every driver, and I'd
> like it if the DRI2 provider was only probed if the screen called
> DRI2ScreenInit, and I'd like it if that didn't rely knowing which order
> CallCallbacks was going to walk its list; I may not get everything I
> want. It might be worth just teaching the vnd layer about the swrast
> provider and letting it claim any otherwise-unclaimed screens, even
> though that feels like a layering violation.
>
> Other things that aren't quite handled yet:
>
> - autotools build system
> - windows and osx builds
> - dmx not ported
> - libglx should be loadable for more than just xfree86
>
> Still, feedback much appreciated.
>
> - ajax
>
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
Based on some experiments I've been working on with this interface, I've 
got a few ideas and suggestions that I can offer.

Using swrast as a last-resort fallback for an unclaimed screen makes 
sense, because as far as I can tell, it can work no matter what hardware 
or driver (or lack thereof) is there. As such, special-casing it from 
the VND layer seems reasonable, and avoids relying on the callback order.

But, both swrast and the DRI2 provider are currently implemented 
internally under what would effectively be a single VND vendor handle. 
If each provider had its own vendor handle, then that would be a cleaner 
match to the VND interface, but that seems like it would be a more 
invasive change.

However, I think just using the same linked list of providers that it's 
got now would still work, so we could implement the VND interface with 
swrast and DRI2 still lumped together, and separate them out later, 
without having to break compatibility.

I've got some follow-on patches to get the xfree86 server working with 
this interface, plus a few other random fixes. I wouldn't call them 
ready for production yet, but I'll send them out so that anyone who's 
interested can try it out.


In the meantime, though, I've been looking into making GPU offloading 
work between drivers, and I was hoping to get some feedback as well.

The basic idea is that we'd extend the VND interface so that each screen 
has a primary vendor (from whichever driver is actually driving the 
desktop), but you can register any number of secondary vendors as well.

Each client would then have its own (screen -> vendor) map. By default, 
it would use the primary vendor for each screen, but the client could 
send some sort of extension request to tell the server to use an 
alternative. After that, the dispatching code is the same -- each 
request gets forwarded to the appropriate vendor based on a (client, 
screen) pair.

Creating contexts, allocating rendering surfaces, and so on would be an 
internal detail between the client and server vendor libraries, so the 
VND interface doesn't need to care about it. I'm also assuming that 
whatever communication you need between drivers to get the resulting 
image onto the screen will be separate from the VND interface.

I think X visuals would be the hardest part, because the secondary (off 
screen) vendor might have a different set of visuals that it can render 
to, but a GLX client still needs to be able to pass one of those visuals 
to XCreateWindow. That's easy enough to describe at the protocol level, 
but defining the resulting driver behavior gets tricky.

-Kyle