![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=92.1){kind=small}
http://www.youtube.com/watch?v=g54y80bl
Pretty much is a laptop running xf86-video-modesetting driver, with my server, an xterm + metacity. Plug in a USB displaylink device, with a kernel drm driver I wrote for it. (Sneaky xrefresh in the background). and the USB device displays the xterm and metacity.
So what actually happens?
The X server at the start had loaded drivers using udev, and the a new driver ABI. It exports one X protocol screen and plugs an internal DrvScreen into it.
When the hotplug happens, the server inits another DrvScreen for the new device, and plugs it into the single protocol screen. It also copies all the driver level pixmaps/pictures/GCs into the new driver. The single protocol screen at the bottom layer multiplexes across the plugged in drvscreens.
This is like Xinerama pushed down a lot further in the stack, so instead of doing iterations at the protocol level, we do it down at the acceleration level. Also I have randr code hooked up so all the outputs appear no matter what GPU they are from.
This isn't exactly what I want for USB hotplug, ideally we'd use the main GPU to render stuff and only scanout using the USB device, but this is step one. I also need the ability to add/remove drvscreens and all the associated data in order to support dynamic GPU switching.
The real solution is a still a long ways off, but this is just a small light in a long tunnel, I've been hacking on this on/off for over a year now, so its nice to see something visible for the first time.
October 21 2011, 16:21:30 UTC 7 months ago
> ideally we'd use the main GPU to render stuff and only scanout using the USB device
I live in hope that, one day, my IGP only has to be used for scanout.
With xf86-video-modesetting + X changes, would (future) dynamic switching using a multi-GPU setup only require KMS drivers for the active and target GPUs?
October 21 2011, 18:25:56 UTC 7 months ago
October 23 2011, 12:35:13 UTC 7 months ago
October 28 2011, 07:12:59 UTC 7 months ago
October 28 2011, 01:18:52 UTC 7 months ago
The hybrid graphics / dynamic CPU switching case is important. But this assumption that hotplugged devices are second class citizens, that work needs to happen on some main GPU, that strikes me as incredibly wrong, as faultily monolithic. USB3, thunderbolt, external PCIe solutions, 40G ethernet... higher bandwidth is happening, and I still think good GPU resources might become a pluggable resource users commonly encounter.
If we can start plugging in high powered GPU bricks, will this infrastructure leverage that and let users hotplug and utilize those diverse resources?
MPX was brilliant because it acknowledged multiple resources. I'm no one, have no platform to be talking or addressing you from w/r/t this issue, but still I emotionally feel connected to this principle: if possible, keep in consideration the idea of pluggable high performance GPU's as you embark upon this incredibly awesome and important work.
Thanks David.
-mf / @rektide
October 28 2011, 07:17:52 UTC 7 months ago
Consider you have an intel GPU and you hotplug an nvidia gpu and want to expand the screen on it? now what does the GL stack report for that single screen? how does a compositor get rendered by both GPUs etc. The reason for only having master + offload GPUs is because the model is a lot easier to get working and is a lot more practical for now. Windows also doesn't try to work in this situation anymore, you can't plug in two GPUs that are different families (not just different manufactureres) it won't display on the second one. We can do a bit better, but doing homogeneous fullscreen spanning GL without application help is always going to be close to impossible to get either right or pretty.
October 28 2011, 07:36:22 UTC 7 months ago
October 28 2011, 08:09:42 UTC 7 months ago
Anonymous
December 3 2011, 12:14:37 UTC 5 months ago
Xspice
Xspice is implemented with a video driver. iiuc this should already work with your demo? mirror mode, two drivers, one for the hardware and another for Xspice, everything is rendered twice. For your real solution I hope you keep this use case in mind.