Radeon KMS, New TTM Code Works But Needs Testing

[curaga]

Sorta related KMS question: since it will give a native-resolution FB console, how can I get a background pic (like I now get with Bootsplash)?

[Mr_Ed]

There are may bugs in redhat bugzilla regarding KMS. Is it not possible to have dri2 on radeon driver without KMS?

[Mithrandir]

There are may bugs in redhat bugzilla regarding KMS. Is it not possible to have dri2 on radeon driver without KMS?

No. And even if it were possible, most of the bugs would remain, because in order to have dri2 a lot of code was rewritten and that should introduce some regressions.

[Davy]

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.


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.


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.

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.

Well, I'm glad to read that "radeon-rewrite is headed for master soon". I'll deal with Mandriva packagers for updated versions of the necessary stuff in order to ease the testing of the stack. Then we'll be able to report good and bad things.
The goal is to test very early to have the best integration as possible in the next release 2010.0 in 6 months, with the crazy hope to have at last a good ati driver out of the box.

I don't think the most important is absolute 3D performance and the maximum FPS, but rather functionalities like beeing able to suspend/resume a laptop, use compiz with xinerama, move the compiz cube with 3D apps moving too, beeing able to use the GNOME switch user utility, flicker free video, offloading the video decoding, blue screen of death like Win$ ;-)...

The Mandriva release notes you are talking about is for the 2009.1 Spring. This release includes X server 1.6 like every new distros (Ubuntu 09.04...).
As you know fglrx legacy driver doesn't support this X server version that every new distros are shipping. And the solution you are suggesting is not to install them! I hope you are kidding!
Which distro do you think a new Linux comer will install? The last year version? Of course not! He will try the latest and if he has a GPU similar to mine, he will clearly feel that Linux isn't ready for desktop. AMD/ATI is responsible for this situation, you should have added X server 1.6 support in the legacy driver! It's your job to follow X.org and not the whole X.org people to follow (or wait for) you.

I personally use Mandriva Cooker, the experimental distro, which has bleeding egde softwares like kernel-tmb which is a patched kernel containing radeon KMS.

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.

I agree that the resources must be working on free driver now. But you won't change my mind that you should have added support for X server 1.6 in Catalyst 9.3 before. Dropping support one month before all the spring distribution releases is unfair and looks like a betrayal.

IMHO, you should now stop fglrx development and focus on a free driver that could rapidly compete with the most advanced drivers (NVidia and Intel). Moreover, I don't understand the need of a radeonhd driver, it is a waste of resources/time/money. The projects should merge now.


Don't be mistaken, I'm not a real end user nor a gamer, as I try to modestly contribute by testing, searching solutions and reporting bugs: that's my favorite game, and that's the reason why I chose bleeding edge instead of stability, and why I'm writing to you!
My kids are the players; tuxracer, supertuxkart and Nexuiz are their favorite games. What I'd personally like to play is flightgear flight simulator; this one isn't freezing my X server but is "segfaulting", that's another story...

[nanonyme]

I agree that the resources must be working on free driver now. But you won't change my mind that you should have added support for X server 1.6 in Catalyst 9.3 before. Dropping support one month before all the spring distribution releases is unfair and looks like a betrayal.

Right, I'm sure ATi wants to hire you immediately if you think writing support for a new X server version is as trivial as that.

[bridgman]

I don't think the most important is absolute 3D performance and the maximum FPS, but rather functionalities like beeing able to suspend/resume a laptop, use compiz with xinerama, move the compiz cube with 3D apps moving too, beeing able to use the GNOME switch user utility, flicker free video, offloading the video decoding, blue screen of death like Win$ ;-)...

OK, so for your board it sounds like the open drivers are what you want anyways. The 3xx-5xx cards don't have UVD (with one exception, the rv550) so video decode acceleration is going to be shader-based and the information to implement that has been public knowledge for at least a year.

The Mandriva release notes you are talking about is for the 2009.1 Spring. This release includes X server 1.6 like every new distros (Ubuntu 09.04...). As you know fglrx legacy driver doesn't support this X server version that every new distros are shipping. And the solution you are suggesting is not to install them! I hope you are kidding!

For most users we're suggesting they upgrade and use the open source drivers. For users who need specific 3D functionality which the open drivers don't have yet, we're suggesting they delay upgrading until the 3D drivers catch up.

Which distro do you think a new Linux comer will install? The last year version? Of course not! He will try the latest and if he has a GPU similar to mine, he will clearly feel that Linux isn't ready for desktop. AMD/ATI is responsible for this situation, you should have added X server 1.6 support in the legacy driver! It's your job to follow X.org and not the whole X.org people to follow (or wait for) you.

If a new user installs any of these distros out of the box they will get the open drivers, not fglrx. If there are problems with the open drivers which interfere with out-of-box operation please file bugs and they will be looked at ASAP.

IMHO, you should now stop fglrx development and focus on a free driver that could rapidly compete with the most advanced drivers (NVidia and Intel).

So... we should kill off fglrx but only AFTER we make it do what you want

With respect, every user wants us to kill off fglrx as soon as we have implemented the features *they* want, but everyone has a different list.

The fglrx driver is still primarily a workstation driver, aimed at the professional graphics market (which is why we focus on enterprise distros rather than bleeding-edge ones). Fglrx is not going to go away in the forseeable future since we still need a binary driver that lets us code-share across multiple OSes. What we are trying to do is shift out-of-box usage to the open drivers, and that seems to be going pretty well.

Moreover, I don't understand the need of a radeonhd driver, it is a waste of resources/time/money. The projects should merge now.

It would take more work to merge them than to keep them separate, since very little work is actually being duplicated. All of the 3D work goes into mesa and drm, ie not into radeon/radeonhd, and the EXA/Xv work we did simply got pushed into both trees since radeonhd mostly runs the same accel code as radeon anyways.

Where the two drivers differ the most is modesetting code (which will become irrelevent in a year as KMS moves into the mainstream) and the underlying structure (which is very hard to merge). There have been a number of discussions between the radeon and radeonhd development groups, and the most likely scenario we all see is both drivers being replaced with something newer and smaller once KMS is available in all of the currently shipping distros.

Depending on how Gallium3D works out for 2D accel it's possible that most of the X drivers will be able to be replaced with a single generic X driver using KMS for modesetting and Gallium3D for acceleration.

[Davy]

For most users we're suggesting they upgrade and use the open source drivers. For users who need specific 3D functionality which the open drivers don't have yet, we're suggesting they delay upgrading until the 3D drivers catch up.


If a new user installs any of these distros out of the box they will get the open drivers, not fglrx. If there are problems with the open drivers which interfere with out-of-box operation please file bugs amd they'll be looked at ASAP.

OK. So as distro makers, for marketing reasons, won't warn their users that they won't be able to play 3D games with their ATI boards (most of end users even don't know which board they have in their boxes), these users will install or upgrade their system and then see it freezing when they start a 3D game. Moreover, downgrading is painful.
I'm not sure it's the good way to bring Linux to the mass market.

So... we should kill off fglrx but only AFTER we make it do what you want

With respect, every user wants us to kill off fglrx as soon as we have implemented the features *they* want, but everyone has a different list.

Sorry, I meant focus on the free driver and just maintain the fglrx driver without trying to add new functionalities that take too much time to get out. It wasn't just: kill that damn thing right now! I agree that we still need it for now.

Even though I've been waiting for AIGLX more than one year, I've never seen redirected direct rendering support (for a good compiz interaction with 3D apps - like glxgears moving with the cube) and people are waiting new video decoding for months...
Could you explain me why NVidia has always been supporting new things 1 year before ATI?
What's the big differences between ATI and NVidia (apart that you finally chose the right side of the force by releasing documentation and support a free driver)?

The fglrx driver is still primarily our workstation driver, aimed at the professional graphics market (which is why we focus on enterprise distros rather than bleeding-edge ones). Fglrx is not going to go away in the forseeable future since we still need a binary driver that lets us code-share across multiple OSes. What we are trying to do is shift out-of-box usage to the open drivers, and that seems to be going pretty well.

What you mean is we still don't know when the free driver will be at least 85% of the fglrx 3D performance making fglrx useless regarding its lack of functionality.

It would take more work to merge them than to keep them separate, since very little work is actually being duplicated. All of the 3D work goes into mesa and drm, ie not into radeon/radeonhd, and the EXA/Xv work we did simply got pushed into both trees since radeonhd mostly runs the same accel code as radeon anyways.

Where the two drivers differ the most is modesetting code (which will become irrelevent in a year as KMS moves into the mainstream) and the underlying structure (which is very hard to merge).

There have been a number of discussions between the radeon and radeonhd development groups, and the most likely scenario we all see is both drivers being replaced with something newer and smaller once KMS is available in all of the currently shipping distros.

In a year?! I thought we could expect KMS for 2.6.31.

Depending on how Gallium3D works out for 2D accel it's possible that most of the X drivers will be able to be replaced with a single generic X driver using KMS for modesetting and Gallium3D for acceleration.

Waoooo! With such a factorization it would be far easier to optimize the whole Xorg stuff and the devs work.
That's really exciting! I can't wait!

[bridgman]

OK. So as distro makers, for marketing reasons, won't warn their users that they won't be able to play 3D games with their ATI boards (most of end users even don't know which board they have in their boxes), these users will install or upgrade their system and then see it freezing when they start a 3D game. Moreover, downgrading is painful. I'm not sure it's the good way to bring Linux to the mass market.

I don't think it's "marketing reasons" that stop the distro makers from providing that information, it's just the effort required to keep track of all the constantly changing data vs the resources they can afford to invest.

The installer and restricted driver managers aren't supposed to let you upgrade on a GPU that isn't supported. If you're seeing that happen, please let us *and* the distro packagers know. Downgrading should be a non-issue if the upgrading doesn't happen in the first place.

If you are seeing freezing with the open drivers please make sure that there are current bug reports filed at bugs.freedesktop.org.

Sorry, I meant focus on the free driver and just maintain the fglrx driver without trying to add new functionalities that take too much time to get out. It wasn't just: kill that damn thing right now! I agree that we still need it for now.

As Nanonyme said if it were trivial to add and validate new distro support we would probably still be doing it. We are not supporting new OS versions on 5xx and earlier for any OSes, this is not just a Linux thing.

Even though I've been waiting for AIGLX more than one year, I've never seen redirected direct rendering support (for a good compiz interaction with 3D apps - like glxgears moving with the cube) and people are waiting new video decoding for months...

I don't understand what you mean about waiting for AIGLX for a year, we added that in September 07. If you mean waiting for RDR (which is what users were really looking for even though they asked for AIGLX) then that shipped in the Cat 9.3 release and it should work for you today on a supported distro (say Ubuntu 8.10).

Your card doesn't have any video decoding hardware other than an MPEG-2 IDCT engine; UVD starts with the RV610 and higher. I don't think NVidia supports any serious decode acceleration on their 5xx-era chips either (their 7xxx series), do they ?

Could you explain me why NVidia has always been supporting new things 1 year before ATI?

Actually in most OSes we tend to support new things first. In Linux, NVidia started supporting consumer features before we did and that gave them a head start.

What's the big differences between ATI and NVidia (apart that you finally chose the right side of the force by releasing documentation and support a free driver)?

Sometimes we're better, sometimes they're better. It depends on when you look, the OS you run, and what you are doing with the system. It's pretty hard to generalize. Next time NVidia chops support for older GPUs, they will get flamed and we'll be "better", but this month it was our turn to chop support for older GPUs so it's our turn to get flamed. This kind of back-and-forth has been going on since before Linux even existed.

Supporting open driver development requires a much bigger ongoing resource commitment than you might think. It's not a question of "just making a decision".

What you mean is we still don't know when the free driver will be at least 85% of the fglrx 3D performance making fglrx useless regarding its lack of functionality.

No. 85% of performance would mean that we wouldn't sell any cards in the workstation space. I meant what I said -- that fglrx is not going away any time soon. You should probably try fglrx on a FirePRO card with a supported workstation OS, running typical workstation apps and workloads, before judging the functionality.

In a year?! I thought we could expect KMS for 2.6.31.

I think 2.6.31 is what everyone is hoping for but it's probably too soon to be sure.

That said, getting into the kernel doesn't mean squat in terms of the mainstream Linux market, since it's the enterprise distros (mostly RH and SuSE, plus maybe Ubuntu LTS) that set priorities for driver development. I expect it will be mid-2010 before those distros will all be running KMS, and probably another year after that before we can think about cutting back on non-KMS support.

(re: moving to a generic X driver running over KMS and Gallium3D) Waoooo! With such a factorization it would be far easier to optimize the whole Xorg stuff and the devs work. That's really exciting! I can't wait!

We think so too. It won't do much for the workstation market (we moved to a driver model like Gallium3D a couple of years ago) but I do think it will be a big help for Linux consumer users.

[Pfanne]

btw can we expect open source drivers for r800 soon after the launch or is this a topic you are not allowed to talk about?

[bridgman]

We have already started collecting information for the next generation of GPUs, so we're hoping to have made a good start on writing documentation before launch. As a result, the delay from introduction to initial acceleration support should be quite a bit less than for previous generations of GPUs (when we were mostly in "catch-up" mode). That's about all I can say right now.