When creating a python venv during the install_dependencies script, we try to use ensurepip if it is installed, as it deals better with cases where multiple venvs are active simultaneously. (as seen in CI buildbot)
[ROCm/rocshmem commit: b7a6d86c6b]
When creating a python venv during the install_dependencies script, we try to use ensurepip if it is installed, as it deals better with cases where multiple venvs are active simultaneously. (as seen in CI buildbot)
Enable image build in Windows.
Remove some useless codes that fail building in Windows.
Some minor improvement.
Temporarily exclude mipmap test files.
Prevent negative tests affect some tests.
Move some catch info log codes into failed cases.
The use of std::call_once caused the initialization flag to be set permanently,
preventing proper re-attempts to load libdxcore.so when needed. This change removes
the once_flag mechanism and relies solely on dxcore_handle_ checks to manage library
loading, allowing proper re-initialization attempts.
Signed-off-by: yangsu13 <Yang.Su2@amd.com>
Reviewed-by: Flora Cui <flora.cui@amd.com>
Replace direct D3DKMT API calls with DXCORE_CALL macro in WDDM
thunk layer. This enables dynamic loading of DXCore functions
while maintaining the same API interface.
Updated thunk functions:
- MapGpuVirtualAddress, CreateAllocation, DestroyAllocation
- ReserveGpuVirtualAddress, FreeGpuVirtualAddress
- MakeResident, Evict, ShareObjects
- QueryResourceInfoFromNtHandle, OpenResourceFromNtHandle
All existing functionality is preserved while adding flexibility
for runtime DXCore availability detection.
Signed-off-by: Chengjun Yao <Chengjun.Yao@amd.com>
Signed-off-by: Yang Su <Yang.Su2@amd.com>
Reviewed-by: Shi.Leslie <Yuliang.Shi@amd.com>
Replace direct D3DKMT API calls with DXCORE_CALL macro in WDDM
thunk layer. This enables dynamic loading of DXCore functions
while maintaining the same API interface.
Updated thunk functions:
- MapGpuVirtualAddress, CreateAllocation, DestroyAllocation
- ReserveGpuVirtualAddress, FreeGpuVirtualAddress
- MakeResident, Evict, ShareObjects
- QueryResourceInfoFromNtHandle, OpenResourceFromNtHandle
All existing functionality is preserved while adding flexibility
for runtime DXCore availability detection.
Signed-off-by: Chengjun Yao <Chengjun.Yao@amd.com>
Signed-off-by: Yang Su <Yang.Su2@amd.com>
Reviewed-by: Shi.Leslie <Yuliang.Shi@amd.com>
Remove static linking to libdxcore library from CMakeLists.txt.
This prepares for dynamic loading implementation and eliminates
hard dependency on DXCore being present at build time.
The DXCore functionality will be loaded dynamically at runtime
in subsequent patches, making the library more flexible for
different deployment scenarios.
Signed-off-by: Chengjun Yao <Chengjun.Yao@amd.com>
Signed-off-by: Yang Su <Yang.Su2@amd.com>
Signed-off-by: Flora Cui <flora.cui@amd.com>
Reviewed-by: Shi.Leslie <Yuliang.Shi@amd.com>
For multi-GPU supporting, local heap and system heap managers are
implemented in thunk runtime, so the heap allocation function
ReserveGpuVirtualAddress should be moved to runtime too.
Reviewed-by: Flora Cui <flora.cui@amd.com>
Signed-off-by: tiancyin <tianci.yin@amd.com>
For multi-GPU supporting, local heap and system heap managers are
implemented in thunk runtime, so the heap allocation function
ReserveGpuVirtualAddress should be moved to runtime too.
Reviewed-by: Flora Cui <flora.cui@amd.com>
Signed-off-by: tiancyin <tianci.yin@amd.com>
In multi-GPU, handle aperture is shared between all GPUs, not belongs to
specific one GPU, so move it from wddm device (which presents a specific GPU)
to thunk runtime which has gloable view, can manage handle aperture for all GPUs.
Reviewed-by: Flora Cui <flora.cui@amd.com>
Signed-off-by: tiancyin <tianci.yin@amd.com>
In multi-GPU, handle aperture is shared between all GPUs, not belongs to
specific one GPU, so move it from wddm device (which presents a specific GPU)
to thunk runtime which has gloable view, can manage handle aperture for all GPUs.
Reviewed-by: Flora Cui <flora.cui@amd.com>
Signed-off-by: tiancyin <tianci.yin@amd.com>
In multi-GPU, system heap space is shared between all GPUs, not belongs to
specific one GPU, so move it from wddm device (which presents a specific GPU)
to thunk runtime which has gloable view, can manage system heap for all GPUs.
Introduce a new va_Mgr instance to manage system heap, since local heap
and system heap both comply with SVM(Shared Virtual Memory), without
this new mgr, every allocation has to call KMD at least once (each GPU
needs a call) to allocate GPU VA, the new mgr manage the space itself,
no longer call KMD.
Reviewed-by: Flora Cui <flora.cui@amd.com>
Signed-off-by: tiancyin <tianci.yin@amd.com>
In multi-GPU, system heap space is shared between all GPUs, not belongs to
specific one GPU, so move it from wddm device (which presents a specific GPU)
to thunk runtime which has gloable view, can manage system heap for all GPUs.
Introduce a new va_Mgr instance to manage system heap, since local heap
and system heap both comply with SVM(Shared Virtual Memory), without
this new mgr, every allocation has to call KMD at least once (each GPU
needs a call) to allocate GPU VA, the new mgr manage the space itself,
no longer call KMD.
Reviewed-by: Flora Cui <flora.cui@amd.com>
Signed-off-by: tiancyin <tianci.yin@amd.com>
In multi-GPU, local heap space is shared between all GPUs, not belongs to
specific one GPU, so move it from wddm device (which presents a specific GPU)
to thunk runtime which has gloable view, can manage local heap for all GPUs.
Reviewed-by: Flora Cui <flora.cui@amd.com>
Signed-off-by: tiancyin <tianci.yin@amd.com>
In multi-GPU, local heap space is shared between all GPUs, not belongs to
specific one GPU, so move it from wddm device (which presents a specific GPU)
to thunk runtime which has gloable view, can manage local heap for all GPUs.
Reviewed-by: Flora Cui <flora.cui@amd.com>
Signed-off-by: tiancyin <tianci.yin@amd.com>
Galantsev, Dmitrii
Aurelien Bouteiller
MachineTom
yangsu13
Flora Cui
Chengjun Yao
tiancyin
Horatio Zhang