[Feature request] Multiple X servers on one graphics card?

[Alex Deucher]

On Tue, Aug 2, 2011 at 11:28 AM, Prof. Dr. Klaus Kusche
<klaus.kusche at computerix.info> wrote:
> On 2011-08-02 16:34, Alex Deucher wrote:
>>
>> On Tue, Aug 2, 2011 at 10:22 AM, Prof. Dr. Klaus Kusche
>> <klaus.kusche at computerix.info>  wrote:
>>>
>>> On 2011-08-02 14:59, Alex Deucher wrote:
>>>>
>>>> On Mon, Aug 1, 2011 at 3:41 PM, Prof. Dr. Klaus Kusche
>>>> <klaus.kusche at computerix.info>    wrote:
>>>>>
>>>>> Hmmm, what's about the opposite approach?
>>>>> To me, it sounds simpler and more logical when the kernel always
>>>>> creates
>>>>> one device node per output (or maybe dynamically per connected output),
>>>>> without any need for configuration or device assignment.
>>>>
>>>> You almost always have more connectors than display controllers (e.g.,
>>>> you might have displayport, svideo, DVI-I and VGA, but only two
>>>> display controllers so you can only use two of the connectors at any
>>>> time).  Also certain combinations of connectors are not possible
>>>> depending on the hw (e.g., the svideo and the VGA port may share the
>>>> same DAC, so you can only use one or the other at the same time).
>>>
>>> Hmmm, for my purposes I was only thinking about new, current hardware,
>>> not about previous-generation cards, and only about digital outputs:
>>>
>>> * The professional, high-quality solution would be ATI's FirePro 2460:
>>> 4 mini Displayports, all active at the same time, single slot
>>> (passive cooling,<  20 W, so that's a great energy saver, too,
>>> competing with thin and zero clients,
>>> and it's silent and long-lived)
>>>
>>> * The XFX HD-677X-Z5F3 most likely offers most ports per Euro and space:
>>> 5 mini Displayports, all active at the same time, single slot,
>>> for less than 100 Euro
>>>
>>> (this would result in 16/20 seats with any quad-crossfire mainboard
>>> and 28/35 seats with some server mainboards if the BIOS is able
>>> to assign addresses to 7 graphics cards)
>>>
>>> Even the low-cost 6450 supports 3 and the 6570 supports 4
>>> independent simultaneous outputs, so any ATI 6xxx card can drive
>>> all its outputs at the same time
>>> (and I believe that was also true for ATI 5xxx)
>>> However, cards with 3 or 4 digital outputs are hard to find
>>> in that price range... (XFX HD6570 is one of them)
>>>
>>> But you're correct, my suggestion above needs to be refined:
>>> One DRI device per display controller.
>>
>> Even then it gets a little tricky.  AMD cards are fairly flexible, but
>> some other cards may have restrictions about which encoders can be
>> driven by which display controllers.  Then how do you decide which
>> display controller gets assigned to which connector(s)?  You also need
>> to factor in things like memory bandwidth.  E.g., a low end card may
>> not be able to drive four huge displays properly, but can drive four
>> smaller displays.
>
> What is your suggestion to "do things right"?
> How would you assign DRI device nodes to multiple monitors?
> Do you have better suggestions for building multi-seat systems
> beyond 4 seats with 4 single-output cards?
>
> How does xrandr currently solve those problems?
> It might also "see" more outputs than there are display controllers,
> it has the same job of assigning connectors to display controllers,
> and it also has the problem that setting all outputs to their
> maximum resolution might cause the card to run out of memory bandwidth.
> So either the logic needed is already there,
> or the problems are not multiseat-specific,
> but affect today's multi-screen environments in general.
>
> I think there is no need to do better than xrandr currently does.
> In fact, that's the multiseat solution we have today:
> Configure one X server (most likely using xrandr) with one huge display
> spanning all the outputs and monitors connected to one card,
> and start one Xephyr per monitor and user within that display.
> This just lacks any acceleration and Xv.
>
> (the fact that xrandr already seems to handle most of this
> was one of the reasons why I suggested that the kernel should just
> export every output the hardware offers to userland: I believed
> that the userland already knows how to allocate and configure outputs,
> and the only thing missing is the ability to access the same card
> from more than one X server or to assign the outputs of one card
> to two or more X servers)

Some drivers can already do this (the radeon driver at least).  google
for zaphod mode.  You basically start one instance of the driver for
each display controller and then assign which randr outputs are used
by each instance of the driver.  It already works and supports
acceleration.  The problem is, each instance shows up as an X protocol
screen rather than a separate X server so, you'd have to fix the input
side.

>
> I also believe and accept that there will be no solution
> supporting all graphics cards existing today and 10 years back.
> Only some cards offer KMS, only some cards offer 3D acceleration,
> some older cards don't even offer dual-screen support for one X server,
> only some cards will offer multi-seat support in future.
> If somebody wants to build a high-density shared-card multiseat system,
> he has to choose suitable hardware.

Even if you only support KMS supported hardware which seems reasonable
to me, you still have a lot of cards out there with interesting
display configurations.  We still make cards with DVI and VGA ports on
them or more connectors than display controllers.  You don't really
want to go through the whole effort if it only works on a handful of
special cards.  It wouldn't take that much more work to come up with
something suitable for the majority of hardware that is out there.  In
most cases, it will probably be a custom configuration for each
person, so as long as the right knobs are there, you can configure
something that works for your particular system.

Alex