[Bug 100742] dpm auto doesn't clock the GPU high enough for SteamVR apps

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100742

Martin Peres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |MOVED

--- Comment #5 from Martin Peres  ---
-- 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100742] dpm auto doesn't clock the GPU high enough for SteamVR apps

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100742

--- Comment #4 from Christoph Haag  ---
The situation has massively improved since I opened this issue at least with
very recent kernels. 

I'm hesitant to close it, at least not before doing some testing to see if it
can still be reproduced.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100742] dpm auto doesn't clock the GPU high enough for SteamVR apps

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100742

--- Comment #3 from Alex Deucher  ---
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 done
by the smu.  Then when commands from that specific context are scheduled, the
kernel driver can force a higher floor for whichever clocks are requested.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100742] dpm auto doesn't clock the GPU high enough for SteamVR apps

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100742

--- Comment #2 from higu...@gmx.net ---
maybe my bug is a dupe from this
https://bugs.freedesktop.org/show_bug.cgi?id=101749

i notice that we all have a RX480... does other AMDGPU cards also have this or
is the problem only related with this hardware?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100742] dpm auto doesn't clock the GPU high enough for SteamVR apps

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100742

--- Comment #1 from Felix Hellmann  ---
I can observe the same behaviour. Setting power_dpm_force_performance_level to
high reduces ans smoothes out the StreamVr Compositor frame timings. Even when
no "real" app is running (so just the basic space you get when launching)

Arch Linux
RX 480
i7 3770k
4.11.7-1-ck
Mesa git from 2017-07-03

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100742] dpm auto doesn't clock the GPU high enough for SteamVR apps

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100742

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: haa...@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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel