GET_IMAGE_CHANNEL_DA(3clc)

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

πŸ’– GET_IMAGE_CHANNEL_DA β€” the OpenCL manual, but make it make sense πŸ’–

okay bestie, gather round, because we're doing the OpenCL Manual thing and this page is literally just one little function that tells you what kind of channel data your image is packing. that's it. that's the whole vibe. it's giving "short queen, big energy" ✨


🌸 NAME 🌸

get_image_channel_data_type β€” return the channel data type. no cap, that's literally what it does πŸ’…


πŸ¦‹ SYNOPSIS πŸ¦‹

here's every single glow-up this function comes in. same name, different image flavor. pick your fighter:

int get_image_channel_data_type(image1d_t image);

int get_image_channel_data_type(image1d_buffer_t image);

int get_image_channel_data_type(image2d_t image);

int get_image_channel_data_type(image3d_t image);

int get_image_channel_data_type(image1d_array_t image);

int get_image_channel_data_type(image2d_array_t image);

✨ DESCRIPTION ✨

so you hand it an image, it hands you back the channel data type. that's the transaction. the valid values it can return are these iconic little guys, and yes you need all of them:

  • CLK_SNORM_INT8
  • CLK_SNORM_INT16
  • CLK_UNORM_INT8
  • CLK_UNORM_INT16
  • CLK_UNORM_SHORT_565
  • CLK_UNORM_SHORT_555
  • CLK_UNORM_SHORT_101010
  • CLK_SIGNED_INT8
  • CLK_SIGNED_INT16
  • CLK_SIGNED_INT32
  • CLK_UNSIGNED_INT8
  • CLK_UNSIGNED_INT16
  • CLK_UNSIGNED_INT32
  • CLK_HALF_FLOAT
  • CLK_FLOAT

like, all fifteen. nobody's skipping any. we respect the whole roster 🫢


πŸŽ€ NOTES πŸŽ€

okay so here's the tea about those CLK_ prefixes you just saw: the values returned by get_image_channel_order (shown above with the CLK_ prefixes) correspond to the CL_ prefixes used to describe the image channel order and data type in the table of supported names and values in clCreateSubBuffer(3clc), and in the list of supported Image Channel Order Values for clCreateImage(3clc). so like, same energy, different font. for example, both CL_UNORM_INT8 and CLK_UNORM_INT8 refer to an image channel data type that is an unnormalized unsigned 8-bit integer. twins fr fr πŸ‘―


🧚 the mapping table (but make it a list) 🧚

so this table describes how the number of channels of an image element maps onto the appropriate components in the float4, int4 or uint4 vector data type β€” for the color values returned by read_image{f|i|ui} or supplied to write_image{f|i|ui}. and here's the rule about the leftovers: the unmapped components will be set to 0.0 for red, green and blue channels, and will be set to 1.0 for the alpha channel. periodt.

so the "float4, int4 or unsigned int4 components of channel data" column, per channel order:

  • CL_R, CL_Rx β†’ (r, 0.0, 0.0, 1.0)
  • CL_A β†’ (0.0, 0.0, 0.0, a)
  • CL_RG, CL_RGx β†’ (r, g, 0.0, 1.0)
  • CL_RA β†’ (r, 0.0, 0.0, a)
  • CL_RGB, CL_RGBx β†’ (r, g, b, 1.0)
  • CL_RGBA, CL_BGRA, CL_ARGB β†’ (r, g, b, a)
  • CL_INTENSITY β†’ (I, I, I, I)
  • CL_LUMINANCE β†’ (L, L, L, 1.0)

πŸ’€ the sampler drama (read this one, it's important) πŸ’€

a kernel that uses a sampler with the CL_ADDRESS_CLAMP addressing mode with multiple images may result in additional samplers being used internally by an implementation. yes, internally. behind the scenes. main character behavior from the implementation, honestly.

if the same sampler is used with multiple images called via read_imagef2d(3clc), then it is possible that an implementation may need to allocate an additional sampler to handle the different border color values that may be needed depending on the image formats being used. and those implementation allocated samplers will count against the maximum sampler values supported by the device, given by CL_DEVICE_MAX_SAMPLERS.

🚨 so if you enqueue a kernel that requires more samplers than the implementation can support, you get a CL_OUT_OF_RESOURCES error returned. not a vibe. budget your samplers, bestie. 😭

πŸ“œ SPECIFICATION πŸ“œ

OpenCL Specification[1]


πŸ‘€ SEE ALSO πŸ‘€


πŸ‘‘ 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 (yes, again β€” this is the footnote one) πŸ“

  1. OpenCL Specification β€” page 292, section 6.12.14 - Image Read and Write Functions

and that's the whole page, babe 🌈 this was The Khronos Group's drop from 01/14/2021, and the man page answering to GET_IMAGE_CHANNEL_DA(3clc) β€” thanks for coming to my TED talk, now go read your image formats πŸ’–βœ¨πŸ¦‹

πŸ“¦ where this page comes from