Interaction between mutable-dispatch and USM extensions

[EwanC]

The cl_khr_command_buffer_mutable_dispatch extension defines a mechanism for updating SVM arguments to command-buffer kernel commands, however there is no mention of the interaction with USM kernel arguments.

It was initially considered that updating USM arguments could be done through the SVM mechanism - num_svm_args / arg_svm_list. However, this will only work if either a) a vendor doesn't support SVM, so can unambiguously treat user passed values here as USM, or b) a vendor implements SVM and USM using the same underlying mechanism so the pointers are interchangeable. E.g passing a USM pointer to clSetKernelArgSVMPointer happens to work as an implementation detail.

Although these two scenarios cover are applicable to the two known vendors of USM a) Codeplay and b) Intel, it would be valid for another vendor in the future to implement both SVM and USM in a way that the pointers are not interchangeable. Therefore, we should have an explicit mechanism for updating USM args. I can think of two possible approaches:

1. Modify cl_khr_command_buffer_mutable_dispatch extension to define USM fields similar to num_svm_args / arg_svm_list but for USM.

2. Add an "Interaction with Other Extensions" section to the USM extension to take advantage of the pointer chaining mechanism in cl_khr_command_buffer_mutable_dispatch, e.g:

   // Pointer chained from cl_mutable_dispatch_config_khr
   typedef struct {
    cl_command_buffer_structure_type_khr type;
    const void* next;
    cl_uint num_usm_args;
    const cl_mutable_dispatch_arg_khr* arg_usm_list;
   } cl_mutable_dispatch_usm_arg_intel;
   
   // Value for cl_command_buffer_structure_type_khr which would need reserved in the XML
   #define CL_STRUCTURE_TYPE_MUTABLE_DISPATCH_USM_ARG_CONFIG_INTEL 2      

[EwanC]

Since this issue was created a draft of cl_khr_unified_svm has been created.

This feature request was motivated by allowing SYCL-Graph to be able to update SYCL USM arguments to kernel nodes in the graph. If cl_khr_unified_svm was used in SYCL implementations rather than the cl_intel_unified_shared_memory vendor extension to implement SYCL USM, as I believe is the intention, it would change the nature of this request to clarify the usage of cl_khr_unified_svm allocations in mutable-dispatch.