GET_IMAGE_CHANNEL_OR(3clc)

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

GET_IMAGE_CHANNEL_OR πŸ’…βœ¨

okay so this is a page from the OpenCL Manual, and bestie it's about one (1) function and the way it will tell you exactly what channel order your image is giving. no cap. let's go 🫢


🌸 NAME 🌸

get_image_channel_order β€” Return the image channel data order.

here's the whole squad of overloads, literally all six of them, character for character:

int get_image_channel_order(image1d_t image);

int get_image_channel_order(image1d_buffer_t image);

int get_image_channel_order(image2d_t image);

int get_image_channel_order(image3d_t image);

int get_image_channel_order(image1d_array_t image);

int get_image_channel_order(image2d_array_t image);

πŸ¦‹ DESCRIPTION πŸ¦‹

it returns the image channel order, periodt. the valid values are these iconic little guys and you do not get to invent new ones:

  • CLK_A
  • CLK_R
  • CLK_Rx
  • CLK_RG
  • CLK_RGx
  • CLK_RA
  • CLK_RGB
  • CLK_RGBx
  • CLK_RGBA
  • CLK_ARGB
  • CLK_BGRA
  • CLK_INTENSITY
  • CLK_LUMINANCE

πŸ’– NOTES πŸ’–

so the values that get_image_channel_order hands back, the ones with the CLK_ prefixes up there, they 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). iykyk. for example β€” and this is the example, fr fr β€” both CL_UNORM_INT8 and CLK_UNORM_INT8 refer to an image channel data type that is an unnormalized unsigned 8-bit integer. same thing, different outfit. πŸ‘‘


πŸŽ€ the mapping table (but make it a list, because vibes) πŸŽ€

the following table describes the mapping of the number of channels of an image element to 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}. 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. noted. πŸ’…

here's the channel order β†’ the float4, int4 or unsigned int4 components of channel data:

  • 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 tea (read this one, it's giving warning) 😭

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. so 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. lowkey sneaky of it.

these implementation-allocated samplers will count against the maximum sampler values supported by the device, given by CL_DEVICE_MAX_SAMPLERS. so budget accordingly bestie 🫢

and enqueuing a kernel that requires more samplers than the implementation can support will result in a CL_OUT_OF_RESOURCES error being returned. that's the whole thing just πŸ’€ing on you. dramatic but true.

⭐ SPECIFICATION ⭐

OpenCL Specification[1]


πŸ‘€ SEE ALSO πŸ‘€

imageFunctions(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 (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 bestie, no crumbs left πŸ“

cute little sign-off: this one's brought to you by The Khronos Group, dated 01/14/2021, filed under GET_IMAGE_CHANNEL_OR(3clc). slay, stay hydrated, go check your channel orders πŸ’–βœ¨πŸŽ€

πŸ“¦ where this page comes from