The current implementation in ROCclr for callback is
based on OCL specification. If in HIP the same command
could get multiple callbacks, then ROCclr will process them in
a reverse order. Unique Markers for each callback will make
sure it won't happen.
Add a dependency wait for callbacks, since HSA signal callback
doesn't guarantee the order.
Change-Id: I9d514734e258312fe9a74d48132361eb17c52d67
With direct dispatch enqueue occurs before callback update and
it can't be tracked in the device backend
Change-Id: Ie8793e3ddb68cc5bb36348f7a8dcdbdc87a2487c
If MT is enabled, then a new callback can be received before the previous
command is processed, causing a conflict of 2 callbacks.
Change-Id: I5ff8f231208e8d62824d590d3c8e791e8e36affb
getLastQueuedCommand(true) will implictly retain the last command, hence if we're not putting it in the waitlist, we should release it.
Change-Id: I1ad4ddcdf1df5237b83e1ea2447eb39a59f7dc3a
Submit explicit profile marker for hipEventRecord to record
timestamps. Enable explicit signal profiling if the API specifies
start and stop events.
Toggle this with env var HIP_FORCE_QUEUE_PROFILING=0
Change-Id: Iae449a63ec3ebf6c2880e65d7b1dd1031a29018f
SWDEV-235579
Move the lock before destroying the queue as there's a multithreaded race condition if the queue
is being destroy and right after we set queue_ to nullptr, another thread can call ihipWaitStreams
which will then call create on that same stream because queue is now nullptr.
Moving the lock on streamSet prevents this from happening because we would remove the stream from that
list and therefore ihipWait will not try to call asHostQueue which tries to create the queue if not created yet
since the stream won't be in the list anymore
Change-Id: I3108657ab403d39d4123e83294fcf1f0880e5563