Skip to content

Commit b75e9cb

Browse files
add doc. part 1
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
1 parent 336acad commit b75e9cb

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

sycl/doc/design/SYCLInstrumentationUsingXPTI.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -250,13 +250,13 @@ All trace point types in bold provide semantic information about the graph, node
250250
| `task_begin` | <div style="text-align: left"><li>**trace_type**: `xpti::trace_point_type_t::task_begin` that marks the beginning of a task belonging to one of the nodes in the graph. When the trace event is for a kernel executing on a device other than the the CPU, this `task_begin` and corresponding `task_end` mark the submit call. To track the execution of the kernel on the device, the `trace_signal` event must be monitored to get the kernel event handle from which the execution statistics can be gathered. </li> <li> **parent**: The global graph event that is created during the `graph_create` event.</li> <li> **event**: The event ID will reflect the ID of the computation or memory operation kernel, which would be one of the nodes in the graph.</li> <li> **instance**: Instance ID for the task that can be used to correlate it with the corresponding `task_end` trace event. </li> <li> **user_data**: `nullptr` </li> <p></p></div> | Same metadata defined for the node the trace task belongs to. |
251251
| `task_end` | <div style="text-align: left"><li>**trace_type**: `xpti::trace_point_type_t::task_end` that marks the end of a task belonging to one of the nodes in the graph. The specific task instance can be tacked through the instance ID parameter which helps correlate the `task_end` with the corresponding `task_begin`. </li> <li> **parent**: The global graph event that is created during the `graph_create` event.</li> <li> **event**: The event ID will reflect the ID of the computation or memory operation kernel, which would be one of the nodes in the graph.</li> <li> **instance**: Instance ID for the task that can be used to correlate it with the corresponding `task_begin` trace event. </li> <li> **user_data**: `nullptr` </li> <p></p></div> | Same metadata defined for the node the trace task belongs to. |
252252
| `signal` | <div style="text-align: left"><li>**trace_type**: `xpti::trace_point_type_t::signal` that marks the an event that contains the `event` handle of an executing kernel on a device. </li> <li> **parent**: The global graph event that is created during the `graph_create` event.</li> <li> **event**: The event ID will reflect the ID of the computation or memory operation kernel, which would be one of the nodes in the graph.</li> <li> **instance**: Instance ID for the task for which the signal has been generated. </li> <li> **user_data**: Address of the kernel event that is returned by the device so the progress of the execution can be tracked. </li> <p></p></div> | Same metadata defined for the node the trace task belongs to. |
253-
| `wait_begin` | <div style="text-align: left"><li>**trace_type**: `xpti::trace_point_type_t::wait_begin` that marks the beginning of the wait on an `event`</li> <li> **parent**: `nullptr`</li> <li> **event**: The event ID will reflect the ID of the command group object submission that created this event or the graph event, if the event is an external event. </li> <li> **instance**: Unique ID to allow the correlation of the `wait_begin` event with the `wait_end` event. </li> <li> **user_data**: String indicating `event.wait` and the address of the event sent in as `const char *` </li> <p></p>Tracing the `event.wait()` or `event.wait_and_throw()` will capture the waiting on the action represented by the event object, which could be the execution of a kernel, completion of a memory operation, etc.</div> | None |
254-
| `wait_end` | <div style="text-align: left"><li>**trace_type**: `xpti::trace_point_type_t::wait_end` that marks the beginning of the wait on an `event`</li> <li> **parent**: `nullptr`</li> <li> **event**: The event ID will reflect the ID of the command group object submission that created this event or the graph event, if the event is an external event. </li> <li> **instance**: Unique ID to allow the correlation of the `wait_begin` event with the `wait_end` event. </li> <li> **user_data**: String indicating `event.wait` and the address of the event sent in as `const char *` </li></div> | None |
255253
| `wait_begin` | <div style="text-align: left"><li>**trace_type**: `xpti::trace_point_type_t::wait_begin` that marks the beginning of the wait on an `event`</li> <li> **parent**: `nullptr`</li> <li> **event**: The event ID will reflect the ID of the command group object submission that created this event or a new event based on the combination of the string "queue.wait" and the address of the event. </li> <li> **instance**: Unique ID to allow the correlation of the `wait_begin` event with the `wait_end` event. </li> <li> **user_data**: String indicating `queue.wait` and the address of the event sent in as `const char *` </li> <p></p>Tracing the `queue.wait()` or `queue.wait_and_throw()` will capture the waiting on the action represented by the event object, which could be the execution of a kernel, completion of a memory operation, etc that is embedded in the command group handler. All wait events contain metadata that indicates the SYCL device on which the corresponding operation has been submitted. If the event is from a command group handler, then the source location information is available as well.</div> | `sycl_device`, `sycl_device_type`, `sycl_device_name`, `sym_function_name`, `sym_source_file_name`, `sym_line_no`, `sym_column_no` |
256254
| `wait_end` | <div style="text-align: left"><li>**trace_type**: `xpti::trace_point_type_t::wait_end` that marks the beginning of the wait on an `event`</li> <li> **parent**: `nullptr`</li> <li> **event**: The event ID will reflect the ID of the command group object submission that created this event or a new event based on the combination of the string "queue.wait" and the address of the event. </li> <li> **instance**: Unique ID to allow the correlation of the `wait_begin` event with the `wait_end` event. </li> <li> **user_data**: String indicating `queue.wait` and the address of the event as `const char *` </li></div> | `sycl_device`, `sycl_device_type`, `sycl_device_name`, `sym_function_name`, `sym_source_file_name`, `sym_line_no`, `sym_column_no` |
257255
| `barrier_begin` | <div style="text-align: left"><li>**trace_type**: `xpti::trace_point_type_t::barrier_begin` that marks the beginning of a barrier while enqueuing a command group object</li> <li> **parent**: The global graph event that is created during the `graph_create` event.</li> <li> **event**: The event ID will reflect the ID of the command group object that has encountered a barrier during the enqueue operation. </li> <li> **instance**: Unique ID to allow the correlation of the `barrier_begin` event with the `barrier_end` event. </li> <li> **user_data**: String indicating `enqueue.barrier` and the reason for the barrier as a `const char *` </li> <p></p>The reason for the barrier could be one of `Buffer locked by host accessor`, `Blocked by host task` or `Unknown reason`.</div> | <li> Computational Kernels </li> `sycl_device`, `sycl_device_type`, `sycl_device_name`, `kernel_name`, `from_source`, `sym_function_name`, `sym_source_file_name`, `sym_line_no`, `sym_column_no` <li>Memory operations</li> `memory_object`, `offset`, `access_range_start`, `access_range_end`, `allocation_type`, `copy_from`, `copy_to` |
258256
| `barrier_end` | <div style="text-align: left"><li>**trace_type**: `xpti::trace_point_type_t::barrier_end` that marks the end of the barrier that is encountered during enqueue.</li> <li> **parent**: The global graph event that is created during the `graph_create` event.</li> <li> **event**: The event ID will reflect the ID of the command group object that has encountered a barrier during the enqueue operation. </li> <li> **instance**: Unique ID to allow the correlation of the `barrier_begin` event with the `barrier_end` event. </li> <li> **user_data**: String indicating `enqueue.barrier` and the reason for the barrier as a `const char *` </li> <p></p>The reason for the barrier could be one of `Buffer locked by host accessor`, `Blocked by host task` or `Unknown reason`.</div> | <li> Computational Kernels </li> `sycl_device`, `sycl_device_type`, `sycl_device_name`, `kernel_name`, `from_source`, `sym_function_name`, `sym_source_file_name`, `sym_line_no`, `sym_column_no` <li>Memory operations</li> `memory_object`, `offset`, `access_range_start`, `access_range_end`, `allocation_type`, `copy_from`, `copy_to` |
259257
| `diagnostics` | <div style="text-align: left"><li>**trace_type**: `xpti::trace_point_type_t::diagnostics` that represents general purpose notifications. For example, it is emitted when an exception is thrown in SYCL runtime. </li> <li> **parent**: Set to NULL.</li> <li> **event**: The event ID will reflect the code location of notification origin, if available. </li> <li> **instance**: An instance ID that records the number of times this code location has been seen. </li> <li> **user_data**: String with diagnostic message as a `const char *` </li></div> | `sym_function_name`, `sym_source_file_name`, `sym_line_no`, `sym_column_no` |
258+
| `queue_create` | <div style="text-align: left"><li>**trace_type**: `xpti::trace_point_type_t::queue_create` that marks the creation of a queue, which could be a device or host queue.</li> <li> **parent**: Set to NULL.</li> <li> **event**: The event ID will reflect the code location of notification origin, if available. </li> <li> **instance**: Not meaningful for this trace type. </li> <li> **user_data**: Not meaningful for this trace type. Could contain string with 'queue_create' or nullptr. </li> <p></p> This signal is emitted only once for every queue object, notifies about successful queue creation (the signal is not emitted if any exception happens during queue creation). </div> | 'sycl_context', 'sycl_device_name', 'sycl_device', 'is_inorder', 'queue_id', 'queue_handle' <li> 'queue_id' is a per-queue unique identificator within program lifetime. Allows to map traces of queue creation, destruction and task executions on a queue. 'queue_handle' is absent for host queue since no backend object is used. </li>|
259+
| `queue_destroy` | <div style="text-align: left"><li>**trace_type**: `xpti::trace_point_type_t::queue_destroy` that marks the destruction of a queue, which could be a device or host queue.</li> <li> **parent**: Set to NULL.</li> <li> **event**: The event ID will reflect the code location of notification origin, if available. </li> <li> **instance**: Not meaningful for this trace type. </li> <li> **user_data**: Not meaningful for this trace type. Could contain string with 'queue_destroy' or nullptr. </li> <p></p> This signal is emitted only once for every queue object, notifies about queue destruction. Contains the same metadata set for corresponding 'queue_create' signal. </div> | 'sycl_context', 'sycl_device_name', 'sycl_device', 'is_inorder', 'queue_id', 'queue_handle' <li> 'queue_id' is a per-queue unique identificator within program lifetime. Allows to map traces of queue creation, destruction and task executions on a queue. 'queue_handle' is absent for host queue since no backend object is used. </li>|
260260

261261
### Metadata description
262262

0 commit comments

Comments
 (0)