Re: RFC: rocm-autopkgtest-helper
Hi Cory,
On 2024-10-14 01:45, Cordell Bloor wrote:
> On 2024-10-13 08:10, Christian Kastner wrote:
>> I *think* this interface might be the wrong one, as it makes it impossible to pass options to the test command.
>
> You might also need to handle environment variables. I suggest testing your implementation out with rccl. Although, I suppose one could always use a wrapper.
I don't really do anything to the environment, other than check for the
presence of three variables that turn some features in the helper on/off.
These can be set by autopkgtest --env (in our worker's case, via
debci_autopkgtest_args).
> One thing that might need some consideration eventually is that not all
> software is compatible with all GPU architectures. The hipBLASLt and
> rocWMMA libraries would be good examples of this. We may eventually need
> a way to express that sort of constraint.
Long-term, this is going to *the* challenge, because it will require
Policy and autopkgtest spec changes. These currently do not have a way
to express GPU architecture.
We've hacked around this in our CI by "abusing" the architecture field,
but that's not a generally applicable solution.
We can probably start by/experiment with custom headers in d/control, eg:
X-ROCm-Architectures: gfx1030 gfx1032 gfx1034
and adapt our tooling as we go. Stuff that stabilizes, we can feed back
upstream, as we've been doing for autopkgtest and debci.
>> I'm leaning towards (B) because when I think of the autopkgtests I
>> implemented, it was more typical for one test call to accept options,
>> than to call more than one test (runner). Hence, if a wrapper cannot
>> be avoided, then best to relegate it to the rarer use case.
>
> That seems reasonable to me. There might be fancier options, but this
> would be sufficient to ensure that the wrapper script is a simple
> program. And we may be able to provide alternative modes of operation in
> the future to handle other common cases, if need be.
Agreed.
Best,
Christian
Reply to: