On Wed, Oct 20, 2021 at 5:40 PM Sean Paul <sean@xxxxxxxxxx> wrote: > On Wed, Oct 20, 2021 at 04:17:28PM -0700, Brian Norris wrote: > > Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"), > > "PSR disable" used non-blocking analogix_dp_send_psr_spd(). The refactor > > accidentally (?) set blocking=true. > > IIRC this wasn't accidental. > > The reason it became synchronous was: > - To avoid racing a subsequent PSR entry (if exit takes a long time) How did this work pre-commit-6c836d965bad then? I don't see any provision for avoiding subsequent PSR entry. Or I guess that was implicitly covered by PSR_FLUSH_TIMEOUT_MS, which means we allowed at least 100ms between exit/entry each time, which was good enough? And in the "new" implementation, that turned into a running average that gets measured on each commit? So we're no longer guaranteed 100ms, and it's even worse if we cheat the timing measurement? I'm still not sure that "race" is truly a problem without consulting some kind of hardware documentation though. It wouldn't surprise me if these things are cancelable. > - To avoid racing disable/modeset > - We're not displaying new content while exiting PSR anyways, so there is > minimal utility in allowing frames to be submitted > - We're lying to userspace telling them frames are on the screen when we're > just dropping them on the floor > > The actual latency gains from doing this synchronously are minimal since the > panel will display new content as soon as it can regardless of whether the > kernel is blocking. There is likely a perceptual difference, but that's only > because kernel is lying to userspace and skipping frames without consent. Hmm, you might well be right about some of the first points (I'm still learning the DRM framework), but I'm a bit skeptical that the perceptual difference is "only" because we're cheating in some way. I'm not doing science here, and it's certainly not a blinded test, but I'm nearly certain this patch cuts out approx 50-80% of the cursor lag I see without this patch (relative to the current Chrome OS kernel). I don't see how cheating would produce a smoother cursor movement -- we'd still be dropping frames, and the movement would appear jumpy somewhere along the way. In any case, I'm absolutely certain that mainline Linux performs much much worse with PSR than the current CrOS kernel, but there are some other potential reasons for that, such as the lack of an input-notifier [1]. > Going back to the first line, it's entirely possible my memory is failing > and this was accidental! Well either way, thanks for the notes. I'll see if I can get anywhere on proving/disproving that they are relevant, or if they can be worked around some other way; or perhaps I can regain the lost performance some other way. It'll be a few days before I get around to that. Brian [1] This got locked up in "controversy": https://patchwork.kernel.org/project/linux-arm-kernel/patch/20180405095000.9756-25-enric.balletbo@xxxxxxxxxxxxx/