[Feature]: allow 0/NULL signal handles for wait operations to be no-op.

[benvanik]

Suggestion Description

HSA barrier-AND and barrier-OR packets have special handling for dependency signals that are 0/NULL.

In AND packets (2.9.8 in the spec):

If a dependent signaling pointer has the value NULL it is considered to be constant 0 in the dependency
condition evaluation.

In OR packets (2.9.9 in the spec):

If a dependent signaling pointer has the value NULL it is considered to be constant non-zero in the
dependency condition evaluation.

In both cases it effectively means that a dependent signal being 0/NULL will have that signal be ignored (in AND it will always be TRUE and in OR it will always be FALSE). The hsa_amd_signal_wait_any API and proposed hsa_amd_signal_wait_all (#250) behave differently by asserting if any signal provided is 0/NULL.

As a user of the API it'd be nice if the wait APIs behaved the same as AQL. This allows soft queues that route barrier packets to the host HSA APIs to work without the need to filter the signals from the packets and is more consistent with the HSA queue packet processing flow. Since the implementation of hsa_amd_signal_wait_any and hsa_amd_signal_wait_all are already filtering the signals it doesn't seem like it would add any additional overheads in the implementations whereas with the current behavior an application needs to filter the signals before passing them to HSA which then filters them again.

Operating System

No response

GPU

No response

ROCm Component

No response