READ_IMAGEH2D(3clc)

✨ NAME ✨

okay bestie, gather round, because this page from the OpenCL Manual is called read_imageh_(2D,_Half) and she does one thing and she does it gorgeously: an element lookup in the 2D image object, handing you back half floating-point values. 💖

half4 read_imageh(image2d_t image, sampler_t sampler, int2 coord);

half4 read_imageh(image2d_t image, sampler_t sampler, float2 coord);

half4 read_imageh(image2d_t image, int2 coord);

half4 read_imageh(image2d_array_t image, int4 coord);

half4 read_imageh(image2d_array_t image, sampler_t sampler, int4 coord);

half4 read_imageh(image2d_array_t image, sampler_t sampler,
                  float4 coord);

look at all those overloads. six of them. she's versatile like that. 💅

---

🌸 DESCRIPTION 🌸

so here's the tea. ☕

• if you're using one of the forms that takes an image2d_t, you use the coordinate (x, y) to do an element lookup in the 2D image object specified by image.
• if you're using one of the forms that takes an image2d_array_t, you use coord.xy to do an element lookup in the 2D image identified by coord.z inside the 2D image array specified by image.

the samplerless read image functions behave exactly like the corresponding read image functions that take integer coordinates and a sampler with filter mode set to CLK_FILTER_NEAREST, normalized coordinates set to CLK_NORMALIZED_COORDS_FALSE, and addressing mode set to CLK_ADDRESS_NONE. no notes, no exceptions, periodt.

now, what do you actually get back? 👀

• read_imageh returns half floating-point values in the range [0.0... 1.0] for image objects created with image_channel_data_type set to one of the predefined packed formats, or CL_UNORM_INT8, or CL_UNORM_INT16.
• read_imageh returns half floating-point values in the range [-1.0... 1.0] for image objects created with image_channel_data_type set to CL_SNORM_INT8, or CL_SNORM_INT16.
• read_imageh returns half floating-point values for image objects created with image_channel_data_type set to CL_HALF_FLOAT.

🚨 okay this part is important, do NOT skim it. The read_imageh calls that take integer coordinates must use a sampler with filter mode set to CLK_FILTER_NEAREST, normalized coordinates set to CLK_NORMALIZED_COORDS_FALSE, and addressing mode set to CLK_ADDRESS_CLAMP_TO_EDGE, CLK_ADDRESS_CLAMP or CLK_ADDRESS_NONE — otherwise the values returned are undefined. undefined!! not "a little weird", not "close enough", undefined. 💀

and one more: values returned by read_imageh for image objects with image_channel_data_type values that aren't specified in the description above are undefined too. if your format isn't on the list, you're in the void, babe. 🙈

---

📝 NOTES 📝

general info about the whole read_image* family, coming right up:

the built-in functions defined in this section can only be used with image memory objects. an image memory object can be accessed by specific function calls that read from and/or write to specific locations in the image.

image memory objects that are being read by a kernel should be declared with the accessQualifiers(3clc) qualifier. write_image calls to image memory objects declared with the accessQualifiers(3clc) qualifier will generate a compilation error. image memory objects that are being written to by a kernel should be declared with the accessQualifiers(3clc) qualifier. read_image calls to image memory objects declared with the accessQualifiers(3clc) qualifier will generate a compilation error. and listen — read_image and write_image calls to the same image memory object in a kernel are not supported. pick a lane. 🚫

the read_image calls return a four component floating-point, integer or unsigned integer color value. those color values are identified as x, y, z, w where x is the red component, y is the green component, z is the blue component and w is the alpha component. iconic naming, honestly. 🌈

here's the mapping of how many channels an image element has → which components of the float4, int4 or uint4 vector data type those color values land in, for values returned by read_image{f|i|ui} or supplied to write_image{f|i|ui}. the unmapped components get set to 0.0 for red, green and blue channels, and set to 1.0 for the alpha channel:

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

and now the ✨ sampler budget drama ✨: 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. if the same sampler is used with multiple images called via read_image{f|i|ui}, then it's 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. those implementation-allocated samplers count against the maximum sampler values supported by the device, given by CL_DEVICE_MAX_SAMPLERS. and enqueuing a kernel that requires more samplers than the implementation can support will result in a CL_OUT_OF_RESOURCES error being returned. so like… budget your samplers, bestie. 🫶

---

🦋 SPECIFICATION 🦋

OpenCL Specification[1]

---

👑 SEE ALSO 👑

imageFunctions(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 27, section 9.5.8 - Image Read and Write Functions (half)

---

aaaand that's the whole page, no cap. 🌟 shoutout to The Khronos Group for writing it, this copy is dated 01/14/2021, and it lives in the manual as READ_IMAGE (2D, HALF(3clc). go read some pixels, you absolute main character. 💖✨🦋