- Header files inside rocclr/utils when included from hipamd or opencl should be included as #include "rocclr/utils/xxx.h" instead of "utils/xxx.h"
Change-Id: Ic0760c33b9d091f5620dec67e5482c9698d22093
[ROCm/clr commit: 78f62d3230]
Shared mutex allows to have access to the list of streams from
multiple threads at the same time.
Change-Id: Ibee64b846cde03321d5b17dbee2829c0bab7e7d6
[ROCm/clr commit: efd3ea4b30]
=> If null stream is not created during sync skip nullstrm creation
=> Do cpu wait on blocking & null stream if it exists
Change-Id: I90d6ced6a2dd1782ba58f3fed4e3608fc0efa55a
[ROCm/clr commit: 17e7b7c2ef]
=> GraphExec instance is destroyed before async launch completes,
destroy after all pending graph launches
=> Remove GraphExec destroy during next sync point(hipStreamSync,
hipDeviceSync etc..)
Change-Id: I4df682aae5787fd6e5240a7be936ce50361345d0
[ROCm/clr commit: f9f995c6d0]
SPT is destroyed with hipDeviceReset(). If a
stream is created right after reset, the same
object id could be reused. Later SPT destructor
incorrectly verifies that the stream is valid
referring to the reused object id causing the
corruption.
Change-Id: I3b1f7ffdf8bab874dca7b8fde22318162997b8f6
[ROCm/clr commit: f6a68b3c2e]
Releasing graph exec after wait completes and before delete hip::stream obj
during stream destroy.
Change-Id: I1d68aa8d844f7d3af330c6d09c44af07f8553551
[ROCm/clr commit: 8e80429b87]
Handle GraphExec instance is destroyed before async launch completes
GraphExec instance is destroyed after async launch completes
GraphExec instance is destroyed without a launch
Change-Id: I45a7c82295fea916c7559bd8f796df710513aea1
[ROCm/clr commit: bf4d10ff61]
=> hipDeviceSynchronize is not allowed during capture.
=> hipEventSynchronize during capture should return hipErrorCapturedEvent error
=> hipEventQuery during capture should return hipErrorCapturedEvent error
hipStreamSynchronize, hipEventSynchronize, hipStreamWaitEvent, hipStreamQuery
For Side Stream(Stream that is not currently under capture):
=> If current thread is capturing in relaxed mode, calls are allowed
=> If any stream in current/concurrent thread is capturing in global mode, calls are not allowed
=> If any stream in current thread is capturing in ThreadLocal mode, calls are not allowed
For Stream that is currently under capture
=> calls are not allowed
=> Any call that is not allowed during capture invalidates the capture sequence
=> It is invalid to call synchronous APIs during capture. Synchronous APIs,
such as hipMemcpy(), enqueue work to the legacy stream and synchronize it before returning.
Change-Id: I201c6e63e1a5d93fd416a3b520264c0fdbe31237
[ROCm/clr commit: 19b4660cbb]
Mempool has capability to track dependency between streams for
faster memory reuse. Enable that capability.
Change-Id: I28266a7e38d0fc4c5d027b9542d3719653840821
[ROCm/clr commit: 17d0c166d2]
Windows path still uses multi threading implementation. Hence, in graphs
all nodes are executed in a queue thread and that requires to manage
mempool in the queue thread. However, the spec allows to destory memory,
allocated in a graph, outside of the graph's execution. That may cause
mempool management to go out of sync.
Change-Id: I0ffb2244b3cb720455ed44d1b3e2487fa8959a77
[ROCm/clr commit: 4f6b0da028]
During hipGraphExecKernelNodeSetParams kernel function can also be updated.
Hence size required for kernel parameters differs from what is allocated during graphInstantiation.
So, create new 128KB kernel pool and allocate kernel args from the pool.
If the pool is full create new 128KB pool. Release kernel pools when graph exec object is destroyed.
Change-Id: I9567946d63400c79cbfd4c5439c654c92557ceae
[ROCm/clr commit: e9957151f3]
Runtime has to release extra memory, held by the pools,
in synchronization points for event, stream or device.
Change-Id: Id533a5e1d137812aa72bdfe101b4b333c6a43d66
[ROCm/clr commit: 3fa4e31180]
- hipArray will be an internal struct from rocm6.0
Signed-off-by: sdashmiz <shadi.dashmiz@amd.com>
Change-Id: Icf97fe96b87be8532098cd7f9ceaad099f99c9b9
[ROCm/clr commit: c089ef4a2b]
hipStreamSynchronize and hipDeviceSynchronize won't longer wait
for CPU commands in DD mode
Change-Id: I079c8bbfc34ddc6d3e2d74c92a34665877e512a5
[ROCm/clr commit: fbea58ba11]
Updating hip_init lock to use std::call_once fixed Performance
drops in TF benchmarks for FP16
Change-Id: Ib1125ac66806b232057ba183e296ea4d0642d08d
[ROCm/clr commit: 2f83719d12]
Avoid syncing blocking streams with the default stream,
since that introduces extra command dependencies and
doesn't allow to destroy memory after last submission
Change-Id: I618e9bd2091c4cf9157125612d8c4759030c5a80
[ROCm/clr commit: 1e88d2c52f]
- invalid to synchronize or query the execution status of a capturing stream but non-capturing streams can.
- If any local thread has an ongoing or concurrent capture sequence initiated with hipStreamCaptureModeGlobal, it is prohibited from unsafe calls
Change-Id: Ifa641e807216d3b7c3e8c2fb1be2f7a50bd641df
[ROCm/clr commit: 7809d2846b]
This reverts commit 1932e88970.
Reason for revert: HIP tests on windows fails
Change-Id: I795ed19d76a41e2fd9971414cefa5bd3be45d4bc
[ROCm/clr commit: 08c8972d97]
Anusha GodavarthySurya
Marko Arandjelovic
German Andryeyev
Saleel Kudchadker
Satyanvesh Dittakavi
Vladana Stojiljkovic
kjayapra-amd
Sourabh Betigeri
Jaydeep Patel
Julia Jiang
sdashmiz
Ioannis Assiouras
Christophe Paquot