AMD Radeon HD 6000 Gallium3D Attempts To Compete With Catalyst

[crazycheese]

On Urban Terror. I have now athlon II x2 240 machine, with Linux Mint 10 and nvidia 8300 IGP connected to 19" CRT (1280x1024).

After issuing /com_maxfps 180 and viewing tutorials there are several differencies.
The fps variates between 50 and 80, exactly as it should be.

Im puzzled.

[ahlaht]

+3, even if I don't own AMD card anymore (yet,.. again) reason being drivers, so here is my vote

I think the demand is actually much higher, mate. If it works, people tend to ignore and use, if it does not work people complain and then ignore and use something else(hardware).

All right. I'll try to post it soon. Possible in a few hours.

Btw. I have made these modifications mostly just for fun and practice (my C was rusty). I was totally expecting that similar patches might already exist, because I don't currently follow any mailing lists so I don't know what the actual developers might be doing or planning.

[ahlaht]

Radeon power management patch

I posted it on bug 38917 because Phoronix does not allow attachments?

https://bugs.freedesktop.org/show_bug.cgi?id=38917

It could probably use some more documentation. See my earlier post for hints.

Some things I forgot to mention:
[*] marks the clock mode that is currently in use.

The clock modes used by dynpm are not marked, but[*] can be used to determine the correct power_state when dynpm is active.

To confirm the settings actually in use do:
cat /sys/kernel/debug/dri/0/radeon_pm_info

Hopefully at least 1 person finds this patch useful.

On an unrelated note I have recently found out that under certain workloads dynpm keeps switching between the clock modes continuously which results in strange user experience (even without the flickering). So among many other things that are missing from dynpm it could use some more intelligence too.

[Drago]

I posted it on bug 38917 because Phoronix does not allow attachments?

https://bugs.freedesktop.org/show_bug.cgi?id=38917

It could probably use some more documentation. See my earlier post for hints.

Some things I forgot to mention:
[*] marks the clock mode that is currently in use.

The clock modes used by dynpm are not marked, but[*] can be used to determine the correct power_state when dynpm is active.

To confirm the settings actually in use do:
cat /sys/kernel/debug/dri/0/radeon_pm_info

Hopefully at least 1 person finds this patch useful.

On an unrelated note I have recently found out that under certain workloads dynpm keeps switching between the clock modes continuously which results in strange user experience (even without the flickering). So among many other things that are missing from dynpm it could use some more intelligence too.

This is awesome work of your side. Please don't stop and try to cooperate with the main developers, so things can be merged to master tree.
I personally started to read Evergreen ISA documentations...will see what will come out of this...

[curaga]

@ahlaht

How about a simple "do not switch again if switched in the last 5 seconds"? Should take care of that pingpong.

[ahlaht]

This is awesome work of your side. Please don't stop and try to cooperate with the main developers, so things can be merged to master tree.
I personally started to read Evergreen ISA documentations...will see what will come out of this...

Thanks.

I already made v2 of the patch (right after sending, DOH), but it doesn't actually change anything so I guess there is no need to send it. I have some additional features in mind, but I probably will not implement them at least not without some actual developer feedback:

- The patch I made does not allow adding completely new power states or clock modes. I suspect this might be needed on some systems and I would have added support for it, but I don't have such hardware.

- The patch currently prints everything even values not used on some systems. This might be bad if those values are uninitialized (non-zero).

- It should be easy to make a nice graphical UI for reclocking and power management. The kernel interface I added is obviously very low level and hard to use, but this needs not to be the case with an external program.

How about a simple "do not switch again if switched in the last 5 seconds"?
Should take care of that pingpong.

Sure, that could work. I was thinking something like: "do not downclock unless total workload during certain period X has dropped below threshold"

But that's just an idea.

[oibaf]

- It should be easy to make a nice graphical UI for reclocking and power management. The kernel interface I added is obviously very low level and hard to use, but this needs not to be the case with an external program.

Ideally there should be such an interface to manage all drivers options (power states, Xv variables, S3TC decompression, ...).

[ahlaht]

I was thinking something like: "do not downclock unless total workload during certain period X has dropped below threshold"

Correction. I actually meant: "do not downclock unless the peak workload during certain period X has dropped below threshold"

[Drago]

Ideally there should be such an interface to manage all drivers options (power states, Xv variables, S3TC decompression, ...).

On all FOSS drivers (radeon,intel,nouveau). With still control center named just 'GPU Controls', or something like that.

[curaga]

Correction. I actually meant: "do not downclock unless the peak workload during certain period X has dropped below threshold"

I thought that was already done, but it was just too trigger-happy, which is why I suggested a time check.