Publish cl_img_unified_svm_external_memory_dma_buf extension specification

Extension adds optional properties to clSVMAllocWithPropertiesKHR to allow passing a dma_buf FD to import as an SVM allocation, and a virtual address to map the allocation to.

Author: paulfradgley

extensions/cl_img_unified_svm_external_memory_dma_buf.asciidoc

@@ -0,0 +1,121 @@
+
+= cl_img_unified_svm_external_memory
+
+== Name Strings
+
+`cl_img_unified_svm_external_memory`
+
+== Version History
+
+[cols="1,1,3",options="header",]
+|====
+| *Date*     | *Version* | *Description*
+| 2025-04-25 | 1.0.0     | Initial revision.
+| 2025-07-17 | 1.1.0     | Added virtual address property.
+|====
+
+== Contacts
+
+Imagination Technologies Developer Forum: +
+https://forums.imgtec.com/
+
+Paul Fradgley, Imagination Technologies (paul.fradgley 'at' imgtec.com)
+	
+== Contributors
+
+Paul Fradgley, Imagination Technologies.
+
+== Notice
+
+Copyright (c) 2025 Imagination Technologies Ltd. All Rights Reserved.
+	
+== Status
+
+Draft.
+
+== Version
+
+Built On: {docdate} +
+Version: 1.1.0
+
+== Dependencies
+
+Requires OpenCL version 3.0 or later.
+Requires the cl_khr_unified_svm extension to be supported.
+
+This extension is written against the wording of the cl_khr_unified_svm v0.2.0 extension specification draft.
+
+== Overview
+
+This extension adds the functionality to import an external FD handle as an SVM allocation.
+The SVM allocation will be mapped to the virtual address provided.
+
+== New API Functions
+
+None
+
+== New API Enums
+
+[source,opencl]
+----
+CL_SVM_ALLOC_EXTERNAL_MEMORY_DMA_BUF_VIRTUAL_ADDRESS_IMG 0x4220
+CL_SVM_ALLOC_EXTERNAL_MEMORY_DMA_BUF_IMG                 0x4221
+----
+
+== Modifications to the OpenCL API Specification
+
+In Section 5.6, add the following text as a new row in the SVM Allocation Properties table:
+	
+    CL_SVM_ALLOC_EXTERNAL_MEMORY_DMA_BUF_IMG
+
+      Provides an external dma_buf handle to import into the new SVM allocation.
+
+    CL_SVM_ALLOC_EXTERNAL_MEMORY_DMA_BUF_VIRTUAL_ADDRESS_IMG
+
+      Provides the virtual address that the new SVM allocation must map to.
++
+
+Add the following text to the list of error values returned by clSVMAllocWithProperties
+	
+    CL_INVALID_PROPERTY if CL_SVM_ALLOC_EXTERNAL_MEMORY_DMA_BUF_IMG is specificed as part of properties,
+    and properties does not include a valid CL_SVM_ALLOC_EXTERNAL_MEMORY_DMA_BUF_VIRTUAL_ADDRESS_IMG.
+  
+    CL_INVALID_PROPERTY if CL_SVM_ALLOC_EXTERNAL_MEMORY_DMA_BUF_VIRTUAL_ADDRESS_IMG is specificed as part of properties,
+    and properties does not include a valid CL_SVM_ALLOC_EXTERNAL_MEMORY_DMA_BUF_IMG.
+
+== Example Usage ==
+
+[source,opencl]
+----
+const cl_svm_alloc_properties_khr* properties = {
+  (cl_svm_alloc_properties_khr) CL_SVM_ALLOC_EXTERNAL_MEMORY_DMA_BUF_IMG,
+  (cl_svm_alloc_properties_khr) external_fd,
+  (cl_svm_alloc_properties_khr) CL_SVM_ALLOC_EXTERNAL_MEMORY_DMA_BUF_VIRTUAL_ADDRESS_IMG,
+  (cl_svm_alloc_properties_khr) svm_virtual_address,
+  0
+};
+
+clSVMAllocWithPropertiesKHR(
+            context,
+            properties,
+            svm_type_index,
+            size,
+            &errcode_ret);
+----
+
+== Issues
+
+. Do we need to add queries for the supported external memory handle types? Or do we add a dependency on the cl_khr_external_memory extension?
++
+--
+`UNRESOLVED`: 
+--
+
+
+. Do the queries need to take into account the SVM capabilities?
+Can the application query whether we can import a particular dma_buf,
+or do we return an error when they try to use an invalid one?
++
+--
+`UNRESOLVED`: 
+--