|
| 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 | + |
| 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. |
0 commit comments