Re: [PATCH] lib/amdgpu: Add ASIC filtering system with family ranges

[vitaly prosyak <vprosyak@amd.com>]

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.

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>