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]
This reverts commit 3afbe3a155.
Reason for revert: patch does not fix all stream hangs. So another patch was merged which fixes all issues.
Change-Id: I332d1ea29c23747b46b7667fe3e34e0ceefd2b23
[ROCm/clr commit: 1f4176062b]
- stream capture should be done before any sync APIs.
Signed-off-by: sdashmiz <shadi.dashmiz@amd.com>
Change-Id: I3d65f67ee68777be71f97f48d460ccaefdd4e1af
[ROCm/clr commit: be966acb0c]
Skip destruction of the null queue for MT. Windows can destroy worker
thread on exit during the stream destruction, causing a race condition.
Change-Id: I3e4bc3ab2b477d38c0aec1fc59e6f1af0f8f6b0f
[ROCm/clr commit: f39655c0c8]
Parallel streams can be destroyed during capture. Make sure runtime
removes the destoryed streams from the list of parallel captured streams
Change-Id: I46b6cbb951e8711f0bf02f2826c3b890b2541ffe
[ROCm/clr commit: 38ad6234f9]
- Aggregate all TLS(Thread Local Storage) variables into a single class
- This is to improve cache accesses per thread
Change-Id: Ic8361eaeae290fff00254684e309471958365eb9
[ROCm/clr commit: 8b391ef18c]
sdashmiz
Anusha GodavarthySurya
German Andryeyev
Ioannis Assiouras
Sourabh Betigeri
Jaydeep Patel
Christophe Paquot
pghafari
Ajay GunaShekar
Rakesh Roy
Saleel Kudchadker
Sarbojit Sarkar