oneapi-src
[L0 v2] make v2 adapter usable through the loader
@pbalcer do you think we could expose L0 v2 adapter through ur_platform_backend_t so we woulnd't have to use a special value like I did in this PR? We expect L0 to coexists along L0 v2 for some time, anyway, right?
I've made this PR because I realized that after https://github.com/oneapi-src/unified-runtime/pull/2168 v2 tests are failing.
@RossBrunton from what I observed if -DUR_CONFORMANCE_TEST_LOADER=1 is passed then both -loader and regular tests (that should be using UR_ADAPTER_FORCE_LOAD) are actually using the loader. I don't even see UR_ADAPTER_FORCE_LOAD anywhere in the logs when I run ctest with --verbose. I wonder if do_add_test handles env variables correctly. Looking at https://github.com/RossBrunton/unified-runtime/blob/8c5c5ad17adc400c42b2c3d58df547a4e9dd2076/test/conformance/CMakeLists.txt#L21C32-L21C35 I don't see the env being anywhere.
We could, but I'd be worried how SYCL would behave, having to chose the correct implementation. Maybe the solution here is to use the appropriate value, but instead hide the adapter by default from urAdapterGet if it wasn't explicitly selected using ONEAPI_DEVICE_SELECTOR=level_zero2:* or something.
We expect L0 to coexists along L0 v2 for some time, anyway, right?
I would expect to remove the legacy adapter after a single release of them coexisting. We wouldn't want to implement features in both for very long.
I would expect to remove the legacy adapter after a single release of them coexisting. We wouldn't want to implement features in both for very long.
@pbalcer Right, but do already have a timeline for implementing all the remaining queue modes? Without them, v2 won't be a full replacement for the legacy adapter.
I would expect to remove the legacy adapter after a single release of them coexisting. We wouldn't want to implement features in both for very long.
@pbalcer Right, but do already have a timeline for implementing all the remaining queue modes? Without them, v2 won't be a full replacement for the legacy adapter.
I think it remains to be seen whether we actually need to do that. If there's no performance difference (or perf is better), why bother? Especially with the normal command lists.
Looks like there was a bug in the environment setting logic, which is fixed by https://github.com/oneapi-src/unified-runtime/pull/2198 . Sorry for missing that!
