On Fri, 16 May 2014 20:49:30 +0100 Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > On Fri, May 16, 2014 at 12:34:08PM -0700, Jesse Barnes wrote: > > On Fri, 16 May 2014 20:20:50 +0100 > > Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > > We haven't even fixed the major regression from enabling FBC. What's > > > another massive slowdown? > > > > I thought you had that fixed in the X driver by avoiding front buffer > > rendering altogether. If that's the case we just need an ioctl to opt > > out of front buffer tracking, right? Presumably that flag would follow > > the current DRM_MASTER process... > > No. All rendering triggers FBC updates. Ville has patches to fix the > majority of that with only nuking FBC when front buffer rendering. (Note > that games aren't usually affected by this because FBC is disabled by > pageflipping.) The overhead could probably be reduced further by periodic > nuking the FBC like (ideally) PSR. And yes X can avoid front buffer > rendering altogether. The remaining challenge is to know when to enable it > (the kernel doesn't give us any information about FBC or PSR after setting a > mode) and when not, i.e. there is already a pageflipping compositor. I thought there was a control bit for when the nuke occurred? If not, yeah I guess we have to go with a sw approach... -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
