CLENQUEUEWRITEIMAGE(3clc)

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

CLENQUEUEWRITEIMAGE(3clc) 💖

okay so bestie, welcome to the OpenCL Manual — yes the actual Khronos one, we're doing this properly ✨

✨ NAME ✨

clEnqueueWriteImage — enqueues a command to write to an image or image array object from host memory. it's giving "put your pixels in the picture" energy 💅

cl_int clEnqueueWriteImage(cl_command_queue command_queue, cl_mem image,
                           cl_bool blocking_write, const size_t *origin,
                           const size_t *region, size_t input_row_pitch,
                           size_t input_slice_pitch, const void * ptr,
                           cl_uint num_events_in_wait_list,
                           const cl_event *event_wait_list,
                           cl_event *event);

🎀 PARAMETERS 🎀

  • command_queue — the command-queue where this write command gets queued up. heads up tho: command_queue and image have to be created with the same OpenCL context, no mixing and matching 🙅‍♀️
  • image — a valid image or image array object. that's it, that's the whole vibe.
  • blocking_write — tells you if the write is blocking or non-blocking, and this one actually matters a lot so listen up 🫶
    • if blocking_write is CL_TRUE, the OpenCL implementation copies the data that ptr points to and enqueues the write command in the command-queue. once clEnqueueWriteImage returns, you can reuse the memory ptr points at. iconic, no waiting.
    • if blocking_write is CL_FALSE, the implementation will use ptr to do a nonblocking write. since it's non-blocking, the implementation can just dip immediately. the memory ptr points to cannot be reused by the application after the call returns 😭 the event argument gives you back an event object you can use to query the execution status of the write command. when that write command is done, then the memory ptr points to can be reused. periodt.
  • origin — defines the (x, y, z) offset in pixels in the 1D, 2D, or 3D image; or the (x, y) offset plus the image index in the image array; or the (x) offset plus the image index in the 1D image array. the rules, fr fr:
    • if image is a 2D image object, origin[2] must be 0.
    • if image is a 1D image or 1D image buffer object, origin[1] and origin[2] must be 0.
    • if image is a 1D image array object, origin[2] must be 0.
    • if image is a 1D image array object, origin[1] describes the image index in the 1D image array.
    • if image is a 2D image array object, origin[2] describes the image index in the 2D image array.
  • region — defines the (width, height, depth) in pixels of the 1D, 2D or 3D rectangle; or the (width, height) in pixels of the 2D rectangle plus the number of images of a 2D image array; or the (width) in pixels of the 1D rectangle plus the number of images of a 1D image array. more rules, slay:
    • if image is a 2D image object, region[2] must be 1.
    • if image is a 1D image or 1D image buffer object, region[1] and region[2] must be 1.
    • if image is a 1D image array object, region[2] must be 1.
  • input_row_pitch — the length of each row in bytes. this value must be greater than or equal to the element size in bytes * width. if row_pitch is set to 0, the appropriate row pitch gets calculated based on the size of each element in bytes multiplied by width. math but make it cute 🧚
  • input_slice_pitch — size in bytes of the 2D slice of the 3D region of a 3D image, or of each image of a 1D or 2D image array being written. this must be 0 if image is a 1D or 2D image. this value must be greater than or equal to row_pitch * height. if slice_pitch is set to 0, the appropriate slice pitch gets calculated based on the row_pitch * height. 👑
  • ptr — the pointer to a buffer in host memory where image data is to be written to. that's the source, bestie.
  • event_wait_list, num_events_in_wait_list — specify events that need to complete before this particular command can be executed. the deets:
    • if event_wait_list is NULL, then this particular command does not wait on any event to complete.
    • if event_wait_list is NULL, num_events_in_wait_list must be 0.
    • if event_wait_list is not NULL, the list of events pointed to by event_wait_list must be valid and num_events_in_wait_list must be greater than 0.
    • the events specified in event_wait_list act as synchronization points.
    • the context associated with events in event_wait_list and command_queue must be the same.
    • the memory associated with event_wait_list can be reused or freed after the function returns. free real estate 💜
  • event — returns an event object that identifies this particular write command and can be used to query or queue a wait for this particular command to complete. event can be NULL, in which case it will not be possible for the application to query the status of this command or queue a wait for this command to complete. lowkey a tradeoff, highkey fine if you don't care.

🌸 NOTES 🌸

calling clEnqueueWriteImage to update the latest bits in a region of the image with the ptr argument value set to host_ptr + (origin[2] * image slice pitch + origin[1] * image row pitch + origin[0] * bytes per pixel), where host_ptr is a pointer to the memory region specified when the image being written is created with CL_MEM_USE_HOST_PTR, must meet the following requirements in order to avoid undefined behavior 🚨 (yes we're being dramatic, this is undefined behavior, we should be dramatic):

  • the host memory region being written contains the latest bits when the enqueued write command begins execution.
  • the input_row_pitch and input_slice_pitch argument values in clEnqueueWriteImage must be set to the image row pitch and slice pitch.
  • the image object is not mapped.
  • the image object is not used by any command-queue until the write command has finished execution.

💀 ERRORS 💀

clEnqueueWriteImage returns CL_SUCCESS if the function is executed successfully. otherwise, it returns one of the following errors:

  1. CL_INVALID_COMMAND_QUEUE if command_queue is not a valid command-queue.
  2. CL_INVALID_CONTEXT if the context associated with command_queue and image are not the same, or if the context associated with command_queue and events in event_wait_list are not the same.
  3. CL_INVALID_MEM_OBJECT if image is not a valid image object.
  4. CL_INVALID_VALUE if the region being written specified by origin and region is out of bounds, or if ptr is a NULL value.
  5. CL_INVALID_VALUE if values in origin and region do not follow rules described in the argument description for origin and region.
  6. CL_INVALID_EVENT_WAIT_LIST if event_wait_list is NULL and num_events_in_wait_list > 0, or event_wait_list is not NULL and num_events_in_wait_list is 0, or if event objects in event_wait_list are not valid events.
  7. CL_INVALID_IMAGE_SIZE if image dimensions (image width, height, specified or compute row and/or slice pitch) for image are not supported by device associated with queue.
  8. CL_INVALID_IMAGE_FORMAT if image format (image channel order and data type) for image are not supported by device associated with queue.
  9. CL_MEM_OBJECT_ALLOCATION_FAILURE if there is a failure to allocate memory for data store associated with image.
  10. CL_INVALID_OPERATION if the device associated with command_queue does not support images (i.e. CL_DEVICE_IMAGE_SUPPORT specified the table of allowed values for param_name for clGetDeviceInfo(3clc) is CL_FALSE).
  11. CL_INVALID_OPERATION if clEnqueueWriteImage is called on image which has been created with CL_MEM_HOST_WRITE_ONLY or CL_MEM_HOST_NO_ACCESS.
  12. CL_EXEC_STATUS_ERROR_FOR_EVENTS_IN_WAIT_LIST if the write operations are blocking and the execution status of any of the events in event_wait_list is a negative integer value.
  13. CL_OUT_OF_RESOURCES if there is a failure to allocate resources required by the OpenCL implementation on the device.
  14. CL_OUT_OF_HOST_MEMORY if there is a failure to allocate resources required by the OpenCL implementation on the host.

🦋 SPECIFICATION 🦋

OpenCL Specification[1]

⭐ SEE ALSO ⭐

clEnqueueReadImage(3clc), clEnqueueCopyImage(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 condition that this copyright notice and permission notice shall be included in all copies or substantial portions of the Materials.

🌈 NOTES 🌈

  1. OpenCL Specification — page 99, section 5.3.3 - Reading, Writing and Copying Image Objects

and that's the whole page, bestie!! 🫶 written by The Khronos Group, dated 01/14/2021, and yeah this is CLENQUEUEWRITEIMAGE(3clc) — go forth and write those images, you absolute icon 💅✨

📦 where this page comes from