* [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s @ 2017-06-28 11:16 Marta Lofstedt 2017-08-04 9:47 ` Lofstedt, Marta ` (3 more replies) 0 siblings, 4 replies; 20+ messages in thread From: Marta Lofstedt @ 2017-06-28 11:16 UTC (permalink / raw) To: intel-gfx The subtests: igt@kms_frontbuffer_tracking@fbc-*draw* has non-consistent results, pending between fail and pass. The fails are always due to "FBC disabled". With this increase in timeout the flip-flop behavior is no longer reproducible. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623 Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com> --- tests/kms_frontbuffer_tracking.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c index c24e4a81..8bec5d5a 100644 --- a/tests/kms_frontbuffer_tracking.c +++ b/tests/kms_frontbuffer_tracking.c @@ -923,7 +923,7 @@ static bool fbc_stride_not_supported(void) static bool fbc_wait_until_enabled(void) { - return igt_wait(fbc_is_enabled(), 2000, 1); + return igt_wait(fbc_is_enabled(), 5000, 1); } static bool psr_wait_until_enabled(void) -- 2.11.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s 2017-06-28 11:16 [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s Marta Lofstedt @ 2017-08-04 9:47 ` Lofstedt, Marta 2017-08-04 18:56 ` Paulo Zanoni 2017-08-25 10:40 ` [PATCH i-g-t v2] " Marta Lofstedt ` (2 subsequent siblings) 3 siblings, 1 reply; 20+ messages in thread From: Lofstedt, Marta @ 2017-08-04 9:47 UTC (permalink / raw) To: intel-gfx; +Cc: Zanoni, Paulo R +Paolo > -----Original Message----- > From: Lofstedt, Marta > Sent: Wednesday, June 28, 2017 2:17 PM > To: intel-gfx@lists.freedesktop.org > Cc: Latvala, Petri <petri.latvala@intel.com>; Lofstedt, Marta > <marta.lofstedt@intel.com> > Subject: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait > timeout to 5s > > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw* > has non-consistent results, pending between fail and pass. > The fails are always due to "FBC disabled". > With this increase in timeout the flip-flop behavior is no longer reproducible. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623 > Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com> > --- > tests/kms_frontbuffer_tracking.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/kms_frontbuffer_tracking.c > b/tests/kms_frontbuffer_tracking.c > index c24e4a81..8bec5d5a 100644 > --- a/tests/kms_frontbuffer_tracking.c > +++ b/tests/kms_frontbuffer_tracking.c > @@ -923,7 +923,7 @@ static bool fbc_stride_not_supported(void) > > static bool fbc_wait_until_enabled(void) { > - return igt_wait(fbc_is_enabled(), 2000, 1); > + return igt_wait(fbc_is_enabled(), 5000, 1); > } > > static bool psr_wait_until_enabled(void) > -- > 2.11.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s 2017-08-04 9:47 ` Lofstedt, Marta @ 2017-08-04 18:56 ` Paulo Zanoni 2017-08-07 6:51 ` Lofstedt, Marta 0 siblings, 1 reply; 20+ messages in thread From: Paulo Zanoni @ 2017-08-04 18:56 UTC (permalink / raw) To: Lofstedt, Marta, intel-gfx Em Sex, 2017-08-04 às 09:47 +0000, Lofstedt, Marta escreveu: > +Paolo > > > -----Original Message----- > > From: Lofstedt, Marta > > Sent: Wednesday, June 28, 2017 2:17 PM > > To: intel-gfx@lists.freedesktop.org > > Cc: Latvala, Petri <petri.latvala@intel.com>; Lofstedt, Marta > > <marta.lofstedt@intel.com> > > Subject: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC > > wait > > timeout to 5s > > > > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw* > > has non-consistent results, pending between fail and pass. > > The fails are always due to "FBC disabled". > > With this increase in timeout the flip-flop behavior is no longer > > reproducible. This is a partial revert of: 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54 kms_frontbuffer_tracking: reduce the FBC wait timeout to 2s (but there's no need to make it a full revert if you don't need) It would be nice to investigate why we're needing 5 seconds instead of 2 now, the document it in the commit message. Also document that this is a partial revert. Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623 > > Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com> > > --- > > tests/kms_frontbuffer_tracking.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/tests/kms_frontbuffer_tracking.c > > b/tests/kms_frontbuffer_tracking.c > > index c24e4a81..8bec5d5a 100644 > > --- a/tests/kms_frontbuffer_tracking.c > > +++ b/tests/kms_frontbuffer_tracking.c > > @@ -923,7 +923,7 @@ static bool fbc_stride_not_supported(void) > > > > static bool fbc_wait_until_enabled(void) { > > - return igt_wait(fbc_is_enabled(), 2000, 1); > > + return igt_wait(fbc_is_enabled(), 5000, 1); > > } > > > > static bool psr_wait_until_enabled(void) > > -- > > 2.11.0 > > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s 2017-08-04 18:56 ` Paulo Zanoni @ 2017-08-07 6:51 ` Lofstedt, Marta 2017-08-07 14:54 ` Paulo Zanoni 0 siblings, 1 reply; 20+ messages in thread From: Lofstedt, Marta @ 2017-08-07 6:51 UTC (permalink / raw) To: Zanoni, Paulo R, intel-gfx > -----Original Message----- > From: Zanoni, Paulo R > Sent: Friday, August 4, 2017 9:56 PM > To: Lofstedt, Marta <marta.lofstedt@intel.com>; intel- > gfx@lists.freedesktop.org > Cc: Latvala, Petri <petri.latvala@intel.com> > Subject: Re: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait > timeout to 5s > > Em Sex, 2017-08-04 às 09:47 +0000, Lofstedt, Marta escreveu: > > +Paolo > > > > > -----Original Message----- > > > From: Lofstedt, Marta > > > Sent: Wednesday, June 28, 2017 2:17 PM > > > To: intel-gfx@lists.freedesktop.org > > > Cc: Latvala, Petri <petri.latvala@intel.com>; Lofstedt, Marta > > > <marta.lofstedt@intel.com> > > > Subject: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC > > > wait timeout to 5s > > > > > > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw* > > > has non-consistent results, pending between fail and pass. > > > The fails are always due to "FBC disabled". > > > With this increase in timeout the flip-flop behavior is no longer > > > reproducible. > > This is a partial revert of: > > 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54 > kms_frontbuffer_tracking: reduce the FBC wait timeout to 2s > > (but there's no need to make it a full revert if you don't need) > > It would be nice to investigate why we're needing 5 seconds instead of > 2 now, the document it in the commit message. Also document that this is a > partial revert. Paulo, do you have data backing up that 2 seconds was ever OK, I fail ~1/10 on various fbc subtests. /Marta > > Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > Thanks, > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623 > > > Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com> > > > --- > > > tests/kms_frontbuffer_tracking.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/tests/kms_frontbuffer_tracking.c > > > b/tests/kms_frontbuffer_tracking.c > > > index c24e4a81..8bec5d5a 100644 > > > --- a/tests/kms_frontbuffer_tracking.c > > > +++ b/tests/kms_frontbuffer_tracking.c > > > @@ -923,7 +923,7 @@ static bool fbc_stride_not_supported(void) > > > > > > static bool fbc_wait_until_enabled(void) { > > > - return igt_wait(fbc_is_enabled(), 2000, 1); > > > + return igt_wait(fbc_is_enabled(), 5000, 1); > > > } > > > > > > static bool psr_wait_until_enabled(void) > > > -- > > > 2.11.0 > > > > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s 2017-08-07 6:51 ` Lofstedt, Marta @ 2017-08-07 14:54 ` Paulo Zanoni 2017-08-08 11:14 ` Lofstedt, Marta 0 siblings, 1 reply; 20+ messages in thread From: Paulo Zanoni @ 2017-08-07 14:54 UTC (permalink / raw) To: Lofstedt, Marta, intel-gfx Em Seg, 2017-08-07 às 06:51 +0000, Lofstedt, Marta escreveu: > > -----Original Message----- > > From: Zanoni, Paulo R > > Sent: Friday, August 4, 2017 9:56 PM > > To: Lofstedt, Marta <marta.lofstedt@intel.com>; intel- > > gfx@lists.freedesktop.org > > Cc: Latvala, Petri <petri.latvala@intel.com> > > Subject: Re: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase > > FBC wait > > timeout to 5s > > > > Em Sex, 2017-08-04 às 09:47 +0000, Lofstedt, Marta escreveu: > > > +Paolo > > > > > > > -----Original Message----- > > > > From: Lofstedt, Marta > > > > Sent: Wednesday, June 28, 2017 2:17 PM > > > > To: intel-gfx@lists.freedesktop.org > > > > Cc: Latvala, Petri <petri.latvala@intel.com>; Lofstedt, Marta > > > > <marta.lofstedt@intel.com> > > > > Subject: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase > > > > FBC > > > > wait timeout to 5s > > > > > > > > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw* > > > > has non-consistent results, pending between fail and pass. > > > > The fails are always due to "FBC disabled". > > > > With this increase in timeout the flip-flop behavior is no > > > > longer > > > > reproducible. > > > > This is a partial revert of: > > > > 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54 > > kms_frontbuffer_tracking: reduce the FBC wait timeout to 2s > > > > (but there's no need to make it a full revert if you don't need) > > > > It would be nice to investigate why we're needing 5 seconds instead > > of > > 2 now, the document it in the commit message. Also document that > > this is a > > partial revert. > > Paulo, do you have data backing up that 2 seconds was ever OK, I fail > ~1/10 on various fbc subtests. All the data I have is the commit message of 64590c7b and the testing I did. I would imagine something changed in the upstream tree since then, causing this to need a longer timeout, that's why I suggested investigating. > > /Marta > > > > Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > > > > Thanks, > > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623 > > > > Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com> > > > > --- > > > > tests/kms_frontbuffer_tracking.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/tests/kms_frontbuffer_tracking.c > > > > b/tests/kms_frontbuffer_tracking.c > > > > index c24e4a81..8bec5d5a 100644 > > > > --- a/tests/kms_frontbuffer_tracking.c > > > > +++ b/tests/kms_frontbuffer_tracking.c > > > > @@ -923,7 +923,7 @@ static bool fbc_stride_not_supported(void) > > > > > > > > static bool fbc_wait_until_enabled(void) { > > > > - return igt_wait(fbc_is_enabled(), 2000, 1); > > > > + return igt_wait(fbc_is_enabled(), 5000, 1); > > > > } > > > > > > > > static bool psr_wait_until_enabled(void) > > > > -- > > > > 2.11.0 > > > > > > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s 2017-08-07 14:54 ` Paulo Zanoni @ 2017-08-08 11:14 ` Lofstedt, Marta 2017-08-11 10:16 ` Lofstedt, Marta 0 siblings, 1 reply; 20+ messages in thread From: Lofstedt, Marta @ 2017-08-08 11:14 UTC (permalink / raw) To: Zanoni, Paulo R, intel-gfx > -----Original Message----- > From: Zanoni, Paulo R > Sent: Monday, August 7, 2017 5:54 PM > To: Lofstedt, Marta <marta.lofstedt@intel.com>; intel- > gfx@lists.freedesktop.org > Cc: Latvala, Petri <petri.latvala@intel.com> > Subject: Re: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait > timeout to 5s > > Em Seg, 2017-08-07 às 06:51 +0000, Lofstedt, Marta escreveu: > > > -----Original Message----- > > > From: Zanoni, Paulo R > > > Sent: Friday, August 4, 2017 9:56 PM > > > To: Lofstedt, Marta <marta.lofstedt@intel.com>; intel- > > > gfx@lists.freedesktop.org > > > Cc: Latvala, Petri <petri.latvala@intel.com> > > > Subject: Re: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase > > > FBC wait timeout to 5s > > > > > > Em Sex, 2017-08-04 às 09:47 +0000, Lofstedt, Marta escreveu: > > > > +Paolo > > > > > > > > > -----Original Message----- > > > > > From: Lofstedt, Marta > > > > > Sent: Wednesday, June 28, 2017 2:17 PM > > > > > To: intel-gfx@lists.freedesktop.org > > > > > Cc: Latvala, Petri <petri.latvala@intel.com>; Lofstedt, Marta > > > > > <marta.lofstedt@intel.com> > > > > > Subject: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase > > > > > FBC wait timeout to 5s > > > > > > > > > > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw* > > > > > has non-consistent results, pending between fail and pass. > > > > > The fails are always due to "FBC disabled". > > > > > With this increase in timeout the flip-flop behavior is no > > > > > longer reproducible. > > > > > > This is a partial revert of: > > > > > > 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54 > > > kms_frontbuffer_tracking: reduce the FBC wait timeout to 2s > > > > > > (but there's no need to make it a full revert if you don't need) > > > > > > It would be nice to investigate why we're needing 5 seconds instead > > > of > > > 2 now, the document it in the commit message. Also document that > > > this is a partial revert. > > > > Paulo, do you have data backing up that 2 seconds was ever OK, I fail > > ~1/10 on various fbc subtests. > > All the data I have is the commit message of 64590c7b and the testing I did. I > would imagine something changed in the upstream tree since then, causing > this to need a longer timeout, that's why I suggested investigating. > If I run current IGT with Kernel 4.2.0, which was released 30 august 2015, that should be around the time when the 64590c7b was done, all kms_frontbuffer_tracking tests fail. If I reset IGT to 64590c7b half of the flip-flopping tests consistently fail the rest consistently pass over 10 runs. If I run IGT@64590c7b on 4.13-rc3+ all kms_fronbuffer_tracking fail. So, indeed some of these tests appear to actually have passed 2 years ago, but it also seem that both the tests and the i915 have change a lot during 2 years. Anyways, I will do some timing analyze to investigate what is really going on here. /Marta > > > > /Marta > > > > > > Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > > > > > > > Thanks, > > > > > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623 > > > > > Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com> > > > > > --- > > > > > tests/kms_frontbuffer_tracking.c | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/tests/kms_frontbuffer_tracking.c > > > > > b/tests/kms_frontbuffer_tracking.c > > > > > index c24e4a81..8bec5d5a 100644 > > > > > --- a/tests/kms_frontbuffer_tracking.c > > > > > +++ b/tests/kms_frontbuffer_tracking.c > > > > > @@ -923,7 +923,7 @@ static bool fbc_stride_not_supported(void) > > > > > > > > > > static bool fbc_wait_until_enabled(void) { > > > > > - return igt_wait(fbc_is_enabled(), 2000, 1); > > > > > + return igt_wait(fbc_is_enabled(), 5000, 1); > > > > > } > > > > > > > > > > static bool psr_wait_until_enabled(void) > > > > > -- > > > > > 2.11.0 > > > > > > > > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s 2017-08-08 11:14 ` Lofstedt, Marta @ 2017-08-11 10:16 ` Lofstedt, Marta 0 siblings, 0 replies; 20+ messages in thread From: Lofstedt, Marta @ 2017-08-11 10:16 UTC (permalink / raw) To: Zanoni, Paulo R, 'intel-gfx@lists.freedesktop.org' Paulo, my currently conclusion in https://bugs.freedesktop.org/show_bug.cgi?id=101623 is that the more than 2 second wait for enable_fbs only occurs when changing between draw domains, typically between blt and mmap_cpu. To me this appear to be way too long time, but I am no expert here. I don't think that the objective of this test is performance of domain changes, but if we have no other way to explore that issue, I guess we should not change the timeout. /Marta > -----Original Message----- > From: Lofstedt, Marta > Sent: Tuesday, August 8, 2017 2:15 PM > To: Zanoni, Paulo R <paulo.r.zanoni@intel.com>; intel- > gfx@lists.freedesktop.org > Cc: Latvala, Petri <petri.latvala@intel.com> > Subject: RE: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait > timeout to 5s > > > > > -----Original Message----- > > From: Zanoni, Paulo R > > Sent: Monday, August 7, 2017 5:54 PM > > To: Lofstedt, Marta <marta.lofstedt@intel.com>; intel- > > gfx@lists.freedesktop.org > > Cc: Latvala, Petri <petri.latvala@intel.com> > > Subject: Re: [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase > > FBC wait timeout to 5s > > > > Em Seg, 2017-08-07 às 06:51 +0000, Lofstedt, Marta escreveu: > > > > -----Original Message----- > > > > From: Zanoni, Paulo R > > > > Sent: Friday, August 4, 2017 9:56 PM > > > > To: Lofstedt, Marta <marta.lofstedt@intel.com>; intel- > > > > gfx@lists.freedesktop.org > > > > Cc: Latvala, Petri <petri.latvala@intel.com> > > > > Subject: Re: [PATCH i-g-t] tests/kms_frontbuffer_tracking: > > > > increase FBC wait timeout to 5s > > > > > > > > Em Sex, 2017-08-04 às 09:47 +0000, Lofstedt, Marta escreveu: > > > > > +Paolo > > > > > > > > > > > -----Original Message----- > > > > > > From: Lofstedt, Marta > > > > > > Sent: Wednesday, June 28, 2017 2:17 PM > > > > > > To: intel-gfx@lists.freedesktop.org > > > > > > Cc: Latvala, Petri <petri.latvala@intel.com>; Lofstedt, Marta > > > > > > <marta.lofstedt@intel.com> > > > > > > Subject: [PATCH i-g-t] tests/kms_frontbuffer_tracking: > > > > > > increase FBC wait timeout to 5s > > > > > > > > > > > > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw* > > > > > > has non-consistent results, pending between fail and pass. > > > > > > The fails are always due to "FBC disabled". > > > > > > With this increase in timeout the flip-flop behavior is no > > > > > > longer reproducible. > > > > > > > > This is a partial revert of: > > > > > > > > 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54 > > > > kms_frontbuffer_tracking: reduce the FBC wait timeout to 2s > > > > > > > > (but there's no need to make it a full revert if you don't need) > > > > > > > > It would be nice to investigate why we're needing 5 seconds > > > > instead of > > > > 2 now, the document it in the commit message. Also document that > > > > this is a partial revert. > > > > > > Paulo, do you have data backing up that 2 seconds was ever OK, I > > > fail > > > ~1/10 on various fbc subtests. > > > > All the data I have is the commit message of 64590c7b and the testing > > I did. I would imagine something changed in the upstream tree since > > then, causing this to need a longer timeout, that's why I suggested > investigating. > > > If I run current IGT with Kernel 4.2.0, which was released 30 august 2015, that > should be around the time when the 64590c7b was done, all > kms_frontbuffer_tracking tests fail. If I reset IGT to 64590c7b half of the flip- > flopping tests consistently fail the rest consistently pass over 10 runs. If I run > IGT@64590c7b on 4.13-rc3+ all kms_fronbuffer_tracking fail. So, indeed > some of these tests appear to actually have passed 2 years ago, but it also > seem that both the tests and the i915 have change a lot during 2 years. > Anyways, I will do some timing analyze to investigate what is really going on > here. > > /Marta > > > > > > > /Marta > > > > > > > > Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623 > > > > > > Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com> > > > > > > --- > > > > > > tests/kms_frontbuffer_tracking.c | 2 +- > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/tests/kms_frontbuffer_tracking.c > > > > > > b/tests/kms_frontbuffer_tracking.c > > > > > > index c24e4a81..8bec5d5a 100644 > > > > > > --- a/tests/kms_frontbuffer_tracking.c > > > > > > +++ b/tests/kms_frontbuffer_tracking.c > > > > > > @@ -923,7 +923,7 @@ static bool fbc_stride_not_supported(void) > > > > > > > > > > > > static bool fbc_wait_until_enabled(void) { > > > > > > - return igt_wait(fbc_is_enabled(), 2000, 1); > > > > > > + return igt_wait(fbc_is_enabled(), 5000, 1); > > > > > > } > > > > > > > > > > > > static bool psr_wait_until_enabled(void) > > > > > > -- > > > > > > 2.11.0 > > > > > > > > > > _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s 2017-06-28 11:16 [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s Marta Lofstedt 2017-08-04 9:47 ` Lofstedt, Marta @ 2017-08-25 10:40 ` Marta Lofstedt 2017-08-25 10:46 ` Petri Latvala 2017-08-25 10:47 ` Chris Wilson 2017-08-25 12:24 ` ✓ Fi.CI.BAT: success for tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s (rev2) Patchwork 2017-08-25 17:40 ` ✓ Fi.CI.IGT: " Patchwork 3 siblings, 2 replies; 20+ messages in thread From: Marta Lofstedt @ 2017-08-25 10:40 UTC (permalink / raw) To: intel-gfx From: "Lofstedt, Marta" <marta.lofstedt@intel.com> The subtests: igt@kms_frontbuffer_tracking@fbc-*draw* has non-consistent results, pending between fail and pass. The fails are always due to "FBC disabled". With this increase in timeout the flip-flop behavior is no longer reproducible. This is a partial revert of: 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54, where the timeout was decreased from 5s to 2s. After investigating the timeout needed, the conclusion is that the longer timeout is only needed when the test swaps between some specific draw domains, typically blt vs. mmap_cpu. The objective of the FBC part of the tests is not to benchmark draw domain changes, it is to check that FBC was (re-)enabled. V2: Added documentation Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623 Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com> Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com> --- tests/kms_frontbuffer_tracking.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c index e03524f1..2538450c 100644 --- a/tests/kms_frontbuffer_tracking.c +++ b/tests/kms_frontbuffer_tracking.c @@ -924,7 +924,7 @@ static bool fbc_stride_not_supported(void) static bool fbc_wait_until_enabled(void) { - return igt_wait(fbc_is_enabled(), 2000, 1); + return igt_wait(fbc_is_enabled(), 5000, 1); } static bool psr_wait_until_enabled(void) -- 2.11.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s 2017-08-25 10:40 ` [PATCH i-g-t v2] " Marta Lofstedt @ 2017-08-25 10:46 ` Petri Latvala 2017-08-25 10:47 ` Chris Wilson 1 sibling, 0 replies; 20+ messages in thread From: Petri Latvala @ 2017-08-25 10:46 UTC (permalink / raw) To: Marta Lofstedt, intel-gfx On 08/25/2017 01:40 PM, Marta Lofstedt wrote: > After investigating the timeout needed, the conclusion is that > the longer timeout is only needed when the test swaps between > some specific draw domains, typically blt vs. mmap_cpu. > The objective of the FBC part of the tests is not to benchmark > draw domain changes, it is to check that FBC was (re-)enabled. Can this explanation be added to the code as a comment too? -- Petri Latvala _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s 2017-08-25 10:40 ` [PATCH i-g-t v2] " Marta Lofstedt 2017-08-25 10:46 ` Petri Latvala @ 2017-08-25 10:47 ` Chris Wilson 2017-08-25 11:54 ` Lofstedt, Marta 2017-08-25 12:50 ` Lofstedt, Marta 1 sibling, 2 replies; 20+ messages in thread From: Chris Wilson @ 2017-08-25 10:47 UTC (permalink / raw) To: Marta Lofstedt, intel-gfx Quoting Marta Lofstedt (2017-08-25 11:40:29) > From: "Lofstedt, Marta" <marta.lofstedt@intel.com> > > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw* > has non-consistent results, pending between fail and pass. > The fails are always due to "FBC disabled". > With this increase in timeout the flip-flop behavior is no > longer reproducible. > > This is a partial revert of: > 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54, > where the timeout was decreased from 5s to 2s. > After investigating the timeout needed, the conclusion is that > the longer timeout is only needed when the test swaps between > some specific draw domains, typically blt vs. mmap_cpu. > The objective of the FBC part of the tests is not to benchmark > draw domain changes, it is to check that FBC was (re-)enabled. > > V2: Added documentation > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623 > Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com> > Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > --- > tests/kms_frontbuffer_tracking.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c > index e03524f1..2538450c 100644 > --- a/tests/kms_frontbuffer_tracking.c > +++ b/tests/kms_frontbuffer_tracking.c > @@ -924,7 +924,7 @@ static bool fbc_stride_not_supported(void) > > static bool fbc_wait_until_enabled(void) > { Try igt_drop_caches_set(device, DROP_RETIRE); instead of relaxing the timeout. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s 2017-08-25 10:47 ` Chris Wilson @ 2017-08-25 11:54 ` Lofstedt, Marta 2017-08-25 12:50 ` Lofstedt, Marta 1 sibling, 0 replies; 20+ messages in thread From: Lofstedt, Marta @ 2017-08-25 11:54 UTC (permalink / raw) To: Chris Wilson, intel-gfx > -----Original Message----- > From: Chris Wilson [mailto:chris@chris-wilson.co.uk] > Sent: Friday, August 25, 2017 1:47 PM > To: Lofstedt, Marta <marta.lofstedt@intel.com>; intel- > gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: > increase FBC wait timeout to 5s > > Quoting Marta Lofstedt (2017-08-25 11:40:29) > > From: "Lofstedt, Marta" <marta.lofstedt@intel.com> > > > > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw* > > has non-consistent results, pending between fail and pass. > > The fails are always due to "FBC disabled". > > With this increase in timeout the flip-flop behavior is no longer > > reproducible. > > > > This is a partial revert of: > > 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54, > > where the timeout was decreased from 5s to 2s. > > After investigating the timeout needed, the conclusion is that the > > longer timeout is only needed when the test swaps between some > > specific draw domains, typically blt vs. mmap_cpu. > > The objective of the FBC part of the tests is not to benchmark draw > > domain changes, it is to check that FBC was (re-)enabled. > > > > V2: Added documentation > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623 > > Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com> > > Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > > --- > > tests/kms_frontbuffer_tracking.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/tests/kms_frontbuffer_tracking.c > > b/tests/kms_frontbuffer_tracking.c > > index e03524f1..2538450c 100644 > > --- a/tests/kms_frontbuffer_tracking.c > > +++ b/tests/kms_frontbuffer_tracking.c > > @@ -924,7 +924,7 @@ static bool fbc_stride_not_supported(void) > > > > static bool fbc_wait_until_enabled(void) { > > Try igt_drop_caches_set(device, DROP_RETIRE); instead of relaxing the > timeout. > -Chris OK, I will test that and do a V3 if it works! /Marta _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s 2017-08-25 10:47 ` Chris Wilson 2017-08-25 11:54 ` Lofstedt, Marta @ 2017-08-25 12:50 ` Lofstedt, Marta 2017-08-25 13:11 ` Chris Wilson 1 sibling, 1 reply; 20+ messages in thread From: Lofstedt, Marta @ 2017-08-25 12:50 UTC (permalink / raw) To: Chris Wilson, intel-gfx > -----Original Message----- > From: Lofstedt, Marta > Sent: Friday, August 25, 2017 2:54 PM > To: 'Chris Wilson' <chris@chris-wilson.co.uk>; intel-gfx@lists.freedesktop.org > Subject: RE: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: > increase FBC wait timeout to 5s > > > > > -----Original Message----- > > From: Chris Wilson [mailto:chris@chris-wilson.co.uk] > > Sent: Friday, August 25, 2017 1:47 PM > > To: Lofstedt, Marta <marta.lofstedt@intel.com>; intel- > > gfx@lists.freedesktop.org > > Subject: Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: > > increase FBC wait timeout to 5s > > > > Quoting Marta Lofstedt (2017-08-25 11:40:29) > > > From: "Lofstedt, Marta" <marta.lofstedt@intel.com> > > > > > > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw* > > > has non-consistent results, pending between fail and pass. > > > The fails are always due to "FBC disabled". > > > With this increase in timeout the flip-flop behavior is no longer > > > reproducible. > > > > > > This is a partial revert of: > > > 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54, > > > where the timeout was decreased from 5s to 2s. > > > After investigating the timeout needed, the conclusion is that the > > > longer timeout is only needed when the test swaps between some > > > specific draw domains, typically blt vs. mmap_cpu. > > > The objective of the FBC part of the tests is not to benchmark draw > > > domain changes, it is to check that FBC was (re-)enabled. > > > > > > V2: Added documentation > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623 > > > Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com> > > > Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > > > --- > > > tests/kms_frontbuffer_tracking.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/tests/kms_frontbuffer_tracking.c > > > b/tests/kms_frontbuffer_tracking.c > > > index e03524f1..2538450c 100644 > > > --- a/tests/kms_frontbuffer_tracking.c > > > +++ b/tests/kms_frontbuffer_tracking.c > > > @@ -924,7 +924,7 @@ static bool fbc_stride_not_supported(void) > > > > > > static bool fbc_wait_until_enabled(void) { > > > > Try igt_drop_caches_set(device, DROP_RETIRE); instead of relaxing the > > timeout. > > -Chris > > OK, I will test that and do a V3 if it works! > /Marta I did some initial testing with igt_drop_caches_set inside fbc_wait_until_enabled and it looks good, I will add this to my weekend tests to get more results. This also appear to improve the runtime of the tests quite a bit. So, maybe the igt_drop_caches_set should be placed somewhere else so it will give runtime improvements not only for the FBC related sub-tests. /Marta _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s 2017-08-25 12:50 ` Lofstedt, Marta @ 2017-08-25 13:11 ` Chris Wilson 2017-08-25 13:33 ` Lofstedt, Marta 2017-09-01 19:12 ` Paulo Zanoni 0 siblings, 2 replies; 20+ messages in thread From: Chris Wilson @ 2017-08-25 13:11 UTC (permalink / raw) To: Lofstedt, Marta, intel-gfx Quoting Lofstedt, Marta (2017-08-25 13:50:16) > > > > -----Original Message----- > > From: Lofstedt, Marta > > Sent: Friday, August 25, 2017 2:54 PM > > To: 'Chris Wilson' <chris@chris-wilson.co.uk>; intel-gfx@lists.freedesktop.org > > Subject: RE: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: > > increase FBC wait timeout to 5s > > > > > > > > > -----Original Message----- > > > From: Chris Wilson [mailto:chris@chris-wilson.co.uk] > > > Sent: Friday, August 25, 2017 1:47 PM > > > To: Lofstedt, Marta <marta.lofstedt@intel.com>; intel- > > > gfx@lists.freedesktop.org > > > Subject: Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: > > > increase FBC wait timeout to 5s > > > > > > Quoting Marta Lofstedt (2017-08-25 11:40:29) > > > > From: "Lofstedt, Marta" <marta.lofstedt@intel.com> > > > > > > > > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw* > > > > has non-consistent results, pending between fail and pass. > > > > The fails are always due to "FBC disabled". > > > > With this increase in timeout the flip-flop behavior is no longer > > > > reproducible. > > > > > > > > This is a partial revert of: > > > > 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54, > > > > where the timeout was decreased from 5s to 2s. > > > > After investigating the timeout needed, the conclusion is that the > > > > longer timeout is only needed when the test swaps between some > > > > specific draw domains, typically blt vs. mmap_cpu. > > > > The objective of the FBC part of the tests is not to benchmark draw > > > > domain changes, it is to check that FBC was (re-)enabled. > > > > > > > > V2: Added documentation > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623 > > > > Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com> > > > > Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > > > > --- > > > > tests/kms_frontbuffer_tracking.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/tests/kms_frontbuffer_tracking.c > > > > b/tests/kms_frontbuffer_tracking.c > > > > index e03524f1..2538450c 100644 > > > > --- a/tests/kms_frontbuffer_tracking.c > > > > +++ b/tests/kms_frontbuffer_tracking.c > > > > @@ -924,7 +924,7 @@ static bool fbc_stride_not_supported(void) > > > > > > > > static bool fbc_wait_until_enabled(void) { > > > > > > Try igt_drop_caches_set(device, DROP_RETIRE); instead of relaxing the > > > timeout. > > > -Chris > > > > OK, I will test that and do a V3 if it works! > > /Marta > > I did some initial testing with igt_drop_caches_set inside fbc_wait_until_enabled and it looks good, I will add this to my weekend tests to get more results. This also appear to improve the runtime of the tests quite a bit. So, maybe the igt_drop_caches_set should be placed somewhere else so it will give runtime improvements not only for the FBC related sub-tests. Sure, all the waits can do with the retire first, give it a common function and a comment for the rationale (which should pretty much the same as given in the changelog). Anytime we use the GPU to invalidate the frontbuffer tracking, we have to wait for a retire to do the flush. Retirement is lazy, and is normally driven by GPU activity but we have a background kworker to make sure we notice when the system becomes idle independent of userspace - except it's low frequency. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s 2017-08-25 13:11 ` Chris Wilson @ 2017-08-25 13:33 ` Lofstedt, Marta 2017-08-29 7:16 ` Lofstedt, Marta 2017-09-01 19:12 ` Paulo Zanoni 1 sibling, 1 reply; 20+ messages in thread From: Lofstedt, Marta @ 2017-08-25 13:33 UTC (permalink / raw) To: Chris Wilson, intel-gfx; +Cc: Zanoni, Paulo R +paulo > -----Original Message----- > From: Chris Wilson [mailto:chris@chris-wilson.co.uk] > Sent: Friday, August 25, 2017 4:12 PM > To: Lofstedt, Marta <marta.lofstedt@intel.com>; intel- > gfx@lists.freedesktop.org > Subject: RE: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: > increase FBC wait timeout to 5s > > Quoting Lofstedt, Marta (2017-08-25 13:50:16) > > > > > > > -----Original Message----- > > > From: Lofstedt, Marta > > > Sent: Friday, August 25, 2017 2:54 PM > > > To: 'Chris Wilson' <chris@chris-wilson.co.uk>; > > > intel-gfx@lists.freedesktop.org > > > Subject: RE: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: > > > increase FBC wait timeout to 5s > > > > > > > > > > > > > -----Original Message----- > > > > From: Chris Wilson [mailto:chris@chris-wilson.co.uk] > > > > Sent: Friday, August 25, 2017 1:47 PM > > > > To: Lofstedt, Marta <marta.lofstedt@intel.com>; intel- > > > > gfx@lists.freedesktop.org > > > > Subject: Re: [Intel-gfx] [PATCH i-g-t v2] > tests/kms_frontbuffer_tracking: > > > > increase FBC wait timeout to 5s > > > > > > > > Quoting Marta Lofstedt (2017-08-25 11:40:29) > > > > > From: "Lofstedt, Marta" <marta.lofstedt@intel.com> > > > > > > > > > > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw* > > > > > has non-consistent results, pending between fail and pass. > > > > > The fails are always due to "FBC disabled". > > > > > With this increase in timeout the flip-flop behavior is no > > > > > longer reproducible. > > > > > > > > > > This is a partial revert of: > > > > > 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54, > > > > > where the timeout was decreased from 5s to 2s. > > > > > After investigating the timeout needed, the conclusion is that > > > > > the longer timeout is only needed when the test swaps between > > > > > some specific draw domains, typically blt vs. mmap_cpu. > > > > > The objective of the FBC part of the tests is not to benchmark > > > > > draw domain changes, it is to check that FBC was (re-)enabled. > > > > > > > > > > V2: Added documentation > > > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623 > > > > > Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com> > > > > > Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > > > > > --- > > > > > tests/kms_frontbuffer_tracking.c | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/tests/kms_frontbuffer_tracking.c > > > > > b/tests/kms_frontbuffer_tracking.c > > > > > index e03524f1..2538450c 100644 > > > > > --- a/tests/kms_frontbuffer_tracking.c > > > > > +++ b/tests/kms_frontbuffer_tracking.c > > > > > @@ -924,7 +924,7 @@ static bool fbc_stride_not_supported(void) > > > > > > > > > > static bool fbc_wait_until_enabled(void) { > > > > > > > > Try igt_drop_caches_set(device, DROP_RETIRE); instead of relaxing > > > > the timeout. > > > > -Chris > > > > > > OK, I will test that and do a V3 if it works! > > > /Marta > > > > I did some initial testing with igt_drop_caches_set inside > fbc_wait_until_enabled and it looks good, I will add this to my weekend tests > to get more results. This also appear to improve the runtime of the tests > quite a bit. So, maybe the igt_drop_caches_set should be placed somewhere > else so it will give runtime improvements not only for the FBC related sub- > tests. > > Sure, all the waits can do with the retire first, give it a common function and a > comment for the rationale (which should pretty much the same as given in > the changelog). Anytime we use the GPU to invalidate the frontbuffer > tracking, we have to wait for a retire to do the flush. > Retirement is lazy, and is normally driven by GPU activity but we have a > background kworker to make sure we notice when the system becomes idle > independent of userspace - except it's low frequency. > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s 2017-08-25 13:33 ` Lofstedt, Marta @ 2017-08-29 7:16 ` Lofstedt, Marta 0 siblings, 0 replies; 20+ messages in thread From: Lofstedt, Marta @ 2017-08-29 7:16 UTC (permalink / raw) To: 'Chris Wilson', 'intel-gfx@lists.freedesktop.org' Cc: Zanoni, Paulo R I can no longer reproduce the flip/flopping "FBC disabled" on the kms_frontbuffer_tracking tests. Instead I hit: WARNING: CPU: 2 PID: 25732 at drivers/gpu/drm/i915/intel_fbc.c:1173 WARNING: CPU: 2 PID: 25732 at drivers/gpu/drm/i915/intel_fbc.c:1141 /Marta > -----Original Message----- > From: Lofstedt, Marta > Sent: Friday, August 25, 2017 4:34 PM > To: Chris Wilson <chris@chris-wilson.co.uk>; intel-gfx@lists.freedesktop.org > Cc: Zanoni, Paulo R <paulo.r.zanoni@intel.com> > Subject: RE: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: > increase FBC wait timeout to 5s > > +paulo > > > -----Original Message----- > > From: Chris Wilson [mailto:chris@chris-wilson.co.uk] > > Sent: Friday, August 25, 2017 4:12 PM > > To: Lofstedt, Marta <marta.lofstedt@intel.com>; intel- > > gfx@lists.freedesktop.org > > Subject: RE: [Intel-gfx] [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: > > increase FBC wait timeout to 5s > > > > Quoting Lofstedt, Marta (2017-08-25 13:50:16) > > > > > > > > > > -----Original Message----- > > > > From: Lofstedt, Marta > > > > Sent: Friday, August 25, 2017 2:54 PM > > > > To: 'Chris Wilson' <chris@chris-wilson.co.uk>; > > > > intel-gfx@lists.freedesktop.org > > > > Subject: RE: [Intel-gfx] [PATCH i-g-t v2] > tests/kms_frontbuffer_tracking: > > > > increase FBC wait timeout to 5s > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Chris Wilson [mailto:chris@chris-wilson.co.uk] > > > > > Sent: Friday, August 25, 2017 1:47 PM > > > > > To: Lofstedt, Marta <marta.lofstedt@intel.com>; intel- > > > > > gfx@lists.freedesktop.org > > > > > Subject: Re: [Intel-gfx] [PATCH i-g-t v2] > > tests/kms_frontbuffer_tracking: > > > > > increase FBC wait timeout to 5s > > > > > > > > > > Quoting Marta Lofstedt (2017-08-25 11:40:29) > > > > > > From: "Lofstedt, Marta" <marta.lofstedt@intel.com> > > > > > > > > > > > > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw* > > > > > > has non-consistent results, pending between fail and pass. > > > > > > The fails are always due to "FBC disabled". > > > > > > With this increase in timeout the flip-flop behavior is no > > > > > > longer reproducible. > > > > > > > > > > > > This is a partial revert of: > > > > > > 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54, > > > > > > where the timeout was decreased from 5s to 2s. > > > > > > After investigating the timeout needed, the conclusion is that > > > > > > the longer timeout is only needed when the test swaps between > > > > > > some specific draw domains, typically blt vs. mmap_cpu. > > > > > > The objective of the FBC part of the tests is not to benchmark > > > > > > draw domain changes, it is to check that FBC was (re-)enabled. > > > > > > > > > > > > V2: Added documentation > > > > > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623 > > > > > > Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com> > > > > > > Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > > > > > > --- > > > > > > tests/kms_frontbuffer_tracking.c | 2 +- > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/tests/kms_frontbuffer_tracking.c > > > > > > b/tests/kms_frontbuffer_tracking.c > > > > > > index e03524f1..2538450c 100644 > > > > > > --- a/tests/kms_frontbuffer_tracking.c > > > > > > +++ b/tests/kms_frontbuffer_tracking.c > > > > > > @@ -924,7 +924,7 @@ static bool fbc_stride_not_supported(void) > > > > > > > > > > > > static bool fbc_wait_until_enabled(void) { > > > > > > > > > > Try igt_drop_caches_set(device, DROP_RETIRE); instead of > > > > > relaxing the timeout. > > > > > -Chris > > > > > > > > OK, I will test that and do a V3 if it works! > > > > /Marta > > > > > > I did some initial testing with igt_drop_caches_set inside > > fbc_wait_until_enabled and it looks good, I will add this to my > > weekend tests to get more results. This also appear to improve the > > runtime of the tests quite a bit. So, maybe the igt_drop_caches_set > > should be placed somewhere else so it will give runtime improvements > > not only for the FBC related sub- tests. > > > > Sure, all the waits can do with the retire first, give it a common > > function and a comment for the rationale (which should pretty much the > > same as given in the changelog). Anytime we use the GPU to invalidate > > the frontbuffer tracking, we have to wait for a retire to do the flush. > > Retirement is lazy, and is normally driven by GPU activity but we have > > a background kworker to make sure we notice when the system becomes > > idle independent of userspace - except it's low frequency. > > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s 2017-08-25 13:11 ` Chris Wilson 2017-08-25 13:33 ` Lofstedt, Marta @ 2017-09-01 19:12 ` Paulo Zanoni 2017-09-04 10:45 ` Chris Wilson 1 sibling, 1 reply; 20+ messages in thread From: Paulo Zanoni @ 2017-09-01 19:12 UTC (permalink / raw) To: Chris Wilson, Lofstedt, Marta, intel-gfx Em Sex, 2017-08-25 às 14:11 +0100, Chris Wilson escreveu: > Quoting Lofstedt, Marta (2017-08-25 13:50:16) > > > > > > > -----Original Message----- > > > From: Lofstedt, Marta > > > Sent: Friday, August 25, 2017 2:54 PM > > > To: 'Chris Wilson' <chris@chris-wilson.co.uk>; intel-gfx@lists.fr > > > eedesktop.org > > > Subject: RE: [Intel-gfx] [PATCH i-g-t v2] > > > tests/kms_frontbuffer_tracking: > > > increase FBC wait timeout to 5s > > > > > > > > > > > > > -----Original Message----- > > > > From: Chris Wilson [mailto:chris@chris-wilson.co.uk] > > > > Sent: Friday, August 25, 2017 1:47 PM > > > > To: Lofstedt, Marta <marta.lofstedt@intel.com>; intel- > > > > gfx@lists.freedesktop.org > > > > Subject: Re: [Intel-gfx] [PATCH i-g-t v2] > > > > tests/kms_frontbuffer_tracking: > > > > increase FBC wait timeout to 5s > > > > > > > > Quoting Marta Lofstedt (2017-08-25 11:40:29) > > > > > From: "Lofstedt, Marta" <marta.lofstedt@intel.com> > > > > > > > > > > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw* > > > > > has non-consistent results, pending between fail and pass. > > > > > The fails are always due to "FBC disabled". > > > > > With this increase in timeout the flip-flop behavior is no > > > > > longer > > > > > reproducible. > > > > > > > > > > This is a partial revert of: > > > > > 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54, > > > > > where the timeout was decreased from 5s to 2s. > > > > > After investigating the timeout needed, the conclusion is > > > > > that the > > > > > longer timeout is only needed when the test swaps between > > > > > some > > > > > specific draw domains, typically blt vs. mmap_cpu. > > > > > The objective of the FBC part of the tests is not to > > > > > benchmark draw > > > > > domain changes, it is to check that FBC was (re-)enabled. > > > > > > > > > > V2: Added documentation > > > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623 > > > > > Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com> > > > > > Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > > > > > --- > > > > > tests/kms_frontbuffer_tracking.c | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/tests/kms_frontbuffer_tracking.c > > > > > b/tests/kms_frontbuffer_tracking.c > > > > > index e03524f1..2538450c 100644 > > > > > --- a/tests/kms_frontbuffer_tracking.c > > > > > +++ b/tests/kms_frontbuffer_tracking.c > > > > > @@ -924,7 +924,7 @@ static bool > > > > > fbc_stride_not_supported(void) > > > > > > > > > > static bool fbc_wait_until_enabled(void) { > > > > > > > > Try igt_drop_caches_set(device, DROP_RETIRE); instead of > > > > relaxing the > > > > timeout. > > > > -Chris > > > > > > OK, I will test that and do a V3 if it works! > > > /Marta > > > > I did some initial testing with igt_drop_caches_set inside > > fbc_wait_until_enabled and it looks good, I will add this to my > > weekend tests to get more results. This also appear to improve the > > runtime of the tests quite a bit. So, maybe the igt_drop_caches_set > > should be placed somewhere else so it will give runtime > > improvements not only for the FBC related sub-tests. > > Sure, all the waits can do with the retire first, give it a common > function and a comment for the rationale (which should pretty much > the > same as given in the changelog). We can do that, sure, especially if it makes the tests faster... > Anytime we use the GPU to invalidate > the frontbuffer tracking, we have to wait for a retire to do the > flush. > Retirement is lazy, and is normally driven by GPU activity but we > have a > background kworker to make sure we notice when the system becomes > idle > independent of userspace - except it's low frequency. ... but our current 2s timeout should have been enough for that, shouldn't it? If I'm looking at the right part of the code, retirement should be once per second, so 2s should have been enough. But it looks like it's not enough Unless I'm misinterpreting the round_up part, which could convert the 1s to 2s, which would still probably be fine... Anyway, 3s looks like as definitely safe even in this case. Maybe we could go with 3s? We can both increase the timeout *and* do cache dropping. Although I think not doing the cache dropping is definitely something that needs to be tested, so doing the cache dropping every time may not be a good idea. > -Chris > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s 2017-09-01 19:12 ` Paulo Zanoni @ 2017-09-04 10:45 ` Chris Wilson 2017-09-04 18:26 ` Paulo Zanoni 0 siblings, 1 reply; 20+ messages in thread From: Chris Wilson @ 2017-09-04 10:45 UTC (permalink / raw) To: Paulo Zanoni, Lofstedt, Marta, intel-gfx Quoting Paulo Zanoni (2017-09-01 20:12:01) > Em Sex, 2017-08-25 às 14:11 +0100, Chris Wilson escreveu: > > Quoting Lofstedt, Marta (2017-08-25 13:50:16) > > > > > > > > > > -----Original Message----- > > > > From: Lofstedt, Marta > > > > Sent: Friday, August 25, 2017 2:54 PM > > > > To: 'Chris Wilson' <chris@chris-wilson.co.uk>; intel-gfx@lists.fr > > > > eedesktop.org > > > > Subject: RE: [Intel-gfx] [PATCH i-g-t v2] > > > > tests/kms_frontbuffer_tracking: > > > > increase FBC wait timeout to 5s > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Chris Wilson [mailto:chris@chris-wilson.co.uk] > > > > > Sent: Friday, August 25, 2017 1:47 PM > > > > > To: Lofstedt, Marta <marta.lofstedt@intel.com>; intel- > > > > > gfx@lists.freedesktop.org > > > > > Subject: Re: [Intel-gfx] [PATCH i-g-t v2] > > > > > tests/kms_frontbuffer_tracking: > > > > > increase FBC wait timeout to 5s > > > > > > > > > > Quoting Marta Lofstedt (2017-08-25 11:40:29) > > > > > > From: "Lofstedt, Marta" <marta.lofstedt@intel.com> > > > > > > > > > > > > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw* > > > > > > has non-consistent results, pending between fail and pass. > > > > > > The fails are always due to "FBC disabled". > > > > > > With this increase in timeout the flip-flop behavior is no > > > > > > longer > > > > > > reproducible. > > > > > > > > > > > > This is a partial revert of: > > > > > > 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54, > > > > > > where the timeout was decreased from 5s to 2s. > > > > > > After investigating the timeout needed, the conclusion is > > > > > > that the > > > > > > longer timeout is only needed when the test swaps between > > > > > > some > > > > > > specific draw domains, typically blt vs. mmap_cpu. > > > > > > The objective of the FBC part of the tests is not to > > > > > > benchmark draw > > > > > > domain changes, it is to check that FBC was (re-)enabled. > > > > > > > > > > > > V2: Added documentation > > > > > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101623 > > > > > > Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com> > > > > > > Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > > > > > > --- > > > > > > tests/kms_frontbuffer_tracking.c | 2 +- > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/tests/kms_frontbuffer_tracking.c > > > > > > b/tests/kms_frontbuffer_tracking.c > > > > > > index e03524f1..2538450c 100644 > > > > > > --- a/tests/kms_frontbuffer_tracking.c > > > > > > +++ b/tests/kms_frontbuffer_tracking.c > > > > > > @@ -924,7 +924,7 @@ static bool > > > > > > fbc_stride_not_supported(void) > > > > > > > > > > > > static bool fbc_wait_until_enabled(void) { > > > > > > > > > > Try igt_drop_caches_set(device, DROP_RETIRE); instead of > > > > > relaxing the > > > > > timeout. > > > > > -Chris > > > > > > > > OK, I will test that and do a V3 if it works! > > > > /Marta > > > > > > I did some initial testing with igt_drop_caches_set inside > > > fbc_wait_until_enabled and it looks good, I will add this to my > > > weekend tests to get more results. This also appear to improve the > > > runtime of the tests quite a bit. So, maybe the igt_drop_caches_set > > > should be placed somewhere else so it will give runtime > > > improvements not only for the FBC related sub-tests. > > > > Sure, all the waits can do with the retire first, give it a common > > function and a comment for the rationale (which should pretty much > > the > > same as given in the changelog). > > We can do that, sure, especially if it makes the tests faster... > > > Anytime we use the GPU to invalidate > > the frontbuffer tracking, we have to wait for a retire to do the > > flush. > > Retirement is lazy, and is normally driven by GPU activity but we > > have a > > background kworker to make sure we notice when the system becomes > > idle > > independent of userspace - except it's low frequency. > > ... but our current 2s timeout should have been enough for that, > shouldn't it? If I'm looking at the right part of the code, retirement > should be once per second, so 2s should have been enough. But it looks > like it's not enough > > Unless I'm misinterpreting the round_up part, which could convert the > 1s to 2s, which would still probably be fine... It can bump the wait by upto a second (it tries to align wakeups on second boundaries). And we may skip the work if the device is busy elsewhere. > Anyway, 3s looks like as definitely safe even in this case. Maybe we > could go with 3s? > > We can both increase the timeout *and* do cache dropping. Although I > think not doing the cache dropping is definitely something that needs > to be tested, so doing the cache dropping every time may not be a good > idea. You are not dropping the caches, it is just doing a retire. The real question is what is the expectation? If we want the test to simply state that when ready FBC et al will be re-enabled, then just add a synchronous debugfs that establishes the condition in the driver that FBC should be ready (atm that is DROP_RETIRE, but you will probably want a better specified knob). If the test is to make sure that FBC is reenabled automatically, then we need to think some more. In a normal workload, this should be the case (since the retire worker you rely on is for hostile userspace). If you simply look at the hostile userspace (and you already are for the frontbuffer writes), then a longer timeout is definitely acceptable, but how long? What is that limit? If you define an upper bound for how long you allow fbc et al to remain off, then we will need an explicit timer to match. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH i-g-t v2] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s 2017-09-04 10:45 ` Chris Wilson @ 2017-09-04 18:26 ` Paulo Zanoni 0 siblings, 0 replies; 20+ messages in thread From: Paulo Zanoni @ 2017-09-04 18:26 UTC (permalink / raw) To: Chris Wilson, Lofstedt, Marta, intel-gfx Em Seg, 2017-09-04 às 11:45 +0100, Chris Wilson escreveu: > Quoting Paulo Zanoni (2017-09-01 20:12:01) > > Em Sex, 2017-08-25 às 14:11 +0100, Chris Wilson escreveu: > > > Quoting Lofstedt, Marta (2017-08-25 13:50:16) > > > > > > > > > > > > > -----Original Message----- > > > > > From: Lofstedt, Marta > > > > > Sent: Friday, August 25, 2017 2:54 PM > > > > > To: 'Chris Wilson' <chris@chris-wilson.co.uk>; intel-gfx@list > > > > > s.fr > > > > > eedesktop.org > > > > > Subject: RE: [Intel-gfx] [PATCH i-g-t v2] > > > > > tests/kms_frontbuffer_tracking: > > > > > increase FBC wait timeout to 5s > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Chris Wilson [mailto:chris@chris-wilson.co.uk] > > > > > > Sent: Friday, August 25, 2017 1:47 PM > > > > > > To: Lofstedt, Marta <marta.lofstedt@intel.com>; intel- > > > > > > gfx@lists.freedesktop.org > > > > > > Subject: Re: [Intel-gfx] [PATCH i-g-t v2] > > > > > > tests/kms_frontbuffer_tracking: > > > > > > increase FBC wait timeout to 5s > > > > > > > > > > > > Quoting Marta Lofstedt (2017-08-25 11:40:29) > > > > > > > From: "Lofstedt, Marta" <marta.lofstedt@intel.com> > > > > > > > > > > > > > > The subtests: igt@kms_frontbuffer_tracking@fbc-*draw* > > > > > > > has non-consistent results, pending between fail and > > > > > > > pass. > > > > > > > The fails are always due to "FBC disabled". > > > > > > > With this increase in timeout the flip-flop behavior is > > > > > > > no > > > > > > > longer > > > > > > > reproducible. > > > > > > > > > > > > > > This is a partial revert of: > > > > > > > 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54, > > > > > > > where the timeout was decreased from 5s to 2s. > > > > > > > After investigating the timeout needed, the conclusion is > > > > > > > that the > > > > > > > longer timeout is only needed when the test swaps between > > > > > > > some > > > > > > > specific draw domains, typically blt vs. mmap_cpu. > > > > > > > The objective of the FBC part of the tests is not to > > > > > > > benchmark draw > > > > > > > domain changes, it is to check that FBC was (re-)enabled. > > > > > > > > > > > > > > V2: Added documentation > > > > > > > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=10 > > > > > > > 1623 > > > > > > > Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com> > > > > > > > Acked-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > > > > > > > --- > > > > > > > tests/kms_frontbuffer_tracking.c | 2 +- > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > > > diff --git a/tests/kms_frontbuffer_tracking.c > > > > > > > b/tests/kms_frontbuffer_tracking.c > > > > > > > index e03524f1..2538450c 100644 > > > > > > > --- a/tests/kms_frontbuffer_tracking.c > > > > > > > +++ b/tests/kms_frontbuffer_tracking.c > > > > > > > @@ -924,7 +924,7 @@ static bool > > > > > > > fbc_stride_not_supported(void) > > > > > > > > > > > > > > static bool fbc_wait_until_enabled(void) { > > > > > > > > > > > > Try igt_drop_caches_set(device, DROP_RETIRE); instead of > > > > > > relaxing the > > > > > > timeout. > > > > > > -Chris > > > > > > > > > > OK, I will test that and do a V3 if it works! > > > > > /Marta > > > > > > > > I did some initial testing with igt_drop_caches_set inside > > > > fbc_wait_until_enabled and it looks good, I will add this to my > > > > weekend tests to get more results. This also appear to improve > > > > the > > > > runtime of the tests quite a bit. So, maybe the > > > > igt_drop_caches_set > > > > should be placed somewhere else so it will give runtime > > > > improvements not only for the FBC related sub-tests. > > > > > > Sure, all the waits can do with the retire first, give it a > > > common > > > function and a comment for the rationale (which should pretty > > > much > > > the > > > same as given in the changelog). > > > > We can do that, sure, especially if it makes the tests faster... > > > > > Anytime we use the GPU to invalidate > > > the frontbuffer tracking, we have to wait for a retire to do the > > > flush. > > > Retirement is lazy, and is normally driven by GPU activity but we > > > have a > > > background kworker to make sure we notice when the system becomes > > > idle > > > independent of userspace - except it's low frequency. > > > > ... but our current 2s timeout should have been enough for that, > > shouldn't it? If I'm looking at the right part of the code, > > retirement > > should be once per second, so 2s should have been enough. But it > > looks > > like it's not enough > > > > Unless I'm misinterpreting the round_up part, which could convert > > the > > 1s to 2s, which would still probably be fine... > > It can bump the wait by upto a second (it tries to align wakeups on > second boundaries). And we may skip the work if the device is busy > elsewhere. Okay, so you're saying that there's no amount of seconds we can wait that will guarantee the retire handler will run, even in IGT's limited environment where the only DRM client running is kms_frontbuffer_tracking? If the answer is yes, then we definitely need to patch kms_frontbuffer_tracking and do something about it. My assumption was that 2s (or 5s here) would be enough. Of course, since this is CI we need a 100% guarantee, 99.99999% is unacceptable. > > > Anyway, 3s looks like as definitely safe even in this case. Maybe > > we > > could go with 3s? > > > > We can both increase the timeout *and* do cache dropping. Although > > I > > think not doing the cache dropping is definitely something that > > needs > > to be tested, so doing the cache dropping every time may not be a > > good > > idea. > > You are not dropping the caches, it is just doing a retire. > > The real question is what is the expectation? If we want the test to > simply state that when ready FBC et al will be re-enabled, then just > add > a synchronous debugfs that establishes the condition in the driver > that > FBC should be ready (atm that is DROP_RETIRE, but you will probably > want > a better specified knob). As much as that's a valid option, I'd prefer to do something that didn't require adding more complex non-standard interactions between kms_frontbuffer_tracking and the Kernel. > If the test is to make sure that FBC is > reenabled automatically, We definitely want to check that. A bug in how we receive/treat the frontbuffer invalidate/flush calls can lead FBC to never get enabled again. > then we need to think some more. In a normal > workload, this should be the case (since the retire worker you rely > on > is for hostile userspace). If you simply look at the hostile > userspace > (and you already are for the frontbuffer writes), then a longer > timeout > is definitely acceptable, but how long? What is that limit? > > If you define an upper bound for how long you allow fbc et al to > remain > off, then we will need an explicit timer to match. See above. I thought there existed an amount of time that we could wait which would guarantee the retire handler would have run. > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* ✓ Fi.CI.BAT: success for tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s (rev2) 2017-06-28 11:16 [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s Marta Lofstedt 2017-08-04 9:47 ` Lofstedt, Marta 2017-08-25 10:40 ` [PATCH i-g-t v2] " Marta Lofstedt @ 2017-08-25 12:24 ` Patchwork 2017-08-25 17:40 ` ✓ Fi.CI.IGT: " Patchwork 3 siblings, 0 replies; 20+ messages in thread From: Patchwork @ 2017-08-25 12:24 UTC (permalink / raw) To: Lofstedt, Marta; +Cc: intel-gfx == Series Details == Series: tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s (rev2) URL : https://patchwork.freedesktop.org/series/26479/ State : success == Summary == IGT patchset tested on top of latest successful build 29d488034a50cd6fbad792cae61321995f0ab51c aubdump: Log some information about the execbuf calls with latest DRM-Tip kernel build CI_DRM_3003 f22dadc265b3 drm-tip: 2017y-08m-25d-11h-48m-56s UTC integration manifest Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 Test kms_frontbuffer_tracking: Subgroup basic: dmesg-warn -> PASS (fi-bdw-5557u) fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:463s fi-bdw-gvtdvm total:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:446s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:363s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:564s fi-bwr-2160 total:279 pass:184 dwarn:0 dfail:0 fail:0 skip:95 time:255s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:527s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:528s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:521s fi-elk-e7500 total:279 pass:230 dwarn:0 dfail:0 fail:0 skip:49 time:437s fi-glk-2a total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:617s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:447s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:424s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:430s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:510s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:470s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:602s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:595s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:467s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:482s fi-skl-6770hq total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:487s fi-skl-gvtdvm total:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:437s fi-skl-x1585l total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:483s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:549s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:404s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_99/ _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
* ✓ Fi.CI.IGT: success for tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s (rev2) 2017-06-28 11:16 [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s Marta Lofstedt ` (2 preceding siblings ...) 2017-08-25 12:24 ` ✓ Fi.CI.BAT: success for tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s (rev2) Patchwork @ 2017-08-25 17:40 ` Patchwork 3 siblings, 0 replies; 20+ messages in thread From: Patchwork @ 2017-08-25 17:40 UTC (permalink / raw) To: Lofstedt, Marta; +Cc: intel-gfx == Series Details == Series: tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s (rev2) URL : https://patchwork.freedesktop.org/series/26479/ State : success == Summary == Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 Test perf: Subgroup polling: fail -> PASS (shard-hsw) fdo#102252 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 shard-hsw total:2230 pass:1230 dwarn:0 dfail:0 fail:18 skip:982 time:9668s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_99/shards.html _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2017-09-04 18:26 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-06-28 11:16 [PATCH i-g-t] tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s Marta Lofstedt 2017-08-04 9:47 ` Lofstedt, Marta 2017-08-04 18:56 ` Paulo Zanoni 2017-08-07 6:51 ` Lofstedt, Marta 2017-08-07 14:54 ` Paulo Zanoni 2017-08-08 11:14 ` Lofstedt, Marta 2017-08-11 10:16 ` Lofstedt, Marta 2017-08-25 10:40 ` [PATCH i-g-t v2] " Marta Lofstedt 2017-08-25 10:46 ` Petri Latvala 2017-08-25 10:47 ` Chris Wilson 2017-08-25 11:54 ` Lofstedt, Marta 2017-08-25 12:50 ` Lofstedt, Marta 2017-08-25 13:11 ` Chris Wilson 2017-08-25 13:33 ` Lofstedt, Marta 2017-08-29 7:16 ` Lofstedt, Marta 2017-09-01 19:12 ` Paulo Zanoni 2017-09-04 10:45 ` Chris Wilson 2017-09-04 18:26 ` Paulo Zanoni 2017-08-25 12:24 ` ✓ Fi.CI.BAT: success for tests/kms_frontbuffer_tracking: increase FBC wait timeout to 5s (rev2) Patchwork 2017-08-25 17:40 ` ✓ Fi.CI.IGT: " Patchwork
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.