[Intel-gfx] [PATCH 00/10] drm/i915: FBC fixes v2

[Rodrigo Vivi]

(just noticed mutt behind tsocks missed this email)

On Wed, Nov 6, 2013 at 1:02 PM,  <ville.syrjala at linux.intel.com> wrote:
> One more attempt at making FBC suck a bit less.
>
> The main thing as before is getting the LRI based render/blitter
> tracking in place.
>
> In this updates series I decided the way to avoid the kms locks in
> execbuffer is to keep an extra reference to the fb.
>
> I added a bunch of locking (struct_mutex and crtc->mutex) to some
> places to hopefully make it bit less racy. I think/hope that it doesn't
> make it more likely to deadlock. We do grab both locks in the fbc work
> now, and we do cancel the work while holding at least one of the locks,
> so it seems a bit bad. But we cancel the work in a lazy fashion (no _sync
> or anything) so I don't think it should deadlock due to that. And we
> already grabbed struct_mutex there anyway, and we already held it while
> cancelling the work, so it's no worse at least :P
>
> The disable_fbc/update_fbc calls from the page flip code are lacking
> kms lock protection, but we can't simply add it there due to possibility
> of deadlocks.
>
> So at least the render/blitter tracking seems to work now without
> upsetting lockdep, so it seems a bit better than what we had at least.
> Maybe someone else will get inspired by this and fix this mess up for
> real...
>
> I've only run this on my IVB, and just running X + some apps w/o
> a compositor. No extensive tests or anything. But if I frob some
> debug register to disable some tracking bits the screen gets
> corrupted, so it seems to be doing its job.
>
> I pushed it here in case someone is interested in a git tree:
> git://gitorious.org/vsyrjala/linux.git fbc_fixes

I did quick test here on my IVB as well and everything worked fine.
I was afraid that this could regress 1 bug on gnome environment fixed
by that lri but it didn't! :)

Also I think this series fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=65396

And if I'm wrong about not any and all frontbuffer rend this also
closes jira 3018.

Besides that: Some time ago I started a fbc rework getting it tied to
pipe_config, but than Daniel suggested that maybe it would be better
to put fbc and psr in new plane_config you were doing instead of
pipe_config. What do you think about it?
And what the latest on plane_config?

Thanks,
Rodrigo.

>
> Ville Syrjälä (10):
>       drm/i915: Use plane_name() in gen7_enable_fbc()
>       drm/i915: Grab struct_mutex around all FBC updates
>       drm/i915: Have FBC keep references to the fb
>       drm/i915: Grab crtc->mutex in intel_fbc_work_fn()
>       drm/i915: Limit FBC flush to post batch flush
>       drm/i915: Emit SRM after the MSG_FBC_REND_STATE LRI
>       drm/i915: Implement LRI based FBC tracking
>       drm/i915: Kill sandybridge_blit_fbc_update()
>       drm/i915: Don't write ILK/IVB_FBC_RT_BASE directly
>       drm/i915: Set has_fbc=true for all SNB+, except VLV
>
>  drivers/gpu/drm/i915/i915_drv.c            |  6 +-
>  drivers/gpu/drm/i915/i915_drv.h            |  6 +-
>  drivers/gpu/drm/i915/i915_gem_context.c    |  7 +++
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 31 ++++++++++
>  drivers/gpu/drm/i915/i915_reg.h            |  1 +
>  drivers/gpu/drm/i915/intel_display.c       | 27 +++++++-
>  drivers/gpu/drm/i915/intel_drv.h           |  1 +
>  drivers/gpu/drm/i915/intel_pm.c            | 98 ++++++++++++++++--------------
>  drivers/gpu/drm/i915/intel_ringbuffer.c    | 66 ++++++++++++++++++--
>  drivers/gpu/drm/i915/intel_ringbuffer.h    |  2 +
>  10 files changed, 188 insertions(+), 57 deletions(-)
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br