From: Matthew Brost <matthew.brost@intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: "igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>,
"Katragadda, MastanX" <mastanx.katragadda@intel.com>
Subject: Re: [igt-dev] [i-g-t] tests/i915/exec_balancer: Added Skip Guc Submission
Date: Wed, 1 Dec 2021 15:57:39 -0800 [thread overview]
Message-ID: <20211201235738.GB36147@jons-linux-dev-box> (raw)
In-Reply-To: <CAKMK7uHN4k9zDEmdQyscj7MsoDFcqVp0P80uEMzHfcaZ8HxnqA@mail.gmail.com>
On Wed, Dec 01, 2021 at 12:46:06PM +0100, Daniel Vetter wrote:
> On Wed, Dec 1, 2021 at 12:37 PM Radoslaw Szwichtenberg
> <radoslaw.szwichtenberg@intel.com> wrote:
> > On 01/12/2021 10:46, Tvrtko Ursulin wrote:
> > > On 30/11/2021 16:48, Matthew Brost wrote:
> > >>
> > >> IMO this fix is 100% correct as this is a known, tracked issue. It was
> > >> agreed upon (arch, i915, GuC team) that we just skip these tests with
> > >> GuC submission.
> > This does not look like a fix to me - you just disable test to hide the
> > result. If this issue is recorded with a bug, is tracked - why cant we
> > just let this test fail till we get this issue fixed?
>
> This is correct in general, but sadly not for gem igts and selftests.
> The state of our validation suite is screwed up enough that
> unfortunately the safe starting point for failing tests is that the
> test is simply wrong, or too much just validating implementation
> details of the current platform/driver, while not actually validating
> stuff that should be tested for.
>
That is exactly what this test is doing - IMO it is validating details
of backend scheduler not ABI nor a POR arch requirement.
> > > I915 team is here on upstream as well.
> > >
> > > Record those acks publicly would be my ask. Unless some security by
> > > obscurity is happening here? Until then from me it is a soft nack to
> > > keep disabling tests which show genuine weaknesses in GuC mode. Soft
> > > until we get a public record of exactly what is broken and in what
> > > circumstances, acked by architects publicly as you say they acked it
> > > somewhere. Commit message devoid of detail is not good enough.
> > This should be most probably documented in the bug, right? Here we
> > should just keep the test as is till the issue is fixed. I don't see how
> > docummenting an issue would enable us to just disable the test.
>
> Sadly the situation is bad enough that I'm tempted to just drop a few
> thousand Acked-by: me tags in this thread for any case where a
> questionable testcase gets in the way. Unless someone can proof that
> it's a POR architectural requirement we're validating here.
>
Agree our selftests / IGTs are a complete mess with many questionable
test cases. You wouldn't believe the amount of time / effort we waste
looking into these.
> I do agree though that really we should just delete such tests
> outright, not hide the mess on each platform individually.
Agree likely should do an audit of our tests and delete some of them.
Matt
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
next prev parent reply other threads:[~2021-12-02 0:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-26 1:57 [igt-dev] [i-g-t] tests/i915/exec_balancer: Added Skip Guc Submission Mastan Katragadda
2021-11-26 2:42 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
2021-11-26 8:46 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
2021-11-29 10:30 ` [igt-dev] [i-g-t] " Tvrtko Ursulin
2021-11-29 10:58 ` Katragadda, MastanX
2021-11-29 11:15 ` Tvrtko Ursulin
2021-11-30 16:48 ` Matthew Brost
2021-12-01 9:46 ` Tvrtko Ursulin
2021-12-01 11:36 ` Radoslaw Szwichtenberg
2021-12-01 11:46 ` Daniel Vetter
2021-12-01 12:14 ` Tvrtko Ursulin
2021-12-01 23:57 ` Matthew Brost [this message]
2021-12-01 23:42 ` Matthew Brost
2021-12-02 9:19 ` Petri Latvala
2021-12-02 9:20 ` Tvrtko Ursulin
2021-12-03 19:36 ` Matthew Brost
-- strict thread matches above, loose matches on Subject: below --
2021-12-09 8:20 Mastan Katragadda
2021-12-10 3:20 ` Matthew Brost
2021-12-10 10:02 ` Tvrtko Ursulin
2021-12-22 9:30 ` Tvrtko Ursulin
2021-12-22 21:02 ` John Harrison
2021-12-23 11:08 ` Tvrtko Ursulin
2021-12-23 11:16 ` Surendrakumar Upadhyay, TejaskumarX
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211201235738.GB36147@jons-linux-dev-box \
--to=matthew.brost@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=igt-dev@lists.freedesktop.org \
--cc=mastanx.katragadda@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox