Re: [Intel-gfx] [PATCH RESEND i-g-t 1/2] tests/kms_frontbuffer_tracking: Skip if CRTC not selected

2017-04-26 Thread Zanoni, Paulo R 
Em Qua, 2017-04-26 às 15:40 -0300, Gabriel Krisman Bertazi escreveu:
> Paulo Zanoni  writes:
> 
> > 
> > Em Qui, 2017-04-20 às 11:11 -0300, Gabriel Krisman Bertazi
> > escreveu:
> > > 
> > > After Linux commit f7e9b004b8a3 ("drm/i915/fbc: inline
> > > intel_fbc_can_choose()"), no_fbc_reason will be updated to a new
> > > error
> > > message if we don't have a plane in the new state, which should
> > > make
> > > the
> > > test skip, but the test code doesn't catch that message and tries
> > > to
> > 
> > What was the previous message that was making the test skip? I was
> > not
> > expecting that patch would affect kms_frontbuffer_tracking
> > behavior.
> 
> The previous message was "FBC disabled: not enough stolen
> memory".  You
> got me wondering if we should even enter that function if
> intel_fbc_alloc_cfb failed.  The patch I mentioned starts triggering
> the
> failure because it changes the error message even if we never enter
> the
> for_each_new_plane_in_state loop in intel_fbc_choose_crtc.
> 
> Does that makes sense?  Let me take another look at the code and see
> what I can come up with.

I think I understand the problem now. My problem with the current
approach is that it changes the kms_frontbuffer_tracking behavior for
more cases than the one affected by this bug, so there's a risk we're
going to end up skipping when we should really be failing. Any case
where we end up not finding a suitable CRTC will be skipped, instead of
only skipping where we can't find a suitable CRTC due to not having
enough stolen memory.

I was already planning on maybe switching opt.small_modes to default as
true. This should help not only on cases where there's not enough
stolen memory, but also on cases where the monitor resolution is too
big for FBC. This would fix the bug.

The reason why I still didn't switch opt.small_modes to true by default
is because I didn't check if doing this will introduce any other
unintended regressions. It shouldn't, but we'll never know until we
actually try. Maybe we should check this with the CI team.

For our CI machines specifically, I think we should also consider just
going to their BIOSes and increasing the amount of stolen memory. We
really want to try to minimize the amount of SKIPs in cases where we
could be testing stuff, so increasing the amount of stolen memory
really sounds the ideal solution for CI.

So 3 possible solutions (and maybe we should do them all):

- Switch opt.small_modes to true by default, and check if this exposes
new problems.
- Increase the amount of stolen memory for CI machines.
- Somehow go back to the previous behavior where the Kernel tells us
that it tried to enable FBC but there's not enough stolen memory.

Thanks,
Paulo

> 
> 
> > 
> > 
> > > 
> > > execute the test, triggering a test failure.
> > 
> > Anyway, I'm trying to understand the situation here. I'm not sure
> > if
> > this fix is correct, I'm wondering if it's a problem in how the
> > Kernel
> > sets the messages. Please explain in more details why this patch
> > does
> > what it does.
> > 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH RESEND i-g-t 1/2] tests/kms_frontbuffer_tracking: Skip if CRTC not selected

2017-04-26 Thread Gabriel Krisman Bertazi 
Paulo Zanoni  writes:

> Em Qui, 2017-04-20 às 11:11 -0300, Gabriel Krisman Bertazi escreveu:
>> After Linux commit f7e9b004b8a3 ("drm/i915/fbc: inline
>> intel_fbc_can_choose()"), no_fbc_reason will be updated to a new
>> error
>> message if we don't have a plane in the new state, which should make
>> the
>> test skip, but the test code doesn't catch that message and tries to
>
> What was the previous message that was making the test skip? I was not
> expecting that patch would affect kms_frontbuffer_tracking behavior.

The previous message was "FBC disabled: not enough stolen memory".  You
got me wondering if we should even enter that function if
intel_fbc_alloc_cfb failed.  The patch I mentioned starts triggering the
failure because it changes the error message even if we never enter the
for_each_new_plane_in_state loop in intel_fbc_choose_crtc.

Does that makes sense?  Let me take another look at the code and see
what I can come up with.


>
>> execute the test, triggering a test failure.
>
> Anyway, I'm trying to understand the situation here. I'm not sure if
> this fix is correct, I'm wondering if it's a problem in how the Kernel
> sets the messages. Please explain in more details why this patch does
> what it does.
>

-- 
Gabriel Krisman Bertazi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx