Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add experimental extension for counter-based events #221

Merged
merged 6 commits into from
Oct 13, 2023
Merged
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 50 additions & 0 deletions scripts/core/EXT_Exp_CounterBasedEvents.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
<%
import re
from templates import helper as th
%><%
OneApi=tags['$OneApi']
x=tags['$x']
X=x.upper()
%>
:orphan:

.. _ZE_experimental_event_counter_based:

=========================
Counter-Based Events Extension
=========================

API
----

* Enumerations

* ${x}_event_counter_based_exp_flags_t
* ${x}_event_counter_based_exp_version_t

* Structures

* ${x}_event_counter_based_exp_desc_t

Counter-Based Events
~~~~~~~~~~~~~~~~~~~~~~~~~~

By default, events in Level Zero contains one of two states: signaled or not signaled.
Signaling of an event, as well as resetting its state, can be done from either host or
device.

Another way of tracking the state of an event is by using a counter, which is incremented
every time a task has completed in the device. Using a counter-based event may provide
Level Zero driver implementations with the opportunity for both functional and performance
optimizations.

The following recommendations and restrictions apply to counter-based events:

- Counter-based events can be used only with in-orders lists, whether those are regular or immediate.
- Counter-based events must not be reset, i.e., a call to ${x}EventHostReset or ${x}CommandListAppendEventReset
is not allowed.
- Counter-based events may be reused multiple times without a need for reset.
wdamon-intel marked this conversation as resolved.
Show resolved Hide resolved
- Counter-based events must not be signaled from host, i.e., a call to ${x}EventHostSignal is not allowed.
- Counter-based events may be used on multiple command lists.
wdamon-intel marked this conversation as resolved.
Show resolved Hide resolved
- Querying a counter-based event queries only the last saved counter value from the last command list that incremented it.
- Synchronizing on a counter-based event waits only the last saved counter value from the last command list that incremented it.
wdamon-intel marked this conversation as resolved.
Show resolved Hide resolved
4 changes: 4 additions & 0 deletions scripts/core/common.yml
Original file line number Diff line number Diff line change
Expand Up @@ -508,6 +508,10 @@ etors:
desc: $x_rtas_geometry_aabbs_exp_cb_params_t
version: "1.7"
value: "0x00020013"
- name: COUNTER_BASED_EVENT_EXP_DESC
desc: $x_event_counter_based_exp_desc_t
version: "1.8"
value: "0x00020014"
- name: COMMAND_GRAPH_EXP_DESC
desc: $x_command_graph_exp_desc_t
version: "2.0"
Expand Down
51 changes: 51 additions & 0 deletions scripts/core/counterbasedevent.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@
#
# Copyright (C) 2019-2022 Intel Corporation
#
# SPDX-License-Identifier: MIT
#
# See YaML.md for syntax definition
#
--- #--------------------------------------------------------------------------
type: header
desc: "Intel $OneApi Level-Zero Extension APIs for Counter-based Events"
version: "1.8"
--- #--------------------------------------------------------------------------
type: macro
desc: "Counter-based Events Extension Name"
version: "1.4"
name: $X_EVENT_COUNTER_BASED_EXP_NAME
value: '"$X_experimental_event_counter_based"'
--- #--------------------------------------------------------------------------
type: enum
desc: "Counter-based Events Extension Version(s)"
version: "1.8"
name: $x_event_counter_based_exp_version_t
etors:
- name: "1_0"
value: "$X_MAKE_VERSION( 1, 0 )"
desc: "version 1.0"
--- #--------------------------------------------------------------------------
type: enum
desc: "Supported event flags for defining counter-based events. Must "
class: $xEvent
name: $x_event_counter_based_exp_flags_t
etors:
- name: IMMEDIATE
desc: "Counter-based event is used for immediate command lists (default)"
- name: NON_IMMEDIATE
desc: "Counter-based event is used for non-immediate command lists"
--- #--------------------------------------------------------------------------
type: struct
desc: "Event descriptor for counter-based events. This structure may be passed to $xEventCreate as pNext member of $x_event_desc_t."
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we want to consider adding flag for event pools for counter based events? i.e, would there be value in creating an event pool where events from that pool are only used as counting events?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes we need flag for event memory pool as those events doesn't require pool memory to be allocated for them, the storage is inherited from command list.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MichalMrozek : sorry, could you clarify the comment about event pool? do we want the counter-based flags to be part of the zeEventPoolCreate or zeEventCreate, or both?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Counter Based Events doesn't need memory backing if they are for immediate command lists, so this must be event pool flag as this is steered to control where allocation happens.
I do not see a need for event flag.
So only change in zeEventPoolCreate flags.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems to me that we are talking about "counter events" being associated at a command queue level. so would it be better to describe a different struct for this entirely so we can cleanly associate at command queue/command list level rather than shoe-horning it into existing event(pool) struct/desc?

we have fences described here as being associated at command queue level, so something similar for "counter events"?
https://spec.oneapi.io/level-zero/latest/core/PROG.html#fences

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We want to leverage events, otherwise all append API's would need to be rewritten.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @MichalMrozek . I have moved the flags to the event pool logic. Please check.

class: $xEvent
version: "1.8"
name: $x_event_counter_based_exp_desc_t
base: $x_base_desc_t
members:
- type: $x_event_counter_based_exp_flags_t
name: flags
desc: |
[in] mode flags.
must be 0 (default) or a valid value of $x_event_counter_based_exp_flag_t
default behavior is counter-based event is only used for immediate command lists.
init: "0"