You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: sycl/doc/extensions/supported/sycl_ext_intel_dataflow_pipes.asciidoc
+33-36Lines changed: 33 additions & 36 deletions
Original file line number
Diff line number
Diff line change
@@ -642,55 +642,47 @@ Automated mechanisms are possible to provide uniquification across calls, and co
642
642
643
643
*NOTE*: The APIs described in this section are experimental. Future versions of this extension may change these APIs in ways that are incompatible with the versions described here.
644
644
645
-
In the experimental API version, read/write methods take template arguments, which can contain the latency control properties `latency_anchor_id` and/or `latency_constraint`.
645
+
In the experimental API version, read/write methods take in a property list as function argument, which can contain the latency control properties `latency_anchor_id` and/or `latency_constraint`.
646
646
647
-
* `sycl::ext::intel::experimental::latency_anchor_id<N>`, where `N` is an integer: An ID to associate with the current read/write function call, which can then be referenced by other `latency_constraint` properties elsewhere in the program to define relative latency constaints. ID must be unique within the application, and a diagnostic is required if that condition is not met.
648
-
* `sycl::ext::intel::experimental::latency_constraint<A, B, C>`: A tuple of three values which cause the current read/write function call to act as an endpoint of a latency constraint relative to a specified `latency_anchor_id` defined by a different instruction.
647
+
* `sycl::ext::oneapi::experimental::latency_anchor_id<N>`, where `N` is an integer: An ID to associate with the current read/write function call, which can then be referenced by other `latency_constraint` properties elsewhere in the program to define relative latency constaints. ID must be unique within the application, and a diagnostic is required if that condition is not met.
648
+
* `sycl::ext::oneapi::experimental::latency_constraint<A, B, C>`: A tuple of three values which cause the current read/write function call to act as an endpoint of a latency constraint relative to a specified `latency_anchor_id` defined by a different instruction.
649
649
** `A` is an integer: The ID of the target anchor defined on a different instruction through a `latency_anchor_id` property.
650
-
** `B` is an enum value: The type of control from the set {`type::exact`, `type::max`, `type::min`}.
650
+
** `B` is an enum value: The type of control from the set {`latency_control_type::exact`, `latency_control_type::max`, `latency_control_type::min`}.
651
651
** `C` is an integer: The relative clock cycle difference between the target anchor and the current function call, that the constraint should infer subject to the type of the control (exact, max, min).
652
652
653
-
The template arguments above don't have to be specified if user doesn't want to apply latency controls. The template arguments can be passed in arbitrary order.
654
-
655
653
=== Implementation
656
654
657
655
[source,c++]
658
656
----
659
-
// Added in version 2 of this extension.
660
-
namespace sycl::ext::intel::experimental {
661
-
enum class type {
662
-
none, // default
663
-
exact,
664
-
max,
665
-
min
666
-
};
667
-
668
-
template <int32_t _N> struct latency_anchor_id {
669
-
static constexpr int32_t value = _N;
670
-
static constexpr int32_t default_value = -1;
671
-
};
672
-
673
-
template <int32_t _N1, type _N2, int32_t _N3> struct latency_constraint {
674
-
static constexpr std::tuple<int32_t, type, int32_t> value = {_N1, _N2, _N3};
0 commit comments