[SYCL][Graph][Doc] Add dynamic_events and other event features to sycl_ext_oneapi_graph

[Bensuo]

Summary

This PR adds wording and support for dynamic dependencies in graphs using dynamic_event, which can be used to define dependencies on eager SYCL operations outside of a graph that can be updated between graph executions. It also adds wording which allows for defining dependencies between separate graphs, and being able to obtain SYCL events which represent the most recent execution of a given node inside a graph.

Changes

• Adds dynamic events which are updatable between graph executions
• Removes limitations on depending on SYCL events from outside a graph
• depends_on property can now take events/dynamic events
• Allow barriers in the explicit API
• Extend barriers to support dynamic events
• Added get_event() to get event for node execution in a graph
• Add a new graph property which requires that an execution event is available
• Add new examples to the usage guide for dynamic events and command_graph::get_event()
• Define some spec only terms for talking about events
  • "Regular" SYCL events which are normal events as defined in the SYCL spec
  • "Limited graph events" - Events returned from recorded submissions to a graph that are only used for defining dependencies inside graphs.
• Remove restrictions on "limited graph events" being used in other graphs
• Now used to define inter-graph dependencies
• Various changes to errors etc. to reflect change
• Add example of this to usage guide

[fabiomestre]

Left a few very minor comments. LGTM otherwise 👍

[guoyejun]

Suggested change

	Graph.begin_recording(SyclQueue);
	Graph.begin_recording(SyclQueue or AnotherSyclQueue);

it could be in different sycl queues

[Bensuo]

Does this need to be specified? There are no restrictions on recording from different queues, or restrictions across queues with normal SYCL submissions. I feel like the user can infer from the lack of this restriction in any of the function definitions that this is fine, and repeating it in every single example or description is unnecessary.

[guoyejun]

does this mean that event from command_graph<graph_state::executable>::get_event(node) can not be used to define dependencies between graphs? If so, we may need to change section 7.2.1 to exclude such event from regular sycl events, or change other sections.

In section 7.2.1, Regular SYCL events: ... and events obtained via command_graph<graph_state::executable>::get_event()
In section 7.2.2, ... or [regular SYCL events] to either handler::depends_on() or property::node::depends_on property, will create external dependencies
In section 7.2.3, ... or [regular SYCL events] to handler::depends_on() will create external dependencies for graph nodes

[Bensuo]

Yes that is correct, it is a little clunky to fully specify in this specification because we are adding errors to existing SYCL functions. I've removed them from the definition of regular SYCL events and added emphasis that try to use these for graph nodes is an error (on top of the existing errors in our function definitions).

[guoyejun]

yes, it's not easy to understand for me since there are so many sources of events and event usages. Not sure if it will be easier if we add a new type of event at the beginning.

1. Graph-limited events
   1.1 event from the same graph
   1.2 event from different graph only if that graph has finalized once and requires_execution_event is enabled
2. Regular SYCL events
   2.1 normal submissions to SYCL queue
   2.2 submitting an executable command_graph
3. Graph-extended events (I don't have a good naming here)
   command_graph<graph_state::executable>::get_event(node) only if requires_execution_event is enabled

My idea is that, if we define all the possible events at the beginning, we are easy to describe their usage latter.

anyway, just for your reference.