[Intel-gfx] [PATCH RESEND] drm: i915: Preserve old FBC status for update without new planes

[Gabriel Krisman Bertazi]

Paulo Zanoni <paulo.r.zanoni at intel.com> writes:

> Em Sex, 2017-06-09 às 22:40 +0300, Ville Syrjälä escreveu:
>> On Fri, Jun 09, 2017 at 08:24:59PM +0100, Chris Wilson wrote:

>> Just a random idea that popped to my head (probably not for the first
>> time); I think the most informative option would be to make the
>> kernel
>> report a separate fbc reason for each pipe. That way at least each
>> pipe
>> would have one clear reason for refusing fbc. Currently some of the
>> reasons are per-pipe and some are global, which leads to this kind of
>> confusion.
>
> That makes a lot of sense. We can definitely consider it.
>
> But this also includes the problem that multiple modesets on the same
> pipe change no_fbc_reason, so at some point we lose the information
> that FBC once failed on this pipe due to the lack of stolen memory, so
> I'm not 100% sure this would fix the specific bug addressed by this
> patch.

It would definitely improve the situation, despite not making a
difference for this specific case.

>
> Also, it increases the complexity of the debugfs interface instead of
> reducing, so I'd be more inclined to implement proposals that involve
> killing no_fbc_reason.
>
> Sometimes I wonder if we should start using tracing or actual (debug-
> only) events to signal user space about FBC being
> enabled/disabled/whatever. Part of the issue is that i915 keeps polling
> debugfs for state, so it can lose info sometimes.

I think this is what would make the most sense to improve the testcase.
Is it possible to increase the buffer logged by fbc_status, such that we
don't miss old errors recently reported?  Is that a good idea for a
debugfs interface?  That would maybe minimize the complexity of the
kernel-userspace interface.


>
>> 
>> But that of course doesn't solve all the problems if the test
>> continues
>> to make fragile assumptions about the kernel behaviour.
>
> It's a trade-off: the more we know (assume) about the Kernel, the more
> we can try to test and also the more can go wrong like it went here.
>
>> 

-- 
Gabriel Krisman Bertazi