[PATCH] drm/amdgpu/gfx9: switch to golden tsc registers for raven/raven2

[Alex Deucher]

On Mon, May 29, 2023 at 5:45 AM Michel Dänzer <michel at daenzer.net> wrote:
>
> On 4/12/23 03:23, Zhang, Jesse(Jie) wrote:
> >
> >   Due to raven/raven2 maybe enable  sclk slow down,
> >     they cannot get clock count by the RLC at the auto level of dpm performance.
> >     So switch to golden tsc register.
>
> At least on this ThinkPad E595 with Picasso, the issue with this change (and the corresponding fbc24293ca16 "drm/amdgpu: change the reference clock for raven/raven2" & 9d2d1827af29 "drm/amdgpu: Differentiate between Raven2 and Raven/Picasso according to revision id") is that the GPU timestamps reported via the AMDGPU_INFO ioctl are no longer consistent with those reported via asynchronous GPU queries (e.g. via glQuery with GL_TIMESTAMP). The latter are still affected by clock changes, and even when the clock doesn't stop altogether, they still tick at 25 MHz, so the two kinds of GPU timestamps keep diverging further.
>

fbc24293ca16 "drm/amdgpu: change the reference clock for raven/raven2"
would also affect that.  Were you seeing the same results with that
patch as well?

Alex


> This makes it impossible to determine the wall clock time at which a certain GPU job finished. GNOME's mutter uses this for adaptive frame scheduling.
>
> You can see the issue with the piglit test arb_timer_query-timestamp-get or with the Vulkan CTS tests dEQP-VK.pipeline.monolithic.timestamp.calibrated.*. (Note that some of these tests could already fail before with GFXOFF enabled, the symptoms are slightly different though)
>
>
> An ideal long-term solution for this might be to modify the GPU microcode to use the golden registers for asynchronous timestamp queries as well.
>
> In the meantime though, these changes need to be reverted for 6.4, at least for Picasso.
>
>
> --
> Earthling Michel Dänzer            |                  https://redhat.com
> Libre software enthusiast          |         Mesa and Xwayland developer
>