[SYCL][Doc] Use secnum option

Signed-off-by: Lukas Sommer <[email protected]>

Author: sommerlukas

sycl/doc/extensions/experimental/sycl_ext_oneapi_graph_fusion.asciidoc

@@ -10,15 +10,16 @@
 :encoding: utf-8
 :lang: en
 :dpcpp: pass:[DPC++]
-:stem: asciimath
+:sectnums:
+:sectnumlevels: 4
 
 // Set the default source code type in this document to C++,
 // for syntax highlighting purposes.  This is needed because
 // docbook uses c++ and html5 uses cpp.
 :language: {basebackend@docbook:c++:cpp}
 
 
-== 1. Notice
+== Notice
 
 [%hardbreaks]
 Copyright (C) Codeplay Software Limited.  All rights reserved.
@@ -28,14 +29,14 @@ of The Khronos Group Inc.  OpenCL(TM) is a trademark of Apple Inc. used by
 permission by Khronos.
 
 
-== 2. Contact
+== Contact
 
 To report problems with this extension, please open a new issue at:
 
 https://github.com/intel/llvm/issues
 
 
-== 3. Dependencies
+== Dependencies
 
 This extension is written against the SYCL 2020 revision 6 specification.  All
 references below to the "core SYCL specification" or to section numbers in the
@@ -45,15 +46,15 @@ This extension builds on top of the proposed SYCL graphs
 https://github.com/reble/llvm/blob/sycl-graph-update/sycl/doc/extensions/proposed/sycl_ext_oneapi_graph.asciidoc[extension
 proposal]. All references to the "graphs proposal" refer to this proposal.
 
-== 4. Status
+== Status
 
 This is a proposed extension specification, intended to gather community
 feedback.  Interfaces defined in this specification may not be implemented yet
 or may be in a preliminary state.  The specification itself may also change in
 incompatible ways before it is finalized.  *Shipping software products should
 not rely on APIs defined in this specification.*
 
-== 5. Overview
+== Overview
 
 The SYCL graph
 https://github.com/reble/llvm/blob/sycl-graph-update/sycl/doc/extensions/proposed/sycl_ext_oneapi_graph.asciidoc[extension
@@ -87,9 +88,9 @@ fusion of two or more kernels in a SYCL graph into a single kernel **at
 runtime**. This requires the extension of the runtime with some sort of JIT
 compiler to allow for the fusion of kernel functions at runtime.
 
-== 6. Specification
+== Specification
 
-=== 6.1. Feature test macro
+=== Feature test macro
 
 This extension provides a feature-test macro as described in the core SYCL
 specification.  An implementation supporting this extension must predefine the
@@ -108,11 +109,11 @@ supports.
 |Initial version of this extension.
 |===
 
-=== 6.2. API modifications
+=== API modifications
 
-==== 6.2.1. Properties
+==== Properties
 
-===== 6.2.1.1. Graph Fusion Property
+===== Graph Fusion Property
 
 The API for `command_graph<graph_state::modifiable>::finalize()` includes a
 `property_list` parameter. The following property, defined by this extension,
@@ -124,7 +125,7 @@ sycl::ext::oneapi::experimental::property::command_graph::perform_fusion
 ```
 
 The property is not prescriptive. Implementations are free to not perform fusion
-if it is not possible (see below section <<_6_5_limitations>>), fusion is not
+if it is not possible (see below section <<_limitations>>), fusion is not
 supported by the implementation, or the implementation decides not to perform
 fusion for other reasons. It is not an error if an implementation does not
 perform fusion even though the property is passed. 
@@ -133,7 +134,7 @@ Implementations can provide a diagnostic message in case fusion was not
 performed through an implementation-specified mechanism, but are not required to
 do so.
 
-===== 6.2.1.2. Barrier property
+===== Barrier property
 
 The following property can be added to the `property_list` of the
 `command_graph<graph_state::modifiable>::finalize()` API.
@@ -150,7 +151,7 @@ The property only takes effect if the
 property is also part of the `property_list` of the same invocation of
 `command_graph<...>::finalize()`. 
 
-===== 6.2.1.3. Local internalization property
+===== Local internalization property
 
 The following property can be passed to three different APIs, namely:
 
@@ -187,7 +188,7 @@ no error if they do not perform internalization. Implementations can provide a
 diagnostic message in case internalization was not performed through an
 implementation-specified mechanism, but are not required to do so.
 
-===== 6.2.1.4. Private internalization property
+===== Private internalization property
 
 The following property can be passed to three different APIs, namely:
 
@@ -224,7 +225,7 @@ no error if they do not perform internalization. Implementations can provide a
 diagnostic message in case internalization was not performed through an
 implementation-specified mechanism, but are not required to do so.
 
-==== 6.2.2. Device information descriptors
+==== Device information descriptors
 
 To support querying whether a SYCL device and the underlying platform support
 kernel fusion for graphs, the following device information descriptor is added
@@ -238,7 +239,7 @@ When passed to `device::get_info<...>()`, the function returns `true` if the
 SYCL `device` and the underlying `platform` support kernel fusion for graphs.
 
 
-=== 6.3. Linearization
+=== Linearization
 
 In order to be able to perform kernel fusion, the commands in a graph must be
 arranged in a valid sequential order. 
@@ -252,7 +253,7 @@ partial order) is implementation defined. The linearization should be
 deterministic, i.e. it should yield the same sequence when presented with the
 same DAG.
 
-=== 6.4. Synchronization in kernels
+=== Synchronization in kernels
 
 Group barriers semantics do not change in the fused kernel and barriers already
 in the unfused kernels are preserved in the fused kernel. Despite this, it is
@@ -261,7 +262,7 @@ same work-group executing a fused kernel, a barrier is added between each of the
 kernels being fused. This automatic insertion of additional barriers can be
 deactivated through the property defined above.
 
-=== 6.5. Limitations
+=== Limitations
 
 Some scenarios might require fusion to be cancelled if some undesired scenarios
 arise.
@@ -278,29 +279,29 @@ The following sections describe a number of scenarios that might require to
 cancel fusion. Note that some implementations might be more capable/permissive
 and might not abort fusion in all of these cases.
 
-==== 6.5.1. Hierarchical Parallelism
+==== Hierarchical Parallelism
 
 The extension does not support kernels using hierarchical parallelism. Although
 some implementations might want to add support for this kind of kernels.
 
-==== 6.5.2. Incompatible ND-ranges of the kernels to fuse
+==== Incompatible ND-ranges of the kernels to fuse
 
 Incompatibility of ND-ranges will be determined by the kernel fusion
 implementation. All implementations should support fusing kernels with the exact
 same ND-ranges, but implementations might cancel fusion as soon as a kernel with
 a different ND-range is submitted.
 
-==== 6.5.3. Kernels with different dimensions
+==== Kernels with different dimensions
 
 Similar to the previous one, it is implementation-defined whether or not to
 support fusing kernels with different dimensionality.
 
-==== 6.5.4. No intermediate representation
+==== No intermediate representation
 
 In case any of the kernels to be fused does not come with an accessible
 suitable intermediate representation, kernel fusion is canceled.
 
-==== 6.5.5. Explicit memory operations and host tasks
+==== Explicit memory operations and host tasks
 
 The graph proposal allows graphs to contain, next to device kernels, explicit
 memory operations and host tasks. As both of these types of commands cannot be
@@ -311,13 +312,13 @@ It is valid to execute some memory operations and host tasks before all device
 kernels and some after all device kernels, as long as that sequence is a valid
 linearization.
 
-==== 6.5.6. Multi-device graph
+==== Multi-device graph
 
 Attempting to fuse a graph containing device kernels for more than one device
 may lead to fusion being cancelled, as kernel fusion across multiple devices
 and/or backends is generally not possible. 
 
-=== 6.6. Internalization
+=== Internalization
 
 While avoiding repeated kernel launch overheads will most likely already improve
 application performance, kernel fusion can deliver even higher performance gains
@@ -368,7 +369,7 @@ no internalization were to happen.
 In sum this allows users to trigger internalization of a buffer or allocated
 device memory by just specifying a single property.
 
-==== 6.6.1. Buffer internalization
+==== Buffer internalization
 
 In some cases, the user will specify different internalization targets for a
 buffer and accessors to such buffer. When incompatible combinations are used, an
@@ -440,9 +441,9 @@ performed. If there is a mismatch between the two accessors (access
 range, access offset, number of dimensions, data type), no
 internalization is performed.
 
-== 7. Examples
+== Examples
 
-=== 7.1. Buffer-based example
+=== Buffer-based example
 
 ```c++
 #include <sycl/sycl.hpp>
@@ -530,7 +531,7 @@ int main() {
 }
 ```
 
-=== 7.2. USM-based example
+=== USM-based example
 
 ```c++
 #include <sycl/sycl.hpp>
@@ -617,11 +618,12 @@ int main() {
 }
 ```
 
-== 8. Contributors
+== Contributors
 
 Lukas Sommer, Codeplay +
 Victor Lomüller, Codeplay +
 Victor Perez, Codeplay +
+Ewan Crawford, Codeplay +
 
 == Revision History