[UR][L0v2] Reuse L0 default context for full-platform SYCL contexts by mateuszpn · Pull Request #21789 · intel/llvm

mateuszpn · 2026-04-16T12:16:24Z

When a SYCL context is created with all root devices of a Level Zero platform, the L0 v2 adapter now calls zeDriverGetDefaultContext instead of zeContextCreate. This ensures SYCL shares the same ze_context_handle_t with other L0 users (e.g. PyTorch), eliminating USM/IPC/residency conflicts from multiple independent contexts over the same driver.

guangyey

Thanks!

pbalcer · 2026-04-21T07:56:10Z

+// Before the fix: urContextCreate always calls zeContextCreate, so two
+// full-platform contexts have different ze_context handles -> test FAILS.
+// After the fix:  urContextCreate reuses the driver default context, so both
+// calls return the same handle -> test PASSES.


Suggested change

// Before the fix: urContextCreate always calls zeContextCreate, so two

// full-platform contexts have different ze_context handles -> test FAILS.

// After the fix: urContextCreate reuses the driver default context, so both

// calls return the same handle -> test PASSES.

pbalcer · 2026-04-21T07:59:15Z

+      std::cout << "PASS: platform default context matches.\n";
+    }
+  }
+


it might also be useful to check that the native handles match the one returned by zeDriverGetDefaultContext.

pbalcer · 2026-04-21T08:02:00Z

+    # Detect whether the Level Zero SDK provides zeDriverGetDefaultContext.
+    # Older L0 loaders do not export this symbol; the guard prevents link failures.
+    # We only check for the typedef in ze_ddi.h to avoid a link step.
+    include(CheckCXXSourceCompiles)
+    set(_UR_L0_SAVED_CMAKE_REQUIRED_INCLUDES "${CMAKE_REQUIRED_INCLUDES}")
+    get_target_property(_L0_INCLUDE_DIRS LevelZeroLoader-Headers INTERFACE_INCLUDE_DIRECTORIES)
+    set(CMAKE_REQUIRED_INCLUDES ${_L0_INCLUDE_DIRS})
+    check_cxx_source_compiles(
+        "#include <ze_ddi.h>\nint main() { ze_pfnDriverGetDefaultContext_t fn = nullptr; (void)fn; return 0; }"
+        HAVE_ZE_DRIVER_GET_DEFAULT_CONTEXT
+    )
+    set(CMAKE_REQUIRED_INCLUDES "${_UR_L0_SAVED_CMAKE_REQUIRED_INCLUDES}")
+    unset(_UR_L0_SAVED_CMAKE_REQUIRED_INCLUDES)
+    if(HAVE_ZE_DRIVER_GET_DEFAULT_CONTEXT)
+        target_compile_definitions(ur_adapter_level_zero_v2 PRIVATE
+            HAVE_ZE_DRIVER_GET_DEFAULT_CONTEXT)
+    endif()
+


Have you encountered link failures? It shouldn't be possible. We hardcode the level-zero loader we link against. This shouldn't be required.

pbalcer · 2026-04-21T08:02:57Z

-  ZE2UR_CALL(zeContextCreate, (hPlatform->ZeDriver, &contextDesc, &zeContext));
+  bool ownZeContext = true;
+
+  if (!pProperties && isFullPlatformRootDeviceList(deviceCount, phDevices)) {


why check against properties being non-null?

It's still being checked. This looks like an unrelated change to me.

pbalcer · 2026-04-21T08:16:15Z

+static bool isDriverRootDevice(ze_device_handle_t zeDevice) {
+  ze_device_handle_t zeRootDevice = nullptr;
+  ze_result_t zeResult =
+      ZE_CALL_NOCHECK(zeDeviceGetRootDevice, (zeDevice, &zeRootDevice));
+
+  if (zeResult == ZE_RESULT_SUCCESS) {
+    return zeRootDevice == nullptr || zeRootDevice == zeDevice;
+  }
+
+  // If unsupported, keep behavior compatible with older loaders/drivers.
+  if (zeResult == ZE_RESULT_ERROR_UNSUPPORTED_FEATURE) {
+    return true;
+  }
+
+  return false;
+}
+
+static bool isFullPlatformRootDeviceList(uint32_t deviceCount,
+                                         const ur_device_handle_t *phDevices) {
+  if (deviceCount == 0 || !phDevices) {
+    return false;
+  }
+
+  ur_platform_handle_t hPlatform = phDevices[0]->Platform;
+
+  std::vector<ze_device_handle_t> requestedDevices;
+  requestedDevices.reserve(deviceCount);
+  for (uint32_t i = 0; i < deviceCount; ++i) {
+    if (!phDevices[i] || phDevices[i]->Platform != hPlatform ||
+        phDevices[i]->RootDevice) {
+      return false;
+    }
+
+    if (!isDriverRootDevice(phDevices[i]->ZeDevice)) {
+      return false;
+    }
+
+    requestedDevices.push_back(phDevices[i]->ZeDevice);
+  }
+
+  sortAndUnique(requestedDevices);
+
+  uint32_t zeDeviceCount = 0;
+  ze_result_t zeResult = ZE_CALL_NOCHECK(
+      zeDeviceGet, (hPlatform->ZeDriver, &zeDeviceCount, nullptr));
+  if (zeResult != ZE_RESULT_SUCCESS || zeDeviceCount == 0) {
+    return false;
+  }
+
+  std::vector<ze_device_handle_t> platformDevices(zeDeviceCount);
+  zeResult = ZE_CALL_NOCHECK(zeDeviceGet, (hPlatform->ZeDriver, &zeDeviceCount,
+                                           platformDevices.data()));
+  if (zeResult != ZE_RESULT_SUCCESS) {
+    return false;
+  }
+
+  platformDevices.resize(zeDeviceCount);
+  platformDevices.erase(std::remove_if(platformDevices.begin(),
+                                       platformDevices.end(),
+                                       [](ze_device_handle_t zeDevice) {
+                                         return !isDriverRootDevice(zeDevice);
+                                       }),
+                        platformDevices.end());
+
+  if (platformDevices.empty()) {
+    return false;
+  }
+
+  sortAndUnique(platformDevices);
+
+  return requestedDevices == platformDevices;
+}
+


This duplicates some of the logic that already exists around urDeviceGet.

llvm/unified-runtime/source/adapters/level_zero/platform.hpp

Line 81 in 0363625

std::vector<std::unique_ptr<ur_device_handle_t_>> URDevicesCache;

I think it might be better to simply compare the devices on the user-provided device list against the list of devices returned from urDeviceGet with default parameters.

pbalcer · 2026-04-29T09:24:13Z

If !phDevices[0] is null, user gave us an incorrect device array. I'd check that earlier or propagate an error to the API.

The checks are moved to the top of urContextCreate

pbalcer · 2026-04-29T09:26:12Z

why is this needed?

The checks are moved to urContextCreate, so the conditions may be removed here.

pbalcer · 2026-04-29T09:30:12Z

maybe we should fail if zeDriverGetDefaultContext doesn't succeed?

Hmm. Previously, we would always create a new context; now we fall back to the same behavior if zeDriverGetDefaultContext fails, which seems reasonable.

Won't zeDriverGetDefaultContext fail on older drivers? I see // REQUIRES-INTEL-DRIVER: lin: 36300 requirement in the SYCL e2e tests.

@kswiecicki there was an issue with us calling a function present in the loader, but not present in the driver. The device sync if i recall correctly. Is this the same scenario?

zeDriverGetDefaultContext fails, which seems reasonable.

Right, makes sense.

If I remember correctly the device sync call was crashing for some reason instead of returning an error., but I believe that was a unique case.

pbalcer · 2026-04-29T09:30:40Z

-  ZE2UR_CALL(zeContextCreate, (hPlatform->ZeDriver, &contextDesc, &zeContext));
+  bool ownZeContext = true;
+
+  if (!pProperties && isFullPlatformRootDeviceList(deviceCount, phDevices)) {


It's still being checked. This looks like an unrelated change to me.

kswiecicki · 2026-04-30T10:36:24Z

phDevices and phContext param checks are already done in the validation layer here.
We could the following restriction to the spec though:

- $X_RESULT_ERROR_INVALID_SIZE: - "`deviceCount == 0`"

@pbalcer what do you think?

@kswiecicki yes, we should just add a check to the validation layer.

kswiecicki · 2026-04-30T10:44:43Z

You can use UR_ASSERT(phDevices[i], UR_RESULT_ERROR_INVALID_NULL_HANDLE).
We could add something along the lines to the spec too:

- $X_RESULT_ERROR_INVALID_NULL_HANDLE - "If device handles in phDevices are not valid handles."

kswiecicki · 2026-04-30T10:59:09Z

Won't zeDriverGetDefaultContext fail on older drivers? I see // REQUIRES-INTEL-DRIVER: lin: 36300 requirement in the SYCL e2e tests.

kswiecicki · 2026-04-30T11:37:49Z

nit: Instead of setting that, you could just create the ur_context_handle_t_ here and return UR_RESULT_SUCCESS.
Then if (!zeContext) { and bool ownZeContext = true fragments could be removed.
Also, is zeDefaultContext necessary since there's zeContext variable that can hold ze_context_handle_t type already.

mateuszpn added 4 commits April 16, 2026 11:31

add test for reusing default context

61e3d35

reuse L0 default context for SYCL default context

f4d2c94

update L0 backend spec

dfce82a

guard against old driver

f78b573

mateuszpn force-pushed the def-context branch 2 times, most recently from dcac904 to 1e8166f Compare April 16, 2026 14:17

mateuszpn marked this pull request as ready for review April 16, 2026 14:20

mateuszpn requested review from a team as code owners April 16, 2026 14:20

mateuszpn force-pushed the def-context branch from 1e8166f to bfbf497 Compare April 16, 2026 14:40

guard against old driver

343d964

mateuszpn force-pushed the def-context branch from bfbf497 to 343d964 Compare April 16, 2026 14:48

guangyey reviewed Apr 18, 2026

View reviewed changes

gmlueck reviewed Apr 20, 2026

View reviewed changes

Comment thread sycl/doc/extensions/supported/sycl_ext_oneapi_backend_level_zero.md Outdated

pbalcer reviewed Apr 21, 2026

View reviewed changes

gmlueck approved these changes Apr 23, 2026

View reviewed changes

bratpiorka requested a review from pbalcer April 27, 2026 09:16

mateuszpn force-pushed the def-context branch 2 times, most recently from 08c8f80 to 2597696 Compare April 28, 2026 14:18

apply comments

2597696

pbalcer reviewed Apr 29, 2026

View reviewed changes

mateuszpn force-pushed the def-context branch from ec47406 to e915336 Compare April 29, 2026 16:54

apply comments

e915336

kswiecicki reviewed Apr 30, 2026

View reviewed changes

kswiecicki mentioned this pull request Apr 30, 2026

[UR][L0] Restrict USM residency to peers with enabled P2P access #21889

Open

Conversation

mateuszpn commented Apr 16, 2026

Uh oh!

guangyey left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants