Power management is probably the hardest part of GPU programming since it ties into everything.
Announcement
Collapse
No announcement yet.
More Radeon Power Management Improvements
Collapse
X
-
Originally posted by agd5f View PostYes, piles and piles of code that touches just about everything.
And using the keyword "auto" for "always high clock" is misleading. Maybe it should be renamed to "laptop-power-source-dependent" or something like that.
Comment
-
Originally posted by Ivaldi View PostBut it seems to work seamless and efficient on a regular desktop system while the OSS driver does not.
Comment
-
Getting smooth automatic power management without graphical glitches or hangs is a huge amount of work and the open source driver just isn't there yet (we're working on it). One could argue it's the most complex part of the driver since it ties into everything:
- asic init
- bus setup
- drawing engine
- displays
etc.
Besides the trickiness of just getting reclocking to work smoothly with the drawing and display blocks, you also need the infrastructure in place to track the amounts of bandwidth or performance required for certain operations. E.g., if you are running a video on a huge display, you can only clock memory so low before you have bandwidth contention between the displays and drawing engine. Add to that certain clock combinations that don't work well together on certain boards, etc.
The pm code in the closed source driver is designed to work with a completely different driver stack, so it's not really possible to just use it. Plus there are 3rd party modules in there for things like i2c thermal chips that are not AMD's IP to release.
Comment
-
There are maybe 20-30 man-years of accumulated effort in the fglrx power management code.
IMO the open source PM code is doing remarkably well considering how new it is. As agd5f said, the driver architectures are totally different so pulling code from fglrx into the open stack would be more work than writing the open PM code from scratch.Test signature
Comment
-
I tried the recent stuff. The good thing is that the 2D driver is now stable for me. No more hard locks. On the other, the KMS, DRI2, or whatever new thing that has been introduced works so and so.
Performance is poor, and I'm unsure about the power management. The dynamic option is not really usable yet. I understand there are technical problems to be solved; but isn't it trying to be too smart/aggressive? If I read past comments well, the flickering is due to frequency changes not masked properly or something; what I don't get is why is it reclocking constantly. For instance, bringing a yakuake terminal up front causes some flickering. I wouldn't thought that was needed, my old card surely can handle it at its lowest power state. Isn't it a bit trigger-happy?
I can't say much about the 'low' and 'high' profiles, because I have no way to measure the temperature of this machine. What surprised me is that there is no difference in performance in OpenArena: both capped at 60 FPS and choking down to the same values in the difficult parts of the map I tested. Is this the expected behavior? Are the frequency values exposed somewhere?
By the way, I wanted to test this with 2.6.34 and I thought that it would be enough by compiling the drm kernel bits from source. However, I see that the stuff from freedesktop is only the library. I'm pretty sure I used to compile both parts in the past. Did this change somehow? Is it still possible to do this?
Comment
-
The kernel bits of drm have moved into the kernel tree. You used to be able to compile it separately, but it was difficult to track the fast-moving kernel development, if I understood correctly.
I think that DRI2 is vsynced by default at the moment -- that's why OpenArena is capped at 60.
I've had the same experience you did with dynpm. Profiles work well and result in nice temperature drops when using the low profile. I use low by default, and switch to default if I want to run something 3d intensive.
Comment
-
Originally posted by pingufunkybeat View PostThe kernel bits of drm have moved into the kernel tree. You used to be able to compile it separately, but it was difficult to track the fast-moving kernel development, if I understood correctly.
I think that DRI2 is vsynced by default at the moment -- that's why OpenArena is capped at 60.
I've had the same experience you did with dynpm. Profiles work well and result in nice temperature drops when using the low profile. I use low by default, and switch to default if I want to run something 3d intensive.
Comment
Comment