Re: [PATCH 2/2] drm/i915/fbc: Allow on unfenced surfaces, for recent gen

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Em Qua, 2016-08-24 às 07:43 +0100, Chris Wilson escreveu:
> On Mon, Aug 22, 2016 at 09:39:17PM -0300, Paulo Zanoni wrote:
> > 
> > 2016-08-18 5:21 GMT-03:00 Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>:
> > > 
> > > Only fbc1 is tied to using a fence. Later iterations of fbc are
> > > more
> > > flexible and allow operation on unfenced frontbuffers.
> > > 
> > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > > Cc: Daniel Vetter <daniel.vetter@xxxxxxxxx>
> > > Cc: "Zanoni, Paulo R" <paulo.r.zanoni@xxxxxxxxx>
> > 
> > Hi
> > 
> > I see this patch was applied. Now, on my Skylake machine, if I boot
> > with i915.enable_fbc=1 I'll get FIFO underruns under fbcon. Just
> > booting already gives me a FIFO underrun message, and then if I
> > "sudo
> > systemctl stop lightdm" I'll get a constantly-blinking screen.
> > 
> > Of course, applying the patch that disables FBC after a FIFO
> > underrun
> > will help stopping the ever-blinking fbcon, but I think we should
> > try
> > to avoid the underruns in the places we know we can, and leave the
> > "disable FBC on FIFO underruns" just for the cases we're not
> > expecting.
> > 
> > Also, please remember that I mentioned there are FBC workarounds
> > for
> > untiled that we still don't implement (although when I re-read my
> > email it may sound like I suggested the workarounds are for non-GTT
> > tracking). IMHO this argument alone should
> > have prevented this patch from being merged...
> > 
> > Based on that, can we please revert this patch? I'm afraid some
> > people
> > would consider these underruns as blockers to enabling FBC, so it's
> > probably better to enable FBC only on X tiled for now, and leave
> > this
> > for when we know how to prevent the underrun (possibly by
> > implementing
> > the missing WAs).
> 
> Sure you can disable FBC - just note that typically framebuffers will
> be
> unfenced.

So we need to investigate why the underruns are happening and implement
the missing workarounds. But IMHO while that's still not happening, tem
porarily reverting the patch seems to be the way to keep the codebase
sane.

> -Chris
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux