Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
