CLENQUEUECOPYBUFFERT(3clc)

✨ NAME ✨

okay bestie, gather round 💖 this one is clEnqueueCopyBufferToImage from the OpenCL Manual — and it's exactly what it sounds like: it enqueues a command to copy a buffer object to an image object. like, buffer data goes in, image comes out. the glow-up is real. 👑

(this is page CLENQUEUECOPYBUFFERT(3clc) btw, iykyk 🎀)

---

🦋 SYNOPSIS 🦋

cl_int clEnqueueCopyBufferToImage(cl_command_queue command_queue,
                                  cl_mem src_buffer, cl_mem dst_image,
                                  size_t src_offset,
                                  const size_t *dst_origin,
                                  const size_t *region,
                                  cl_uint num_events_in_wait_list,
                                  const cl_event *event_wait_list,
                                  cl_event *event);

---

🌸 PARAMETERS 🌸

• command_queue — a valid command-queue, periodt. and the OpenCL context linked to command_queue, src_buffer, and dst_image has to be the same one — no mixing contexts, that's not the vibe.
• src_buffer — a valid buffer object 💜
• dst_image — a valid image object ✨
• src_offset — where you start copying data from in src_buffer. that's it, that's the starting line.
• dst_origin — this one's the ✨coordinate queen✨. it defines the (x, y, z) offset in pixels for a 1D, 2D or 3D image; or the (x, y) offset plus the image index in a 2D image array; or the (x) offset plus the image index in a 1D image array. here's the rules, no cap:
  • if dst_image is a 2D image object, dst_origin[2] must be 0.
  • if dst_image is a 1D image or 1D image buffer object, dst_origin[1] and dst_origin[2] must be 0.
  • if dst_image is a 1D image array object, dst_origin[2] must be 0.
  • if dst_image is a 1D image array object, dst_origin[1] describes the image index in that 1D image array.
  • if dst_image is a 2D image array object, dst_origin[2] describes the image index in that 2D image array.
• region — the size situation 💅 it 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. rules again:
  • if dst_image is a 2D image object, region[2] must be 1.
  • if dst_image is a 1D image or 1D image buffer object, region[1] and region[2] must be 1.
  • if dst_image is a 1D image array object, region[2] must be 1.

and now the math, bestie, stay with me 🧮 — the size in bytes of the region to be copied from src_buffer, called src_cb, gets computed like this:

• width * height * depth * bytes/image_element if dst_image is a 3D image object
• width * height * bytes/image_element if dst_image is a 2D image
• width * height * arraysize * bytes/image_element if dst_image is a 2D image array object
• width * bytes/image_element if dst_image is a 1D image or 1D image buffer object
• width * arraysize * bytes/image_element if dst_image is a 1D image array object

• event_wait_list, num_events_in_wait_list — these two are a package deal 🫶 they specify events that need to finish before this particular command can run. the deets:
  • if event_wait_list is NULL, then this particular command doesn't 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 in event_wait_list act as synchronization points ✋
  • the context associated with the 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 — go ahead, reclaim that memory, you deserve it 🌈
• event — returns an event object that identifies this particular copy command, and you can use it to query or queue a wait for this particular command to complete. but lowkey: event can be NULL, and if it is, the application won't be able to query the status of this command or queue a wait for it to complete. in that case clEnqueueBarrierWithWaitList(3clc) can be used instead. and heads up ⚠️ if event_wait_list and the event arguments are both not NULL, the event argument should not refer to an element of the event_wait_list array.

---

💀 ERRORS 💀

clEnqueueCopyBufferToImage returns CL_SUCCESS if the function is executed successfully 🎉 otherwise, it hands you one of these:

• CL_INVALID_COMMAND_QUEUE if command_queue is not a valid command-queue.
• CL_INVALID_CONTEXT if the context associated with command_queue, src_buffer and dst_image are not the same, or if the context associated with command_queue and events in event_wait_list are not the same.
• CL_INVALID_MEM_OBJECT if src_buffer is not a valid buffer object and dst_image is not a valid image object, or if dst_image is a 1D image buffer object created from src_buffer.
• CL_INVALID_VALUE if the 1D, 2D, or 3D rectangular region specified by dst_origin and dst_origin + region refers to a region outside dst_origin, or if the region specified by src_offset and src_offset + src_cb refers to a region outside src_buffer.
• CL_INVALID_VALUE if values in dst_origin and region do not follow the rules described in the argument description for dst_origin and region. (yes, the rules above. read them. 👀)
• 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.
• CL_MISALIGNED_SUB_BUFFER_OFFSET if src_buffer is a sub-buffer object and the offset specified when the sub-buffer object is created is not aligned to the CL_DEVICE_MEM_BASE_ADDR_ALIGN value for the device associated with the queue.
• CL_INVALID_IMAGE_SIZE if image dimensions (image width, height, specified or computed row and/or slice pitch) for dst_image are not supported by the device associated with the queue.
• CL_INVALID_IMAGE_FORMAT if image format (image channel order and data type) for dst_image are not supported by the device associated with the queue.
• CL_MEM_OBJECT_ALLOCATION_FAILURE if there is a failure to allocate memory for the data store associated with src_buffer or dst_image.
• CL_INVALID_OPERATION if the device associated with command_queue does not support images — i.e. CL_DEVICE_IMAGE_SUPPORT specified in the table of OpenCL Device Queries for clGetDeviceInfo(3clc) is CL_FALSE. no images, no service 😭
• 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.

---

📜 SPECIFICATION 📜

OpenCL Specification[1]

---

👀 SEE ALSO 👀

clEnqueueReadBuffer(3clc), clEnqueueWriteBuffer(3clc), clCreateBuffer(3clc), clEnqueueCopyBuffer(3clc), clEnqueueCopyImageToBuffer(3clc)

---

💖 AUTHORS 💖

The Khronos Group

---

🎀 COPYRIGHT 🎀

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 110, section 5.3.4 - Copying between Image and Buffer Objects

---

and that's the whole page, bestie 🫶 brought to you by The Khronos Group, dated 01/14/2021, living its life as CLENQUEUECOPYBUFFERT(3clc) in the OpenCL Manual. go copy that buffer into that image. slay. 💅✨