Open hdelan opened 1 year ago
I think the discussion in https://github.com/intel/llvm/issues/4381 might be related.
I am currently working on the multi-device context in CUDA adapter, however this bug is in the L0 adapter/L0 driver. Which is unrelated to the CUDA BE.
As far I can tell, the discussion in #4381 goes beyond CUDA BE/adaptor. I didn't read carefully the whole discussion, so feel free to ignore my comment if it's not relevant.
I am currently working on the multi-device context in CUDA adapter, however this bug is in the L0 adapter/L0 driver. Which is unrelated to the CUDA BE.
Should we close https://github.com/intel/llvm/pull/6446?
Should we close #6446?
Perhaps wait until I have a PR up ;)
As far as I can tell the discussion in #4381 is about how to get the same functionality in CUDA PI/adapter that is currently working (sometimes not working) in L0 PI/adapter.
The L0 adapter should manage data migration between devices in the same context for a given buffer/image
L0 doesnt migrate data between devices. If there's P2P, then peer access is used, instead of migrating the data.
To check if P2P is available, idea is to use sycl::ext::oneapi::peer_access::access_supported. We dont have that support yet in the L0 backend to return the correct value. Suggestion in the meantime would be to either user L0 interop or to use ze_peer https://github.com/oneapi-src/level-zero-tests/tree/master/perf_tests/ze_peer to confirm if such support is available in your target system.
correction here: From @smaslov-intel comment here:
https://github.com/intel/llvm/issues/4381#issuecomment-1130716121
we are migrating buffers, which is what the sample here is referring to. My comment above was above USM.
@smaslov-intel : is the idea that L0 backend also migrates images?
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be automatically closed in 30 days.
Using checkout
clang version 17.0.0 (https://github.com/intel/llvm.git 23a6f389c1e45df077c6f15b691835b2976fda4d)
This may be a problem with the L0 adapter or with the L0 driver that I am using. Any advice would be appreciated.
The L0 adapter should manage data migration between devices in the same context for a given buffer/image. I would expect this to print out 101 for all vals. Instead the L0 driver appears to be segfaulting.
Here is backtrace from gdb: