[ubuntu-x] Add tag for GPU fan related problems? [was: Tagging Xorg bugs (especially -intel)]

Martin Olsson mnemo at minimum.se
Mon May 11 16:57:18 BST 2009


Bryce Harrington wrote:
> On Fri, May 08, 2009 at 06:51:50PM +0200, Martin Olsson wrote:
>> Someone posted this additional info in the bug btw (apparently there is some
>> upstream work on -ati power management that didn't make it into jaunty!):
>> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/373669/comments/2
> 
> Would you mind forwarding this bug upstream, and chatting with Alex
> Deucher about it (he's on #radeon).  Alex works at AMD so would likely
> have access to docs (or could at least talk to the relevant engineers).
> So upstreaming this bug would probably be very fruitful in getting a
> complete solution.
> 

I filed this upstream bug for tracking purposes:
https://bugs.freedesktop.org/show_bug.cgi?id=21678

I also followed up with Alex on AMD/ATI and there seems to be two waves
of improvements coming upstream. The first one is the clockgating option
etc available in the post 6.12 branch (i.e. current master), however the
second and more complete wave of power management fixes will come only
once radeon KMS has stabilized.

Alex full reply is attached below, very interesting reading indeed.


		Martin





Deucher, Alexander wrote:
> Hi Martin,
>
>   The problem with power management is that it's involved with just
> about every aspect of the driver, as such it's not a simple
> implementation.  To do it properly, it really has to be done in the new
> kernel modesetting enabled (kms) drm since that would know the state of
> not only the command stream but also the displays.
>
> The current driver architecture it not well suited to power management
> and most of what we do now would be a hack and would have to be re-done
> properly once the kms drm is ready.  example, if you want to scale the
> memory clocks, you need to make sure you still provide enough bandwidth
> for the displays (single vs. multi-head, etc.) and enough bandwidth for
> the drawing engine (texture fetches, vertex buffers, command buffers,
> etc.).  Or if you are playing back a video, you'll want to scale the
> memory clock and pcie lanes enough to provide enough bandwidth for the
> video playback, but also reduce power usage if possible; same for engine
> clock.  You'll want to reduce that to save power, but still leave it
> high enough to render the frame without raising the latency too much.
> Adjusting the voltage has similar requirements.  The problem with the
> current driver setup is that that X driver is only aware of the displays
> and 2D (EXA, XV), but not 3D.  To be done right, the driver would need
> insight into the incoming command stream and the displays which is
> currently only possible in the kms enabled drm.
>
> In addition to the above requirement, X lacks a generic driver attribute
> system that can be changed dynamically.  There are interfaces like
> xrandr and Xv attributes, but they for displays and Xv respectively, not
> general driver attributes.  In order to change the power profile on the
> fly you'd need some sort of dynamic interface.  The drm could expose it
> via sysfs for example.  Then applications like gnome-power-manager could
> dynamically change the power profile (AC/DC transition, user selected
> power profile, etc.).
>
> The information to implement most power management features is already
> available.  The radeon driver in git has code to change the engine and
> memory clocks of both atombios-based (r4xx-r7xx) and pre-atom-based
> cards (r1xx-r3xx) as well as adjusting the number of pcie lanes
> (r3xx-r7xx).
>
> Things like fan control and temperature readings (if available) are
> implemented via third party chips controlled via i2c at least for
> pre-r6xx chips.  The power mode data table information in atombios.h in
> the radeon/radeonhd drivers have everything you'd need to implement
> support for these chips (other than documentation on the third party
> chips themselves which in most cases is available from the third party).
> The data table will tell you what chips are present and the gpio info
> needed to access the chips via i2c.  In many cases there may already be
> i2c chip drivers for some of the third party chips in the kernel as part
> of lmsensors, etc.  Integrating properly with lmsensors is another
> reason this should be done in the drm rather than in the radeon xorg
> driver.  For some r6xx and newer chips, some of the functionality has
> moved on chip, but we are still sorting out information on that
> interface.
>
> In the next major release of the radeon driver, the basic power
> management features you mentioned below will be available as driver
> options and we will probably see some other improvements as well.
> However, full-blown power management will probably only be available in
> the kms enabled drm.  There is enough information available already to
> implement decent power management, but we are currently limited by
> driver infrastructure and developer man power.
>
> I hope this helps.  Feel free to forward this information to others.
>
> Alex
>
>
> -----Original Message-----
> From: Martin Olsson [mailto:martin at minimum.se]
> Sent: Monday, May 11, 2009 10:10 AM
> To: gpudriverdevsupport
> Subject: Status of upstream fan control / power management code?
>
> Hi,
>
> I normally triage xorg bugs for Ubuntu Linux and it has come to my
> attention that some
> users would like to use the -ati driver but they are unable to do so
> because that
> driver lacks the proper power management code causing it to run their
> GPU fans at 100%
> speed all the time. Switching to fglrx makes the fans run slower in a
> "on demand" mode
> like they do on Windows etc. The affect user said he preferred the open
> source driver,
> even if it did not have the same 3D features yet, but that the fan issue
> was just too
> annoying to ignore.
>
> I'm thinking specifically about this bug:
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/37
> 3669
> The user has -radeon 6.12.1 on a Mobility Radeon HD 3400 Series
> [1002:95c4],
>
> While discussing this issue with some other ubuntu people, someone said
> that AMD/ATI
> has not yet released specs for the PowerPlay API. Is that really the
> issue here?
> Is there no way to get the fans to run at less than 100% speed because
> of missing
> specifications or is that misunderstanding? This seems odd to be given
> that AMD
> even released 3D specs for r600/r700 a few days ago?
>
> In particular, I've heard that -radeon has some cool power management
> features in
> their upstream version (I'm thinking about the clockgating option and so
> on).
> Does that mean that the fan problem will be corrected as well?
>
> Maybe you could shed some light on the general situation upstream and
> what your
> opinions are about the future. With you're permission I'd like to
> forward your
> reply to the other ubuntu xorg packagers etc.
>
> Is there anything Ubuntu can do right now, or in the next release, to
> provide a better out
> of the box experience for these AMD/ATI users with respect to fan
> control / power management?
>
>
> Thank you,
>
>
> 		Martin
>
>




More information about the Ubuntu-x mailing list