| Bug ID | 100742 |
|---|---|
| Summary | dpm auto doesn't clock the GPU high enough for SteamVR apps |
| Product | DRI |
| Version | unspecified |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | haagch@frickel.club |
RX 480, Ryzen 1600X, tested on linux 4.10 and linux drm-next-4= .12-wip, latest upstream linux-firmware git. Same behavior on both kernels. I recorded this video, showing umr top, sclk and mclk, while running the si= mple "Atlas Demo Scene" in the Destinations SteamVR app: https://www.youtu= be.com/watch?v=3DU_mceDSBF7o With the "auto" setting the GPU power level is not set high enoug= h for SteamVR to render at the Vive's native 90 fps, so reprojection (interpolation to 90 fps) needs to kick in constantly. Speculation time: The SteamVR frametime graph shows the purple GPU load from the application ("Destinations") completely below the 11 ms which the application= is probably is probably targeting, so dpm has clocked the GPU fast enough for the application to run at 90 fps. But then the application submits frames to the SteamVR compositor which also takes some GPU time and pushes the "tota= l" GPU time taken to render one frame in the app and then display it in the compos= itor over the target 11 ms time. Is this correct? Does dpm somehow analyze a per process GPU load? At least = in this case the GPU needs to clock fast enough to allow the application + the SteamVR compositor to both render in under 11 ms per frame.
I can observe the same behaviour. Setting power_dpm_force_perf= ormance_level to high reduces ans smoothes out the StreamVr Compositor frame timings. Even w= hen no "real" app is running (so just the basic space you get when la= unching) Arch Linux RX 480 i7 3770k 4.11.7-1-ck Mesa git from 2017-07-03
maybe my bug is a dupe from this https://bugs.freedesktop.org/show_bug.= cgi?id=3D101749 i notice that we all have a RX480... does other AMDGPU cards also have this= or is the problem only related with this hardware?
I think we probably need to add a new op to the context ioctl =
to allow the
application to request a floor for a specific clock (sclk, mclk, dclk, eclk,
etc.) so that the application can override the natural dynamic selection do=
ne
by the smu. Then when commands from that specific context are scheduled, t=
he
kernel driver can force a higher floor for whichever clocks are requested.<=
/pre>
The situation has massively improved since I opened this issue= at least with very recent kernels.=20 I'm hesitant to close it, at least not before doing some testing to see if = it can still be reproduced.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | MOVED |
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this = link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/157.