Was man unter supported oder done versteht - gezeigt am Beispiel des Powermanagements von xf86-video-ati-6.14.5

05/07/2012 - 16:01 von Andreas Hartmann | Report spam
Hallo zusammen,

das Thema Energieverbrauch bzw. Betriebsbedingungen ist mir mal wieder
bei Tests mit meiner Graka mit xf86-video-ati-6.14.5 aufgefallen:
Einfach Rechner starten und in einer Konsole (kein X) stehen lassen.
Innerhalb kürzester Zeit ist die GPU bei 68,5°C. Idle-Modus! Vom
Catalyst weiß ich: die Temperatur im Idle-Modus unter KDE 4.7.4 liegt
bei 50°C (selbe Umgebungstemperatur), fast 20° weniger.
Da kann ja was nicht stimmen.

Das führt mich zur Seite http://www.x.org/wiki/RadeonFeature/ zum Teil
"Power Saving". Alles grün ("DONE"), zumindest was meinen Teil angeht.
Warum wird dann das Teil trotzdem heiß?

Ahh, weiter unten ist der Beipackzettel. In dem ist zu lesen:

Ich brauche einen Kernel >= 2.6.35. Ok, 3.4.4 erfüllt diese Anforderung.

Des weiteren werden 2 grundsàtzliche Powermanagement-Methoden
unterstützt. Wieso 2? Eine automatisch funktionierende würde doch
vollauf genügen! Egal, weiterlesen.

Die erste Methode heißt "dynpm", die zweite "profile". Dann folgt eine
Erlàuterung der beiden Methoden.


Methode dynpm:
Mir wird klar, daß das die gewünschte Methode ist, daß sie aber nicht
funktioniert (weiter oben stand doch "done" - wieso wird etwas
implementiert und als done bezeichnet, wenn es nach Einschàtzung der
Entwickler selbst nicht funktioniert!?): regelmàßiges Flackern beim
Steuern. Ein Test (an _einem_ Bildschirm) bestàtigt die Einschàtzung der
Entwickler sofort. Ganz abgesehen davon geht die Temperatur trotz
làngeren Wartens im Idle-Mode nicht auf die Temperatur, welche der
Catalyst 12.6 erreicht. Ca. 6°C vorher ist Schluß.


Methode profile:
Nachdem die Einschàtzung der Entwickler zu dynpm bestàtigt wurde (nicht
brauchbar), kommt nun profile dran. Man lernt, daß es 5 verschiedene
Profiles gibt. Das "default" profile ist, wie der Name vermuten làßt,
default. Default ist ein Synonym für nonstop "Vollgas". Ok, das erklàrt
die enormen Temperaturen im Idle-Mode. Da das Standard ist, vermute ich,
daß der Rest wahrscheinlich nicht wirklich brauchbar / sinnvoll ist
(sonst wàre das ja nicht standard).

Es gibt drei weitere profiles, low, mid und high. Die GPU wird hier
_statisch_ entweder im low, mid oder high Modus gefahren, sprich,
entweder grundsàtzlich maximales Energiesparen (low) oder eben Vollgas
(high). Falls der Monitor via DPMS schlafen geht, wird in low geschaltet.

Dann gibt es noch ein "auto"-Profile, das abhàngig von der
Stromversorgung agiert, entweder mid (Batteriebetrieb) oder high
(Netzbetrieb) bzw. low, falls DPMS den Bildschirm abgeschaltet hat.

In anderen Worten: die profile-Methode ist die Holzhammer-Methode.
Natürlich auch nicht ohne Einschrànkungen, denn vor dem Einsatz von low
wird gewarnt.

Ich war trotzdem mutig und habe low getestet. Es traten im Testzeitraum
bei mir keine Probleme auf. Die Temperatur fiel zügig ab auf ca. 2°C
weniger als bei Catalyst 12.6 bei laufendem KDE 4.7.4. Soweit wunderbar.
Das Problem dabei: damit kann man nicht arbeiten. Der Bildaufbau ist
schleppend (ok, wundert nicht). Damit ist das low Profile gestorben.

High zu testen ist sinnlos, weil es im Großen und Ganzen default
entspricht. Also bleibt noch mid. Mid ist leistungstechnisch ok, aber
die Temperatur steigt wieder zügigst auf ca. 60°C, also ca. 10°C mehr
als beim Catalyst 12.6.


Fazit:
Powermanagement unter xf86-video-ati-6.14.5 ist "done", wird aber von
den Entwicklern selbst quasi als unbrauchbar eingestuft (dynpm).
Dafür gibt's die Holzhammermethode "profile" als Ersatz, welche per
default auf Vollgas làuft und vor low gewarnt wird. mid ist auch kaum
brauchbar. De facto gibt es also gar kein Powermanagement in xf86-video-ati.

Man fragt sich natürlich: warum funktionierts mit Catalyst genauso, wie
man sich das als User vorstellt? AMD ist bei der Entwicklung beider
Treiber beteiligt. Das heißt, am fehlenden KnowHow kann es nicht hàngen!

Die Einschàtzung zum Implementierungsstand finde ich daher bedenklich.


Wer ist der Dumme?
Natürlich der User, welcher mit diesem Treiber seine Karte entweder
unbemerkt nonstop röstet (fanless Karten), falls er nicht selbst aktiv
danach schaut oder im Falle von aktiv gekühlten Karten den Sound des
Lüfters nonstop genießen darf bzw. den Lüfter frühzeitig in Rente
schickt. In beiden Fàllen darf er natürlich auch eine höhere
Stromrechnung genießen.


In der aktuellen c't Kompakt-Ausgabe wird dieses Problem nur am Rande
erwàhnt (naja, immerhin) und nicht ausdrücklich davor gewarnt.
Daß man den Catalyst-Treiber bei openSUSE sehr komfortabel in das System
integriert bekommt, welcher sogar automatisch ohne weiteres Zutun
Kernelwechsel (auch mehrere parallele Kernel) und Kernelversionen bis
3.4 unterstützt, wird natürlich Dank Debian / Ubuntu bzw. Redhat -
Tunnelblick nicht erwàhnt.



Schade!
Gruß,
Andreas
 

Lesen sie die antworten

#1 Thomas Bächler
05/07/2012 - 16:11 | Warnen spam
Am 05.07.2012 16:01, schrieb Andreas Hartmann:
das Thema Energieverbrauch bzw. Betriebsbedingungen ist mir mal wieder
bei Tests mit meiner Graka mit xf86-video-ati-6.14.5 aufgefallen:
Einfach Rechner starten und in einer Konsole (kein X) stehen lassen.



Du sagst, ein Feature sei in xf86-video-ati drin, testest aber in der
Konsole, wo xf86-video-ati nicht einmal benutzt wird. Kommt dir da nicht
was komisch vor?

Gut, es könnte sein, dass das Power Management bereits im Kerneltreiber
drin ist und den X Treiber nicht braucht - aber das hast du scheinbar
nicht einmal recherchiert. Ich weiß es auch nicht, aber alleine deine
Testbeschreibung ist dadurch irgendwie wertlos.

Innerhalb kürzester Zeit ist die GPU bei 68,5°C. Idle-Modus! Vom
Catalyst weiß ich: die Temperatur im Idle-Modus unter KDE 4.7.4 liegt
bei 50°C (selbe Umgebungstemperatur), fast 20° weniger.
Da kann ja was nicht stimmen.



Du vergleichst Werte beim Ausführen von KDE mit Werten auf der Konsole.
Da kann ja was nicht stimmen.

Das führt mich zur Seite http://www.x.org/wiki/RadeonFeature/ zum Teil
"Power Saving". Alles grün ("DONE"), zumindest was meinen Teil angeht.
Warum wird dann das Teil trotzdem heiß?

[...]

Wer ist der Dumme?



Der Dumme ist der, der sich, anstatt an der enstsprechenden Stelle einen
Bug zu reporten, in einer deutschen Newsgroup aufregt. In dieser
Newsgroup liest wahrscheinlich kein einziger verantwortlicher Entwickler
mit, der das Problem genauer analysieren könnte.

Der freedesktop.org-Bugtracker bzw. die entsprechende Mailingliste sind
der Ort, an dem man die radeon-Entwickler kontaktieren kann.

Ähnliche fragen