On Thu, Jun 19, 2014 at 08:28:11PM +0100, Chris Wilson wrote: > On Thu, Jun 19, 2014 at 12:06:13PM -0700, Ben Widawsky wrote: > > This is one part in a few fixes needed to make FBC work with limited > > stolen memory and large resolution displays. It is not the full > > solution, but one (easy) step. > > > > The patch is straight-forward, it attempts to check there will be room > > for FBC before trying to "reclaim" > > But it special cases one particular allocation. Why don't you just > reserve stolen upfront for FBC? Compute the maximum buffer size the > hardware could support and try to claim it during stolen init. > -Chris > I agree this would be the best approach (and what I had planned to do). For one, I didn't find the interfaces I wanted in the drm_mm to do what I needed (though I didn't look very hard). I ended up getting stuck with having to decide whether to reclaim the scanout (and fastboot), or FBC. I believe this should be a decision left to the user, where user is the distro packaging. I'd like to just point out some math at this point too. Common stolen size is 32M 3840 x 2160 x 4 = 31.64M So we have a real problem if we want to reuse any of stolen memory, which the first 3 patches address to some extent. Anyway, I think I was pretty clear that the patch is incomplete, and primarily meant to motivate the relevant parties to figure out how they want to handle the stolen reclaim. -- Ben Widawsky, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
