CL_IMAGE_FORMAT(3clc)

πŸ“¦
version 1.0~svn33624 Β· 3 versions
, in ubuntu jammy, ubuntu noble

🌸 NAME 🌸

okay so this is CL_IMAGE_FORMAT(3clc) from the OpenCL Manual β€” and bestie, it's literally just the image format descriptor structure. that's it. that's the whole vibe. it's defined as:

typedef struct _cl_image_format {
cl_channel_order image_channel_order;
cl_channel_type
image_channel_data_type; }
cl_image_format;

she's small but she's iconic πŸ’…


πŸŽ€ MEMBERS πŸŽ€

✨ image_channel_order ✨

this one says how many channels you've got and how they're laid out β€” like, the actual memory layout where the channels get stored in the image. the valid values are all listed below, no cap πŸ‘‡

  • CL_R, CL_Rx, or CL_A β€” that's the format, bestie. the source doesn't tack on any extra note for these ones, so i'm not gonna make anything up. 🫢
  • CL_INTENSITY β€” this format can only be used if channel data type = CL_UNORM_INT8, CL_UNORM_INT16, CL_SNORM_INT8, CL_SNORM_INT16, CL_HALF_FLOAT, or CL_FLOAT. anything else? nope, not allowed, periodt.
  • CL_LUMINANCE β€” same deal, this format can only be used if channel data type = CL_UNORM_INT8, CL_UNORM_INT16, CL_SNORM_INT8, CL_SNORM_INT16, CL_HALF_FLOAT, or CL_FLOAT. don't try it with anything else πŸ™ˆ
  • CL_RG, CL_RGx, or CL_RA β€” again, that's just the format name. no extra notes attached to these in the source. πŸ’œ
  • CL_RGB or CL_RGBx β€” this format can only be used if channel data type = CL_UNORM_SHORT_565, CL_UNORM_SHORT_555 or CL_UNORM_INT101010. three options, that's the whole list, fr fr.
  • CL_RGBA β€” format name, that's it, no extra commentary. πŸ’–
  • CL_ARGB, CL_BGRA β€” this format can only be used if channel data type = CL_UNORM_INT8, CL_SNORM_INT8, CL_SIGNED_INT8 or CL_UNSIGNED_INT8. four types, no more, i don't make the rules (well, the spec does) ✨

πŸ¦‹ image_channel_data_type πŸ¦‹

and this member describes the size of the channel data type. important caveat incoming: the number of bits per element, which is determined by image_channel_data_type and image_channel_order together, must be a power of two. that's not a suggestion, that's the law of the land πŸ‘‘

here's every supported value, no skips, no cuts:

  • CL_SNORM_INT8 β€” each channel component is a normalized signed 8-bit integer value.
  • CL_SNORM_INT16 β€” each channel component is a normalized signed 16-bit integer value.
  • CL_UNORM_INT8 β€” each channel component is a normalized unsigned 8-bit integer value.
  • CL_UNORM_INT16 β€” each channel component is a normalized unsigned 16-bit integer value.
  • CL_UNORM_SHORT_565 β€” represents a normalized 5-6-5 3-channel RGB image. the channel order must be CL_RGB or CL_RGBx. non-negotiable bestie.
  • CL_UNORM_SHORT_555 β€” represents a normalized x-5-5-5 4-channel xRGB image. the channel order must be CL_RGB or CL_RGBx.
  • CL_UNORM_INT_101010 β€” represents a normalized x-10-10-10 4-channel xRGB image. the channel order must be CL_RGB or CL_RGBx.
  • CL_SIGNED_INT8 β€” each channel component is an unnormalized signed 8-bit integer value.
  • CL_SIGNED_INT16 β€” each channel component is an unnormalized signed 16-bit integer value.
  • CL_SIGNED_INT32 β€” each channel component is an unnormalized signed 32-bit integer value.
  • CL_UNSIGNED_INT8 β€” each channel component is an unnormalized unsigned 8-bit integer value.
  • CL_UNSIGNED_INT16 β€” each channel component is an unnormalized unsigned 16-bit integer value.
  • CL_UNSIGNED_INT32 β€” each channel component is an unnormalized unsigned 32-bit integer value.
  • CL_HALF_FLOAT β€” each channel component is a 16-bit half-float value.
  • CL_FLOAT β€” each channel component is a single precision floating-point value.
watch out for the sneaky naming, bestie β€” the channel-order list spells it CL_UNORM_INT101010 while the data-type list spells it CL_UNORM_INT_101010. that's not me being sloppy, that's exactly how the source has it. copy-paste carefully. 😭

and that's every single member value, all 15 data types and all the channel orders, laid out with love 🌈

✨ DESCRIPTION ✨

okay so say you wanna specify a normalized unsigned 8-bit / channel RGBA image, bestie? you literally do this:

image_channel_order = CL_RGBA
image_channel_data_type = CL_UNORM_INT8

and boom, that's the vibe πŸ’…

now, image_channel_data_type values of CL_UNORM_SHORT_565, CL_UNORM_SHORT_555 and CL_UNORM_INT_101010 are special cases of packed image formats where the channels of each element are packed into a single unsigned short or unsigned int. for these special packed image formats, the channels are normally packed with the first channel in the most significant bits of the bitfield, and successive channels occupying progressively less significant locations. it's giving bit-budgeting, fr fr 🧚

  • CL_UNORM_SHORT_565 β€” R is in bits 15:11, G is in bits 10:5 and B is in bits 4:0 🌈
  • CL_UNORM_SHORT_555 β€” bit 15 is undefined, R is in bits 14:10, G in bits 9:5 and B in bits 4:0 πŸ’€
  • CL_UNORM_INT_101010 β€” bits 31:30 are undefined, R is in bits 29:20, G in bits 19:10 and B in bits 9:0 πŸ‘‘

OpenCL implementations must maintain the minimum precision specified by the number of bits in image_channel_data_type. no shortcuts, no cap.

if the image format specified by image_channel_order, and image_channel_data_type cannot be supported by the OpenCL implementation, then the call to clCreateImage(3clc) will return a NULL memory object. so like… vibe check failed, bestie 😭

πŸ“š SPECIFICATION πŸ“š

OpenCL Specification[1] 🫢


πŸ‘€ SEE ALSO πŸ‘€


✍️ AUTHORS ✍️

The Khronos Group πŸ‘‘


Copyright Β© 2007-2010 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 92, section 5.3.1.1 - Image Format Descriptor πŸ“–

and that's the tea, bestie! this whole page was brought to you by The Khronos Group, dated 01/14/2021, and it's literally CL_IMAGE_FORMAT(3clc) πŸ’–βœ¨ periodt.

πŸ“¦ where this page comes from