Radeon KMS, New TTM Code Works But Needs Testing

[Davy]

J?r?me: Is this current work already part of Gallium3D framework, or is it the very latest work before moving to Gallium? Could you tell us, in a few words, the current status of Radeon against Gallium3D?

Sorry for my ignorance and thank you VERY much for all the great job you are doing, in the name of the whole community and particularly the ones let down by ATI/AMD (I'm the unlucky owner of a R580 / X1900 XT).

[suokko]

I can't figure out what I'm doing wrong way when building ddx driver. It doesn't want to accept drm driver version 2.0.0 which makes it disable dri

dmesg output

Xorg.0.log

01:00.0 VGA compatible controller: ATI Technologies Inc M9+ 5C61 [Radeon Mobility 9200 (AGP)] (rev 01)

configure output from ddx driver


git versions:
mesa/drm/modesetting-gem
mesa/mesa/radeon-rewrite
jglisse/xf86-video-ati/radeon-gem-cs3
jglisse/drm-next/drm-next-radeon

Maybe r200 cards aren't supported yet? There seems to be initialization errors in drm too

[MuPuF]

Your dmesg when loading radeon module with modeset=1 would be usefull to know what's going wrong. Can't guess otherwise.

Here are more information :

01:05.0 VGA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress 200M]

Xorg log

dmesg without modeset=1 with this strange line :
[drm] Initialized radeon 1.29.0 20080528 for 0000:01:05.0 on minor 0

dmesg with modeset=1

So, when I load the module with modeset=1, it sets the right resolution on my display but the screen remains black. I know this is the right resolution because when I'm running my dual-head display, I get a black rectangle of 1280*800 on the upper-left corner and rubbish everywhere else. I tried with or without dual-head and the result is the same.

Also, when using your branch of the xorg radeon driver, using compiz results in a non-responsive GUI (it is like stuck on a frame). I tried the latest master branch of the driver and I get a proper responsive GUI.

Hope this will help (it was not that easy to get the dmesg log with modeset=1 ). Thanks a lot.

[bridgman]

J?r?me: Is this current work already part of Gallium3D framework, or is it the very latest work before moving to Gallium? Could you tell us, in a few words, the current status of Radeon against Gallium3D?

Sorry for my ignorance and thank you VERY much for all the great job you are doing, in the name of the whole community and particularly the ones let down by ATI/AMD (I'm the unlucky owner of a R580 / X1900 XT).

Davy, the work Jerome is doing is more of a pre-requisite for Gallium3D making it into production. Jerome is working on getting production-ready memory management working with the X driver and pre-Gallium3D mesa driver. The combionation of gem/newttm, kms, modified X driver, and radeon-rewrite will be the "next revision" of the open source stack.

The Gallium3D work is being done on top of early versions of the gem/ttm/kms code; it won't work on the driver stack that is shipping in distros today (other than F11-ish).

MostAwesomeDude is the expert on 3xx-5xx Gallium3D, but I guess the short answer is "partially implemented, but what's implemented seems to work"; ie still in development. We plan to have Richard and Cooper start working on Gallium3D as well once we have 6xx/7xx 3d up to the same level as 5xx in the "classic mesa" tree.

[monraaf]

We plan to have Richard and Cooper start working on Gallium3D as well once we have 6xx/7xx 3d up to the same level as 5xx in the "classic mesa" tree.

Are they still working on the classic mesa tree? There hasn't been a commit in the public repo for 11 days now. Sorry for the impatience

[bridgman]

Well, Cooper is on vacation and Richard is porting the existing code to work in the radeon-rewrite framework and learning bufmgr/cs/gem/ttm along the way. I guess we could push non-working work-in-progress but not sure that would help anyone.

You'll probably see some commits next week anyways.

[glisse]

Here are more information :

01:05.0 VGA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress 200M]

Xorg log

dmesg without modeset=1 with this strange line :
[drm] Initialized radeon 1.29.0 20080528 for 0000:01:05.0 on minor 0

dmesg with modeset=1

So, when I load the module with modeset=1, it sets the right resolution on my display but the screen remains black. I know this is the right resolution because when I'm running my dual-head display, I get a black rectangle of 1280*800 on the upper-left corner and rubbish everywhere else. I tried with or without dual-head and the result is the same.

Also, when using your branch of the xorg radeon driver, using compiz results in a non-responsive GUI (it is like stuck on a frame). I tried the latest master branch of the driver and I get a proper responsive GUI.

Hope this will help (it was not that easy to get the dmesg log with modeset=1 ). Thanks a lot.

According to log kernel is working fine, is their more message after last line ? If so you might want to load fbcon before loading radeon so you get a console once radeon is loaded. In KMS the screen will stay black until some one ask to set a video mode either fbcon or an xserver...

The non responsive GUI is with modeset=1 ?

[MuPuF]

According to log kernel is working fine, is their more message after last line ? If so you might want to load fbcon before loading radeon so you get a console once radeon is loaded. In KMS the screen will stay black until some one ask to set a video mode either fbcon or an xserver...

The non responsive GUI is with modeset=1 ?

I did some more testing, it is still unsuccessful ...
So, it really seems that the kernel crashes when loading KMS. In fact, when I load the module at boot time, the boot process just stops (the hdd light stops glowing). I got an half working KMS when I let Xorg load the radeon module. I saw loads of vertical lines and a moving cube for the mouse and then everything turned red and became stuck.
As for example about the kernel crashes, I have this kind of lines in my kernel logs (notice the colliding lines) :

May  2 02:03:16 cathaou kernel: [drm] radeon: Initializing kernel modesetting.
May  2 02:03:16 cathaou [B][U]kerMay[/U][/B]  2 02:04:35 cathaou kernel: Linux version 2.6.29-ARCH (root@T-POWA-LX) (gcc version 4.3.3 (GCC) ) #1 SMP PREEMPT Wed Apr 29 14:25:30 UTC 2009++

or

May  2 15:22:42 cathaou kernel: [drm] radeon: VRAM 128M
May  2 15:22:42 cathaou kernel: [B][U][drm] May[/U][/B]  2 15:23:40 cathaou kernel: Linux version 2.6.29-ARCH (root@T-POWA-LX) (gcc version 4.3.3 (GCC) ) #1 SMP PREEMPT Wed Apr 29 14:25:30 UTC 2009

or the one I showed you first (as you can see, there aren't any more lines after what I sent you except the ones from the next reboot) :

May  2 18:31:03 cathaou kernel: [drm] Panel Size 1280x800
May  2 18:33:29 cathaou kernel: Linux version 2.6.29-KMS-ge85cc5c-dirty (mupuf@cathaou) (gcc version 4.4.0 (GCC) ) #2 SMP PREEMPT Fri May 1 20:52:43 CEST 2009

The non responsive GUI isn't with modeset=1, sorry if I haven't been clear enough. Setting up modeset=1 always leads to a crash. Seems like my card is really really weird.
I'm about to try to mount my / in sync mode and to log sooner with syslog-ng.

[Davy]

Davy, the work Jerome is doing is more of a pre-requisite for Gallium3D making it into production. Jerome is working on getting production-ready memory management working with the X driver and pre-Gallium3D mesa driver. The combionation of gem/newttm, kms, modified X driver, and radeon-rewrite will be the "next revision" of the open source stack.

The Gallium3D work is being done on top of early versions of the gem/ttm/kms code; it won't work on the driver stack that is shipping in distros today (other than F11-ish).

MostAwesomeDude is the expert on 3xx-5xx Gallium3D, but I guess the short answer is "partially implemented, but what's implemented seems to work"; ie still in development. We plan to have Richard and Cooper start working on Gallium3D as well once we have 6xx/7xx 3d up to the same level as 5xx in the "classic mesa" tree.

Thanks for your explanations John.
So If I understand, J?r?me's work is both for future Gallium3D driver and for radeon-rewrite that is still an old fashion Mesa driver.
Am I right?

So what's the release plan order for this new "pre Gallium" stack?
Do we need to wait kernel memory management and mode setting to be upstream (2.6.31) before a new mesa and then a new xorg ati driver?
Or perhaps the mesa part could be out before upstream kernel integration with fallback to actual memory management...

My distribution is a Mandriva Cooker, it provides an experimental kernel already including KMS, and DRM stuff, I wonder when the other needed things (mesa, xf86-video-ati) will be available in a more official state (Beta or RC).

The reason why I can't wait is because I'm in a very bad state for now. I have regressions with the free drivers: both ati and radeonhd are freezing my display when I start most 3D apps that used to work a few times ago (supertuxkart,tuxracer...), tough compiz and googleearth 4 are running quite well. And fglrx doesn't support X server 1.6 for my R580.

I really regret that your employer has decided to drop fglrx support for GPU older than R600. I would understand such a decision if we have a more usable free driver, but it was clearly too early. The minimum would have been to add X server 1.6 support in the fglrx legacy driver! Could we hope such an improvement for the next fglrx legacy update, or are we let down forever?

[bridgman]

Thanks for your explanations John.
So If I understand, J?r?me's work is both for future Gallium3D driver and for radeon-rewrite that is still an old fashion Mesa driver.
Am I right?

Yep. Memory management is also a pre-requisite for kernel modesetting. What Jerome is doing is trying to get a memory management implementation which can be accepted into the kernel tree -- kms and mm have been around for some months now but only in branches.

So what's the release plan order for this new "pre Gallium" stack? Do we need to wait kernel memory management and mode setting to be upstream (2.6.31) before a new mesa and then a new xorg ati driver? Or perhaps the mesa part could be out before upstream kernel integration with fallback to actual memory management...

The radeon-rewrite branch is designed to work with legacy (pre-mm, pre-kms) drm or with the new kms/gem/newttm drm that airlied, glisse and others are working on, so the new mesa code should hit master first.

My distribution is a Mandriva Cooker, it provides an experimental kernel already including KMS, and DRM stuff, I wonder when the other needed things (mesa, xf86-video-ati) will be available in a more official state (Beta or RC).

If it provides kernel modesetting functionality today then it should already have the modified xf86-video-ati; airlied & agd5f did most of that work months ago. If you just have "kms in the kernel but can't actually use it" then it would need to pick up the kms-aware -ati driver from a branch. Not sure of status or plans there, but you need a kms-aware X driver to run kms.

EDIT - I saw your post on Nabble; looks like it's just the kernel right now ? Based on what I saw in the Mandriva release notes you may just have Intel KMS support anyways, not sure. Since radeon-rewrite is headed for master soon you could in principle have all this for testing soon (assuming Mandriva packagers will accept both the drm and the -ati driver) but it won't be backed up by upstream kernel code for a while.

The reason why I can't wait is because I'm in a very bad state for now. I have regressions with the free drivers: both ati and radeonhd are freezing my display when I start most 3D apps that used to work a few times ago (supertuxkart,tuxracer...), tough compiz and googleearth 4 are running quite well. And fglrx doesn't support X server 1.6 for my R580.

Why not stay with 8.10 until the 3d driver is in the state you want ? Upgrading without driver support is going to hurt; I have advised a few times that if your primary use is gaming then you probably don't want to upgrade to 9.04 yet.

I really regret that your employer has decided to drop fglrx support for GPU older than R600. I would understand such a decision if we have a more usable free driver, but it was clearly too early. The minimum would have been to add X server 1.6 support in the fglrx legacy driver! Could we hope such an improvement for the next fglrx legacy update, or are we let down forever?

There are no plans for a legacy fglrx update at this time. Putting resources into improving the open source drivers instead seems like the best way to meet what our consumer users are looking for. For a lot of users the open drivers are more satisfying than fglrx already, but if you're into gaming on your Linux system then the 3d stack isn't quite there yet so you probably want to stay with a working distro version for a bit longer. Bleeding-edge distros are rarely a good choice for fglrx anyways; if you want stability then stay a bit back from the bleeding edge.