[UR][L0v2] Add graph support for batched queue by KFilipek · Pull Request #21324 · intel/llvm

KFilipek · 2026-02-19T13:07:12Z

This PR adds support for graph capture and execution in the Level Zero v2 batched queue implementation.

Changes:

Add command list determination mechanism that switches between immediate and regular command lists based on graph
capture state
Implement previously unsupported graph API methods:
- queueBeginGraphCapteExp() - begin graph capture
- queueBeginCapteIntoGraphExp() - begin capture into existing graph
- queueEndGraphCapteExp() - end graph capture
- queueIsGraphCapteEnabledExp() - check capture status
- enqueueGraphExp() - execute captured graph
Update operations to use appropriate command list and event pool during graph capture

…thods

kswiecicki · 2026-02-20T10:59:13Z

unified-runtime/source/adapters/level_zero/v2/queue_batched.cpp

                           .borrow(hDevice->Id.value(), eventFlags);
 }

 ur_event_handle_t ur_queue_batched_t::createEventIfRequestedRegular(


It should no longer be createEventIfRequestedRegular since there's an event_pool param that decides the origin of created event.

kswiecicki · 2026-02-20T10:59:21Z

unified-runtime/source/adapters/level_zero/v2/queue_batched.cpp

 ur_event_handle_t ur_queue_batched_t::createEventAndRetainRegular(
-    ur_event_handle_t *phEvent, ur_event_generation_t batch_generation) {
-  auto hEvent = eventPoolRegular->allocate();
+    event_pool *pool, ur_event_handle_t *phEvent,


kswiecicki · 2026-02-20T13:17:02Z

unified-runtime/source/adapters/level_zero/v2/queue_batched.hpp


-  ur_result_t queueBeginGraphCapteExp() override {
-    return UR_RESULT_ERROR_UNSUPPORTED_FEATURE;
+  ur_result_t enqueueGraphExp(ur_exp_executable_graph_handle_t hGraph,


I think only helper methods are defined here. Implementations of the enqueue operation for batched queue are stored in the queue_batched.cpp.

kswiecicki · 2026-02-20T13:19:37Z

unified-runtime/source/adapters/level_zero/v2/queue_batched.cpp


  markIssuedCommandInBatch(currentRegular);

-  UR_CALL(currentRegular->getActiveBatch().appendKernelLaunch(


getActiveBatch is no longed used anywhere.

kswiecicki · 2026-02-20T14:53:21Z

unified-runtime/source/adapters/level_zero/v2/queue_batched.cpp

@@ -189,14 +195,19 @@

  TRACK_SCOPE_LATENCY("ur_queue_batched_t::enqueueKernelLaunch");
  auto currentRegular = currentCmdLists.lock();


lockedBatch is more fitting than currentRegular.

kswiecicki · 2026-02-20T15:13:33Z

unified-runtime/source/adapters/level_zero/v2/queue_batched.cpp

  TRACK_SCOPE_LATENCY("ur_queue_batched_t::enqueueKernelLaunch");
  auto currentRegular = currentCmdLists.lock();
+  auto &eventPool =
+      currentRegular->isGraphCapture() ? eventPoolImmediate : eventPoolRegular;


You might also move the event pool choosing logic to a helper method getEventPool or something, like you did for getListManager. Perhaps there could also be getCurrentGeneration helper method in batched queue.

I would suggest a helper method for generating events, since the event pool is needed only to create an event to be passed as an argument for command list manager functions.

Such a helper could look like this:

ur_event_t ur_queue_batched_t::getEvent(ur_event_handle_t *phEvent, ur_event_generation_t batch_generation) { if (isGraphCapture()) { return createEventIfRequestedRegular(phEvent, batch_generation); } else { return createEventIfRequested(eventPoolImmediate.get(), phEvent, this); }

Where createEventIfRequested(...) is a default implementation from event_pool.hpp . There should also be a version with retaining events.

This way, enqueueing operations is simplified to:

UR_CALL(currentRegular->getListManager().appendKernelLaunch( hKernel, workDim, pGlobalWorkOffset, pGlobalWorkSize, pLocalWorkSize, launchPropList, waitListView, getEvent(phEvent, currentRegular->getCurrentGeneration())));

EuphoricThinking · 2026-02-23T12:42:30Z

unified-runtime/source/adapters/level_zero/v2/queue_batched.hpp

+  // capture. If the graph capture is active, the immediate command list manager
+  // handle is returned, otherwise the regular command list manager handle is
+  // returned.
+  ur_command_list_manager &getListManager() {


I would add a comment on why we need an immediate list when the graph capture is active

EuphoricThinking · 2026-02-23T12:58:50Z

unified-runtime/source/adapters/level_zero/v2/queue_batched.cpp

  TRACK_SCOPE_LATENCY("ur_queue_batched_t::enqueueKernelLaunch");
  auto currentRegular = currentCmdLists.lock();
+  auto &eventPool =
+      currentRegular->isGraphCapture() ? eventPoolImmediate : eventPoolRegular;


I would suggest a helper method for generating events, since the event pool is needed only to create an event to be passed as an argument for command list manager functions.

Such a helper could look like this:

ur_event_t ur_queue_batched_t::getEvent(ur_event_handle_t *phEvent, ur_event_generation_t batch_generation) { if (isGraphCapture()) { return createEventIfRequestedRegular(phEvent, batch_generation); } else { return createEventIfRequested(eventPoolImmediate.get(), phEvent, this); }

Where createEventIfRequested(...) is a default implementation from event_pool.hpp . There should also be a version with retaining events.

This way, enqueueing operations is simplified to:

UR_CALL(currentRegular->getListManager().appendKernelLaunch( hKernel, workDim, pGlobalWorkOffset, pGlobalWorkSize, pLocalWorkSize, launchPropList, waitListView, getEvent(phEvent, currentRegular->getCurrentGeneration())));

EuphoricThinking · 2026-02-23T13:10:49Z

unified-runtime/source/adapters/level_zero/v2/queue_batched.hpp

-  ur_event_handle_t
-  createEventAndRetainRegular(ur_event_handle_t *phEvent,
-                              ur_event_generation_t batch_generation);
+  ur_event_handle_t createEventAndRetainRegular(


After this patch, this function is not used anywhere, so it could be removed.

EuphoricThinking · 2026-02-23T13:18:18Z

unified-runtime/source/adapters/level_zero/v2/queue_batched.hpp

    return maxNumberOfEnqueuedOperations <= enqueuedOperationsCounter;
  }
+
+  bool isGraphCapture() const { return isGraphCaptureActive; }


Maybe isGraphCaptureActive()?

EuphoricThinking · 2026-02-23T13:25:03Z

unified-runtime/source/adapters/level_zero/v2/queue_batched.hpp

+        batchLocked->isGraphCapture() ? eventPoolImmediate : eventPoolRegular;
+    return batchLocked->getListManager().appendGraph(
+        hGraph, waitListView,
+        createEventIfRequestedRegular(


Does it work when graph capturing is not active? Is it possible to enqueue a graph on a regular command list?

Is it possible to enqueue a graph on a regular command list?

Not sure, let's test it. What definitely doesn't work, is enqueuing a command buffer (i.e., another command list) on a regular command list.

KFilipek requested a review from a team as a code owner February 19, 2026 13:07

KFilipek marked this pull request as draft February 19, 2026 13:07

KFilipek had a problem deploying to WindowsCILock February 19, 2026 13:07 — with GitHub Actions Error

KFilipek self-assigned this Feb 19, 2026

KFilipek force-pushed the 07-graph_for_batched branch from 560edb4 to 7c9779b Compare February 19, 2026 13:12

KFilipek temporarily deployed to WindowsCILock February 19, 2026 13:13 — with GitHub Actions Inactive

KFilipek had a problem deploying to WindowsCILock February 19, 2026 13:34 — with GitHub Actions Failure

KFilipek temporarily deployed to WindowsCILock February 19, 2026 13:34 — with GitHub Actions Inactive

KFilipek temporarily deployed to WindowsCILock February 20, 2026 09:39 — with GitHub Actions Inactive

KFilipek added 2 commits February 20, 2026 11:35

[!] implement command list determine mechanism

c7fc9d6

[!] implement graph API for batched queue

9d59915

KFilipek force-pushed the 07-graph_for_batched branch from 09eaf7d to 2200aa5 Compare February 20, 2026 10:43

KFilipek had a problem deploying to WindowsCILock February 20, 2026 10:44 — with GitHub Actions Error

[!] implement enqueue graph API for batched queue and change event me…

3f6298f

…thods

KFilipek force-pushed the 07-graph_for_batched branch from 2200aa5 to 3f6298f Compare February 20, 2026 10:53

KFilipek temporarily deployed to WindowsCILock February 20, 2026 10:55 — with GitHub Actions Inactive

KFilipek temporarily deployed to WindowsCILock February 20, 2026 11:20 — with GitHub Actions Inactive

KFilipek had a problem deploying to WindowsCILock February 20, 2026 11:20 — with GitHub Actions Failure

KFilipek temporarily deployed to WindowsCILock February 20, 2026 11:20 — with GitHub Actions Inactive

KFilipek had a problem deploying to WindowsCILock February 20, 2026 11:30 — with GitHub Actions Failure

kswiecicki requested changes Feb 20, 2026

View reviewed changes

KFilipek temporarily deployed to WindowsCILock February 23, 2026 09:10 — with GitHub Actions Inactive

KFilipek requested a review from EuphoricThinking February 23, 2026 09:41

EuphoricThinking requested changes Feb 23, 2026

View reviewed changes

KFilipek had a problem deploying to WindowsCILock February 23, 2026 14:44 — with GitHub Actions Error

[!] simplify creating an event

66e360e

KFilipek force-pushed the 07-graph_for_batched branch from 1d21010 to 66e360e Compare February 23, 2026 14:47

KFilipek temporarily deployed to WindowsCILock February 23, 2026 14:48 — with GitHub Actions Inactive

KFilipek had a problem deploying to WindowsCILock February 23, 2026 15:09 — with GitHub Actions Failure

KFilipek temporarily deployed to WindowsCILock February 23, 2026 15:09 — with GitHub Actions Inactive


		markIssuedCommandInBatch(currentRegular);

		UR_CALL(currentRegular->getActiveBatch().appendKernelLaunch(

		@@ -189,14 +195,19 @@

		TRACK_SCOPE_LATENCY("ur_queue_batched_t::enqueueKernelLaunch");
		auto currentRegular = currentCmdLists.lock();

Conversation

KFilipek commented Feb 19, 2026

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!

4 participants