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@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
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
