(just noticed mutt behind tsocks missed this email) On Wed, Nov 6, 2013 at 1:02 PM, <ville.syrjala@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
