Adobe AE allocates/destroys system memory per each frame
in some effects, which is a very expensive operation.
Disable pinning and force sysmem allocation in VidMM.
That allows to trigger resource cache in runtime and
avoid paging operations, caused by pinning.
The actual benchmark doesn't have significant improvement
from the change, but GPU view traces are much cleaner.
Change-Id: I92cdd87d37c64611788f05250f71d6fe489b4d7e
Pinned copy can cause big performance drops, because slow pinning under Windows.
Use up to 128MB for staging transfers. Change staging buffer size to 4MB.
Linux path should still have the old defaults.
Change-Id: I954edceb3ec89e8e670be116aa2d0a9564c8b11c
This reverts commit 4afca0647e.
Reason for revert: ROCr query should now be usable in upcoming release.
Change-Id: I2207761ca6af5d585d090bae1af09eb9a8e9bad6
Sync between compute and SDMA engines can be very expensive under Windows.
Use CP DMA for tiny transfers (< 1KiB) to avoid syncs and improve performance.
Change-Id: I9db39a2199f7b9e337ed08fd36d9cbc150502f1f
HIP can't rely on the resource tracking, used in OCL and requires different explicit sync.
Make sure ROCCLR syncs compute only when SDMA is used and vise versa.
The new logic will allow to enable CPDMA without unnecessary waits.
Change-Id: Ib9d1788cfd5afa5ea2fec4c96a37d8b9c4d0059d
Blender creates and destroys big allocations during the benchmark.
That causes big delays, because vidmm has to page-in/page-out memory.
Change-Id: I2baf4545807127406e3d2870a7581ff9ae7bcdb5
- Make sure SQQT trace is captured for RGP server if the queue is destroyed before normal capture is done.
- Remove prepare queue from the logic. It's not really used for any HW capture and can cause RGP server abort if destroyed before capture is even started(delayed capture)
Change-Id: I6eb19963190a5769c6477a5496c1b831a6d59b89
In X86 on Windows, sizeof(size_t)=4, but size=8, for
amd::KernelParameterDescriptor::HiddenGlobalOffsetX/Y/Z items.
Loose the condition to prevent crash.
Change-Id: I2216f71f4d4fd6dd3766023b1c821cb3d35d7848
The ROCclr assigns zero-based IDs to GPUs in the order they are
discovered. That zero-based ID is what is used to identify the GPU
on which the HIP_OPS activity took place.
When multiple ranks are used, each rank's first logical device always
has GPU ID 0, regardless of which physical device is selected with
CUDA_VISIBLE_DEVICES. Because of this, when merging trace files from
multiple ranks, GPU IDs from different processes may overlap.
The long term solution is to use the KFD's gpu_id which is stable
across APIs and processes. Unfortunately the gpu_id is not yet exposed
by the ROCr, so for now use the driver's node id.
Change-Id: Ib78854527d600d175bb76e2df0747c33f898c615
- Use a dirty flag to determine fence optimization
- If fence is dirty submit a marker at top level to sync.
Change-Id: I53fb19b5bb05b7c7b37c41637a6c7aaf870b639a
Jacob Lambert
jatang
kjayapra-amd
Todd tiantuo Li
Ioannis Assiouras
pghafari
Jaydeep Patel
German
Saleel Kudchadker
Tao Sang
Sourabh Betigeri
Anusha GodavarthySurya
Alex Xie
Juan Manuel MARTINEZ CAAMAÑO
Maneesh Gupta
Julia Jiang
Laurent Morichetti
Ajay
Alex (Bin) Xie
Christophe Paquot