[Intel-gfx] [PATCH 00/15] Accurate frontbuffer tracking and psr conversion

[Chris Wilson]

On Mon, Jun 16, 2014 at 07:51:20PM +0200, Daniel Vetter wrote:
> Hi all,
> 
> This patch series adds accurate frontbuffer tracking to i915 and then converts
> psr over to use. Bunch of things still need to be done.
> 
> - PSR needs to be re-tested. I lack the hardware for that. The frontbuffer
>   tracking itself is tested.
> 
> - PSR igt testcase needs to be extended so that we cover all upload methods on
>   all plane types.
> 
> - DRRS/downclocking needs to be unified and put into this framework properly.
>   Also needs proper locking for all of the DRRS state.
> 
> - fbc also needs to be fixed up, with state handling properly split between
>   crtc_enable/disable, primary fb updates and the fb tracking for nuking. A bit
>   unclear how we want to integrate gtt cpu write tracking through the hw, since
>   that seems to be the hw tracking piece that actually works.
> 
> General blueprint for display runtime power saving features:
> - Have all your state in either intel_crtc or dev_priv, protected by its own
>   lock.
> 
> - Do state setup in crtc_enable, cleanup in crtc_disable with a pair of
>   enable/disable fuctions. Optionally update everywhere else you want (e.g.
>   primary plane updates for fbc). Not state setup anywhere else allowed, except
>   maybe an _init for setting up work items, locks, ...
> 
> - Intercept the invalidation/flush signals you need like
>   psr_invalidate/psr_flush. Track internally which frontbuffer bits you're
>   interested in and invalidate/flush accordingly. You can also use these for
>   workarounds (e.g. on hsw we force-flush for sprite changes since the flip
>   signal doesn't result in a hw image upload).
> 
> 
> Note that currently the gtt tracking has a bit a gap: We never exit it. Bunch of
> fixes are possible:
> - Wire up the core dirty_fb ioctl to flush framebuffers. This is used by generic
>   userspace to flush dummy buffers, which in our case means gtt mmaps. So maps
>   perfectly.
> 
> - Do a delayed gtt pte teardown and force-flush. Probably too ugly to care
>   really.
> 
> - Try to integrate hw gtt write tracking logic. Note that current psr code
>   doesn't rely on this - I've killed the X-tiled checks completely.
> 
> Big thanks to Chris for some great ideas for the fb tracking scheme and the
> precise placement of the invalidate/flush functions.
> 
> Comments, flames and especially testing on psr hardware highly welcome.

I like it. I think this is a big step in the right direction, and
doesn't look too intrusive to normal operations. I would like to get
Ville's FBC tracking on top so we check for any idiosynacracies we may
have missed.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre