[Intel-gfx] [PATCH 0/4] Attempt to re-enable FBC on gen3

Adam Jackson ajax at redhat.com
Fri Apr 23 17:17:38 CEST 2010


Disclaimer: I haven't tested this extensively, it just seems logical, and I
really hate to see us lose FBC on gen3 since that's the family being used in
low-wattage devices.  Wider testing would be greatly appreciated.

The only thing I really don't like about this is how we hit every CRTC on
resume trying to enable FBC.  But that's sort of a problem in the normal case
anyway.  On pre-gen4, we can only compress plane A, so we hardwire that to
pipe B since LVDS is limited to pipe B.  Ideally, you'd like to compress
whichever CRTC has more pixels, assuming they're both mostly static. It's
really awkward to do that in the current one-at-a-time CRTC setup kind of
world though.

On gen4 and later we can compress either plane, so it's a little messier;
we'll compress whichever CRTC gets set up last, before suspend, but then after
suspend we'll compress the highest-numbered CRTC.  Either way, when multiple
CRTCs are active, we're already sometimes compressing a suboptimal plane, so
making more ways for that to happen isn't a huge deal.

(Then, of course, you'd like to switch which pipe you compress to the one with
the more static image, if they have different update rates.  But that's way
into diminishing returns territory.)

- ajax




More information about the Intel-gfx mailing list