[SYCL][Graph] Update spec for native recording mode#21616
[SYCL][Graph] Update spec for native recording mode#21616adamfidel wants to merge 3 commits intointel:syclfrom
Conversation
sycl/doc/extensions/experimental/sycl_ext_oneapi_graph.asciidoc
Outdated
Show resolved
Hide resolved
| mechanism. | ||
|
|
||
| Because capture happens at the backend level, the SYCL runtime has no | ||
| visibility into the captured commands. As a result: |
There was a problem hiding this comment.
Does it make sense to just link to 12.2. Limitations of Native Recording here to avoid duplicating the limitations?
| | Implies update support which is unavailable for native recording. | ||
| | `feature_not_supported` | ||
|
|
||
| | Multiple queues recording to the same graph simultaneously |
There was a problem hiding this comment.
I think we need a similar wording adjustment as suggested in the property section. Multiple queue recording is supported but only with queue transition.
| When `property::graph::enable_native_recording` was set on the graph, | ||
| this call delegates to the backend's native graph-capture mechanism | ||
| rather than transitioning the queue through the SYCL runtime recording state model. | ||
| In this mode only a single queue may be recording at a time for a given graph. |
There was a problem hiding this comment.
We should mention that this can only be called once per graph and clarify regarding the multi-queue recording.
| . Calling `update()` on an executable graph created from a graph with | ||
| `property::graph::enable_native_recording`. | ||
|
|
||
| == Revision History |
There was a problem hiding this comment.
Probably want to update this as well.
| | `get_nodes()` / `get_root_nodes()` | ||
| | No SYCL node model is built during native capture; returns empty vectors. | ||
| | _(no exception — returns empty)_ | ||
|
|
There was a problem hiding this comment.
Our experiments with SYCL buffer has shown issues. Should we add this as a limitation for now? It can be updated in the future if we see a pathway for extending support.
sycl/doc/extensions/experimental/sycl_ext_oneapi_graph.asciidoc
Outdated
Show resolved
Hide resolved
| capture. If the backend does not support this capability the | ||
| `command_graph` constructor will throw `feature_not_supported`. | ||
|
|
||
| Additionally, native recording requires the queue to be backed by an |
There was a problem hiding this comment.
I think we should highlight these are backend requirements for the L0v2 adapter. There could be other backend implementations for this mode.
Also, we might also want some phrasing to clarify that immediate command lists are used by default with V2 adapter on compatible devices and no user action is required.
| | `get_nodes()` / `get_root_nodes()` | ||
| | No SYCL node model is built during native capture; returns empty vectors. | ||
| | _(no exception — returns empty)_ | ||
|
|
There was a problem hiding this comment.
I think we should also add a limitation, "Events signaled from a command submission within a graph may only be used within the same graph".
There are mechanisms in place where we could relax this, but it requires more work to understand what is needed to support this.
Co-authored-by: Matthew Michel <matthew.michel@intel.com>
2 participants
This PR updates the SYCL graph specification to document the
property::graph::enable_native_recording. In native recording mode, graph capture is delegated to the backend, rather than managed at the SYCL level using Unified Runtime's Command-Buffer feature.