Contact
Please see the Issues list in the Khronos OpenCL-Docs repository:
https://github.com/KhronosGroup/OpenCL-Docs
Contributors
Kevin Petit, Arm Ltd.
Jeremy Kemp, Imagination Technologies
Alastair Murray, Codeplay Software Ltd.
Balaji Calidas, Qualcomm
Notice
Copyright 2008-2023 The Khronos Group Inc.
This Specification is protected by copyright laws and contains material proprietary to Khronos. Except as described by these terms, it or any components may not be reproduced, republished, distributed, transmitted, displayed, broadcast or otherwise exploited in any manner without the express prior written permission of Khronos.
This Specification has been created under the Khronos Intellectual Property Rights Policy, which is Attachment A of the Khronos Group Membership Agreement available at www.khronos.org/files/member_agreement.pdf and defines the terms 'Scope', 'Compliant Portion', and 'Necessary Patent Claims'.
Khronos grants a conditional copyright license to use and reproduce the unmodified Specification for any purpose, without fee or royalty, EXCEPT no licenses to any patent, trademark or other intellectual property rights are granted under these terms. Parties desiring to implement the Specification and make use of Khronos trademarks in relation to that implementation, and receive reciprocal patent license protection under the Khronos Intellectual Property Rights Policy must become Adopters and confirm the implementation as conformant under the process defined by Khronos for this Specification; see https://www.khronos.org/adopters.
Khronos makes no, and expressly disclaims any, representations or warranties, express or implied, regarding this Specification, including, without limitation: merchantability, fitness for a particular purpose, non-infringement of any intellectual property, correctness, accuracy, completeness, timeliness, and reliability. Under no circumstances will Khronos, or any of its Promoters, Contributors or Members, or their respective partners, officers, directors, employees, agents or representatives be liable for any damages, whether direct, indirect, special or consequential damages for lost revenues, lost profits, or otherwise, arising from or in connection with these materials.
Where this Specification identifies specific sections of external references, only those specifically identified sections define normative functionality. The Khronos Intellectual Property Rights Policy excludes external references to materials and associated enabling technology not created by Khronos from the Scope of this specification, and any licenses that may be required to implement such referenced materials and associated technologies must be obtained separately and may involve royalty payments.
Khronos® and Vulkan® are registered trademarks, and SPIR™, SPIR-V™, and SYCL™ are trademarks of The Khronos Group Inc. OpenCL™ is a trademark of Apple Inc. used under license by Khronos. OpenGL® is a registered trademark and the OpenGL ES™ and OpenGL SC™ logos are trademarks of Hewlett Packard Enterprise used under license by Khronos. All other product names, trademarks, and/or company names are used solely for identification and belong to their respective owners.
Dependencies
This extension is written against the OpenCL Specification version 3.0.9.
This extension requires OpenCL 3.0.
This extension requires cl_ext_image_requirements_info
.
New API Enums
Accepted value for the param_name parameter to clGetImageRequirementsInfoEXT:
CL_IMAGE_REQUIREMENTS_SLICE_PITCH_ALIGNMENT_EXT 0x1291
Modifications to the OpenCL API Specification
- (Modify Section 5.3.1, Creating Image Objects)
-
The following text:
image_format is a pointer to a structure that describes format properties of the image to be allocated. A 1D image buffer or 2D image can be created from a buffer by specifying a buffer object in the image_desc→mem_object. A 2D image can be created from another 2D image object by specifying an image object in the image_desc→mem_object. Refer to the Image Format Descriptor section for a detailed description of the image format descriptor.
is replaced with:
image_format is a pointer to a structure that describes format properties of the image to be allocated. An image can be created from a buffer by specifying a buffer object in the image_desc→_mem_object_. A 2D image can be created from another 2D image object by specifying an image object in the image_desc→_mem_object_. Refer to the Image Format Descriptor section for a detailed description of the image format descriptor.
The following text:
CL_INVALID_
if a 2D image is created from a buffer and
the row pitch and base address alignment does not follow the rules described
for creating a 2D image from a buffer.
is replaced with:
CL_INVALID_
if an image is created from a buffer and
the row or slice pitch and base address alignment do not follow the rules
described for creating an image from a buffer.
The following text is added to the list of error conditions for clCreateImageWithProperties:
CL_INVALID_
if an image is created from a buffer and the buffer
passed in image_desc→_mem_object is too small to be used as a data store
for the image, e.g. if its size is smaller than the value returned for
CL_IMAGE_
for the parameters used to create the image.
The following text:
For a 2D image created from a buffer, the pitch specified (or computed if
pitch specified is 0) must be a multiple of the maximum of the
CL_DEVICE_
value for all devices in the context associated
with the buffer specified by mem_object that support images.
is replaced with:
For an image created from a buffer, the pitch specified (or computed if
pitch specified is 0) must be a multiple of the
CL_IMAGE_
value for the image_format,
image_type and flags used to create the image.
The following text is added to the description for image_slice_pitch
:
For an image created from a buffer, the pitch specified (or computed if
pitch specified is 0) must be a multiple of the
CL_IMAGE_
value for the image_format,
image_type and flags used to create the image.
The following text:
mem_object
may refer to a valid buffer or image memory object. mem_object
can be a buffer memory object if image_type is CL_MEM_
or CL_MEM_
. mem_object
can be an image object if image_type
is CL_MEM_
. Otherwise it must be NULL
. The image pixels are
taken from the memory objects data store. When the contents of the specified
memory objects data store are modified, those changes are reflected in the
contents of the image object and vice-versa at corresponding synchronization
points.
is replaced with:
mem_object
may refer to a valid buffer or image memory object. mem_object
can be an image object if image_type is CL_MEM_
.
Otherwise it must be NULL
. The image pixels are taken from the memory objects
data store. When the contents of the specified memory objects data store are
modified, those changes are reflected in the contents of the image object and
vice-versa at corresponding synchronization points.
The following text is added:
For a 1D image created from a buffer object, the image_width
× size of
element in bytes must be ≤ size of the buffer object. The image data in the
buffer object is stored as a single scanline which is a linear sequence of
adjacent elements.
For a 1D image array created from a buffer object, the image_slice_pitch
×
image_array_size
must be ≤ size of the buffer object specified by mem_object
.
The image data in the buffer object is stored as a linear sequence of adjacent 1D
slices. Each slice is a single scanline padded to image_slice_pitch
bytes.
Each scanline is a linear sequence of image elements.
For a 2D image array created from a buffer object, the image_slice_pitch
×
image_array_size
must be ≤ size of the buffer object specified by mem_object
.
The image data in the buffer object is stored as a linear sequence of adjacent 2D
slices. Each slice is a linear sequence of adjacent scanlines padded to
image_slice_pitch
bytes. Each scanline is a linear sequence of image elements padded
to image_row_pitch
bytes.
For a 3D image created from a buffer object, the image_slice_pitch
×
image_depth
must be ≤ size of the buffer object specified by mem_object
.
The image data in the buffer object is stored as a linear sequence of adjacent 2D
slices padded to image_slice_pitch
bytes. Each slice is a linear sequence of adjacent
scanlines. Each scanline is a linear sequence of image elements padded to
image_row_pitch
bytes.
The following text:
Concurrent reading from, writing to and copying between both a buffer object and 1D image buffer or 2D image object associated with the buffer object is undefined. Only reading from both a buffer object and 1D image buffer or 2D image object associated with the buffer object is defined.
is replaced with:
Concurrent reading from, writing to and copying between both a buffer object and an image object associated with the buffer object is undefined. Only reading from both a buffer object and image object associated with the buffer object is defined.
- (Modify section 5.3.X, Querying image requirements)
The following is added to the _List of supported param_names by clGetImageRequirementsInfoEXT:
Image Requirement Info | Return type | Info. returned in param_value |
---|---|---|
|
|
Returns the slice pitch alignment required in bytes for images created from
a buffer with the parameters passed to clGetImageRequirementsInfoEXT.
The value returned is a power of two. image_format and image_desc are
allowed to be |
Conformance tests
-
Test access from kernel
-
For all image types
-
For a few/all image formats
-
For several values of row/slice pitch
-
With or without a host_ptr
-
Create buffer and fill with data
-
Optionally create a sub-buffer with a randomly selected offset?
-
Create an image from the buffer
-
Read the image from a kernel and compare with values read using the buffer and direct addressing. They must match.
-
-
TODO Test access via read/write/map commands?
-
TODO Test copy to/from buffer?
-
TODO Test fill?
-
TODO Test copy to/from another image?
-
Test clGetImageInfo
-
For all image types (one format per element size)
-
For a few different row/pitch sizes (image dimensions being equal or not)
-
Create an image from a buffer
-
Check that the returned values for
CL_IMAGE_
andROW_ PITCH CL_IMAGE_
are correct.SLICE_ PITCH
-
-
Test clGetMemObjectInfo
-
For all image types (1 format only)
-
Create an image from a buffer
-
Check that
CL_MEM_
correctly returns the buffer that was used.ASSOCIATED_ MEMOBJECT
-
-
Negative testing for clCreateImage (alignment)
-
For a few/all image formats
-
For all image types
-
Query row pitch, slice pitch and base image address alignment for the format
-
Create an image from a buffer with invalid row pitch (not a multiple of required alignment) and check that
CL_INVALID_
is returned.IMAGE_ FORMAT_ DESCRIPTOR -
Create an image from a buffer with invalid slice pitch (not a multiple of required alignment) and check that
CL_INVALID_
is returned.IMAGE_ FORMAT_ DESCRIPTOR -
Create an image from a buffer with invalid base address alignment (not a multiple of required alignment) and check that
CL_INVALID_
is returned.IMAGE_ FORMAT_ DESCRIPTOR
-
-
Negative testing for clCreateImage (buffer size)
-
For a few image formats (at least smallest and biggest element types)
-
For all image types
-
Create a buffer too small
-
Check that image creation from that buffer is rejected with
CL_INVALID_
IMAGE_ SIZE
-