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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
