HIP should block the stream until callback is done. This change
will introduce extra marker that will block the queue.
Note: MT path doesn't really require extra marker, but the logic
is identical to avoid extra checks for direct dispatch
Change-Id: Ib90fd2d751adf337f5e43ac6098e84767530233b
On StreamBegincapture captures the parameters passed to APIs and respective node will be created and added to graph
All parameters are passed to STREAM_CAPTURE macro, it checks if stream in capture mode and redirects the call to the capture function and returns
Updated hipStream and hipEvent with capture parameters
Added handling for hipStreamBeginCapture & hipStreamEndCapture
Change-Id: Ic8926a7b4336c2cc81f0b3a9a224aa392c474134
Fix wrong mixing of current device and stream device in
ihipModuleLaunchKernel() and hipLaunchCooperativeKernel().
Fix missing hipSetDevice() in hipMemcpyWithStream* tests.
Change-Id: I09333bb40d239bb42c832df5ea16d17eeaeff5e7
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
German Andryeyev
Saleel Kudchadker
Anusha Godavarthy Surya
Tao Sang
Rahul Garg
Sarbojit Sarkar
Aryan Salmanpour
Vladislav Sytchenko
Christophe Paquot
Payam
kjayapra-amd