On Mon, May 29, 2023 at 5:45 AM Michel Dänzer <[email protected]> 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 >
