Re: Running autopkgtests with AMD GPUs with rocm-test-launcher

[Cordell Bloor <cgmb@slerp.xyz>]

Hi Christian,

On 2025-04-24 02:09, Christian Kastner wrote:

> it might even be a good idea to ship such a wrapper for *all*
> packages, even the single-test ones, to provide a unified, well-known
> entry point for running tests, so that tests for any -tests <binpkg>
> can always be launched with
>
>     $ /usr/libexec/rocm/<binpkg>/runtests
>
> (or whatever name fits better than runtests).
>

Let's do this.

I did a bit of brainstorming on alternative verbs, but I couldn't come up with anything better than run-tests. The best alternative I could come up with was "verify", but the path to the script refers to the test package, not the library it is verifying. My only suggestion for improvement would be to put a dash in between "run" and "test" just for consistency with the package name.

Using run-tests would make the executable path into something like:

/usr/libexec/rocm/librocrand1-tests/run-tests

or for the top-level meta-package:

/usr/libexec/rocm/rocm-tests/run-tests

I would also suggest an optional "--filter" argument supported by all versions of the script. The filter categories would be "smoke", "basic", "extended", or "special". The default value for the filter would be "basic" as that is a good option for a novice user checking that ROCm is working on their hardware (or for a packager doing a quick check on their system before upload).

The filter categories are chosen because there are corresponding options upstream for all libraries that we can draw from:

• smoke (0x1)
• The upstream projects all have smoke test filters used for verifying correctness on emulated hardware. The smoke tests should execute in under five minutes on reasonable hardware.
• basic (0x2)
• The upstream tests run on pull requests. In upstream jargon this is sometimes known as "psdb", "quick", or "checkin". The basic test suite should execute in under an hour on reasonable hardware.
• extended (0x4)
• The upstream tests run for new commits on trunk. In upstream jargon this is sometimes known as "osdb", "extended", "daily", or "nightly". The smoke tests should execute in under eight hours on reasonable hardware.
• special (0x8)
• These would mostly be tests that are so slow that upstream doesn't run them often (e.g., rocblas tests for 32-bit overflow when multiplying large matrices). In upstream jargon these are sometimes called "weekly". The special tests can execute for as long as they require.

There are also two aliases:

• autopkgtest (0x7)
  
• This is an alias for "smoke,basic,extended". The smoke tests are a subset of the basic tests so it's not important that it's included in this list. There are also no special tests in the Debian archives yet, so this filter would be equivalent to what we're currently running on ci.rocm.debian.net.
  
• all (0xF)
• This is an alias for "smoke,basic,extended,special". It would primarily be used to add the special tests, once we have them.

I don't want to exactly match the upstream naming because it doesn't correspond to how Debian would be using the tests. Nor do I wish to imply that the Debian test categories will always correspond exactly to any particular upstream filter. The various upstream libraries aren't entirely consistent with each other (and their naming might not be stable).

Sincerely,
Cory Bloor