On 5/31/23 16:01, Alex Deucher wrote: > 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?
Yes. That one is problematic because user space uses the reference clock for converting the results of asynchronous GPU queries from clock ticks to seconds. Since that clock still ticks at 25 MHz, the computed values in seconds are incorrect and keep diverging further from the corresponding values from the AMDGPU_INFO ioctl. >> 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. Any thoughts on whether or not this might be feasible? >> 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
