| 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 simple "Atlas Demo Scene" in the Destinations SteamVR app: https://www.youtube.com/watch?v=U_mceDSBF7o With the "auto" setting the GPU power level is not set high enough 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 "total" GPU time taken to render one frame in the app and then display it in the compositor 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.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
