Announcement

**MartjeB** · 20 April 2009, 10:15 AM

I've been struggeling with this myself over the past few weeks. It seems fglrx is unstable even with 1 seat and the opensource driver (-ati & -radeonhd) do not run on multiple cards..

**c1981** · 20 April 2009, 10:42 AM

I couldn't get the open source drivers working either - nor did I expect them to work as the Gpu's in question are 'fairly new'.

I would have thought that ATi would have made a decent driver by now.. Nvidia's proprietary driver works perfectly with multiseat.

Did you try any other options in xorg.conf that improved stability; or is it really not viable with Ati at the moment?

**MartjeB** · 20 April 2009, 11:19 AM

At the moment ATi is worthless, but I hope Egbert Eich will fix the problem described in bugzilla. Otherwise I'll have to dive into the code myself, which I don't want to, because I'm rather busy atm.

**bridgman** · 20 April 2009, 12:58 PM

You may find that 2x 3450 works better than a mix of 4670 and 3450. I think the multi-GPU focus has been mostly on sets of identical cards so far.

AFAIK multi-seat support with fglrx is primarily controlled through the aticonfig command and amdpcsdb, not the xorg.conf file. The initial aticonfig command between install and first run is pretty important IIRC. Taking a conf file from one driver to the other is probably not what you want, at least for the driver/GPU bits.

I think you want VideoOverlay off for modern GPUs. From 5xx on we use Textured Video, not VideoOverlay. Most of the other options in your conf file are NVidia-specific so I expect the driver will ignore them.

The issue with the open drivers and multi-GPU support is not related to the newness of the GPU but a limitation in RandR - the multiscreen model used in RandR assumes a single physical frame buffer shared by all the displays, and that isn't compatible with multiple GPUs unless something like "shatter" is added to the framework.

**MartjeB** · 20 April 2009, 01:18 PM

Originally posted by bridgman View Post

The issue with the open drivers and multi-GPU support is not related to the newness of the GPU but a limitation in RandR - the multiscreen model used in RandR assumes a single physical frame buffer shared by all the displays, and that isn't compatible with multiple GPUs unless something like "shatter" is added to the framework.

This shouldn't be a problem when running >1 xservers (which is the case in Multiseat), right?

Right now, with RandR 1.2, you get multiple X screens, one per-GPU, each of which can have multiple monitors connected.

http://liquidat.wordpress.com/2007/1...g-development/

**bridgman** · 20 April 2009, 01:23 PM

From the same link, further down the page :

I don’t think this statement:

"Right now, with RandR 1.2, you get multiple X screens, one per-GPU, each of which can have multiple monitors connected."

Is correct. According to:

XStrikeForce/HowToRandR12 - Debian Wiki

http://wiki.debian.org/XStrikeForce/HowToRandR12

multiple boards is not supported by RandR 1.2

Not sure which is correct?

I believe the issue is that RandR can only process commands for the first GPU. Not 100% sure though, haven't played with it myself.

EDIT : That reminds me; I remember seeing a couple of posts indicating that turning RandR *off* in fglrx helped in certain cases; not sure if that was multiseat or Xinerama, but they're both similar in the sense that you *don't* want all the screens joined together at driver level.

**c1981** · 20 April 2009, 02:10 PM

I've just replaced the ATI's with NVIDIA cards;

1 x 9600 GT
1 x 8600 GT
2 x 8400 GS

Works perfectly...

I thought as Radeon 3450 and 4670 are both in the same generation
driver-wise, that it should've worked - as it does with Nvidia.

The Randr thing is new to me; as far as i knew multiseat (when using
multiple X servers) was about using evdev, isolating the pci bus id's, and using gdm,kdm or xdm to initiate the x-servers.

**c1981** · 20 April 2009, 02:17 PM

Mixing the different GPU's shouldn't have mattered all that much - as they all invoke their own X-servers.
I've set up mixed environments of Intel, Matrox, ATI and Nvidia before (which is a pain as all the libraries have to be maintained seperately) - that also worked, although it was with old GPU's all of which are supported by FOSS drivers.

I'll look into the video-overlay tip; although I doubt it was the reason for the entire system to lock up while attempting to bring up gdm on all x-servers.
With Nvidia or Matrox if any setting was incorrect - the X-server would die, not the entire machine like with Ati...

But there is a slim chance that someone will code a fix then?

Or do you suggest looking into the Randr thing...?

**c1981** · 20 April 2009, 02:21 PM

Seems Randr is applicable when doing either a Xephyr or XGL multiseat - with individual x-servers the gpu's don't "see" each other as active, nor do they share a framebuffer..

Announcement

fglrx multiseat crash

fglrx multiseat crash

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment