All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Prof. Dr. Klaus Kusche" <klaus.kusche@computerix.info>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [Feature request] Multiple X servers on one graphics card?
Date: Tue, 02 Aug 2011 17:28:54 +0200	[thread overview]
Message-ID: <4E3817B6.8000205@computerix.info> (raw)
In-Reply-To: <CADnq5_PPLRMU_hHo7AMbnVfL8C9hk-u=hwY0-yr2Shb68j2_oQ@mail.gmail.com>

On 2011-08-02 16:34, Alex Deucher wrote:
> On Tue, Aug 2, 2011 at 10:22 AM, Prof. Dr. Klaus Kusche
> <klaus.kusche@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@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)

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.

Microsoft Multipoint Server also depends on the driver of the card
to be able to configure all the outputs simultaneously - some cards do,
other's don't.

Klaus.

-- 
Prof. Dr. Klaus Kusche
Private address: Rainstraße 9/1, 88316 Isny, Germany
+49 7562 6211377 Klaus.Kusche@computerix.info http://www.computerix.info
Office address: NTA Isny gGmbH, Seidenstraße 12-35, 88316 Isny, Germany
+49 7562 9707 36 kusche@nta-isny.de http://www.nta-isny.de

  reply	other threads:[~2011-08-02 15:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-30 18:48 [Feature request] Multiple X servers on one graphics card? Prof. Dr. Klaus Kusche
2011-07-31 20:09 ` Dave Airlie
2011-08-01  8:14   ` Prof. Dr. Klaus Kusche
2011-08-01 19:41   ` Prof. Dr. Klaus Kusche
2011-08-01 19:47     ` Dave Airlie
2011-08-01 20:22       ` Alan Cox
2011-08-02  8:17         ` Prof. Dr. Klaus Kusche
2011-08-02 10:26           ` Alan Cox
2011-08-02 10:28             ` Rafał Miłecki
2011-08-02 11:10               ` Prof. Dr. Klaus Kusche
2011-08-02 15:27                 ` Michel Dänzer
2011-08-02 11:54             ` Prof. Dr. Klaus Kusche
2011-08-02 15:43         ` Christoph Bumiller
2011-08-02 12:59     ` Alex Deucher
2011-08-02 14:22       ` Prof. Dr. Klaus Kusche
2011-08-02 14:34         ` Alex Deucher
2011-08-02 15:28           ` Prof. Dr. Klaus Kusche [this message]
2011-08-02 15:48             ` Alex Deucher
2011-08-02 19:11               ` Prof. Dr. Klaus Kusche
2011-08-03 17:51                 ` Alex Deucher
2011-08-03 19:25                   ` Prof. Dr. Klaus Kusche
2011-08-02 23:31               ` Chi-Thanh Christopher Nguyen
  -- strict thread matches above, loose matches on Subject: below --
2011-08-02 13:34 Tomasz Borowik
2011-08-03  6:35 Prof. Dr. Klaus Kusche

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E3817B6.8000205@computerix.info \
    --to=klaus.kusche@computerix.info \
    --cc=alexdeucher@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.