Radeon Driver Power Management Has Room For Improvement

[bridgman]

While this is true - assuming that the mentioned "pm logic" is documented (which I admittedly don't know) - it still feels that not working on this is pretty much defeating the whole effort. I mean, all right task #1 is enabling chips. I think no one ever questioned that. But what is #2?

Task #2 is stability, ie trying to make the HW/SW combination not crash. Task #3 is supporting other driver developers (#2 and #3 are probably same priority really).

Between #1, 2 and 3 all the time is used up. You are making reasonable proposals for what we do with all the leftover time but there isn't any leftover time.

So I guess after enabling basic functionality - which seemed more or less straightforward for the past few generations due to small/moderate changes

This is the first problem with your argument. The fact that the changes are relatively small doesn't mean they are quick or easy, and you've probably figured out that we have larger changes coming down the pipe.

- in my opinion the next vital thing would be pm. Especially in the era of mobile devices and the Fusion APU which is best known for its low consumption. So burning power unnecessarily with the APUs seem to defeat the whole purpose and should be a key focus for AMD. Hence Average Linux Joe buys a new machine, installs $HISFAVOURITEDISTRO and he doesn't care anymore 'cause desktop effects work and there's plenty of battery time remaining.

OK, so let's just be clear. Improving PM is more important than making the chip work reliably in the first place and allowing other developers to work effectively ? Those are the choices.

Well, I'm just an outsider so what do I know about AMD's aims and goals but I think I heard somewhere that it was to give good out-of-the-box experience for Linux users. However, halving the battery life out-of-the-box will not please many users... so what I described still makes sense to me. Please point out my mistakes and misunderstandings if you have time. Thanks!

I guess there are two key points here. One is that you are starting with the (invalid) assumption that Alex has lots of time left over and has been spending it on things you consider less important than power management. You look at the changes for new GPU support, see that they are relatively small, and assume the work was fast and easy. Not so.

The second key point is that some things can only be done by AMD employees, while others can be done by any developer. Unless/until we are keeping up with things that only AMD folks can do, it doesn't seem to make sense to slow *everything* and *everybody* down to work on something that other community developers could do just as easily.

You are probably also making the assumption that getting power management working the way you want would be fast and easy. That`s probably wrong too

Good questions though.

[HokTar]

Task #2 is stability, ie trying to make the HW/SW combination not crash. Task #3 is supporting other driver developers (#2 and #3 are probably same priority really).

Good points, forgot about those (well, I implicitly assumed that if a chip is working it means working stable). Alex indeed answers all radeon related letters on mesa-dev, etc.

Between #1, 2 and 3 all the time is used up. You are making reasonable proposals for what we do with all the leftover time but there isn't any leftover time.

Well, I can see that. This is exactly the reason I mentioned your new recruits.

This is the first problem with your argument. The fact that the changes are relatively small doesn't mean they are quick or easy, and you've probably figured out that we have larger changes coming down the pipe.

The small changes can be tricky and cumbersome, so I tried not to underestimate them. Hearing from bigger changes is always fascinating!

OK, so let's just be clear. Improving PM is more important than making the chip work reliably in the first place and allowing other developers to work effectively ? Those are the choices.

I never said or implied this.

I guess there are two key points here. One is that you are starting with the (invalid) assumption that Alex has lots of time left over and has been spending it on things you consider less important than power management. You look at the changes for new GPU support, see that they are relatively small, and assume the work was fast and easy. Not so.

See above -- I didn't imply that Alex wasn't working his ass off and that the changes were trivial.
However, it seemed that Dave Airlie was asked/hired/whatever to bring up cayman support. This suggests that Alex was working on something else which is not yet visible for normal people.

The second key point is that some things can only be done by AMD employees, while others can be done by any developer. Unless/until we are keeping up with things that only AMD folks can do, it doesn't seem to make sense to slow *everything* and *everybody* down to work on something that other community developers could do just as easily.

Again, this is not what I meant. However, you are implying that pm is easy yet I remember how much Alex and if memory serves Rafal Milecki struggled to get to a somewhat working state.

You are probably also making the assumption that getting power management working the way you want would be fast and easy. That`s probably wrong too

I know that it's not. Otherwise it would have been done ages ago, wouldn't it?

Good questions though.

Thank you for your time and answers, it made things clearer. Can we expect some update in the foreseeable future on who you hired and/or when they are supposed to start and/or what you have in mind as for their first tasks?

[Welsh Dwarf]

How do you see this ?

/sys/kernel/debug/dri/0/radeon_pm_info

You need debugfs mounted.

HTH

[whitecat]

/sys/kernel/debug/dri/0/radeon_pm_info

You need debugfs mounted.

HTH

Thx.
What stands for 0 and 64 ?

[getbent]

dynclks

I don't recall seeing any mention of using dynclks being enabled?

On my system it doesn't seem to be possible to enable at runtime (only during kernel boot radeon.dynclks=1).

$ cat /sys/module/radeon/parameters/dynclks
1

[darkbasic]

And its really weird that why GPU low is consumes higher than fglrx in idle state.
I think it's needed to be top priority thing since all open source stack users just wasting their electricity and I guess it's simple to fix than trying to put better 3D stuff.

I do agree, having at least a working low profile is a must. For some cards it does work as well as catalyst, for others it simply doesn't work
Even dynpm does work very well on my HD3870 with linux-3.0.0-rc5 (except a bit of flickering) but it seems I'm lucky. Wondering if/when dynpm will be the default

[whitecat]

Even dynpm does work very well on my HD3870 with linux-3.0.0-rc5 (except a bit of flickering) but it seems I'm lucky.

What's the vendor of your card?
Maybe the level of support is due to the BIOS provided by the vendors.

[darkbasic]

What's the vendor of your card?

Uhm... I don't remember. I will check.

[ahlaht]

Fixing dynpm?

Even dynpm does work very well on my HD3870 with linux-3.0.0-rc5 (except a bit of flickering) but it seems I'm lucky. Wondering if/when dynpm will be the default

I have been playing a little with the power management code and dynpm and the impression I currently have is that it is possible to make it work very well. The simplest fix would be to add some more user configuration options so that users could optionally enable some lower power states too.

The only problem is the flicker. I have no idea how to get rid of it. Are there any ideas or documentation? I personally will not be using dynpm until there is a way to get rid of the flicker.

[Welsh Dwarf]

Thx.
What stands for 0 and 64 ?

Frankly, I don't really know. I'll have to refer this one to the radeon gods on mount mesa