On Wed, Oct 27, 2021 at 06:41:25AM +0000, Kasireddy, Vivek wrote:
> Hi Ville,
>
> >
> > On Mon, Oct 25, 2021 at 11:38:11PM -0700, Vivek Kasireddy wrote:
> > > On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
> > > more framebuffers/scanout buffers results in only one that is mappable/
> > > fenceable. Therefore, pageflipping between these 2 FBs where only one
> > > is mappable/fenceable creates latencies large enough to miss alternate
> > > vblanks thereby producing less optimal framerate.
> > >
> > > This mainly happens because when i915_gem_object_pin_to_display_plane()
> > > is called to pin one of the FB objs, the associated vma is identified
> > > as misplaced and therefore i915_vma_unbind() is called which unbinds and
> > > evicts it. This misplaced vma gets subseqently pinned only when
> > > i915_gem_object_ggtt_pin_ww() is called without the mappable flag. This
> > > results in a latency of ~10ms and happens every other vblank/repaint cycle.
> > >
> > > Testcase:
> > > Running Weston and weston-simple-egl on an Alderlake_S (ADLS) platform
> > > with a 8K@60 mode results in only ~40 FPS. Since upstream Weston submits
> > > a frame ~7ms before the next vblank, the latencies seen between atomic
> > > commit and flip event is 7, 24 (7 + 16.66), 7, 24..... suggesting that
> > > it misses the vblank every other frame.
> > >
> > > Here is the ftrace snippet that shows the source of the ~10ms latency:
> > > i915_gem_object_pin_to_display_plane() {
> > > 0.102 us | i915_gem_object_set_cache_level();
> > > i915_gem_object_ggtt_pin_ww() {
> > > 0.390 us | i915_vma_instance();
> > > 0.178 us | i915_vma_misplaced();
> > > i915_vma_unbind() {
> > > __i915_active_wait() {
> > > 0.082 us | i915_active_acquire_if_busy();
> > > 0.475 us | }
> > > intel_runtime_pm_get() {
> > > 0.087 us | intel_runtime_pm_acquire();
> > > 0.259 us | }
> > > __i915_active_wait() {
> > > 0.085 us | i915_active_acquire_if_busy();
> > > 0.240 us | }
> > > __i915_vma_evict() {
> > > ggtt_unbind_vma() {
> > > gen8_ggtt_clear_range() {
> > > 10507.255 us | }
> > > 10507.689 us | }
> > > 10508.516 us | }
> > >
> > > Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx>
> > > Cc: Manasi Navare <manasi.d.navare@xxxxxxxxx>
> > > Signed-off-by: Vivek Kasireddy <vivek.kasireddy@xxxxxxxxx>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_fb_pin.c | 11 +++++++++--
> > > drivers/gpu/drm/i915/display/intel_overlay.c | 11 ++++++++---
> > > drivers/gpu/drm/i915/gem/i915_gem_domain.c | 6 ++++--
> > > drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 ++-
> > > 4 files changed, 23 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c
> > b/drivers/gpu/drm/i915/display/intel_fb_pin.c
> > > index 3f77f3013584..53c156d9a9f9 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
> > > @@ -144,7 +144,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
> > >
> > > if (!ret) {
> > > vma = i915_gem_object_pin_to_display_plane(obj, &ww, alignment,
> > > - view, pinctl);
> > > + view, pinctl, uses_fence);
> > > if (IS_ERR(vma)) {
> > > ret = PTR_ERR(vma);
> > > goto err_unpin;
> > > @@ -218,9 +218,16 @@ int intel_plane_pin_fb(struct intel_plane_state *plane_state)
> > > INTEL_INFO(dev_priv)->display.cursor_needs_physical;
> > >
> > > if (!intel_fb_uses_dpt(fb)) {
> > > + struct intel_crtc *crtc = to_intel_crtc(plane_state->hw.crtc);
> > > + struct intel_crtc_state *crtc_state =
> > > + to_intel_crtc_state(crtc->base.state);
> > > + bool uses_fence = intel_plane_uses_fence(plane_state);
> > > + bool is_bigjoiner = crtc_state->bigjoiner ||
> > > + crtc_state->bigjoiner_slave;
> >
> > Bigjoiner is just an implementation detail. It is not the cause of any
> > of this.
> [Kasireddy, Vivek] Right, bigjoiner/8K is just exposing the underlying issue; which is
> that sometimes, large objects/scanout buffers that fail range overflow checks and thus
> are not mappable/fenceable keep getting evicted and reinserted leading to latencies.
> I guess I could mark an object/vma as permanently un-mappable/un-fenceable and try
> not to map it subsequently but this would result in one scanout buffer that is mappable
> but others that are not. Would this be acceptable -- assuming we are pageflipping
> between multiple FBs?
> Any ideas on solving this issue cleanly?
We might just consider skipping PIN_MAPPABLE if the vma is too big.
What the specific defition of "too big" would be I'm not sure.
--
Ville Syrjälä
Intel
