Clarify Interaction with other extensions

[EwanC]

See feedback from intel#5626 (comment)

We need to specify the interaction with existing oneAPI extensions that could have behaviour affected as a result of graphs, and going forward monitor extensions going into DPC++ for possible interactions we'll need to update to take account of.

There is an extension sycl_ext_oneapi_enqueue_barrier we should probably specify the compatibility with one way or another.

[EwanC]

List of extensions it might be worth specifying the interaction with

1. https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/supported/sycl_ext_oneapi_discard_queue_events.asciidoc - Specify how this property interacts with record and replay, can't be used in handler::depends_on() to another graph node to create an edge
2. https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/supported/sycl_ext_oneapi_enqueue_barrier.asciidoc - Forbid for revision 1 to keep implementation scope manageable? Look at for rev 2?
3. https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/supported/sycl_ext_oneapi_memcpy2d.asciidoc - Forbid these handler functions for the moment to keep implementation scope manageable? Although they could be supportable for rev 2.
4. https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/supported/sycl_ext_oneapi_queue_priority.asciidoc - Specify that queue priority is ignored by graph recording.
5. https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/supported/sycl_ext_oneapi_queue_empty.asciidoc - query is ignored during graph recording and behaves as normal, recorded commands are not counted as submitted.
6. https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/supported/sycl_ext_intel_queue_index.asciidoc - What does index mean for recording? Should we remember the index of nodes
7. https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/experimental/sycl_ext_codeplay_kernel_fusion.asciidoc - Forbid interaction and tell users to wait on graph fusion.
8. https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/experimental/sycl_ext_oneapi_kernel_properties.asciidoc - Forbid new handler methods in graphs to keep implementation scope manageable? Then look at for rev 2?
9. https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/proposed/sycl_ext_oneapi_prod.asciidoc - Ignored by graph recording, but should we go further and throw an exception?
10. https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/proposed/sycl_ext_oneapi_device_global.asciidoc - new hander/queue functions ignored by graphs to keep implementation scope manageable? Look at for rev 2?

[EwanC]

There's also a pending PR for SYCL boundless images spec that adds new functions to a handler - intel#8307 - we could pre-emptively forbid these and then look at it for rev 2 if merged by then

[Bensuo]

https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/supported/sycl_ext_oneapi_discard_queue_events.asciidoc - Specify how this property interacts with record and replay, can't be used in handler::depends_on() to another graph node to create an edge

I'm not sure we need to specify anything do we? Trying to use the property with depends_on() would already throw an exception. If we specify how edges are created I think the user could infer that they wouldn't be able to do this either.

[Bensuo]

https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/supported/sycl_ext_intel_queue_index.asciidoc - What does index mean for recording? Should we remember the index of nodes

I'd guess we'd have to do as you say and then partition the graph such that we could have separate command lists for each index. For now we could just say that the queue index is ignored when recording and then potentially support it later? Quite a niche extension by the sounds of it so maybe not top priority.

[Bensuo]

https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/proposed/sycl_ext_oneapi_prod.asciidoc - Ignored by graph recording, but should we go further and throw an exception?

I think as it's just a performance hint we can just say we ignore it.

https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/experimental/sycl_ext_oneapi_kernel_properties.asciidoc

I think this is safe to forbid for now, it should be handled by the handler but given what it does I'd wager there's code in the commands/scheduler that also deals with this.

https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/proposed/sycl_ext_oneapi_device_global.asciidoc

Hmm I think this is also safer to forbid for revision 1. I think if we sort out kernel bundles/spec constants this should work automatically, since they seem to be set for the device image inside the kernel bundle. However the design is quite complex so it's hard to say for sure without digging deeper into it.