Applied CR comments

Author: dm-vodopyanov

sycl/doc/extensions/EnqueueBarrier/enqueue_barrier.asciidoc

@@ -1,4 +1,4 @@
-= SYCL_EXT_INTEL_ENQUEUE_BARRIER
+= SYCL_EXT_ONEAPI_ENQUEUE_BARRIER
 :source-highlighter: coderay
 :coderay-linenums-mode: table
 
@@ -25,11 +25,6 @@ NOTE: This document is better viewed when rendered as html with asciidoctor.  Gi
 
 This document presents a series of changes proposed for a future version of the SYCL Specification. The goal of this proposal is to provide non-blocking APIs that provide synchronization on SYCL command queue for programmers.
 
-
-== Name Strings
-
-+SYCL_EXT_INTEL_ENQUEUE_BARRIER+
-
 == Notice
 
 Copyright (c) 2019-2020 Intel Corporation.  All rights reserved.
@@ -45,7 +40,7 @@ Because the interfaces defined by this specification are not final and are subje
 == Version
 
 Built On: {docdate} +
-Revision: 1
+Revision: 2
 
 == Contact
 Please open an issue in the https://github.com/intel/llvm/tree/sycl/sycl/doc/extensions/[extensions repository]
@@ -55,7 +50,7 @@ Please open an issue in the https://github.com/intel/llvm/tree/sycl/sycl/doc/ext
 This extension provides a feature-test macro as described in the core SYCL
 specification section 6.3.3 "Feature test macros".  Therefore, an
 implementation supporting this extension must predefine the macro
-`SYCL_EXT_INTEL_ENQUEUE_BARRIER` to one of the values defined in the table below.
+`SYCL_EXT_ONEAPI_ENQUEUE_BARRIER` to one of the values defined in the table below.
 Applications can test for the existence of this macro to determine if the
 implementation supports this feature, or applications can test the macro's
 value to determine which of the extension's APIs the implementation supports.
@@ -68,12 +63,12 @@ value to determine which of the extension's APIs the implementation supports.
 
 == Dependencies
 
-This extension is written against the SYCL 1.2.1 specification, Revision v1.2.1-6.
+This extension is written against the SYCL 2020 specification, revision 3.
 
 == Overview
 
-SYCL 1.2.1 defines a graph-based task execution model, based on kernels or explicit memory operations submitted to out-of-order queues. Dependencies between these kernels are represented by
-accessors that form data dependence edges in the execution graph. The USM extension <<usmlink,[1]>> doesn't have accessors, so instead solves
+SYCL 2020 defines a graph-based task execution model, based on kernels or explicit memory operations submitted to out-of-order queues. Dependencies between these kernels are represented by
+accessors that form data dependence edges in the execution graph. Unified Shared Memory (USM) doesn't have accessors, so instead solves
 this by defining `handler::depends_on` methods to specify event-based control dependencies between command groups.
 
 There are situations where defining dependencies based on events is more explicit than desired or required by an application. For instance, the user may know that a given task depends on all previously submitted tasks. Instead of explicitly adding all the required depends_on calls, the user could express this intent via a single call, making the program more concise and explicit.
@@ -91,9 +86,9 @@ two new members to the `queue` class:
 [grid="rows"]
 [options="header"]
 |========================================
-|*handler::ext_intel_barrier*|*queue::ext_intel_submit_barrier*
-|`void ext_intel_barrier()` | `event ext_intel_submit_barrier()`
-|`void ext_intel_barrier( const vector_class<event> &waitList )` | `event ext_intel_submit_barrier( const vector_class<event> &waitList )`
+|*handler::ext_intel_barrier*|*queue::ext_oneapi_submit_barrier*
+|`void ext_intel_barrier()` | `event ext_oneapi_submit_barrier()`
+|`void ext_intel_barrier( const vector_class<event> &waitList )` | `event ext_oneapi_submit_barrier( const vector_class<event> &waitList )`
 |========================================
 
 The first variant of the barrier takes no parameters, and waits for all previously submitted commands to the queue to enter the `info::event_command_status::complete` state before any command later submitted to the same queue is allowed to execute. A second variant of the barrier accepts a list of events, with the behavior that no commands submitted to the same queue after barrier submission may execute until all events in the `waitList` have entered the `info::event_command_status::complete` state.  Both variants are non-blocking from the host program perspective, in that they do not wait for the barrier conditions to have been met before returning.
@@ -134,7 +129,7 @@ Queue.submit([&](cl::sycl::handler& cgh) {
 ...
 ----
 
-==== 2. Using `queue::ext_intel_submit_barrier()`:
+==== 2. Using `queue::ext_oneapi_submit_barrier()`:
 
 [source,c++,NoName,linenums]
 ----
@@ -149,7 +144,7 @@ Queue.submit([&](cl::sycl::handler& cgh) {
   // CG3
 });
 
-Queue.ext_intel_submit_barrier();
+Queue.ext_oneapi_submit_barrier();
 
 Queue.submit([&](cl::sycl::handler& cgh) {
   // CG4
@@ -185,7 +180,7 @@ Queue3.submit([&](cl::sycl::handler& cgh) {
 ...
 ----
 
-==== 2. Using `queue::ext_intel_submit_barrier()`:
+==== 2. Using `queue::ext_oneapi_submit_barrier()`:
 
 [source,c++,NoName,linenums]
 ----
@@ -198,7 +193,7 @@ auto event_barrier2 = Queue2.submit([&](cl::sycl::handler& cgh) {
   // CG2
 });
 
-Queue3.ext_intel_submit_barrier( vector_class<event>{event_barrier1, event_barrier2} );
+Queue3.ext_oneapi_submit_barrier( vector_class<event>{event_barrier1, event_barrier2} );
 
 Queue3.submit([&](cl::sycl::handler& cgh) {
   // CG3
@@ -227,44 +222,45 @@ void wait();
 template <typename T>
 event submit(T cgf, const queue &secondaryQueue);
 
-event ext_intel_submit_barrier();
+event ext_oneapi_submit_barrier();
 
-event ext_intel_submit_barrier( const vector_class<event> &waitList );
+event ext_oneapi_submit_barrier( const vector_class<event> &waitList );
 
 void wait();
 ...
 ----
-=== Add rows to Table 4.22
+=== Add rows to Table 28
 
 [cols="70,300"]
 [grid="rows"]
 [options="header"]
 |========================================
 |*Member functions*|*Description*
-|`event ext_intel_submit_barrier()` | Same effect as submitting a `handler::ext_intel_barrier()` within a command group to this `queue`.  The returned event enters the `info::event_command_status::complete` state when all events that the barrier is dependent on (implicitly from all previously submitted commands to the same queue) have entered the `info::event_command_status::complete` state.
-|`event ext_intel_submit_barrier( const vector_class<event> &waitList )` | Same effect as submitting a `handler:ext_intel_barrier( const vector_class<event> &waitList )` within a command group to this `queue`.  The returned event enters the `info::event_command_status::complete` state when all events that the barrier is dependent on (explicitly from `waitList`) have entered the `info::event_command_status::complete` state.
+|`event ext_oneapi_submit_barrier()` | Same effect as submitting a `handler::ext_intel_barrier()` within a command group to this `queue`.  The returned event enters the `info::event_command_status::complete` state when all events that the barrier is dependent on (implicitly from all previously submitted commands to the same queue) have entered the `info::event_command_status::complete` state.
+|`event ext_oneapi_submit_barrier( const vector_class<event> &waitList )` | Same effect as submitting a `handler:ext_intel_barrier( const vector_class<event> &waitList )` within a command group to this `queue`.  The returned event enters the `info::event_command_status::complete` state when all events that the barrier is dependent on (explicitly from `waitList`) have entered the `info::event_command_status::complete` state.
 |========================================
 
 
-=== Modify Section 4.8.2
+=== Modify Section 4.9.3
 
 ==== Change first sentence from:
-A command group scope in SYCL, as it is defined in Section 3.4.1, consists of a single kernel or explicit memory
-operation (handler methods such as copy, update_host, fill), together with its requirements.
+The member functions and objects defined in this scope will define the requirements for the kernel execution or 
+explicit memory operation, and will be used by the SYCL runtime to evaluate if the operation is ready for execution.
 
 ==== To:
 
-A command group scope in SYCL, as it is defined in Section 3.4.1, consists of a single kernel, explicit memory
-operation (handler methods such as copy, update_host, fill) or barrier, together with its requirements.
+The member functions and objects defined in this scope will define the requirements for the kernel execution,  
+explicit memory operation or barrier, and will be used by the SYCL runtime to evaluate if the operation is ready for execution.
+
 
-=== Modify part of Section 4.8.3
+=== Modify part of Section 4.9.4
 
 *Change from:*
 [source,c++,NoName,linenums]
 ----
 ...
-template<typename T, int dim, access::mode mode, access::target tgt>
-void fill(accessor<T, dim, mode, tgt> dest, const T& src);
+template <typename T>
+void fill(void *ptr, const T &pattern, size_t count);
 
 };
 ...
@@ -274,8 +270,8 @@ void fill(accessor<T, dim, mode, tgt> dest, const T& src);
 [source,c++,NoName,linenums]
 ----
 ...
-template<typename T, int dim, access::mode mode, access::target tgt>
-void fill(accessor<T, dim, mode, tgt> dest, const T& src);
+template <typename T>
+void fill(void *ptr, const T &pattern, size_t count);
 
 void ext_intel_barrier();
 
@@ -285,15 +281,15 @@ void ext_intel_barrier( const vector_class<event> &waitList );
 ...
 ----
 
-=== Add a new section between Section 4.8.6 and 4.8.7
+=== Add a new section between Section 4.9.4 and 4.9.5
 
-4.8.X SYCL functions for enqueued synchronization barriers
+4.9.X SYCL functions for enqueued synchronization barriers
 
 Barriers may be submitted to a queue, with the effect that they prevent later operations submitted to the same queue from executing until the barrier wait conditions have been satisfied. The wait conditions can be explicitly described by `waitList` or implicitly from all previously submitted commands to the same queue. There are no constraints on the context from which queues may participate in the `waitList`. Enqueued barriers do not block host program execution, but instead form additional dependence edges with the execution task graph. 
 
 Barriers can be created by two members of the `handler` class that force synchronization on the SYCL command queue. The first variant of the `handler` barrier (`handler::barrier()`) takes no parameters, and waits for all previously submitted commands to the queue to enter the `info::event_command_status::complete` state before any command later submitted to the same queue is allowed to execute. The second variant of the `handler` barrier (`handler::barrier( const vector_class<event> &waitList )`) accepts a list of events, with the behavior that no commands submitted to the same queue after barrier submission may execute until all events in the waitList have entered the `info::event_command_status::complete` state. 
 
-=== Add a new table in the new section between 4.8.6 and 4.8.7: Member functions of the handler class.
+=== Add a new table in the new section between 4.9.4 and 4.9.5: Member functions of the handler class.
 
 [cols="70,300"]
 [grid="rows"]
@@ -304,9 +300,6 @@ Barriers can be created by two members of the `handler` class that force synchro
 |`void ext_intel_barrier( const vector_class<event> &waitList` ) | Prevents any commands submitted afterward to this queue from executing until all events in `waitList` have entered the `info::event_command_status::complete` state.  If `waitList` is empty, then the barrier has no effect.
 |========================================
 
-== References
-1. [[usmlink]]https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/USM/USM.adoc
-
 == Issues
 
 None.

sycl/doc/extensions/LevelZeroBackend/LevelZeroBackend.md

@@ -9,7 +9,6 @@ The currently supported targets are all Intel GPUs starting with Gen9.
 
 NOTE: This specification is a draft. While describing the currently implemented behaviors it is known to be not complete nor exhaustive.
       We shall continue to add more information, e.g. explain general mapping of SYCL programming model to Level-Zero API.
-      It will also be gradually changing to a SYCL-2020 conforming implementation.
 
 ## 2. Prerequisites
 

sycl/doc/extensions/MemChannel/MemChannel.asciidoc

@@ -23,11 +23,11 @@ Because the interfaces defined by this specification are not final and are subje
 == Version
 
 Built On: {docdate} +
-Revision: 1
+Revision: 2
 
 == Dependencies
 
-This extension is written against the SYCL 2020 provisional specification, Revision 1.
+This extension is written against the SYCL 2020 specification, Revision 3.
 
 The use of this extension requires a target that supports cl_intel_mem_channel_property or equivalent if OpenCL is used as the underlying device runtime.  
 
@@ -65,7 +65,7 @@ Add a new property to Table 4.33: Properties supported by the SYCL buffer class
 |===
 --
 
-Add a new constructor to Table 4.34: Constructors of the buffer property classes as follows:
+Add a new constructor to Table 41: Constructors of the buffer property classes as follows:
 
 --
 [options="header"]
@@ -75,7 +75,7 @@ Add a new constructor to Table 4.34: Constructors of the buffer property classes
 |===
 --
 
-Add a new member function to Table 4.35: Member functions of the buffer property classes as follows:
+Add a new member function to Table 42: Member functions of the buffer property classes as follows:
 
 --
 [options="header"]
@@ -103,7 +103,7 @@ enum class aspect {
 } // namespace sycl
 ```
 
-Add an entry for the new aspect to Table 4.20: Device aspects defined by the core SYCL specification:
+Add an entry for the new aspect to Table 26: Device aspects defined by the core SYCL specification:
 
 --
 [options="header"]

sycl/doc/extensions/USMAddressSpaces/usm_address_spaces.asciidoc

@@ -11,9 +11,6 @@ NOTE: Khronos(R) is a registered trademark and SYCL(TM) and SPIR(TM) are tradema
 NOTE: This document is better viewed when rendered as html with asciidoctor.  GitHub does not render image icons.
 This document describes an extension to the SYCL USM extension that adds new explicit address spaces for the possible locations that USM pointers can be allocated.  Users can create pointers that point into these address spaces explicitly in order to pass additional information to their compiler so as to enable optimizations.  
 
-== Name Strings
-+SYCL_EXT_INTEL_USM_ADDRESS_SPACES+
-
 == Notice
 Copyright (c) 2020 Intel Corporation.  All rights reserved.
 
@@ -28,11 +25,11 @@ Because the interfaces defined by this specification are not final and are subje
 == Version
 
 Built On: {docdate} +
-Revision: 1
+Revision: B
 
 == Dependencies
 
-This extension is written against the SYCL 1.2.1 specification, Revision 7.  It requires the Unified Shared Memory SYCL proposal.
+This extension is written against the SYCL 2020 specification, Revision 3.
 
 If SPIR-V is used by the implementation, this extension also requires support for the SPV_INTEL_usm_storage_classes SPIR-V extension.
 
@@ -61,9 +58,9 @@ The goal of this division of the global address space is to enable users to expl
 While automatic address space inference is often possible for accessors, it is harder for USM pointers as it requires inter-procedural optimization with the host code.
 This additional information can be particularly beneficial on FPGA targets where knowing that a pointer only ever accesses host or device memory can allow compilers to produce more area efficient memory-accessing hardware.  
 
-== Modifications to the SYCL Specification, Version 1.2.1 revision 7
+== Modifications to the SYCL Specification, Version 2020 revision 3
 
-=== Section 3.5.2 SYCL Device Memory Model
+=== Section 3.8.2 SYCL Device Memory Model
 
 Add to the end of the definition of global memory:
 Global memory is a virtual address space which overlaps the device and host address spaces.  
@@ -74,21 +71,22 @@ Add two new memory regions as follows:
 
 *Host memory* is a sub-region of global memory.  USM pointers allocated with the host alloc type reside in this address space.  
 
-=== Section 3.5.2.1 Access to memory
+=== Section 3.8.2.1 Access to memory
 
-In the second last paragraph, add cl::sycl::device_ptr and cl::sycl::host_ptr to the list of explicit pointer classes.  
+In the second last paragraph, add sycl::device_ptr and sycl::host_ptr to the list of explicit pointer classes.  
 
 === Section 4.7.7.1 Multi-pointer Class
 
 In the overview of the multi_ptr class replace the address_space enum with the following:
 ```c++
 enum class address_space : int {
-    global_space,
-    local_space,
-    constant_space,
-    private_space,
-    ext_intel_global_device_space,
-    ext_intel_global_host_space
+  global_space,
+  local_space,
+  constant_space, // Deprecated in SYCL 2020
+  private_space,
+  generic_space,
+  ext_intel_global_device_space,
+  ext_intel_global_host_space
 };
 ```
 
@@ -99,7 +97,7 @@ Add the following new conversion operator:
 explicit operator multi_ptr<ElementType, access::address_space::global_space>() const; 
 ```
 
-Add a new row to Table 4.54: Constructors of the SYCL multi_ptr class template, as follows:
+Add a new row to Table 91: Constructors of the SYCL multi_ptr class template, as follows:
 
 --
 [options="header"]

sycl/include/CL/sycl/feature_test.hpp

@@ -24,7 +24,7 @@ namespace sycl {
 #define SYCL_EXT_ONEAPI_MATRIX 2
 #endif
 #define SYCL_EXT_INTEL_BF16_CONVERSION 1
-#define SYCL_EXT_INTEL_ENQUEUE_BARRIER 1
+#define SYCL_EXT_ONEAPI_ENQUEUE_BARRIER 1
 #define SYCL_EXT_INTEL_MEM_CHANNEL_PROPERTY 1
 #define SYCL_EXT_INTEL_USM_ADDRESS_SPACES 1
 #define SYCL_EXT_ONEAPI_BACKEND_LEVEL_ZERO 1

sycl/include/CL/sycl/handler.hpp

@@ -2307,7 +2307,9 @@ class __SYCL_EXPORT handler {
   /// \param WaitList is a vector of valid SYCL events that need to complete
   /// before barrier command can be executed.
   __SYCL2020_DEPRECATED("use 'ext_intel_barrier' instead")
-  void barrier(const std::vector<event> &WaitList);
+  void barrier(const std::vector<event> &WaitList) {
+    ext_intel_barrier(WaitList);
+  }
 
   /// Copies data from one memory region to another, both pointed by
   /// USM pointers.