Radeon DPM Is Fantastic For Power Use, Thermal Performance

[GreatEmerald]

And btw, I can monitor GPU frequencies like this:

 while (true) do cat /sys/kernel/debug/dri/0/radeon_pm_info; sleep 1; done

That's way too complex, just do:

watch cat /sys/kernel/debug/dri/0/radeon_pm_info

[Michael]

That's way too complex, just do:

watch cat /sys/kernel/debug/dri/0/radeon_pm_info

At last check, radeon_pm_info changed on Linux 3.11 and no longer was showing the core/memory frequencies. PTS already supports monitoring radeon_pm_info on supported kernels but with the configurations I had tried it wasn't working. But I'll see if it's working again with latest Git...

[ua=42]

Micheal. I've looked at the code and I noticed something.

In setting the values for $config['color']['paint']
#e12128 and #E00022 are visually identical.
and
757575 is nearly the same as 79776 and 555555 (79776 and 555555 are different from each other)

Unless there is a reason to have a certain length to $config['color']['paint'], removing #e12128 and 757575 would get rid of some confusing colors.


I am also a bit confused about color_cache.
In color_cache I can tell that you are assigning colors to sets of data. I'm not sure if I understand what you are trying to do with this bit of code

if(empty($colors))  
				{
					return false;  // 
				}
		
				$hsl = self::color_rgb_to_hsl($colors[0]);
				$hsl = self::shift_hsl($hsl, $color_shift % 360);
				$color = self::color_hsl_to_hex($hsl);

				$color_shift += $color_shift_size;
				if($color_shift == ($color_shift_size * 3))
				{
					$color_shift_size *= 0.3;
					$colors[0] = self::color_shade($colors[0], 0.9, 1);
				}
				else if($color_shift > 630)
				{
					// We have already exhausted the cache pool once
					array_shift($colors);  
					$color_shift = 0;
				}
			}
			while(in_array($color, $cache[$ns]));
			
			$cache[$ns][$id] = $color;
		}

I hope I'm not too noobish. I've programed allot before in other languages, but this is the first time I've seriously looked at php.

[agd5f]

At last check, radeon_pm_info changed on Linux 3.11 and no longer was showing the core/memory frequencies. PTS already supports monitoring radeon_pm_info on supported kernels but with the configurations I had tried it wasn't working. But I'll see if it's working again with latest Git...

The format of the debugfs information is different if DPM is enabled because the two pm methods don't really align exactly.

[curaga]

And it's still in debugfs (ie: under a debug option, thus not available in production builds)...

[droste]

I can also confirm power management is very good for me on 5750 and 5770 cards.

Could you test with two monitors? It doesn't work with a second monitor attached on my 5770! ( https://bugzilla.kernel.org/show_bug.cgi?id=60523 )

[ua=42]

Ok. After doing some research I know what needs to be changed for the color chart picker

According to some papers, you can get to about 22 colors before they become really hard to visually distinguish from each other.
If you have 12 colors or less, there is a set of colors that are very distinguished from one another (unless you are color blind)

So I propose the code be changed in the following ways.

if there is less than 12 different lines use the following 11 colors (since we can't use white).

array('#000000', '#0000FF', '#FF0000', '#00FF00', '#FFFF00', '#FF00FF', '#FF8080', '#808080', '#800000', '#FF8000');

if there is less than 22 different lines, use the following 21 colors (since we can't use white)

array('#000000', '#FFB300', '#803E75', '#FF6800', '#A6BDD7', '#C10020', '#CEA262', '#817066', '#007D34', '#F6768E', '#00538A', '#FF7A5C', '#53377A', '#FF8E00', '#B32851', '#F4C800', '#7F180D', '#93AA00', '#593315', '#F13A13', '#232C16');

If you have 22 or more lines, then there will be visibility issues. Not sure if it would be better to fail and tell the user split the data sets, or try to fill in colors, by picking colors in-between the ones already being used.

[Gabrielbyrnei]

I get a totally unstable system when booting on 3.11 rc3.

At the instant i run folding@home or firefox, system hangs but my mouse is still moving around, just doesen't click on stuff.
When choosing 3.10.3 and doing the same thing it works fine.

AMD Athlon II x4 630
ATI 4850


I did download the updated firmware RV770_smc.bin from http://people.freedesktop.org/~agd5f/radeon_ucode/

Now on /lib/firmware/radeon i have 3 firmware files for my card:

RV770_me.bin
RV770_pfp.bin
RV770_smc.bin

On the link theres only the _smc.bin file, so maybe i only need smc and not the me and pfp?


This is all on openSUSE 12.3, kernel 3.11-rc3 from kernel:HEAD repository, Mesa 9.2 git.

[Gabrielbyrnei]

I get a totally unstable system when booting on 3.11 rc3.

At the instant i run folding@home, system hangs but my mouse is still alive.
When choosing 3.10.3 and doing the same thing it works fine.

AMD Athlon II x4 630
ATI 4850


I did download the updated firmware RV770_smc.bin from http://people.freedesktop.org/~agd5f/radeon_ucode/

Now on /lib/firmware/radeon i have 3 firmware files for my card:

RV770_me.bin
RV770_pfp.bin
RV770_smc.bin

On the link theres only the _smc.bin file, so maybe i only need smc and not the me and pfp?

This is all on openSUSE 12.3, kernel 3.11-rc3 from Kernel:HEAD repository and Mesa 9.2 git

[Michael]

Ok. After doing some research I know what needs to be changed for the color chart picker

According to some papers, you can get to about 22 colors before they become really hard to visually distinguish from each other.
If you have 12 colors or less, there is a set of colors that are very distinguished from one another (unless you are color blind)

So I propose the code be changed in the following ways.

if there is less than 12 different lines use the following 11 colors (since we can't use white).

array('#000000', '#0000FF', '#FF0000', '#00FF00', '#FFFF00', '#FF00FF', '#FF8080', '#808080', '#800000', '#FF8000');

if there is less than 22 different lines, use the following 21 colors (since we can't use white)

array('#000000', '#FFB300', '#803E75', '#FF6800', '#A6BDD7', '#C10020', '#CEA262', '#817066', '#007D34', '#F6768E', '#00538A', '#FF7A5C', '#53377A', '#FF8E00', '#B32851', '#F4C800', '#7F180D', '#93AA00', '#593315', '#F13A13', '#232C16');

If you have 22 or more lines, then there will be visibility issues. Not sure if it would be better to fail and tell the user split the data sets, or try to fill in colors, by picking colors in-between the ones already being used.

I'll try out that array and see how the results look on some of the common graphs. There's been many revisions to this code and it's rather a mess right now. Originally, pts_Graph used a static array of possible colors to pick for line graphs but when the need arose for a dynamic number of color combinations, I tried coming up with a way to dynamically calculate new colors based upon other predefined colors that fit the overall color scheme of PTS/OB. That was mostly guessing and trial and error due to not much experience with color-choosing stuff. SInce then at least two or three times, Phoronix readers have attempted to improve the color selection ways but to not much avail and mostly cluttering the code to a greater extent.