Skip to content

Commit 19024c1

Browse files
rebleEwanCBensuo
authored
[SYCL][DOC] Adding design document for command graph extension (#183)
Co-authored-by: Ewan Crawford <[email protected]> Co-authored-by: Ben Tracy <[email protected]>
1 parent ba05ff1 commit 19024c1

File tree

2 files changed

+67
-0
lines changed

2 files changed

+67
-0
lines changed

sycl/doc/design/CommandGraph.md

+66
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,66 @@
1+
# Command Graph Extension
2+
3+
This document describes the implementation design of the
4+
[SYCL Graph Extension](https://github.com/intel/llvm/pull/5626).
5+
6+
A related presentation can be found
7+
[here](https://www.youtube.com/watch?v=aOTAmyr04rM).
8+
9+
## Requirements
10+
11+
An efficient implementation of a lazy command graph execution and its replay
12+
requires extensions to the UR layer. Such an extension is command buffers,
13+
where a command-buffer object represents a series of operations to be enqueued
14+
to the backend device and their dependencies. A single command graph can be
15+
partitioned into more than one command-buffer by the runtime.
16+
We distinguish between backends that support command buffer extensions and
17+
those that do not. Currently command buffer extensions are only supported by
18+
Level Zero. All other backends would fall back to an emulation mode, or not
19+
be reported as supported.
20+
21+
The emulation mode targets support of functionality only, without potentially
22+
resulting performance improvements, i.e. execution of a closed Level Zero
23+
command list multiple times.
24+
25+
### Command Buffer extension
26+
27+
| Function | Description |
28+
| ------------------------- | ------------------------ |
29+
| `piextCommandBufferCreate` | create a command-buffer. |
30+
| `piextCommandBufferRetain` | incrementing reference count of command-buffer. |
31+
| `piextCommandBufferRelease` | decrementing reference count of command-buffer. |
32+
| `piextCommandBufferFinalize` | no more commands can be appended, makes command buffer ready to enqueue on command-queue. |
33+
| `piextCommandBufferNDRangeKernel` | append a kernel execution command to command buffer. |
34+
| `piextEnqueueCommandBuffer` | submit command-buffer to queue for execution |
35+
| `piextCommandBufferMemcpyUSM` | append a USM memcpy command to the command-buffer. |
36+
| `piextCommandBufferMemBufferCopy` | append a mem buffer copy command to the command-buffer. |
37+
| `piextCommandBufferMemBufferCopyRect` | append a rectangular mem buffer copy command to the command-buffer. |
38+
39+
## Design
40+
41+
![Basic architecture diagram.](images/SYCL-Graph-Architecture.svg)
42+
43+
There are two sets of user facing interfaces that can be used to create a
44+
command graph object:
45+
Explicit and Record & Replay API. Within the runtime they share a common
46+
infrastructure.
47+
48+
## Scheduler integration
49+
50+
When there are no requirements for accessors in a command graph the scheduler
51+
is bypassed and it is directly enqueued to a command buffer. If
52+
there are requirements, commands need to be enqueued by the scheduler.
53+
54+
## Memory handling: Buffer and Accessor
55+
56+
There is no extra support for Graph-specific USM allocations in the current
57+
proposal. Memory operations will be supported subsequently by the current
58+
implementation starting with `memcpy`.
59+
60+
Buffers and accessors are supported in a command graph. Following restrictions
61+
are required to adapt buffers and their lifetime to a lazy work execution model:
62+
63+
- Lifetime of a buffer with host data will be extended by copying the underlying
64+
data.
65+
- Host accessor on buffer that are used by a command graph are prohibited.
66+
- Copy-back behavior on destruction of a buffer is prohibited.
Loading

0 commit comments

Comments
 (0)