Name

    ARM_import_memory

Name Strings

    cl_arm_import_memory
    cl_arm_import_memory_host
    cl_arm_import_memory_dma_buf

    cl_arm_import_memory will be reported if at least one of the other extension
    strings is also reported.

Contributors

    Robert Elliott, ARM
    Vatsalya Prasad, ARM
    Kévin Petit, ARM

Contact

    Kévin Petit, ARM (kevin.petit 'at' ARM.com)

IP Status

    No claims or disclosures are known to exist.

Version

    Revision: #6, Jan 5th, 2018

Number

    OpenCL Extension #38

Status

    Complete.

Extension Type

    OpenCL device extension

Dependencies

    Requires OpenCL version 1.0 or later. Requires OpenCL 1.2 for host access
    cl_mem_flags use when importing, as these were introduced in OpenCL 1.2.

Overview

    This extension adds a new function that allows for direct memory import into
    OpenCL via the clImportMemoryARM function.

    Memory imported through this interface will be mapped into the device's page
    tables directly, providing zero copy access. It will never fall back to copy
    operations and aliased buffers, instead producing an error when mapping is
    not possible.

    Types of memory supported for import are specified as additional extension
    strings.

Header File

    cl_ext.h

Glossary

    No new terminology is introduced by this extension.

New Types

    None

New Procedures and Functions

    The new function

      cl_mem clImportMemoryARM( cl_context context,
                                cl_mem_flags flags,
                                const cl_import_properties_arm *properties,
                                void *memory,
                                size_t size,
                                cl_int *errorcode_ret );

    Description

      Given a suitable pointer to an external memory allocation <memory> this
      function will map the memory into the device page tables.

      The flags argument provides standard OpenCL memory object flags.

      Valid <flags> are:

        * CL_MEM_READ_WRITE, CL_MEM_WRITE_ONLY, CL_MEM_READ_ONLY
        * CL_MEM_HOST_WRITE_ONLY, CL_MEM_HOST_READ_ONLY, CL_MEM_HOST_NO_ACCESS -
          where the host flags are only hints and only apply from OpenCL 1.2
          onwards.
        * CL_MEM_USE_HOST_PTR - this flag has no effect, it is ignored.

      The properties argument provides a list of key value pairs, with a zero
      terminator. properties can be NULL or point to a single zero value if the
      default behaviour is desired.

      Valid <properties> are:

        * CL_IMPORT_TYPE_ARM

      Valid values for CL_IMPORT_TYPE_ARM are:

        * CL_IMPORT_TYPE_HOST_ARM - this is the default
        * CL_IMPORT_TYPE_DMA_BUF_ARM

      If <properties> is NULL, default values are taken.

      Valid <memory> pointer is dependent on the TYPE passed in properties.

    Errors

      CL_INVALID_CONTEXT on invalid context.

      CL_INVALID_VALUE on invalid flag input.

      CL_INVALID_PROPERTY when invalid properties are passed.

      CL_INVALID_VALUE if memory is NULL.

      CL_INVALID_OPERATION when host virtual pages in the range of <memory> to
      <memory>+<size> are not mapped in the userspace address space. This does
      _not_ include cases where physical pages are not allocated. For specific
      behaviour see documentation for those memory types.

      CL_INVALID_OPERATION when an imported memory object has been passed to
      one of the following API functions (they can't be used with imported
      memory objects):

             * clEnqueueMapBuffer
             * clEnqueueMapImage
             * clEnqueueUnmapMemObject
             * clEnqueueReadImage
             * clEnqueueWriteImage
             * clEnqueueReadBuffer
             * clEnqueueReadBufferRect
             * clEnqueueWriteBuffer
             * clEnqueueWriteBufferRect
             * clEnqueueCopyBuffer
             * clEnqueueCopyBufferRect
             * clEnqueueCopyBufferToImage
             * clEnqueueCopyImageToBuffer
             * clEnqueueCopyImage
             * clEnqueueFillBuffer
             * clEnqueueFillImage

      Futher error information may be reported via the cl_context callback
      function.

New memory import types

    Linux dma_buf memory type - CL_IMPORT_TYPE_DMA_BUF_ARM

      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.

      Flags attached to a dma_buf file handle take precedence over memory flags
      supplied to clImportMemoryARM. For example, if a dma_buf allocation
      originally created with a read-only flag is passed to clImportMemoryARM
      with the READ_WRITE flag, the more restrictive READ_ONLY will take
      precedence.

      dma_buf allocations are page-aligned and their size is a whole number of
      pages.

      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

      If the extension string cl_arm_import_memory_host is exposed then importing
      from normal userspace allocations (such as those created via malloc) is
      supported.

      If the host OS is linux and overcommit of VA is allowed, then this
      function will commit and pin physical pages for the VA range. This may
      cause larger physical allocations than the application typically provokes
      if memory is sparsely used. In this case sub-ranges of the host allocation
      should be passed to the import function individually.

      It is the application's responsibility to align for the datatype being
      accessed. Though the application is free to provide allocations without
      any specific alignment on coherent systems, there is a requirement to
      provide pointers aligned to a cache line on systems where there is no
      HW-managed coherency between CPU and GPU. When alignment is less than a
      page size then whole pages touched by addresses in the range of <memory>
      to <memory>+<size> will be mapped into the device. If the page is already
      mapped by another unaligned import, an error will occur.

      Cache coherency will be HW-managed on systems where it is supported.
      Otherwise, cache maintenance operations will be added by the CL runtime
      where needed.

      Importing host memory that is otherwise being used by a device outside
      of the CPU/GPU coherency domain isn't guaranteed to work and the GPU
      caches may contain stale data.

      Importing dma_buf pages through a CPU mapping is undefined.

      Importing two allocations that aren't page-aligned and that request
      different memory flags is unsupported; an error will be returned.

      This method is recommended to be used when interoperating with an existing
      host library which performs its own allocation and cannot be passed
      handles to mapped OpenCL buffers.

      See also, the code example below.

New Tokens

    None

Interactions with other extensions

    This extension produces cl_mem memory objects which are compatible with all
    other uses of cl_mem in the standard API, including creating images from
    the resulting cl_mem and subject to the restrictions listed in this
    document.

    In order to guarantee data consistency, applications must ensure that neither
    the host nor any device attempt to perform simultaneous read and write
    operations on any part of the memory backing an imported buffer or sub-buffers
    created therefrom, even if these accesses do not overlap. For example, this
    implies that it is not possible to write part of the memory backing an imported
    buffer on the host while reading a sub-buffer created from that buffer on a
    device, even if the memory written by the host is not visible through the
    sub-buffer.

    This extension also provides an alternative to image import via EGL.

Sample Code

    CL_IMPORT_TYPE_DMA_BUF_ARM

      #define WIDTH  1024
      #define HEIGHT 512

      // Create buffer to be used as a hardware texture with graphics APIs (can also
      // include video/camera use flags here)
      int dma_buf_handle = get_dma_buf_handle_from_exporter_kernel_module( ..., WIDTH * HEIGHT * 2 );

      cl_int error = CL_SUCCESS;
      cl_mem buffer = clImportMemoryARM( ctx,
                                         CL_MEM_READ_WRITE,
                                         { CL_IMPORT_TYPE_ARM, CL_IMPORT_TYPE_DMA_BUF_ARM, 0 },
                                         &dma_buf_handle
                                         WIDTH * HEIGHT * 2,
                                         &error );

      if( error == CL_SUCCESS )
      {
          // Use <buffer> as you would any other cl_mem buffer
      }


    CL_IMPORT_TYPE_HOST_ARM

      #define WIDTH  1024
      #define HEIGHT 512

      // tightly packed buffer we will treat as RGB565
      char *buffer = malloc( WIDTH * HEIGHT * 2 );

      // The type CL_IMPORT_TYPE_HOST_ARM can be omitted as it is the default
      cl_int error = CL_SUCCESS;
      cl_mem buffer = clImportMemoryARM( ctx,
                                         CL_MEM_READ_WRITE,
                                         NULL,
                                         buffer,
                                         WIDTH * HEIGHT * 2,
                                         &error );

      if( error == CL_SUCCESS )
      {
          // Use <buffer> as you would any other cl_mem buffer
      }

Conformance Tests

    None

Revision History

    Revision: #1, Apr 27th, 2015 - Initial revision
    Revision: #2, Apr 28th, 2015 - Added properties field to avoid type
                                   inferrence. Added Issues section.
    Revision: #3, May 5th, 2015  - Added image support info in Issues.
    Revision: #4, Aug 4th, 2015  - Revised based on implementation and design
                                   changes made during review.
    Revision: #5, May 3rd, 2017  - Additional restrictions on host operations
                                   and general cleanup / clarification.
    Revision: #6, Jan 5th, 2018  - Support creating a sub-buffer from an imported
                                   buffer.