[270.18] Overclocking is _still_ broken for 8xxx (probably 9xxx too) class GPUs

[artem]

Ditto for 275.09.04

[artem]

And not fixed in 280 beta too.

This is getting really sad.

This regression is now almost half a year old.

[artem]

And not fixed in 280.13 as well

[zander]

I took some time this morning to track down a G80-based card and was able to reproduce the problem.

The driver rejects the increased "core" clock frequency because the frequency of a related domain doesn't meet a ratio requirement in a path that sanity-checks incoming clock frequencies. This is due to a bug in one of the associated control calls. If the "core" clock frequency is increased in small increments, this bug can be worked around to a certain degree, as you discovered.

I tested a fix locally and will try to get it into an upcoming 28x.xx driver release. They say Better late than never, but I imagine that's bitter-sweet in this case. At the risk of sounding insincere, I do apologize for the terrible turn-around time.

[artem]

Zander, taking into consideration the attitude towards open source that most closed sources companies have, I only wish to say "Thank you!" It's been a long wait but I'm very glad it's going to be fixed.

However there's still a lingering question why NVIDIA decided to forbid GTX 4XX/5XX overclocking under Linux. I'm not interested in overclocking of those GPUs (I simply don't own them and moreover I don't overclock anything ever, because it's just not worth it) but people keep inquiring.

[zander]

It wasn't so much a policy decision, it was more a question of picking battles.

FERMI GPUs are very complex, with elaborate clock trees and memory interfaces (e.g. GDDR5, EDC, ECC, etc.). The NV-CONTROL overclocking interface, on the other hand, is quite naive. In order to properly support clock manipulation on FERMI and newer GPUs, a fair amount of work will need to be done in at least the X driver, NV-CONTROL and nvidia-settings to overhaul the overclocking infrastructure. I believe on Windows, a lot of this type of functionality was moved outside of the driver for that reason.

We do have a bug tracking this RFE internally, and I expect we'll get to it eventually. But given ever-increasing hardware/software complexity, general driver quality concerns and other long-standing feature requests (such as the long-neglected RandR extension), it's hard to justify the effort for a small subset of the NVIDIA Linux graphics driver user base at this time.

[kokoko3k]

Has Nouveau better support to reclock fermi based cards?

Am i wrong or am i missing something...
How can a reverse enginered driver provide functionality that the proprietary one doesn't?

[artem]

Originally Posted by kokoko3k

Has Nouveau better support to reclock fermi based cards?

Am i wrong or am i missing something...
How can a reverse engineered driver provide functionality that the proprietary one doesn't?

Overclocking of Fermi based cards is implemented in Windows drivers, NVIDIA just chose not to implement this feature in Linux drivers due to the increased complexity of the architecture.

[Gusar]

Originally Posted by kokoko3k

Has Nouveau better support to reclock fermi based cards?

Am i wrong or am i missing something...
How can a reverse enginered driver provide functionality that the proprietary one doesn't?

You're confusing reclocking and overclocking. Overclocking is changing the frequencies from those the card was programmed with (they're set in the vbios). Reclocking is switching between the programmed frequencies. To use the marketing term, reclocking = PowerMizer. That commit means nouveau is receiving first code to eventually support PowerMizer. But I'm very sure it doesn't support overclocking.

[kokoko3k]

If you look into the commit, you'll see:

prog_clk(struct drm_device *dev, int clk, struct nvc0_pm_clock *info)

...but i was clearly fooled, how bad

[Licaon]

so, any news?

[alex421]

Hello,

Overclocking still seems not to work with the latest driver on my computer, is there any news?

Thx,
Alex