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

[vitaly prosyak <vprosyak@amd.com>]

On 2026-04-24 10:04, Jani Nikula wrote:
> 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.
>
>

Hi Jani,

Thanks for the quick follow-up and for taking a look — much appreciated.

Understood regarding bandwidth. I’ll reach out to the IGT maintainers for a more detailed review and continue iterating in the more generic direction as discussed.

Thanks again for the guidance, it’s been very helpful in shaping the approach.

BR,
Vitaly

>> 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>