| Message ID | CAKL7Q7pTKteC4HxuhtZtzBLOZDe4r3cGGj4cEbWXx4zg3gstHg@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
2013/6/26 Deucher, Alexander <Alexander.Deucher@amd.com>: > > >> -----Original Message----- >> From: Joshua C. [mailto:joshuacov@gmail.com] >> Sent: Wednesday, June 26, 2013 1:52 PM >> To: dri-devel@lists.freedesktop.org >> Cc: Deucher, Alexander >> Subject: RADEON / DPM: GPU cannot properly up-clock >> >> First of all thank you guys for pushing this out! Great work! >> >> I tried the latest code in drm-next-3.11-wip (up to commit >> b3c1e0c3ba885db44 "drm/radeon: fix endian issues in atombios dpm >> code") in connection with the latest radeon_ucode (latest update on >> 2013-06-26). I also reintroduced the debugfs info so that I can better >> observe the gpu-settings. For this I put back the following patch: >> >> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c >> b/drivers/gpu/drm/radeon/radeon_pm.c >> index 7ba5d6f..9367234 100644 >> --- a/drivers/gpu/drm/radeon/radeon_pm.c >> +++ b/drivers/gpu/drm/radeon/radeon_pm.c >> @@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct >> radeon_device *rdev) >> ret = device_create_file(rdev->dev, &dev_attr_power_method); >> if (ret) >> DRM_ERROR("failed to create device file for power method\n"); >> + >> + if (radeon_debugfs_pm_init(rdev)) { >> + DRM_ERROR("Failed to register debugfs file for PM!\n"); >> + } >> + >> DRM_INFO("radeon: dpm initialized\n"); >> } >> >> -- >> 1.8.2.1 > > I removed that code for a reason when DPM is active. With DPM the hardware changes the power state dynamically internally so that old debugging information is completely irrelevant when DPM is active. > > Alex > > I see. Do you have any idea why I see those delays when playing a HD-movie? They do not appear when switching to dynpm. I use the latest llvm(3.4svn), libdrm(2.4.45), mesa(9.2.0 devel), xserver(1.14.99.0), xf86-video-ati(deve) - all fetched from git as of 2013-06-26. -- --joshua
On Wed, Jun 26, 2013 at 4:57 PM, Joshua C. <joshuacov@gmail.com> wrote: > 2013/6/26 Deucher, Alexander <Alexander.Deucher@amd.com>: >> >> >>> -----Original Message----- >>> From: Joshua C. [mailto:joshuacov@gmail.com] >>> Sent: Wednesday, June 26, 2013 1:52 PM >>> To: dri-devel@lists.freedesktop.org >>> Cc: Deucher, Alexander >>> Subject: RADEON / DPM: GPU cannot properly up-clock >>> >>> First of all thank you guys for pushing this out! Great work! >>> >>> I tried the latest code in drm-next-3.11-wip (up to commit >>> b3c1e0c3ba885db44 "drm/radeon: fix endian issues in atombios dpm >>> code") in connection with the latest radeon_ucode (latest update on >>> 2013-06-26). I also reintroduced the debugfs info so that I can better >>> observe the gpu-settings. For this I put back the following patch: >>> >>> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c >>> b/drivers/gpu/drm/radeon/radeon_pm.c >>> index 7ba5d6f..9367234 100644 >>> --- a/drivers/gpu/drm/radeon/radeon_pm.c >>> +++ b/drivers/gpu/drm/radeon/radeon_pm.c >>> @@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct >>> radeon_device *rdev) >>> ret = device_create_file(rdev->dev, &dev_attr_power_method); >>> if (ret) >>> DRM_ERROR("failed to create device file for power method\n"); >>> + >>> + if (radeon_debugfs_pm_init(rdev)) { >>> + DRM_ERROR("Failed to register debugfs file for PM!\n"); >>> + } >>> + >>> DRM_INFO("radeon: dpm initialized\n"); >>> } >>> >>> -- >>> 1.8.2.1 >> >> I removed that code for a reason when DPM is active. With DPM the hardware changes the power state dynamically internally so that old debugging information is completely irrelevant when DPM is active. >> >> Alex >> >> > > I see. Do you have any idea why I see those delays when playing a > HD-movie? They do not appear when switching to dynpm. I use the latest > llvm(3.4svn), libdrm(2.4.45), mesa(9.2.0 devel), xserver(1.14.99.0), > xf86-video-ati(deve) - all fetched from git as of 2013-06-26. What type of movie is it and what are you using to decode the movie? UVD? CPU? Alex
2013/6/27 Alex Deucher <alexdeucher@gmail.com>: > On Wed, Jun 26, 2013 at 4:57 PM, Joshua C. <joshuacov@gmail.com> wrote: >> 2013/6/26 Deucher, Alexander <Alexander.Deucher@amd.com>: >>> >>> >>>> -----Original Message----- >>>> From: Joshua C. [mailto:joshuacov@gmail.com] >>>> Sent: Wednesday, June 26, 2013 1:52 PM >>>> To: dri-devel@lists.freedesktop.org >>>> Cc: Deucher, Alexander >>>> Subject: RADEON / DPM: GPU cannot properly up-clock >>>> >>>> First of all thank you guys for pushing this out! Great work! >>>> >>>> I tried the latest code in drm-next-3.11-wip (up to commit >>>> b3c1e0c3ba885db44 "drm/radeon: fix endian issues in atombios dpm >>>> code") in connection with the latest radeon_ucode (latest update on >>>> 2013-06-26). I also reintroduced the debugfs info so that I can better >>>> observe the gpu-settings. For this I put back the following patch: >>>> >>>> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c >>>> b/drivers/gpu/drm/radeon/radeon_pm.c >>>> index 7ba5d6f..9367234 100644 >>>> --- a/drivers/gpu/drm/radeon/radeon_pm.c >>>> +++ b/drivers/gpu/drm/radeon/radeon_pm.c >>>> @@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct >>>> radeon_device *rdev) >>>> ret = device_create_file(rdev->dev, &dev_attr_power_method); >>>> if (ret) >>>> DRM_ERROR("failed to create device file for power method\n"); >>>> + >>>> + if (radeon_debugfs_pm_init(rdev)) { >>>> + DRM_ERROR("Failed to register debugfs file for PM!\n"); >>>> + } >>>> + >>>> DRM_INFO("radeon: dpm initialized\n"); >>>> } >>>> >>>> -- >>>> 1.8.2.1 >>> >>> I removed that code for a reason when DPM is active. With DPM the hardware changes the power state dynamically internally so that old debugging information is completely irrelevant when DPM is active. >>> >>> Alex >>> >>> >> >> I see. Do you have any idea why I see those delays when playing a >> HD-movie? They do not appear when switching to dynpm. I use the latest >> llvm(3.4svn), libdrm(2.4.45), mesa(9.2.0 devel), xserver(1.14.99.0), >> xf86-video-ati(deve) - all fetched from git as of 2013-06-26. > > What type of movie is it and what are you using to decode the movie? UVD? CPU? > > Alex Here is an example of the information from one of the films: Stream 0 Type: Video Codec: H264 - MPEG-4 AVC (part 10) (avc1) Lang: English Res: 1280x544 Bitrate: 23.976215 Format: Planar 4:2:0 YVU Stream 1 Type: Audio Codec: DTS Audio (dts ) Lang: English Channels: 3F2R/LFE Freq: 48000 Hz Bitrate: 1536 kb/s I recompiled the whole videostack (mesa, llvm, drm, xserver, xf86-video-ati, vdpau - all from git) against the patched kernel and can say that currently there are no visible regressions. The "slow motion" is almost gone. However I still see it in some frames but I'm not sure if this is a kernel-part-problem or just a mesa-problem. However I observe the following: Under windows: smooth play, temps in idle: 34-35C, cpu-usage: up to 5% on all cores on a 4-core cpu, temps when playing the film: up to 42C, cpu-usage: up to 5% on all 4 cores Under linux (updated as described above): some discrepences (those happen pretty rarely, though), temps in idle: 34-36C, cpu-usage: up to 5%, temps when playing the film: no more than 37C, cpu-usage: one core is constantly spiking up to 40% the other 3 stay below 7%. When looking through the dmesg I cannot see that dpm is changing the power state to "uvd". This makes me believe that I'm maybe using a cpu-decode rather then the dedicated uvd. The gpu-temps are also staying surpricingly low comapred to windows... -- --joshua
2013/6/28 Joshua C. <joshuacov@gmail.com>: > 2013/6/27 Alex Deucher <alexdeucher@gmail.com>: >> On Wed, Jun 26, 2013 at 4:57 PM, Joshua C. <joshuacov@gmail.com> wrote: >>> 2013/6/26 Deucher, Alexander <Alexander.Deucher@amd.com>: >>>> >>>> >>>>> -----Original Message----- >>>>> From: Joshua C. [mailto:joshuacov@gmail.com] >>>>> Sent: Wednesday, June 26, 2013 1:52 PM >>>>> To: dri-devel@lists.freedesktop.org >>>>> Cc: Deucher, Alexander >>>>> Subject: RADEON / DPM: GPU cannot properly up-clock >>>>> >>>>> First of all thank you guys for pushing this out! Great work! >>>>> >>>>> I tried the latest code in drm-next-3.11-wip (up to commit >>>>> b3c1e0c3ba885db44 "drm/radeon: fix endian issues in atombios dpm >>>>> code") in connection with the latest radeon_ucode (latest update on >>>>> 2013-06-26). I also reintroduced the debugfs info so that I can better >>>>> observe the gpu-settings. For this I put back the following patch: >>>>> >>>>> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c >>>>> b/drivers/gpu/drm/radeon/radeon_pm.c >>>>> index 7ba5d6f..9367234 100644 >>>>> --- a/drivers/gpu/drm/radeon/radeon_pm.c >>>>> +++ b/drivers/gpu/drm/radeon/radeon_pm.c >>>>> @@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct >>>>> radeon_device *rdev) >>>>> ret = device_create_file(rdev->dev, &dev_attr_power_method); >>>>> if (ret) >>>>> DRM_ERROR("failed to create device file for power method\n"); >>>>> + >>>>> + if (radeon_debugfs_pm_init(rdev)) { >>>>> + DRM_ERROR("Failed to register debugfs file for PM!\n"); >>>>> + } >>>>> + >>>>> DRM_INFO("radeon: dpm initialized\n"); >>>>> } >>>>> >>>>> -- >>>>> 1.8.2.1 >>>> >>>> I removed that code for a reason when DPM is active. With DPM the hardware changes the power state dynamically internally so that old debugging information is completely irrelevant when DPM is active. >>>> >>>> Alex >>>> >>>> >>> >>> I see. Do you have any idea why I see those delays when playing a >>> HD-movie? They do not appear when switching to dynpm. I use the latest >>> llvm(3.4svn), libdrm(2.4.45), mesa(9.2.0 devel), xserver(1.14.99.0), >>> xf86-video-ati(deve) - all fetched from git as of 2013-06-26. >> >> What type of movie is it and what are you using to decode the movie? UVD? CPU? >> >> Alex > > Here is an example of the information from one of the films: > > Stream 0 > Type: Video > Codec: H264 - MPEG-4 AVC (part 10) (avc1) > Lang: English > Res: 1280x544 > Bitrate: 23.976215 > Format: Planar 4:2:0 YVU > Stream 1 > Type: Audio > Codec: DTS Audio (dts ) > Lang: English > Channels: 3F2R/LFE > Freq: 48000 Hz > Bitrate: 1536 kb/s > > I recompiled the whole videostack (mesa, llvm, drm, xserver, > xf86-video-ati, vdpau - all from git) against the patched kernel and > can say that currently there are no visible regressions. The "slow > motion" is almost gone. However I still see it in some frames but I'm > not sure if this is a kernel-part-problem or just a mesa-problem. > > However I observe the following: > > Under windows: smooth play, temps in idle: 34-35C, cpu-usage: up to 5% > on all cores on a 4-core cpu, temps when playing the film: up to 42C, > cpu-usage: up to 5% on all 4 cores > > Under linux (updated as described above): some discrepences (those > happen pretty rarely, though), temps in idle: 34-36C, cpu-usage: up to > 5%, temps when playing the film: no more than 37C, cpu-usage: one core > is constantly spiking up to 40% the other 3 stay below 7%. > > When looking through the dmesg I cannot see that dpm is changing the > power state to "uvd". This makes me believe that I'm maybe using a > cpu-decode rather then the dedicated uvd. The gpu-temps are also > staying surpricingly low comapred to windows... > > -- > --joshua With the latest git 7982128c3d447df27db963af67bc6b8dc7efb1de "drm/radeon/dpm: add debugfs support for SI" from git://people.freedesktop.org/~agd5f/linux drm-next-3.11 everything works fine here (on TURKS). Under Linux I get the same temps as under windows. No more tearing when watching videos. The GPU re-clocks as desired... -- --joshua
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c index 7ba5d6f..9367234 100644 --- a/drivers/gpu/drm/radeon/radeon_pm.c +++ b/drivers/gpu/drm/radeon/radeon_pm.c @@ -1066,6 +1066,11 @@ static int radeon_pm_init_dpm(struct radeon_device *rdev) ret = device_create_file(rdev->dev, &dev_attr_power_method); if (ret) DRM_ERROR("failed to create device file for power method\n"); + + if (radeon_debugfs_pm_init(rdev)) { + DRM_ERROR("Failed to register debugfs file for PM!\n"); + } + DRM_INFO("radeon: dpm initialized\n"); }
First of all thank you guys for pushing this out! Great work! I tried the latest code in drm-next-3.11-wip (up to commit b3c1e0c3ba885db44 “drm/radeon: fix endian issues in atombios dpm code”) in connection with the latest radeon_ucode (latest update on 2013-06-26). I also reintroduced the debugfs info so that I can better observe the gpu-settings. For this I put back the following patch: -- 1.8.2.1 Everything works fine, however I think that my gpu (ati 6670, see below) doesn't reclock properly (OR doesn't reclock at all). I observed the gpu-temps and compared those with the readings when using “profile” and “dynpm”. Usually (with dynpm) the temps stay low and jump up when I start glxgears or any HD-movie. With the latest dpm my temps and the gpu stay in the lowest profile all the time. It doesn't reclock even if I start any demanding work like HD-Movie. Dmesg shows this: *** [ 1.307529] == power state 0 == [ 1.307530] ui class: none [ 1.307531] internal class: boot [ 1.307532] caps: [ 1.307533] uvd vclk: 0 dclk: 0 [ 1.307534] power level 0 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.307535] power level 1 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.307536] power level 2 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.307537] status: c r b [ 1.307538] == power state 1 == [ 1.307539] ui class: performance [ 1.307539] internal class: none [ 1.307540] caps: [ 1.307541] uvd vclk: 0 dclk: 0 [ 1.307542] power level 0 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.307543] power level 1 sclk: 40000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.307544] power level 2 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.307544] status: [ 1.307545] == power state 2 == [ 1.307546] ui class: none [ 1.307546] internal class: uvd [ 1.307547] caps: video [ 1.307549] uvd vclk: 70000 dclk: 56000 [ 1.307549] power level 0 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.307550] power level 1 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.307551] power level 2 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.307552] status: [ 1.311858] switching from power state: [ 1.311859] ui class: none [ 1.311860] internal class: boot [ 1.311860] caps: [ 1.311861] uvd vclk: 0 dclk: 0 [ 1.311862] power level 0 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.311863] power level 1 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.311864] power level 2 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.311865] status: c b [ 1.311866] switching to power state: [ 1.311866] ui class: performance [ 1.311867] internal class: none [ 1.311868] caps: [ 1.311869] uvd vclk: 0 dclk: 0 [ 1.311869] power level 0 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.311870] power level 1 sclk: 40000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.311871] power level 2 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.311872] status: r and later (other dmesg output is attached) [ 1.360509] switching from power state: [ 1.360510] ui class: performance [ 1.360510] internal class: none [ 1.360511] caps: [ 1.360511] uvd vclk: 0 dclk: 0 [ 1.360512] power level 0 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.360512] power level 1 sclk: 40000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.360513] power level 2 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.360513] status: c r [ 1.360514] switching to power state: [ 1.360514] ui class: performance [ 1.360515] internal class: none [ 1.360515] caps: [ 1.360515] uvd vclk: 0 dclk: 0 [ 1.360516] power level 0 sclk: 10000 mclk: 15000 vddc: 900 vddci: 0 [ 1.360516] power level 1 sclk: 40000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.360517] power level 2 sclk: 80000 mclk: 100000 vddc: 1100 vddci: 0 [ 1.360517] status: c r *** The radeon_pm_info shows all the time: [root@localhost ~]# cat /sys/kernel/debug/dri/0/radeon_pm_info default engine clock: 800000 kHz current engine clock: 99990 kHz default memory clock: 1000000 kHz current memory clock: 150000 kHz voltage: 1100 mV PCIE lanes: 16 When using the “dynpm” settings I could see the voltage dropping back to 900mV (as in performace, power level 0) but now it stays high all the time. When playing a HD-Moving I can see the film in a “slow-motion” which also confirms that the gpu doesn't reclock. Setting dynpm reclocks fine and the HD-movie plays smoothly. My gpu is: 01:00.0 VGA compatible controller: ATI Technologies Inc Turks XT [AMD Radeon HD 6600 Series] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Device e194 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 56 Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at fe620000 (64-bit, non-prefetchable) [size=128K] Region 4: I/O ports at e000 [size=256] Expansion ROM at fe600000 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee0f00c Data: 41d2 Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Capabilities: [150 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Kernel driver in use: radeon Can some take a look at this? Thanks, joshua