[Intel-gfx] [PATCH 1/3] drm/i915: Enable FBC at Haswell.

[Daniel Vetter]

On Wed, Apr 10, 2013 at 10:18 AM, Ville Syrjälä
<ville.syrjala at linux.intel.com> wrote:
>> > > +     dpfc_ctl |= (HSW_DPFC_CTL_FENCE_EN | obj->fence_reg);
>> >
>> > The CPU fence field must be written with 0. SNB/IVB could do with the
>> > same fix.
>> >
>>
>> Where did you get this restriction for HSW?
>
> BSpec.
>
>> Should we write 0 or not touch
>> by removing lis line?
>
> Not sure. The spec doesn't say whether the "CPU fence enable" bit still
> has some meaning or not. I guess the safe approach would be to set the
> fence to 0 and only set the fence enable bit when we actually have a
> fence.
>
> BTW the whole dpfc_ctl handing seems to a bit broken. You're doing it
> via RMW, but you're not clearing the fields that you modify. So you
> could be just ORing bits to whatever garbage the register had before.

Ok, I guess it's time for me to write down the fbc master plan here ;-)

So imo psr and fbc fit into the exact same category: Both safe a bit
of power if the display contents doesn't change. And for both we need
to know when contents has changed so that we can either disable it or
through some hw magic update screen contents. So imo we can (and
should) wire up all the psr magic into the same
intel_enable/disable_fbc functions.

Now on platforms thus far the power savings part of fbc worked usually
rather well, real ugliness kicked in when trying to enable the hw
magic to detect display contents changes. The hw supplies three pieces
for that:
- cpu fence to detect writes from the cpu through the gtt
- blt fbc range - each time the blt touches anything in there fbc gets a note
- render fbc range - same
- pageflips send a signal to fbc/psr to update screen

Those above three things are usually riddled with workarounds, tend to
hang the box (or as in the case of the gen6 blitter) totally kill
throughput when enabled. The only thing which seems to work is the
pageflip stuff.

So my proposal is that before we enable anything like fbc or psr by
default, we can all this hw magic. Completely.

And then we replace it with some nice software tracking. The main idea
is that at least on modern desktop, screen updates always happen with
pageflips. That means for X only one active crtc since X still doesn't
have per-crtc pixmaps, but meh.

Now for the pageflipping compositor model we don't need any of the
fancy (and usually broken) hw magic to detect updates to the currently
scanning out framebuffer - the compositor always renders to the
backbuffer.

So the idea is now to enable fbc/psr when pageflipping and disable it
as soon as we detect a frontbuffer rendering event. Thanks to the
current gem api we can do this pretty cheaply:
- CPU writes to the frontbuffer call sw_finish_ioctl. I need to still
check whether that only applies to cpu maps or also gtt maps.
- GTT writes could easily be caught by unmapping userspace ptes (we
have the infrastructure for that already), but I hope we can avoid
that.
- Currently we have some fragile code in our execbuf handler to detect
render of the gpu. I think we can rip this all out and instead detect
frontbuffer gpu rendering in the busy ioctl - that has been
established as the canonical interface for userspace to ask the kernel
to flush the frontbuffer. Aside: This semantics was not designed, but
we've realized that this is what it is eventually ;-)

Now once we have done the Big Rip and restricted fbc/psr enabling to
pageflips and disabling to these few places there's one thing left: We
need proper locking. My proposal is to add a new fbc_mutex which
protects all the special fbc state. That way we can avoid the current
ugly locking hell between kms and gem: Since due to modeset/dpms
changes we need to update fbc state, we enable it in the kms pageflip
code if possible, but gem events ditacte when we need to disable it
again. But if the fbc state is protected by its own mutex which needs
within the kms/gem locks we should be fine.

Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch