Tag: multiseat

adopt a child and make multi-card work on Linux

Previously, the message was for toolkit, now it targets new upcoming developers… okay, if I’d be offensive I could say it targets vendor distributions which care for desktop on Linux :)

—

I have started hacking on X due the laboratory at my university I was working was running an amazing project to employ computer labs in all high-schools of the state I was living, in Brazil. It was a successful and all 2.100 schools used the multiseat computing model.

The beginning of my work in this project happened back in 2006 [0], and on that time I was trying to understand the situation that Linux using multiple graphics cards was living – that is only part of the needed work for making multiseat. The work proceeded but I never could actually push the patches to the mainline. Afterwards, and now at Nokia, I took this work again targeting some clean-up on X server code. It mostly went upstream (see VGA arbiter, libpciaccess and current xserver code). But the code is buggy and lot of work still needs to make it work properly.

—

Seems that I have a son now, but he (or should be she?) is a rebel baby and generates lot of trouble. Rather, I’m mean and want to give he away!

—

I don’t care about multi-card development nowadays and for an unknown reason no one also cares. But people use a lot: try to mix old graphics cards with new cards…. boom! Try to use multi-card with decent hw acceleration… boom! Try to hotplug graphics devices… no way! Hotswitch… hardly! Perform close to a single-card system… only in your dream! Some guys are kindly contributing sending patches for a while and unfortunately our open-source community are lacking man-power to make it get reviewed properly and eventually land at upstream. So here’s your big chance:

ADOPT IT!

[0] BTW, I found the first patch I sent for X. It dates back in April 2006 and was against Xgl, GLX backend. Very funny :)

multiseat with multiple X servers (or “the right way”)

So last week I posted on lkml an old patch that we were carrying for a long time in the Linux community. It basically brings the multiple (old) video cards functionally again on Linux and X server (and this time doing on the right and beauty way). For the people that was following multiseat implementations, this is a HUGE step: we will finally be able to discard the old and ugly hack (a mix of Xorg, several Xephyr servers + evdev) and and go to a clean way, starting multiple X servers in parallel. Cool! Well, not that much, because it might take some time to be in your beloved distribution :)

It’s too early and I don’t know if it’s recommended to say this, but if you want to give a try basically you have to get all X components, this X server patches, my libpciaccess and Dave’s kernel patchset. Again: it’s a very unstable work!

If you’re concerned with the technical explanations then you can follow the nice memo that Dave wrote about this.

multiseat – roadmap

This week our laboratory at university released the MDM utility to ease the process of installation and configuration of a multiseat box. The idea is that the end-user should not use some boring and hard howtos anymore to deploy it. Just installing a distro package must be enough now. Try it, use it, report the bugs and send the patches! :)

But I would like to call attention here because we’re still relying on the ugly Xephyr solution to build the multiseat on a simple PC machine (there are people selling this solution. Sigh). A lot of cool stuffs arriving in the linux graphics stack are lacking with this solution. So lets try trace the roadmap here that we can follow in the short/medium-term to build a good one solution:

– Vga Arbiter
We should as fast as we can forget the Xephyr hack. Definitely several instances of Xorg – one for each user session – is what we want. If someone wants to use several graphics cards to deploy a multiseat, then (s)he would probably face the problem of the vga legacy address. The vga arbitration is the solution.

Jesse seems that will work towards this in 2.6.28. There’s also a “minor” problem here that the X server still not posting secondary cards (after pci-rework).

– xrandr 1.3
To deploy a multiseat with one video card/multi-crtc, the randr extension is enough to cover the hotplug of output devices. For a multi-card configuration, xrandr must be GPU aware. So we must done some work here as well to do the automagically configuration of output devices.

– input hotplug
So far MDM is not using the last input features of X to plug or re-plug a device in the machine. It is using its own ugly method to poll for devices. Some work here is needed.

– ConsoleKit integration
Device ownership (e.g. audio, pen drive, cameras, usb toys, output and input devices) when multiple users are in the same machine could be a mess. Moreover, the security problems implied by this could be harmful. ConsoleKit seems to solve this all. It is able to keep track of all the users currently logged in.

Honestly I never took a closer look at ConsoleKit. I’m not sure if it’s prepared enough to support multiseat. So we need to take care of this as well eventually putting some hook inside MDM to work with it.

– DRI + modesetting
Support DRI in multiple X servers in parallel is not ready yet. Some redesign must be done to achieve this.

– tools for auto configuration
After all this work, some easy tools and very user-friendly would be awesome to setup on-the-fly the multiseat in the desktop environments.

Benchmarking it all

After a long journey I come back in this… So I did a set of benchmarks to evaluate the VGA arbitration versus the RAC usage. My goal is to evaluate the performance difference of a multi-head/multi-card environment, i.e., an Xorg using the RAC to another using the arbitration.

The experiments consisted of two applications running at the same time in each Xorg server, one at each screen. This is interesting because it stress the semaphore task of the arbiter inside kernel, creating race conditions between the screens. The experiments were performed ten times and the average result was picked.

In the first experiment a common operation to fill solid rectangles (x11perf -rect500) was started in each screen simultaneously. The X server using RAC obtained 3395 rectangles per second on screen one and 3400 on screen two. OTOH, the VGA arbiter obtained 3385 and 3400 rectangles respectively.

The second experiment showed a “close to real” usage of the VGA interface arbitration with Kobo Deluxe game :) The X server using RAC shows an average of 162.86 FPS on screen one against 163.91 FPS using the arbiter. On screen two, RAC shows 172.27 FPS and VGA arbiter 172.96 FPS.

This two experiments leads to the conclusion that the performance overhead of the arbiter is comparable of the RAC. Cool!

One thing that we must keep in mind is that the arbitration also adds the functionality to use various clients of the arbiter at the same time, for instance to deploy a multiseat starting several instances of Xorg (which is my big goal).

UPDATE:

21:53 < airlied> vignatti: you should also mention that the arbiter lets GPUs
completely opt out of VGA life if they can disable their VGA
decoding resources..
21:53 < airlied> vignatti: which means you end up with no arbitration for those
cards so no overhead.

Thanks for remember airlied :)

—

I’ll do another post entry concerning how to give a try of it all. For now I’m spending all my hacking time trying to solve others — not so related — things such as why the Xorg using the pciaccess rework doesn’t work with multiple cards. So sad :(