Bug 69721 - Can't reach maximum memory speed (or core speed) when using dpm=1 on r600g on cards not sticking to reference board
Summary: Can't reach maximum memory speed (or core speed) when using dpm=1 on r600g on...
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: All All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-23 16:13 UTC by Alexandre Demers
Modified: 2014-09-26 22:10 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

Attachments

Description Alexandre Demers 2013-09-23 16:13:24 UTC 
After fixing bug 68235, it appears the maximum memory speed (or core speed) can't always be reached. This situation depends on the voltage tweaking seen on some cards. As an exemple, XFX HD-695X-ZNDC has the following maximum values:
max_sclk_vddc->80000, max_mclk_vddci->125000, max_mclk_vddc->125000.
However, the maximum memory clock value should be 130000 and the core clock should be 83000.

As Alex Deucher explained: "This patch set works around the issue by limiting the sclk and mclk to the highest levels listed in the clk/voltage dependency tables.  I'll need to dig a bit more internally to try and figure out how to handle these clks properly."
Comment 1 Alexandre Demers 2013-09-23 16:14:13 UTC 
That is with kernel 3.11.0 or 3.12-rc1 with the two patches proposed in bug 68235.
Comment 2 Alexandre Demers 2014-09-22 04:30:38 UTC 
Hi Alex.
A year ago, while we were struggling with dpm on Cayman, you implemented a fix to limit the maximum memory and core speeds to the reference ones in the clk/voltage dependency tables. Now that Cayman is working great, I'm  wondering if you would have the time "to dig a bit more internally to try and figure out how to handle these clks properly" when a card is not using the reference values? Is there a way to read the maximum speed from the video card bios or at least to identify a card built to exceed the reference values?

I'm ready to test any patch you can throw at me.

Cheers!
Alexandre
Comment 3 Alex Deucher 2014-09-22 14:18:06 UTC 
Did you try again after fixing the vddci setup?
Comment 4 Alexandre Demers 2014-09-22 16:19:23 UTC 
(In reply to comment #3)
> Did you try again after fixing the vddci setup?

To my knowledge, the memory speed is still limited to 1250 instead of reaching its maximum speed of 1300; the same thing goes for the core clock. I'll need to have a look at the code, but the last time I had a look, we were still calling btc_get_max_clock_from_voltage_dependency_table(), which was limiting the speed to the reference values.

If I have time, I'll look at the code tonight and add some code to print values that would be limited by btc_get_max_clock_from_voltage_dependency_table().

Other than this limitation, I have mostly no problem with my Cayman GPU.
Comment 5 Alex Deucher 2014-09-22 16:31:35 UTC 
(In reply to comment #4)
> (In reply to comment #3)
> > Did you try again after fixing the vddci setup?
> 
> To my knowledge, the memory speed is still limited to 1250 instead of
> reaching its maximum speed of 1300; the same thing goes for the core clock.
> I'll need to have a look at the code, but the last time I had a look, we
> were still calling btc_get_max_clock_from_voltage_dependency_table(), which
> was limiting the speed to the reference values.

Right.  I mean have you tried reverting that patch or just skipping the calls to btc_get_max_clock_from_voltage_dependency_table().  I think they should work fine now that vddci is fixed.
Comment 6 Alexandre Demers 2014-09-22 19:30:36 UTC 
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > Did you try again after fixing the vddci setup?
> > 
> > To my knowledge, the memory speed is still limited to 1250 instead of
> > reaching its maximum speed of 1300; the same thing goes for the core clock.
> > I'll need to have a look at the code, but the last time I had a look, we
> > were still calling btc_get_max_clock_from_voltage_dependency_table(), which
> > was limiting the speed to the reference values.
> 
> Right.  I mean have you tried reverting that patch or just skipping the
> calls to btc_get_max_clock_from_voltage_dependency_table().  I think they
> should work fine now that vddci is fixed.

Well that was one of the plans. ;) I'll try it later and let you know.
Comment 7 Alexandre Demers 2014-09-23 04:43:58 UTC 
It seems to run as expected now. I've submitted a patch (http://lists.freedesktop.org/archives/dri-devel/2014-September/068789.html). Maybe it could/should be tested on other GPUs.
Comment 8 Alexandre Demers 2014-09-26 22:10:59 UTC 
Closing since it should be fixed in kernel 3.18 (pull request from drm-next-3.18).

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.