| Priority | medium |
|---|---|
| Bug ID | 82201 |
| Assignee | dri-devel@lists.freedesktop.org |
| Summary | [HAWAII] GPU doesn't reclock, poor 3D performance |
| Severity | normal |
| Classification | Unclassified |
| OS | Linux (All) |
| Reporter | kai@dev.carbon-project.org |
| Hardware | x86-64 (AMD64) |
| Status | NEW |
| Version | git |
| Component | Drivers/Gallium/radeonsi |
| Product | Mesa |
No matter what program I run, the clock of the GPU stays: # cat /sys/kernel/debug/dri/*/radeon_pm_info power level avg sclk: 30000 mclk: 15000 power level avg sclk: 30000 mclk: 15000 The attached screenshot shows Portal 2 with a GALLIUM_HUD=3Dfps overlay. Th= e ~30 FPS are in the menu, the 8-15 FPS are in the level. My stack is (base: Debian Testing): GPU: Hawaii PRO [Radeon R9 290] (ChipID =3D 0x67b1) Linux: Git:~agdf5/linux:drm-next-3.17-rebased-on-fixes:fa78380797 (calls it= self 3.16-rc6) Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/ucode.tar.g= z> > 9e05820da42549ce9c89d147cf1f8e19 /lib/firmware/= updates/3.16.0-rc6-citadel/radeon/hawaii_ce.bin > c8bab593090fc54f239c8d7596c8d846 /lib/firmware/updates/3.16.0-rc6-cit= adel/radeon/hawaii_mc.bin > 3618dbb955d8a84970e262bb2e6d2a16 /lib/firmware/updates/3.16.0-rc6-cit= adel/radeon/hawaii_me.bin > c000b0fc9ff6582145f66504b0ec9597 /lib/firmware/updates/3.16.0-rc6-cit= adel/radeon/hawaii_mec.bin > 0643ad24b3beff2214cce533e094c1b7 /lib/firmware/updates/3.16.0-rc6-cit= adel/radeon/hawaii_pfp.bin > ba6054b7d78184a74602fd81607e1386 /lib/firmware/updates/3.16.0-rc6-cit= adel/radeon/hawaii_rlc.bin > 11288f635737331b69de9ee82fe04898 /lib/firmware/updates/3.16.0-rc6-cit= adel/radeon/hawaii_sdma.bin > 284429675a5560e0fad42aa982965fc2 /lib/firmware/updates/3.16.0-rc6-cit= adel/radeon/hawaii_smc.bin libdrm: Git:master/libdrm-2.4.56 LLVM: SVN:trunk/r214546 (3.6 snapshot) libclc: Git:master/5b48f170c8 Mesa: Git:master/e41cc45361 DDX: Git:master/fbf575cb01 + Patch from http://lists.x.org/archives/xorg-driver-ati/2014-August/026534.html X: 2:1.16.0-1 (1.16.0) Let me know, if you need further information (current Xorg.0.log (attachment 103995 [details]), dmesg (at= tachment 103996 [details]) and glxinfo (attachment 103997 [details]) can be fou= nd attached to bug 82055).
Since the image was a bit too large, I can't attach it here. You can find the screenshot at at http://imgur.com/vFBfQpQ
Please attach your dmesg output with radeon.dpm=1 set on the kernel command line in grub. That dumps some additional debugging output. Also please attach a copy of your vbios. (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/<pci bus id> echo 1 > rom cat rom > /tmp/vbios.rom echo 0 > rom
Created attachment 104081 [det= ails] VBIOS from (In reply to comment #2) > Please attach your dmesg output with radeon.dpm= =3D1 set on the kernel command > line in grub. That dumps some additional debugging output. I'll reboot later and attach that dmesg, I'm currently bisecting X for bug 82055. > Also please attach a copy of your vbios. Here you go. Below you find the lspci output, maybe you can reach out to XFX directly, if that should help: > 01:00.0 VGA compatible controller: Advanced Micr= o Devices, Inc. [AMD/ATI] Hawaii PRO [Radeon R9 290] (prog-if 00 [VGA contr= oller]) > Subsystem: XFX Pine Group Inc. Device 9295 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- Pa= rErr- Stepping- SERR- FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TA= bort- <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 45 > Region 0: Memory at e0000000 (64-bit, prefetchable) [size=3D25= 6M] > Region 2: Memory at f0000000 (64-bit, prefetchable) [size=3D8M] > Region 4: I/O ports at e000 [size=3D256] > Region 5: Memory at f7e00000 (32-bit, non-prefetchable) [size= =3D256K] > Expansion ROM at f7e40000 [disabled] [size=3D128K] > Capabilities: [48] Vendor Specific Information: Len=3D08 <?= > > Capabilities: [50] Power Management version 3 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=3D0mA PME(D0-,D= 1+,D2+,D3hot+,D3cold-) > Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0 = 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 256 bytes, MaxReadReq 512 bytes > DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPw= r- TransPend- > LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, = Exit Latency L0s <64ns, L1 <1us > ClockPM- Surprise- LLActRep- BwNot- > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- > LnkSta: Speed 8GT/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: 8GT/s, EnterCompliance- Sp= eedDis- > Transmit Margin: Normal Operating Range, Ente= rModifiedCompliance- ComplianceSOS- > Compliance De-emphasis: -6dB > LnkSta2: Current De-emphasis Level: -3.5dB, Equalizati= onComplete+, EqualizationPhase1+ > EqualizationPhase2+, EqualizationPhase3+, Lin= kEqualizationRequest- > Capabilities: [a0] MSI: Enable+ Count=3D1/1 Maskable- 64bit+ > Address: 00000000fee00358 Data: 0000 > Capabilities: [100 v1] Vendor Specific Information: ID=3D0001 = Rev=3D1 Len=3D010 <?> > Capabilities: [150 v2] Advanced Error Reporting > UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCm= plt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- > UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCm= plt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- > UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCm= plt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- > CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- Non= FatalErr+ > CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- Non= FatalErr+ > AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCa= p+ ChkEn- > Capabilities: [270 v1] #19 > Capabilities: [2b0 v1] Address Translation Service (ATS) > ATSCap: Invalidate Queue Depth: 00 > ATSCtl: Enable-, Smallest Translation Unit: 00 > Capabilities: [2c0 v1] #13 > Capabilities: [2d0 v1] #1b > Kernel driver in use: radeon
| What | Removed | Added |
|---|---|---|
| Attachment #104081 description | VBIOS from | VBIOS from XFX R9-290A-EDBD |
Created attachment 104094 [details] dmesg with radeon.dpm=1 set Here you go. The last power state entry in dmesg is: > switching from power state: > ui class: performance > internal class: none > caps: > uvd vclk: 0 dclk: 0 > power level 0 sclk: 30000 mclk: 15000 pcie gen: 3 pcie lanes: 16 > power level 1 sclk: 98000 mclk: 125000 pcie gen: 3 pcie lanes: 16 > status: c r > switching to power state: > ui class: performance > internal class: none > caps: > uvd vclk: 0 dclk: 0 > power level 0 sclk: 30000 mclk: 15000 pcie gen: 3 pcie lanes: 16 > power level 1 sclk: 98000 mclk: 125000 pcie gen: 3 pcie lanes: 16 > status: c r
Are you checking radeon_pm_info while the app is running? E.g., via ssh or via another X terminal? If you switch to another VT or something like that there will not be any activity. Can you try is with something simple like glxgears? E.g., run `vblank_mode=0 glxgears -fullscreen` and then check radeon_pm_info via ssh while gears is running.
(In reply to comment #5) > Are you checking radeon_pm_info while the app is running? E.g., via ssh or > via another X terminal? If you switch to another VT or something like that > there will not be any activity. Can you try is with something simple like > glxgears? E.g., run `vblank_mode=0 glxgears -fullscreen` and then check > radeon_pm_info via ssh while gears is running. I've always checked through SSH from a second machine. Now for your glxgears test: reclocking works (in Portal 2 as well, where I get 58-60 FPS now). The only difference is the radeon.dpm=1 on the kernel command line. Was that expected? I thought DPM was activated automatically with your 3.17 branch (it says so during boot as well, see e.g. attachment 103996 [details]) or at least I interpreted the "[drm] radeon: dpm initialized" line that way. As far as I'm concerned this can be closed, though the radeon man page should probably get a line like "setting radeon.dpm=1 is mandatory for reclocking on the following ASICs". I let you decide whether this is something that should have happend automatically (my preference) or that requires the kernel parameter and close/keep the report accordingly.
Are(In reply to comment #6) > Now for your glxgears test: reclocking works (in Portal 2 as well, where I > get 58-60 FPS now). The only difference is the radeon.dpm=1 on the kernel > command line. Are you absolutely sure you need radeon.dpm=1 ? Reclocking works here (R9 290X) without it. I just rechecked and I don't have it on my kernel command line (new "drm-next-3.17" branch). Nor do I have it anywhere in /etc.
dpm is enabled by default for hawaii asics. You shouldn't need to force it on the command line. forcing it just enabled additional debugging output.
(In reply to comment #7) > Are(In reply to comment #6) > > Now for your glxgears test: reclocking works (in Portal 2 as well, where I > > get 58-60 FPS now). The only difference is the radeon.dpm=1 on the kernel > > command line. > > Are you absolutely sure you need radeon.dpm=1 ? Yes. > Reclocking works here (R9 > 290X) without it. I just rechecked and I don't have it on my kernel command > line (new "drm-next-3.17" branch). Nor do I have it anywhere in /etc. If unsure with what you've booted, look at dmesg, one of the first lines looks like: > Command line: BOOT_IMAGE=/vmlinuz-3.16.0-rc6-citadel root=/dev/mapper/citadel--vg-vol--root ro quiet radeon.dpm=1
(In reply to comment #8= ) > dpm is enabled by default for hawaii asics. You= shouldn't need to force it > on the command line. forcing it just enabled additional debugging out= put. I can only state, that by setting radeon.dpm=3D1 I get 60 FPS in e.g. Porta= l 2 and without I'm at 15 FPS max. As written in comment #0, I've built your drm-next-3.17-rebased-on-fixes branch, my top commit is commit fa783807977da98da35590fd1d5efdfd4f33fd59 Author: Christian K=C3=B6nig <christian.koenig@amd.com> Date: Mon Jul 28 13:30:12 2014 +0200 drm/radeon: allow userptr write access under certain conditions It needs to be anonymous memory (no file mappings) and we are requried to install an MMU notifier. Signed-off-by: Christian K=C3=B6nig <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> I even went through several reboots, switching between "with radeon.dp= m=3D1" and without. All showed the same result. Let me know, if there is something els= e, I can do to assist in debugging this.
Created attachment 104101 [details] [review] enable dpm=1 debugging even when dpm is not forced This patch enables the additional dpm debugging output even when it is not explictly set on the command line. Does it help? The only thing I can figure is that the debugging output adds a small delay that may have a positive impact.
Created attachment 104103 [details] dmesg output with attachment 104101 [details] [review] and no "radeon.dpm=1" set
Created attachment 104104 [details] dmesg output with attachment 104101 [details] [review] and "radeon.dpm=1" set
Did it help? With the patch applied, the behavior of the driver is identical whether or not you append radeon.dpm=1 to your kernel command line.
(In reply to comment #11) > Created attachment 104101 [details] [review] [review] > enable dpm=1 debugging even when dpm is not forced > > This patch enables the additional dpm debugging output even when it is not > explictly set on the command line. Does it help? The only thing I can > figure is that the debugging output adds a small delay that may have a > positive impact. You're not going to like this. But setting radeon.dpm=1 must have some other side effect. I booted each configuration represent by attachment 104103 [details] and attachment 104104 [details] two times. The first (104103) is the stack from comment #0 plus the patch from attachment 104101 [details] [review] applied to the kernel, then booted without radeon.dpm=1 (see the dmesg output for the kernel command line). When I start Portal 2 I stay at the numbers reported in comment #0 (ie. at low FPS). If I boot the stack from comment #0 with the patch from attachment 104101 [details] [review] applied to the kernel and DO set radeon.dpm=1 on the kernel command line (see second dmesg output; 104104), then I get 60 FPS in Portal 2.
I don't have any other ideas off hand. That patch represents is the only difference explicitly setting that parameter changes.
(In reply to comment #= 15) > I booted each configuration represent by attachment 104103 [details] and attachment 104104= [details] two times. Just to clarify: the boot and testing order was: rebooting into configuration 104103 =E2=86=92 starting Portal 2 with GALLIU= M_HUD=3Dfps =E2=86=92 verifying FPS in level as low =E2=86=92 powering off booting configuration 104104 =E2=86=92 starting Portal 2 with GALLIUM_HUD= =3Dfps =E2=86=92 verifying FPS in level as high =E2=86=92 powering off booting configuration 104103 =E2=86=92 starting Portal 2 with GALLIUM_HUD= =3Dfps =E2=86=92 verifying FPS in level as low =E2=86=92 rebooting into configuration 104104= =E2=86=92 starting Portal 2 with GALLIUM_HUD=3Dfps =E2=86=92 verifying FPS in level as high
(In reply to comment #16) > I don't have any other ideas off hand. That patch represents is the only > difference explicitly setting that parameter changes. Ok, no problem; I just keep the radeon.dpm=1 around and I'm going to be happy, I hope. But I guess we should keep this bug open, until we find the cause? Maybe we should change the title to something like "reclocking only with radeon.dpm=1 set"? But that's all your call.
(In reply to comment #18) > (In reply to comment #16) > > I don't have any other ideas off hand. That patch represents is the only > > difference explicitly setting that parameter changes. > > Ok, no problem; I just keep the radeon.dpm=1 around and I'm going to be > happy, I hope. But I guess we should keep this bug open, until we find the > cause? Maybe we should change the title to something like "reclocking only > with radeon.dpm=1 set"? But that's all your call. Yeah, let's keep it open for now. Maybe we'll get more useful feedback once more people start testing hawaii.
(In reply to comment #19) > Maybe we'll get more useful feedback once more people start testing hawaii. That sounds like I failed to provide something? If you have any request, what I should check, just let me know. Ie. trying a different compiler?