Use ROC_ENABLE_LARGE_BAR (0/1) to toggle. The support is
enabled by default.
Change-Id: I6cb93a46594cb6f5e90bf6057738330225efb553
[ROCm/clr commit: d10d691e76]
This issue happens because we getLastQueuedCommand when recording
the event and do end_ - start_ so it takes the ticks for the
completion of the last command before event record. This may not
happen if one records a marker command for hipEventRecord
Change-Id: I1d6b06a5befb3b93f16b67692c59dca25c982e0f
[ROCm/clr commit: 5b60eee02e]
This issue happens because we getLastQueuedCommand when recording
the event and do end_ - start_ so it takes the ticks for the
completion of the last command before event record. This may not
happen if one records a marker command for hipEventRecord
Change-Id: I1d6b06a5befb3b93f16b67692c59dca25c982e0f
This issue happens because we getLastQueuedCommand when recording
the event and do end_ - start_ so it takes the ticks for the
completion of the last command before event record. This may not
happen if one records a marker command for hipEventRecord
Change-Id: I1d6b06a5befb3b93f16b67692c59dca25c982e0f
[ROCm/hip commit: 43986c6791]
This issue happens because we getLastQueuedCommand when recording
the event and do end_ - start_ so it takes the ticks for the
completion of the last command before event record. This may not
happen if one records a marker command for hipEventRecord
Change-Id: I1d6b06a5befb3b93f16b67692c59dca25c982e0f
Maintain compatability with the old finding for now for the
convenience of commit order.
Change-Id: I99b236cbb3d61b00650e3da7fe5931d4c4b3fec6
[ROCm/clr commit: 1f0c398a6f]
Maintain compatability with the old finding for now for the
convenience of commit order.
Change-Id: I99b236cbb3d61b00650e3da7fe5931d4c4b3fec6
[ROCm/hip commit: 024764c337]
In the case where SQ_WAVE_TRAPSTS_XNACK_ERROR_MASK is set, we also need
to set the TTMP11_EXCP_RAISED_BIT in ttmp11. If we don't, the debugger
may think that the wave is halted at launch (halted without events).
Change-Id: I8c19605bbfc145275728de4ad1979d3ba8bb478a
In the case where SQ_WAVE_TRAPSTS_XNACK_ERROR_MASK is set, we also need
to set the TTMP11_EXCP_RAISED_BIT in ttmp11. If we don't, the debugger
may think that the wave is halted at launch (halted without events).
Change-Id: I8c19605bbfc145275728de4ad1979d3ba8bb478a
[ROCm/ROCR-Runtime commit: 838c6bd6ad]
Mesa address lib faults if the only acceptable swizzle modes are
forbidden. The old address lib simply ignored the forbidden list
in this case. Mesa addrlib will not select linear unless there
is no other option so allowing linear mode for tiled images will
still use tiled modes when possible.
Change-Id: I1aa44d072db902c968484dbff67b482af03b45d9
Mesa address lib faults if the only acceptable swizzle modes are
forbidden. The old address lib simply ignored the forbidden list
in this case. Mesa addrlib will not select linear unless there
is no other option so allowing linear mode for tiled images will
still use tiled modes when possible.
Change-Id: I1aa44d072db902c968484dbff67b482af03b45d9
[ROCm/ROCR-Runtime commit: c60364e1e0]
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
[ROCm/clr commit: 163fdd6b74]
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
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
[ROCm/hip commit: 6b361bc1a0]
Saleel Kudchadker
Evgeny
Jason Tang
Christophe Paquot
Karthik Jayaprakash
Matt Arsenault
Chauncey Hui
Laurent Morichetti
Sean Keely
Payam Ghafari
Pruthvi Madugundu