Re: [PATCH 00/25] Fix FBC for real

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Wed, Jun 18, 2014 at 10:03:27PM +0200, Daniel Vetter wrote:
> On Wed, Jun 18, 2014 at 08:58:33PM +0300, ville.syrjala@linux.intel.com wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > This series rewrites the FBC code to actually work. It utilizes the
> > hardware tracking/nuking as much as possible, eg. relying on hardware
> > nuke on flip when possible.
> > 
> > I also introduce the generic ring and vblank notifier gizmos which could
> > be used for various other things. I already included a patch to convert
> > the IPS enable to be asynchronous by using the vblank notifier. Other
> > users for thse could be mmio flips, watermark programming, atomic
> > gamma/color correction (single buffered registers all) updates from vblank
> > interrupt, etc.
> > 
> > There's also a rather big behavioural change that FBC now stays enabled
> > even when multiple pipes are active. FBC just automatially migrates to
> > the primary plane where it's deemed most beneficial. We do that
> > determination by looking at the rate at which the plane is pulling data
> > (pixel rate * cpp). That seems like a reasonable choice all else being
> > equal. Eventually we might want to adjust the FBC score based on
> > nuke/invalidate frequency as well.
> > 
> > The locking now has a new fbc.mutex. I had to split the page flip code
> > apart a bit to accomondate. I'm not entirely sure if it wouldn't be
> > better to just keep struct_mutex locked all through there, but then
> > I'd need rework the locking in the fbc code to not take struct_mutex
> > when called from the page flip code. And then I'd have to start
> > questioning whether fbc.mutex has any point existing.
> > 
> > I pushed the lot here:
> > git://gitorious.org/vsyrjala/linux.git fbc_update_thing_14
> 
> Just very cursory look at it, but this conflicts badly (well the
> integration with the driver) with my frontbuffer tracking stuff. My idea
> was to essentially hide all the fbc integration points we have sprinkled
> all over behind that one and maybe even switch to manual invalidation for
> gt rendering with a cpu register write and ditch all the complexity we
> have with injecting cmds into rings right now.

Well yeah if you want to kill the hardware tracking entirely the end
result ought to have less code, especially since psr needs the software
tracking anyway. Although on certain (older) platforms you can't really
turn off the hardware tracking, so the software tracking is somewhat
pointless.

Anyways, I think you're going to have to find another sucker to do that
work if you want to go that way. I don't think I'll have time for major
redesigns until maybe next year.

-- 
Ville Syrjälä
Intel OTC