Merge from 'sycl' to 'sycl-web'

Author: iclsrc

sycl/doc/design/CommandGraph.md

@@ -277,6 +277,13 @@ Level Zero:
    `waitForEvents` on the same command-list. Resulting in additional latency when
    executing a UR command-buffer.
 
+3. Dependencies between multiple submissions must be handled by the runtime.
+   Indeed, when a second submission is performed the signal conditions 
+   of *WaitEvent* are redefined by this second submission. 
+   Therefore, this can lead to an undefined behavior and potential
+   hangs especially if the conditions of the first submissions were not yet 
+   satisfied and the event has not yet been signaled.
+
 Future work will include exploring L0 API extensions to improve the mapping of
 UR command-buffer to L0 command-list.
 

sycl/doc/extensions/experimental/sycl_ext_oneapi_graph.asciidoc

@@ -1059,9 +1059,10 @@ void
 handler::ext_oneapi_graph(command_graph<graph_state::executable>& graph)
 ----
 
-|Invokes the execution of a graph. Only one instance of `graph` may be executing,
-or pending execution, at any time. Concurrent graph execution can be achieved by
-finalizing a graph in modifiable state into multiple graphs in executable state.
+|Invokes the execution of a graph. Only one instance of `graph` will
+execute at any time. If `graph` is submitted multiple times, dependencies
+are automatically added by the runtime to prevent concurrent executions of 
+an identical graph.
 
 Parameters:
 
@@ -1073,8 +1074,6 @@ Exceptions:
   to a queue which is associated with a device or context that is different
   from the device and context used on creation of the graph.
 
-* Throws synchronously with error code `invalid` if a previous submission of
-  `graph` has yet to complete execution.
 |===
 
 === Thread Safety
@@ -1590,6 +1589,12 @@ outputs of the modifiable graph, a technique called _Whole Graph Update_. The
 modifiable graph must have the same topology as the graph originally used to
 create the executable graphs, with the nodes targeting the same devices and
 added in the same order.
+If a graph has been updated since its last submission, the sequential 
+execution constraint is no longer required.
+The automatic addition of dependencies is disabled and updated graphs 
+can be submitted simultaneously.
+Users are therefore responsible for explicitly managing potential dependencies
+between these executions to avoid data races.
 
 :sycl-kernel-function: https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sycl-kernel-function
 
@@ -1719,15 +1724,6 @@ runtime.
 
 == Issues
 
-=== Simultaneous Graph Submission
-
-Enable an instance of a graph in executable state to be submitted for execution
-when a previous submission of the same graph has yet to complete execution.
-
-**UNRESOLVED:** Trending "yes". Backend support for this is inconsistent, but
-the runtime could schedule the submissions sequentially for backends which don't
-support it.
-
 === Multi Device Graph
 
 Allow an executable graph to contain nodes targeting different devices.
@@ -1792,6 +1788,9 @@ if used in application code.
   `sycl::ext::intel::property::queue::no_immediate_command_list`
   should be set on construction to any queues an executable
   graph is submitted to.
+. Synchronization between multiple executions of the same command-buffer 
+  must be handled in the host for level-zero backend, which may involve 
+  extra latency for subsequent submissions.
 
 == Revision History
 

sycl/include/sycl/queue.hpp

@@ -412,9 +412,7 @@ class __SYCL_EXPORT queue : public detail::OwnerLessBase<queue> {
   /// \return a SYCL event object, which corresponds to the queue the command
   /// group is being enqueued on.
   event ext_oneapi_submit_barrier(
-      const detail::code_location &CodeLoc = detail::code_location::current()) {
-    return submit([=](handler &CGH) { CGH.ext_oneapi_barrier(); }, CodeLoc);
-  }
+      const detail::code_location &CodeLoc = detail::code_location::current());
 
   /// Prevents any commands submitted afterward to this queue from executing
   /// until all events in WaitList have entered the complete state. If WaitList
@@ -427,10 +425,7 @@ class __SYCL_EXPORT queue : public detail::OwnerLessBase<queue> {
   /// group is being enqueued on.
   event ext_oneapi_submit_barrier(
       const std::vector<event> &WaitList,
-      const detail::code_location &CodeLoc = detail::code_location::current()) {
-    return submit([=](handler &CGH) { CGH.ext_oneapi_barrier(WaitList); },
-                  CodeLoc);
-  }
+      const detail::code_location &CodeLoc = detail::code_location::current());
 
   /// Performs a blocking wait for the completion of all enqueued tasks in the
   /// queue.

sycl/source/detail/graph_impl.cpp

@@ -772,12 +772,40 @@ exec_graph_impl::enqueue(const std::shared_ptr<sycl::detail::queue_impl> &Queue,
         CurrentPartition->MPiCommandBuffers[Queue->get_device()];
 
     if (CommandBuffer) {
-      if (!previousSubmissionCompleted()) {
-        throw sycl::exception(
-            make_error_code(errc::invalid),
-            "This Graph cannot be submitted at the moment "
-            "because the previous run has not yet completed.");
+      // if previous submissions are incompleted, we automatically
+      // add completion events of previous submissions as dependencies.
+      // With Level-Zero backend we cannot resubmit a command-buffer until the
+      // previous one has already completed.
+      // Indeed, since a command-list does not accept a list a dependencies at
+      // submission, we circumvent this lack by adding a barrier that waits on a
+      // specific event and then define the conditions to signal this event in
+      // another command-list. Consequently, if a second submission is
+      // performed, the signal conditions of this single event are redefined by
+      // this second submission. Thus, this can lead to an undefined behaviour
+      // and potential hangs. We have therefore to expliclty wait in the host
+      // for previous submission to complete before resubmitting the
+      // command-buffer for level-zero backend.
+      // TODO : add a check to release this constraint and allow multiple
+      // concurrent submissions if the exec_graph has been updated since the
+      // last submission.
+      for (std::vector<sycl::detail::EventImplPtr>::iterator It =
+               MExecutionEvents.begin();
+           It != MExecutionEvents.end();) {
+        auto Event = *It;
+        if (!Event->isCompleted()) {
+          if (Queue->get_device().get_backend() ==
+              sycl::backend::ext_oneapi_level_zero) {
+            Event->wait(Event);
+          } else {
+            CGData.MEvents.push_back(Event);
+          }
+          ++It;
+        } else {
+          // Remove completed events
+          It = MExecutionEvents.erase(It);
+        }
       }
+
       NewEvent = CreateNewEvent();
       sycl::detail::pi::PiEvent *OutEvent = &NewEvent->getHandleRef();
       // Merge requirements from the nodes into requirements (if any) from the

sycl/source/detail/queue_impl.cpp

@@ -356,6 +356,11 @@ event queue_impl::memcpyFromDeviceGlobal(
   return MDiscardEvents ? createDiscardedEvent() : ResEvent;
 }
 
+event queue_impl::getLastEvent() const {
+  std::lock_guard<std::mutex> Lock{MLastEventMtx};
+  return MDiscardEvents ? createDiscardedEvent() : MLastEvent;
+}
+
 void queue_impl::addEvent(const event &Event) {
   EventImplPtr EImpl = getSyclObjImpl(Event);
   assert(EImpl && "Event implementation is missing");

sycl/source/detail/queue_impl.hpp

@@ -202,6 +202,8 @@ class queue_impl {
 #endif
   }
 
+  event getLastEvent() const;
+
 private:
   void queue_impl_interop(sycl::detail::pi::PiQueue PiQueue) {
     if (has_property<ext::oneapi::property::queue::discard_events>() &&

sycl/source/queue.cpp

@@ -192,6 +192,38 @@ void queue::wait_and_throw_proxy(const detail::code_location &CodeLoc) {
   impl->wait_and_throw(CodeLoc);
 }
 
+/// Prevents any commands submitted afterward to this queue from executing
+/// until all commands previously submitted to this queue have entered the
+/// complete state.
+///
+/// \param CodeLoc is the code location of the submit call (default argument)
+/// \return a SYCL event object, which corresponds to the queue the command
+/// group is being enqueued on.
+event queue::ext_oneapi_submit_barrier(const detail::code_location &CodeLoc) {
+  if (is_in_order())
+    return impl->getLastEvent();
+
+  return submit([=](handler &CGH) { CGH.ext_oneapi_barrier(); }, CodeLoc);
+}
+
+/// Prevents any commands submitted afterward to this queue from executing
+/// until all events in WaitList have entered the complete state. If WaitList
+/// is empty, then ext_oneapi_submit_barrier has no effect.
+///
+/// \param WaitList is a vector of valid SYCL events that need to complete
+/// before barrier command can be executed.
+/// \param CodeLoc is the code location of the submit call (default argument)
+/// \return a SYCL event object, which corresponds to the queue the command
+/// group is being enqueued on.
+event queue::ext_oneapi_submit_barrier(const std::vector<event> &WaitList,
+                                       const detail::code_location &CodeLoc) {
+  if (is_in_order() && WaitList.empty())
+    return impl->getLastEvent();
+
+  return submit([=](handler &CGH) { CGH.ext_oneapi_barrier(WaitList); },
+                CodeLoc);
+}
+
 template <typename Param>
 typename detail::is_queue_info_desc<Param>::return_type
 queue::get_info() const {

sycl/test-e2e/Basic/vec_bool.cpp renamed to sycl/test-e2e/Basic/vector/bool.cpp

@@ -12,9 +12,11 @@
 //
 //===----------------------------------------------------------------------===//
 
-#define SYCL_SIMPLE_SWIZZLES
 #include <sycl/sycl.hpp>
 
+#include <cstddef> // std::byte
+#include <tuple>   // std::ignore
+
 int main() {
   std::byte bt{7};
   // constructors
@@ -30,7 +32,7 @@ int main() {
     // operator[]
     assert(vb16[3] == std::byte{2});
     // explicit conversion
-    std::byte(vb1.x());
+    std::ignore = std::byte(vb1.x());
     std::byte b = vb1;
 
     // operator=