From: Jani Nikula <jani.nikula@intel.com>
To: vitaly prosyak <vprosyak@amd.com>,
vitaly.prosyak@amd.com, igt-dev@lists.freedesktop.org
Cc: Jesse Zhang <jesse.zhang@amd.com>
Subject: Re: [PATCH] lib/amdgpu: Add ASIC filtering system with family ranges
Date: Fri, 24 Apr 2026 17:04:38 +0300 [thread overview]
Message-ID: <5c99e331ee82b89449985c23ad0fd35b9fff2777@intel.com> (raw)
In-Reply-To: <558d511c-e72c-486c-8f87-9a720ed3ae13@amd.com>
On Wed, 22 Apr 2026, vitaly prosyak <vprosyak@amd.com> wrote:
> On 2026-04-22 03:57, Jani Nikula wrote:
>> On Wed, 22 Apr 2026, <vitaly.prosyak@amd.com> wrote:
>>> From: Vitaly Prosyak <vitaly.prosyak@amd.com>
>>>
>>> Add comprehensive ASIC-based test filtering system following IGT
>>> coding standards with three-tier priority configuration.
>> I would have expected an attempt to make an IGT shared filtering system
>> generic enough to plug into any vendor's platforms, instead of going
>> all-in on AMD only.
>>
>> That should be the mindset anyway, try to make it generic first. At the
>> very least the commit message should explain why this is AMD specific,
>> what it would take to make it generic, and "we didn't even think about
>> it" is just not good enough.
>>
>> BR,
>> Jani.
>>
>>
> Hi Jani,
>
> Thanks for the feedback — that’s a fair point, and I agree with the general direction.
>
> My initial focus was to solve the immediate AMD CI problem (fragile user queue tests on specific ASICs), which is why the current implementation is AMD-specific and uses amdgpu_asic_addr.h definitions. That said, I do agree the right long-term approach is to make this generic at the IGT framework level.
>
> A couple of thoughts on that:
>
> The filtering mechanism itself can be fully generic, but the data (ASIC tables, ranges, identifiers) is inherently vendor-specific.
> What I have in mind is:
> A common IGT filtering framework (core logic)
> Per-vendor backends/tables/configs (e.g., AMD, Intel, others)
> Separate config sources per vendor (config file + env), while reusing the same infrastructure
>
> One key benefit of integrating this into IGT core is that we avoid having each test/subtest manually check whether it should run. Instead, the framework can centrally decide, which keeps tests cleaner and avoids duplicated logic.
>
> Regarding your suggestion, I think it makes sense to:
>
> Rework the patch with generic naming and structure
> Clearly document:
> why the current version is AMD-specific
> what is required to generalize it
> Keep AMD as the first implementation backend, but not hardcode the design around it
>
> My proposal would be:
>
> I update the patch in this direction (generic framework + AMD-specific backend)
> We validate the approach in AMD CI for some time (since that’s where the need is immediate)
> Then I follow up with results and iterate towards making it fully usable across IGT
>
> Does this approach sound reasonable?
>
> Appreciate your feedback — it definitely helps steer this in the right direction.
I see that you're moving this to more generic direction, and already
sent patches to that effect. Thanks for that, appreciated.
That said, I'm afraid I don't have the bandwidth for detailed review of
it. Please ping the IGT maintainers.
BR,
Jani.
>
> BR,
> Vitaly
>>> Structure and Design:
>>> - Uses family range arrays similar to amd_queue_reset.c
>>> - Supports up to 4 ASIC ranges per skip rule
>>> - Intensive use of amdgpu_asic_addr.h definitions (FAMILY_*, AMDGPU_*_RANGE)
>>> - No global variables - all state in struct asic_filter_context
>>> - Read-only static const tables (asic_table, builtin_skip_table)
>>>
>>> Three-Tier Priority System:
>>> 1. Built-in production array (checked first, requires rebuild)
>>> 2. Config file /etc/igt/asic_skip.conf (development, no rebuild)
>>> 3. Environment variable IGT_ASIC_SKIP_CONFIG (runtime, no rebuild)
>>>
>>> Features:
>>> - Family range structure: {family_id, chip_id_min, chip_id_max}
>>> - Glob pattern matching for subtests (fnmatch)
>>> - Comprehensive deployment guide in source code
>>> - 10 commented examples in builtin_skip_table[]
>>> - Complete family & range documentation
>>> - Dump functionality showing all three sources
>>>
>>> Documentation in Source:
>>> - 5-step deployment guide
>>> - Family & range reference (9 families, 18 ranges)
>>> - Glob patterns guide
>>> - 10 ready-to-use examples
>>>
>>> Files Added:
>>> - lib/amdgpu/amd_asic_filter.h - API and structures
>>> - lib/amdgpu/amd_asic_filter.c - Full implementation with guide
>>>
>>> Cc: Jesse Zhang <jesse.zhang@amd.com>
>>> Signed-off Vitaly Prosyak <vitaly.prosyak@amd.com>
--
Jani Nikula, Intel
next prev parent reply other threads:[~2026-04-24 14:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-22 4:17 [PATCH] lib/amdgpu: Add ASIC filtering system with family ranges vitaly.prosyak
2026-04-22 4:28 ` Zhang, Jesse(Jie)
2026-04-22 6:15 ` ✓ i915.CI.BAT: success for " Patchwork
2026-04-22 6:23 ` ✓ Xe.CI.BAT: " Patchwork
2026-04-22 7:57 ` [PATCH] " Jani Nikula
2026-04-22 14:40 ` vitaly prosyak
2026-04-24 14:04 ` Jani Nikula [this message]
2026-04-24 17:09 ` vitaly prosyak
2026-04-22 10:19 ` ✗ Xe.CI.FULL: failure for " Patchwork
2026-04-23 9:41 ` ✓ i915.CI.Full: success " 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=5c99e331ee82b89449985c23ad0fd35b9fff2777@intel.com \
--to=jani.nikula@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=jesse.zhang@amd.com \
--cc=vitaly.prosyak@amd.com \
--cc=vprosyak@amd.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