CLCREATEIMAGE(3clc)

📦
version 1.0~svn33624 · 3 versions
, in ubuntu jammy, ubuntu noble

💅 CLCREATEIMAGE(3clc) — OpenCL Manual, section 3clc 💅

okay so bestie, welcome to the OpenCL Manual, section 3clc. this page is literally about clCreateImage. no cap. let's get into it. 🫶

🌸 NAME 🌸

clCreateImage — Creates a 1D image, 1D image buffer, 1D image array, 2D image, 2D image array or 3D image object. ✨

✨ SYNOPSIS ✨

cl_mem clCreateImage(cl_context context, cl_mem_flags flags,
                     const cl_image_format *image_format,
                     const cl_image_desc *image_desc, void *host_ptr,
                     cl_int *errcode_ret);

🎀 PARAMETERS 🎀

  • context — A valid OpenCL context on which the image object is to be created. 💖
  • flags — A bit-field that is used to specify allocation and usage information about the image memory object being created and is described in the table below. 📋

For all image types except CL_MEM_OBJECT_IMAGE1D_BUFFER, if value specified for flags is 0, the default is used which is CL_MEM_READ_WRITE. 👑

✨ to be continued… ✨

Okay so — quick vibe check on that first bit before we get into the flag buffet, because CL_MEM_OBJECT_IMAGE1D_BUFFER plays by its own lil rules. 👑

For CL_MEM_OBJECT_IMAGE1D_BUFFER image type: if you don't pass CL_MEM_READ_WRITE, CL_MEM_READ_ONLY or CL_MEM_WRITE_ONLY in flags, bestie, they get inherited from the corresponding memory access qualifiers attached to buffer. The CL_MEM_USE_HOST_PTR, CL_MEM_ALLOC_HOST_PTR and CL_MEM_COPY_HOST_PTR values cannot be specified in flags at all — but they're inherited from the corresponding memory access qualifiers associated with buffer. And if CL_MEM_COPY_HOST_PTR shows up in the memory access qualifier values for buffer, it does not imply any additional copies when the sub-buffer is created from buffer. Same energy for CL_MEM_HOST_WRITE_ONLY, CL_MEM_HOST_READ_ONLY or CL_MEM_HOST_NO_ACCESS — if you leave them out of flags, they get inherited from the corresponding memory access qualifiers associated with buffer. 🫶

✨ the cl_mem_flags lineup (the main character list) ✨

  • CL_MEM_READ_WRITE — this flag says the memory object will be read and written by a kernel. This is the default, so if you're not specifying anything, congrats, you're already here. 💅
  • CL_MEM_WRITE_ONLY — this flag says the memory object will be written but not read by a kernel.
🚨 Reading from a buffer or image object created with CL_MEM_WRITE_ONLY inside a kernel is undefined. Not "maybe weird", not "probably fine" — undefined. Do not do it.

CL_MEM_READ_WRITE and CL_MEM_WRITE_ONLY are mutually exclusive. Pick one, queen.

  • CL_MEM_READ_ONLY — this flag says the memory object is a read-only memory object when used inside a kernel.
🚨 Writing to a buffer or image object created with CL_MEM_READ_ONLY inside a kernel is undefined. Same deal as above, same energy.

CL_MEM_READ_WRITE or CL_MEM_WRITE_ONLY and CL_MEM_READ_ONLY are mutually exclusive.

  • CL_MEM_USE_HOST_PTR — this flag is valid only if host_ptr is not NULL. If you specify it, it means the application wants the OpenCL implementation to use the memory referenced by host_ptr as the storage bits for the memory object.

OpenCL implementations are allowed to cache the buffer contents pointed to by host_ptr in device memory. That cached copy can be used when kernels are executed on a device. 🧠✨

💀 The result of OpenCL commands that operate on multiple buffer objects created with the same host_ptr or overlapping host regions is considered to be undefined. Don't be messy.

Refer to the dataTypes(3clc) for host_ptr for memory objects (buffer and images) created using CL_MEM_USE_HOST_PTR.

  • CL_MEM_ALLOC_HOST_PTR — this flag says the application wants the OpenCL implementation to allocate memory from host accessible memory.

CL_MEM_ALLOC_HOST_PTR and CL_MEM_USE_HOST_PTR are mutually exclusive. ✌️

  • CL_MEM_COPY_HOST_PTR — this flag is valid only if host_ptr is not NULL. If specified, it means the application wants the OpenCL implementation to allocate memory for the memory object and copy the data from the memory referenced by host_ptr.

CL_MEM_COPY_HOST_PTR and CL_MEM_USE_HOST_PTR are mutually exclusive.

CL_MEM_COPY_HOST_PTR can be used with CL_MEM_ALLOC_HOST_PTR to initialize the contents of the cl_mem object allocated using host-accessible (e.g. PCIe) memory. 🎀

  • CL_MEM_HOST_WRITE_ONLY — this flag says the host will only write to the memory object (using OpenCL APIs that enqueue a write or a map for write). This can be used to optimize write access from the host — like, for example, enabling write combined allocations for memory objects for devices that communicate with the host over a system bus such as PCIe. 🔥
  • CL_MEM_HOST_READ_ONLY — this flag says the host will only read the memory object (using OpenCL APIs that enqueue a read or a map for read).

CL_MEM_HOST_WRITE_ONLY and CL_MEM_HOST_READ_ONLY are mutually exclusive.

  • CL_MEM_HOST_NO_ACCESS — this flag says the host will not read or write the memory object.

CL_MEM_HOST_WRITE_ONLY or CL_MEM_HOST_READ_ONLY and CL_MEM_HOST_NO_ACCESS are

picking up right where that table left off… the final row just says mutually exclusive. which is the polite way of saying bestie, those two? you can't run both. pick one. 💅
  • image_format — a pointer to a struct describing the format properties of the image you're about to allocate. the full tea on the image format descriptor lives in cl_image_format(3clc). 🎀
  • image_desc — a pointer to a struct describing the type and dimensions of the image to be allocated. more deets over at imageDescriptor(3clc). ✨
  • host_ptr — a pointer to the image data that may already be allocated by the application. the table below tells you exactly how big the buffer that host_ptr points to has to be. 🫶
    • CL_MEM_OBJECT_IMAGE1D → size of buffer must be ≥ image_row_pitch
    • CL_MEM_OBJECT_IMAGE1D_BUFFER → size of buffer must be ≥ image_row_pitch
    • CL_MEM_OBJECT_IMAGE2D → size of buffer must be ≥ image_row_pitch * image_height
    • CL_MEM_OBJECT_IMAGE3D → size of buffer must be ≥ image_slice_pitch * image_depth
    • CL_MEM_OBJECT_IMAGE1D_ARRAY → size of buffer must be ≥ image_slice_pitch * image_array_size
    • CL_MEM_OBJECT_IMAGE2D_ARRAY → size of buffer must be ≥ image_slice_pitch * image_array_size

okay so how does the data actually sit in there? 🦋

for a 3D image or a 2D image array, the image data specified by host_ptr is stored as a linear sequence of adjacent 2D image slices or 2D images respectively. each 2D image is a linear sequence of adjacent scanlines. each scanline is a linear sequence of image elements. layers on layers on layers, iconic honestly. 👑

for a 2D image, the image data specified by host_ptr is stored as a linear sequence of adjacent scanlines. each scanline is a linear sequence of image elements. simple. clean. slay. 🌸

for a 1D image array, the image data specified by host_ptr is stored as a linear sequence of adjacent 1D images respectively. each 1D image or 1D image buffer is a single scanline which is a linear sequence of adjacent elements. 📏

  • errcode_ret — will return an appropriate error code. and if errcode_ret is NULL? then no error code is returned. no receipts, no problem. 🙈

🚨 ERRORS 🚨

clCreateImage returns a valid non-zero image object and errcode_ret is set to CL_SUCCESS if the image object is created successfully. otherwise? it returns a NULL value with one of these error values handed back in errcode_ret: 😭

  • CL_INVALID_CONTEXT if context is not a valid context.
  • CL_INVALID_VALUE if values specified in flags are not valid.
  • CL_INVALID_IMAGE_FORMAT_DESCRIPTOR if values specified in image_format are not valid or if image_format is NULL.
  • CL_INVALID_IMAGE_DESCRIPTOR if values specified in image_desc are not valid or if image_desc is NULL.
  • CL_INVALID_IMAGE_SIZE if image dimensions specified in image_desc exceed the minimum maximum image dimensions described in the table of allowed values for param_name for clGetDeviceInfo(3clc) for all devices in context.
  • CL_INVALID_HOST_PTR if host_ptr in image_desc is NULL and CL_MEM_USE_HOST_PTR or CL_MEM_COPY_HOST_PTR are set in flags or if host_ptr is not NULL but CL_MEM_COPY_HOST_PTR or CL_MEM_USE_HOST_PTR are not set in flags.
  • CL_INVALID_VALUE if a 1D image buffer is being created and the buffer object was created with CL_MEM_WRITE_ONLY and flags specifies CL_MEM_READ_WRITE or CL_MEM_READ_ONLY, or if the buffer object was created with CL_MEM_READ_ONLY and flags specifies CL_MEM_READ_WRITE or CL_MEM_WRITE_ONLY, or if flags specifies CL_MEM_USE_HOST_PTR or CL_MEM_ALLOC_HOST_PTR or CL_MEM_COPY_HOST_PTR.
  • CL_INVALID_VALUE if a 1D image buffer is being created and the buffer object was created with CL_MEM_HOST_WRITE_ONLY and flags specifies CL_MEM_HOST_READ_ONLY, or if the buffer object was created with CL_MEM_HOST_READ_ONLY and flags specifies CL_MEM_HOST_WRITE_ONLY, or if the buffer object was created with CL_MEM_HOST_NO_ACCESS and flags specifies CL_MEM_HOST_READ_ONLY or CL_MEM_HOST_WRITE_ONLY.
  • CL_IMAGE_FORMAT_NOT_SUPPORTED if the image_format is not supported.
  • CL_MEM_OBJECT_ALLOCATION_FAILURE if there is a failure to allocate memory for image object.
  • CL_INVALID_OPERATION if there are no devices in context that support images (i.e. CL_DEVICE_IMAGE_SUPPORT (specified in the table of OpenCL Device Queries for clGetDeviceInfo(3clc)) is CL_FALSE).
  • CL_OUT_OF_RESOURCES if there is a failure to allocate resources required by the OpenCL implementation on the device.
  • CL_OUT_OF_HOST_MEMORY if there is a failure to allocate resources required by the OpenCL implementation on the host.
heads up bestie: that CL_INVALID_VALUE for 1D image buffers is a whole vibe check on its own — read it twice, your flags and your buffer's flags have to actually agree. 💀

📜 SPECIFICATION 📜

OpenCL Specification[1]

👀 SEE ALSO 👀

imageDescriptor(3clc), cl_image_format(3clc), classDiagram(3clc)

👑 AUTHORS 👑

The Khronos Group

Copyright © 2007-2011 The Khronos Group Inc.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and/or associated documentation files (the "Materials"), to deal in the Materials without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Materials, and to permit persons to whom the Materials are furnished to do so, subject to the following conditions: the above copyright notice and this permission notice shall be included in all copies or substantial portions of the Materials.

Wait, let me say that again in the exact words, no cap:

Copyright © 2007-2011 The Khronos Group Inc.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and/or associated documentation files (the "Materials"), to deal in the Materials without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Materials, and to permit persons to whom the Materials are furnished to do so, subject to the condition that this copyright notice and permission notice shall be included in all copies or substantial portions of the Materials.

okay ignore my little detour above — the version right under the heading is the real one, that's the exact text, no edits. 😭

🎀 NOTES 🎀

  1. OpenCL Specification page 90, section 5.3.1 - Creating Image Objects

and that's the whole page bestie!! 🫶 this one came from The Khronos Group, dated 01/14/2021, and the page itself is CLCREATEIMAGE(3clc). go forth and allocate your images correctly, you've absolutely got this. ✨💜

📦 where this page comes from