From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/4] drm/i915/gt: Remove platform comments from workarounds
Date: Fri, 23 Dec 2022 09:02:35 +0000 [thread overview]
Message-ID: <4c8ffcd3-259e-f651-6f32-296896d8b4b7@linux.intel.com> (raw)
In-Reply-To: <20221222155535.gmih2rurxlo2xuo5@ldmartin-desk2.lan>
On 22/12/2022 15:55, Lucas De Marchi wrote:
> On Thu, Dec 22, 2022 at 10:27:00AM +0000, Tvrtko Ursulin wrote:
>>
>> On 22/12/2022 08:25, Lucas De Marchi wrote:
>>> The comments are redundant to the checks being done to apply the
>>> workarounds and very often get outdated as workarounds need to be
>>> extended to new platforms or steppings. Remove them altogether with
>>> the following matches (platforms extracted from intel_workarounds.c):
>>>
>>> find drivers/gpu/drm/i915/gt/ -name '*.c' | xargs sed -i -E \
>>>
>>> 's/(Wa.*):(bdw|chv|bxt|glk|skl|kbl|cfl|cfl|whl|cml|aml|chv|cl|bw|ctg|elk|ilk|snb|dg|pvc|g4x|ilk|gen|glk|kbl|cml|glk|kbl|cml|hsw|icl|ehl|ivb|hsw|ivb|vlv|kbl|pvc|rkl|dg|adl|skl|skl|bxt|blk|cfl|cnl|glk|snb|tgl|vlv|xehpsdv).*/\1/'
>>> find drivers/gpu/drm/i915/gt/ -name '*.c' | xargs sed -i -E \
>>>
>>> 's/(Wa.*):(bdw|chv|bxt|glk|skl|kbl|cfl|cfl|whl|cml|aml|chv|cl|bw|ctg|elk|ilk|snb|dg|pvc|g4x|ilk|gen|glk|kbl|cml|glk|kbl|cml|hsw|icl|ehl|ivb|hsw|ivb|vlv|kbl|pvc|rkl|dg|adl|skl|skl|bxt|blk|cfl|cnl|glk|snb|tgl|vlv|xehpsdv).*\*\//\1
>>>
>>> Same things was executed in the gem directory, omitted here for brevity.
>>
>>> There were a few false positives that included the workaround
>>> description. Those were manually patched.
>>
>> sed -E 's/(Wa[a-zA-Z0-9_]+)[:,]([a-zA-Z0-9,-_\+\[]{2,})/\1/'
>
> then there are false negatives. We have Was in the form
> "Wa_xxx:tgl,dg2, mtl". False positives we can fixup, false negatives
> we simply don't see. After running that in gt/:
>
> $ git grep ": mtl" -- drivers/gpu/drm/i915/
> drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
> drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
> drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
> drivers/gpu/drm/i915/gt/intel_gt_pm.c: /* Wa_14017073508: mtl */
> drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c: * Wa_14017073508: mtl
> drivers/gpu/drm/i915/i915_reg.h:/* Wa_14017210380: mtl */
>
> I was going with the platform names to avoid the false
> negatives and because I was entertaining the idea of only doing this for
> latest platforms where we do have the "Wa_[[:number:]]" form
>
>>
>> Maybe..
>>
>> Matt recently said he has this worked planned, but more importantly -
>> I gather then that the WA lookup tool definitely does not output these
>> strings?
>
> Whatever it does it's true only at the time it's called. It simply tells
> what
> are the platforms and steppings the Wa applies to. We can change the
> output to whatever we want, but that is not the point.
> Those comments get stale and bring no real value as they match 1:1
> what the code is supposed to be doing. Several times a patch has to
> update just that comment to "extend a workaround" to a next platform.
> This is not always done, so we get a comment that doesn't match what is
> supposed to be there.
Tl;dr; version - lets park this until January and discuss once everyone
is back.
Longer version. I've been trying to get us talking about this a couple
times before and I'd really like to close with an explicit consensus,
discussion points addressed instead of skipped and just moving ahead
with patches.
References:
3fcf71b9-337f-6186-7b00-27cbfd116743@linux.intel.com
Y5j0b/bykbitCa4Q@mdroper-desk1.amr.corp.intel.com
So point I wanted to discuss is whether these comments are truly useless
or maybe they can help during review. If the tool can actually output
them then I am leaning towards that they can be.
Thought is, when a patch comes for review adding a new platform,
stepping, whatever, to an existing if condition, if it contains the
comments reviewer can more easily spot a hyphotetical logic inversion
error or similar. It is also trivial to check that both condition and
comment have been updated. (So lets not be rash and remove something
maybe useful just because it can go stale *only if* reviewers are not
giving sufficient attention that changes are made in tandem.)
From a slightly different angle - do we expect anyone reviewing
workaround patches will cross-check against the tool? Would it be
simpler and more efficient that they could just cross-check against the
comment output from the tool and put into the patch by the author?
And point here to stress out is that accidental logic errors (missed
workarounds) can be super expensive to debug in the field. Sometimes it
can literally take _months_ for sporadic and hard to reproduce issues to
get debugged, handed over between the teams, etc. So any way in which we
can influence the likelyhood of that happening is something to weigh
carefully.
Secondary but also important - if i915 is end of line then an extra why
we want to rip out this for ancient platforms. Is the cost/benefit
positive there?
As a side note, and going back to the question of what the tool can
output. Long time ago I had an idea where we could improve all this by
making it completely data-driven. Have the WA database inspecting tool
output a table which could be directly pasted into code and interpreted
by i915.
For reference look at intel_workarounds_table.h in
https://patchwork.freedesktop.org/patch/399377/?series=83580&rev=3 and
see what you thing. That was just a sketch of the idea, not complete,
and yes, i915 end of life point makes it moot.
Regards,
Tvrtko
next prev parent reply other threads:[~2022-12-23 9:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-22 8:25 [Intel-gfx] [PATCH 0/4] Remove platform acronyms and stepping from comments Lucas De Marchi
2022-12-22 8:25 ` [Intel-gfx] [PATCH 1/4] drm/i915/gt: Remove platform comments from workarounds Lucas De Marchi
2022-12-22 10:27 ` Tvrtko Ursulin
2022-12-22 15:55 ` Lucas De Marchi
2022-12-23 9:02 ` Tvrtko Ursulin [this message]
2022-12-23 18:28 ` Lucas De Marchi
2023-01-03 23:03 ` Matt Roper
2023-01-04 9:58 ` Tvrtko Ursulin
2023-01-04 19:34 ` Matt Roper
2023-01-05 13:35 ` Tvrtko Ursulin
2023-01-07 0:29 ` Matt Roper
2023-01-12 21:42 ` Lucas De Marchi
2023-01-16 13:01 ` Tvrtko Ursulin
2022-12-22 8:25 ` [Intel-gfx] [PATCH 2/4] fixup! " Lucas De Marchi
2022-12-22 8:25 ` [Intel-gfx] [PATCH 3/4] drm/i915: " Lucas De Marchi
2022-12-22 8:25 ` [Intel-gfx] [PATCH 4/4] fixup! " Lucas De Marchi
2022-12-22 17:15 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Remove platform acronyms and stepping from comments Patchwork
2022-12-22 17:39 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-12-22 23:07 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
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=4c8ffcd3-259e-f651-6f32-296896d8b4b7@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lucas.demarchi@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