CLCREATEBUFFER(3clc)

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

💖 NAME 💖

okay bestie, welcome to the OpenCL manual page for clCreateBuffer — this is the 3clc corner of the OpenCL Manual, and today's mission is: Creates a buffer object. ✨ That's it, that's the whole vibe.

Here's the signature, character for character, no cap:

cl_mem clCreateBuffer(cl_context context, cl_mem_flags flags,
                      size_t size, void *host_ptr, cl_int *errcode_ret);

🌸 PARAMETERS 🌸

  • context — a valid OpenCL context that's gonna be used to create the buffer object. gotta be valid bestie, we don't do invalid contexts here 💅
  • flags — a bit-field ✨ used to specify allocation and usage info, like which memory arena should be used to allocate the buffer object and how it's gonna be used. Below is every possible value for flags, all of them, no skips. And listen — if the value you specify for flags is 0, the default kicks in, and the default is CL_MEM_READ_WRITE. 🫶

🎀 the flags, one by one 🎀

  • CL_MEM_READ_WRITE — this flag says the memory object will be read and written by a kernel. This one is the default, she's the main character 👑
  • 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. 😭 (translation: don't do it, it's giving chaos)

CL_MEM_READ_WRITE and CL_MEM_WRITE_ONLY are mutually exclusive.

  • 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. 💀

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 undefined. 🙈

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 you specify it, it means the application wants the OpenCL implementation to allocate memory for the memory object and copy the data from 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. that combo ate, fr fr 🔥

  • 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 (e.g. enable 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 mutually exclusive.

…and that's only part 1 bestie, the rest is loading ✨💅

  • size — the size, in bytes, of the buffer memory object we're about to allocate. bestie this is literally the whole point, it's how much memory you're claiming 💖
  • host_ptr — a pointer to buffer data that your application maybe already allocated. important part: the size of the buffer that host_ptr points to has to be ≥ size bytes. no shrinking allowed, the vibes must be equal or bigger 🫶
  • errcode_ret — this is where the error code gets returned. if errcode_ret is NULL, then no error code comes back. so like, if you don't want the tea, don't ask for it 🙈

💀 ERRORS 💀

okay so the deal is: if everything goes good, you get a valid non-zero buffer object and errcode_ret gets set to CL_SUCCESS. iconic. but if it doesn't work out, you get a NULL value back, and errcode_ret will hold one of these little guys instead:

  • CL_INVALID_CONTEXT — if context is not a valid context. ma'am. that's not a context.
  • CL_INVALID_VALUE — if the values specified in flags are not valid as defined in the table above. check the table, bestie, it's right there 📋
  • CL_INVALID_BUFFER_SIZE — if size is 0. zero bytes?? be so fr. also, implementations may return CL_INVALID_BUFFER_SIZE if size is greater than the CL_DEVICE_MAX_MEM_ALLOC_SIZE value specified in the table of allowed values for param_name for clGetDeviceInfo(3clc) for all devices in context.
  • CL_INVALID_HOST_PTR — if host_ptr 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. so like, you gotta commit both ways or neither way, no half-in-half-out energy 🎀
  • CL_MEM_OBJECT_ALLOCATION_FAILURE — if there is a failure to allocate memory for the buffer object. it just. didn't fit 😭
  • 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.
literally two different places can run out of stuff and you have to be able to tell them apart. device vs host. do not mix them up 💅

✨ SPECIFICATION ✨

OpenCL Specification[1]

🦋 SEE ALSO 🦋

like go read those too, the lore is interconnected 🌈

👑 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 66, section 5.2.1 - Creating Buffer Objects

and that's the whole page, bestie!! 🫶✨ this one came from The Khronos Group, dated 01/14/2021, and yeah it's literally filed under CLCREATEBUFFER(3clc). go make some buffers, you're gonna slay 💖🎀🦋

📦 where this page comes from