Multi-user hardware video acceleration

[An(noymous)droid]

I asked this question before. I would like to know if things have changed with regard to 2D and 3D hardware acceleration under X.

Question: Is is it actually possible for two or more simultaneously logged-in users to benefit from 2D/3D hardware acceleration?

Test Scenario: I create two user accounts, user1 and user2. I log in first as user1 and then, without logging out as user1, also log in as user2 (double emphasis on the word "without"). Only the first user account, user1, will get hardware video acceleration. The second user, user2, will not get hardware acceleration. For user2 to get hardware acceleration, it's necessary to log out user1.

It appears that as far as hardware acceleration is concerned, X is still a single-user system.

[bridgman]

I *think* it's possible as long as you are running KMS. Not 100% sure though...

Are you running KMS now ? Hopefully no

[rohcQaH]

It appears that as far as hardware acceleration is concerned, X is still a single-user system.

That's right. When you switch to a different X server, the previous server has to release the hardware and the new one locks it. This involves copying all important data out of vram and back into it, which is why VT switching has always been sloooooow.
(This is also the reason, why multiseat systems with a single GPU have always involved ugly hackery)

KMS makes the kernel manage vram, which should (in theory) make it possible to have several X servers share the vram (sharing of the GPU is done via DRI, it has always been shared between direct rendering clients and the server).

Now that's the theory; the new architecture does allow the feature. But this is a somewhat exotic case, probably not well tested. Some people reported success, others ran into trouble along the way.

If it doesn't work with KMS, try upgrading your kernel.

Good luck, please tell us if it worked!

[An(noymous)droid]

That's right. When you switch to a different X server, the previous server has to release the hardware and the new one locks it. This involves copying all important data out of vram and back into it, which is why VT switching has always been sloooooow.
(This is also the reason, why multiseat systems with a single GPU have always involved ugly hackery)

KMS makes the kernel manage vram, which should (in theory) make it possible to have several X servers share the vram (sharing of the GPU is done via DRI, it has always been shared between direct rendering clients and the server).

Okay, thanks for the clarifications. Unfortunately the "solution" in my case is worse than the problem (as you and bridgman note in your emoticons). My KMS grief should probably be the subject of a separate post (Debian Unstable running on an AMD RS780 IGP with Xorg Radeon driver 6.13.0, Mesa 7.7.1, and Linux 2.6.32-4). I had to explicitly disable KMS:

/etc/modprobe.d/radeon-kms.conf
options radeon modeset=0

[nanonyme]

Just to make sure this test is anyhow capable of producing useful results: are we talking of two users logged on on two different monitors so that both are viewable and rendered? Since afaik used switching just suspends graphics for the user whose screen isn't visible atm. (unless this too has changed)
So what I expect to happen: User1 logs in, has hardware accel. User switch, user1 gets suspended. User2 logs in, has hardware accel. User switch, user2 gets suspended. User1 logs in again, user1 continues rendering from the point from which graphics were suspended and has hardware accel again.

[bridgman]

Okay, thanks for the clarifications. Unfortunately the "solution" in my case is worse than the problem (as you and bridgman note in your emoticons). My KMS grief should probably be the subject of a separate post (Debian Unstable running on an AMD RS780 IGP with Xorg Radeon driver 6.13.0, Mesa 7.7.1, and Linux 2.6.32-4). I had to explicitly disable KMS:

/etc/modprobe.d/radeon-kms.conf
options radeon modeset=0

You might want to try a newer kernel. The drm code in 2.6.32 was the first to include KMS for the 780, but it was still in staging. The 2.6.33 kernel had a lot of the grief removed and was the first where KMS for 6xx and higher was out of staging. Updating libdrm and libdrm-radeon probably wouldn't hurt.

[An(noymous)droid]

You might want to try a newer kernel. The drm code in 2.6.32 was the first to include KMS for the 780, but it was still in staging. The 2.6.33 kernel had a lot of the grief removed and was the first where KMS for 6xx and higher was out of staging. Updating libdrm and libdrm-radeon probably wouldn't hurt.

It's not really a problem for me since I know the fix (disable KMS . So I'll just wait for the proper kernel/drm versions to trickle down to Debian Unstable. Just wondering how this season's Linux releases (e.g. Ubuntu Lucid) will handle the switch to KMS since they'll still be running kernel 2.6.32.

[nanonyme]

But yeah, the real trick would be two different users logged in on two different monitors (likely two X servers started at the same time and set to use the particular monitor exclusively) and have *both* have hardware rendering at the same time.

[bridgman]

Lucid is actually running a 2.6.32 kernel but using the kernel graphics driver (aka drm) from 2.6.33 (I think Tormod said 2.6.33.2).

[Kano]

Just to make fglrx happy ATI is as usual unable to make fglrx ready for .33 kernel - unofficial patches are out since ages for that. Do you remember that 2.6.33 final was out on 24-Feb-2010? What's your excuse for this? I still wait for a DEVELOPER explainatin not your guess why xv lags behind too.