Quoting Ville Syrjälä (2020-12-03 12:45:43) > On Wed, Dec 02, 2020 at 09:28:09PM +0000, Chris Wilson wrote: > > Since we try and estimate how long we require to update the registers to > > perform a plane update, it is of vital importance that we measure the > > distribution of plane updates to better guide our estimate. If we > > underestimate how long it takes to perform the plane update, we may > > slip into the next scanout frame causing a tear. If we overestimate, we > > may unnecessarily delay the update to the next frame, causing visible > > jitter. > > > > Replace the warning that we exceed some arbitrary threshold for the > > vblank update with a histogram for debugfs. > > > > v2: Add a per-crtc debugfs entry so that the information is easier to > > extract when testing individual CRTC, and so that it can be reset before > > a test. > > > > v3: Flip the graph on its side; creates space to label the time axis. > > > > Updates: 4684 > > | > > 1us | > > | > > 4us |******** > > |********** > > 16us |*********** > > |***** > > 66us | > > | > > 262us | > > | > > 1ms | > > | > > 4ms | > > | > > 17ms | > > | > > Going that high feels a bit overkill to me. I'd be satisified > with an upper limit of <1ms or something. I thought 16ms was overkill, but looking at the results, we do get some delays >1ms (but not raising an error for missing the start of vblank). I capped it there just in case there is a bug where we wait for a whole vblank, which is about as severe a bug as one might expect. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
