Update cl_arm_import_memory specification
Signed-off-by: Kevin Petit <kevin.petit@arm.com>
diff --git a/extensions/arm/cl_arm_import_memory.txt b/extensions/arm/cl_arm_import_memory.txt
index 4807e0b..0f1ca04 100644
--- a/extensions/arm/cl_arm_import_memory.txt
+++ b/extensions/arm/cl_arm_import_memory.txt
@@ -31,7 +31,7 @@
Version
- Revision: #9, Jan 10th, 2020
+ Revision: #10, Feb 13th, 2020
Number
@@ -110,6 +110,7 @@
* CL_IMPORT_TYPE_ARM
* CL_IMPORT_TYPE_PROTECTED_ARM
+ * CL_IMPORT_DMA_BUF_DATA_CONSISTENCY_WITH_HOST_ARM
Valid values for CL_IMPORT_TYPE_ARM are:
@@ -131,6 +132,13 @@
* CL_IMPORT_TYPE_DMA_BUF_ARM is the only valid value for
CL_IMPORT_TYPE_ARM.
+ Valid values for CL_IMPORT_DMA_BUF_DATA_CONSISTENCY_WITH_HOST_ARM are:
+
+ * CL_FALSE - maintaining data consistency between memory and the host's
+ view of it is the application's responsibility (default).
+ * CL_TRUE - data consistency between memory and the host's view is
+ managed by the OpenCL runtime.
+
If <properties> is NULL, default values are taken.
Valid <memory> pointer is dependent on the TYPE passed in properties.
@@ -197,13 +205,18 @@
If the extension string cl_arm_import_memory_dma_buf is exposed then
importing from dma_buf file handles is supported.
- The CL runtime manages dma_buf memory coherency between the host CPU and
- GPU. It is the application's responsibility to ensure visibility in memory
- of changes done by devices which aren't in the same coherency domain as
- the GPU and CPU before using that memory from an OpenCL command. This can
- be achieved either by not enqueueing the workload until the data is
- visible, or by using a user event to prevent the command from being
- executed until the expected data has reached memory.
+ When CL_IMPORT_DMA_BUF_DATA_CONSISTENCY_WITH_HOST_ARM is set to CL_TRUE,
+ the OpenCL runtime manages data consistency between the host CPU and the
+ memory backing the dma_buf allocation. The application is still responsible
+ for ensuring that changes to the memory done outside of the coherency domain
+ in which the host CPU and the OpenCL device reside are made visibible to
+ that coherency domain before using that memory from an OpenCL command. This
+ can be achieved either by not enqueueing the workload until the data is
+ visible, or by using a user event to prevent the command from being executed
+ until the expected data has reached memory.
+
+ Prior to the introduction of CL_IMPORT_DMA_BUF_DATA_CONSISTENCY_WITH_HOST_ARM
+ drivers always managed data consistency between the host CPU and memory.
Flags attached to a dma_buf file handle take precedence over memory flags
supplied to clImportMemoryARM. For example, if a dma_buf allocation
@@ -217,9 +230,6 @@
<size> must be less than or equal to the size of the imported dma_buf
allocation.
- If an application only requires communication between the host CPU and
- the GPU, it should favour using host imports as described further.
-
See also, the code example below.
Host process memory type - CL_IMPORT_TYPE_HOST_ARM
@@ -419,3 +429,4 @@
Revision: #8, Aug 21st, 2019 - Clarified requirements on the size
parameter to clImportMemoryARM.
Revision: #9, Jan 10th, 2020 - Add support for Android harware buffers.
+ Revision: #10, Feb 13th, 2020 - Make dma_buf <-> host data consistency optional.
