[Feature]: add a `hsa_amd_signal_wait_all` API.

[benvanik]

Suggestion Description

hsa_amd_signal_wait_any exists and routes to hsaKmtWaitOnMultipleEvents_Ext and is useful for implementing host-side barrier-or packet behavior. There's currently not a hsa_amd_signal_wait_all, though, which is needed to efficiently implement the barrier-and packet behavior. hsaKmtWaitOnMultipleEvents_Ext has a WaitOnAll flag and it'd be useful to have a top-level API that routes to that.

Operating System

No response

GPU

No response

ROCm Component

No response

[atgutier]

Will take a look at this.

[atgutier]

Can you test #250 or point me to any tests you may have for this when you get a chance?

[benvanik]

(I don't have anything running yet but can try to make a test for this - thanks for implementing it :)

[benvanik]

I haven't tested it yet but one quirk of hsa_amd_signal_wait_any is that it does not allow 0/NULL signal handles. This is inconsistent with the AQL hsa_barrier_or_packet_t that allows any signal to have a 0/NULL value to have it be ignored (effectively). When implementing soft queues that support the barrier packets it'd be nice to be able to pass the dependency signals directly to the APIs without needing to filter them at the application level. The hsa_barrier_and_packet_t treats 0/NULL as having a 0 value (so effectively ignored). This may be worth doing as a separate thing so I'll file a new issue for it (I think your PR #250 is consistent with hsa_amd_signal_wait_any's behavior by checking the validity of signal handles).

[atgutier]

I haven't tested it yet but one quirk of hsa_amd_signal_wait_any is that it does not allow 0/NULL signal handles. This is inconsistent with the AQL hsa_barrier_or_packet_t that allows any signal to have a 0/NULL value to have it be ignored (effectively). When implementing soft queues that support the barrier packets it'd be nice to be able to pass the dependency signals directly to the APIs without needing to filter them at the application level. The hsa_barrier_and_packet_t treats 0/NULL as having a 0 value (so effectively ignored). This may be worth doing as a separate thing so I'll file a new issue for it (I think your PR #250 is consistent with hsa_amd_signal_wait_any's behavior by checking the validity of signal handles).

Sounds good. I think that 0/NULL semantics matching the barrier should be doable.

[benvanik]

Cool! Filed at #252!

[systems-assistant[bot]]

This issue has been migrated to: https://github.com/ROCm/rocm-systems/issues/281