SAMPLER_T(3clc)
π SAMPLER_T π
okay bestie, welcome to sampler_t from the OpenCL manual (3clc), and lemme tell you, this one is lowkey the vibe-controller for your images π
β¨ NAME β¨
sampler_t β a type that controls how elements of an image object get read by read_image{f|i|ui}. it's giving "the rules of the reading situation" fr fr π
const sampler_t <sampler name> = <value>
constant sampler_t <sampler name> = <value>
__constant sampler_t <sampler name> = <value>
πΈ DESCRIPTION πΈ
so the image read functions take a sampler argument, right? and that sampler can show up in three different ways, pick your fighter:
- passed as an argument to the kernel using
clSetKernelArg(3clc)π«Ά - declared in the outermost scope of kernel functions β¨
- a constant variable of type
sampler_tdeclared in the program source π
Sampler variables in a program are declared to be of type sampler_t. and here's the tea: a variable of sampler_t type declared in the program source must be initialized with a 32-bit unsigned integer constant, which gets interpreted as a bit-field specifying these properties:
- Addressing Mode
- Filter Mode
- Normalized Coordinates
these properties control how elements of an image object are read by imageFunctions(3clc). no cap, that's the whole job πΈ
Samplers can also be declared as global constants in the program source using the syntax shown at the top of this page (you saw it, the const sampler_t moment π).
and now, the sampler fields, described in the table below (rip the table, we're doing it in cute little bullets now, same facts tho π¦):
π Sampler State β <normalized coords>
Specifies whether the x, y and z coordinates are passed in as normalized or unnormalized values. This must be a literal value and can be one of the following predefined enums:
CLK_NORMALIZED_COORDS_TRUECLK_NORMALIZED_COORDS_FALSE
β οΈ the samplers used with an image in multiple calls toimageFunctions(3clc){f|i|ui}declared in a kernel must use the same value for<normalized coords>. like, consistency is the moment, bestie π
π Sampler State β <addressing mode>
Specifies the image addressing-mode, i.e. how out-of-range image coordinates are handled. This must be a literal value and can be one of the following predefined enums:
CLK_ADDRESS_MIRRORED_REPEATβ Flip the image coordinate at every integer junction. This addressing mode can only be used with normalized coordinates. If normalized coordinates are not used, this addressing mode may generate image coordinates that are undefined. πCLK_ADDRESS_REPEATβ out-of-range image coordinates are wrapped to the valid range. This address mode can only be used with normalized coordinates. If normalized coordinates are not used, this addressing mode may generate image coordinates that are undefined. πCLK_ADDRESS_CLAMP_TO_EDGEβ out-of-range image coordinates are clamped to the extent. π«ΆCLK_ADDRESS_CLAMPβ out-of-range image coordinates will return a border color. This is similar to theGL_ADDRESS_CLAMP_TO_BORDERaddressing mode. π¨CLK_ADDRESS_NONEβ for this addressing mode the programmer guarantees that the image coordinates used to sample elements of the image refer to a location inside the image; otherwise the results are undefined. periodt. π
π for 1D and 2D image arrays, the addressing mode applies only to the x and (x, y) coordinates. The addressing mode for the coordinate which specifies the array index is always CLK_ADDRESS_CLAMP_TO_EDGE. iconic behaviour honestly π
β Sampler State β <filter mode>
Specifies the filtering mode to use. This must be a literal value and can be one of the following predefined enums:
CLK_FILTER_NEARESTCLK_FILTER_LINEAR
refer to section 8.2 for a description of these filter modes πβ¨
π NOTES π
okay bestie, listen up, because this part is lowkey important β¨
First things first: samplers that you declare with the constant qualifier? They do not count towards the maximum number of arguments pointing to the constant address space, and they also don't count towards the maximum size of the constant address space allowed per device. That's CL_DEVICE_MAX_CONSTANT_ARGS and CL_DEVICE_MAX_CONSTANT_BUFFER_SIZE, as described in table 4.3. So they're basically free real estate π
And the max number of samplers you can declare in a kernel? You can query that with the CL_DEVICE_MAX_SAMPLERS token in clGetDeviceInfo(3clc). Go check it, don't guess π«Ά
Now, the border color situation, and this is giving very specific:
If the <addressing mode> in the sampler is CLK_ADDRESS_CLAMP, then out-of-range image coordinates return the border color. That border color depends on the image channel order, and it can be one of these values:
- If the image channel order is
CL_A,CL_INTENSITY,CL_Rx,CL_RA,CL_RGx,CL_RGBx,CL_ARGB,CL_BGRA, orCL_RGBA, the border color is(0.0f, 0.0f, 0.0f, 0.0f). π all zeroes, nothing to see here. - If the image channel order is
CL_R,CL_RG,CL_RGB, orCL_LUMINANCE, the border color is(0.0f, 0.0f, 0.0f, 1.0f). okay that last one is a 1.0f, we love a little finale π
β οΈ heads up, this next bit is the sneaky part: a kernel that uses a sampler with theCL_ADDRESS_CLAMPaddressing 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 viaimageFunctions(3clc), 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. And here's the thing β these implementation-allocated samplers will count against the maximum sampler values supported by the device, the ones given byCL_DEVICE_MAX_SAMPLERS. Enqueuing a kernel that requires more samplers than the implementation can support will result in aCL_OUT_OF_RESOURCESerror being returned. so yeah. budget your samplers, bestie π
π Example π
okay here's the moment, the little code snippet, she's cute:
const sampler_t samplerA =
CLK_NORMALIZED_COORDS_TRUE |
CLK_ADDRESS_REPEAT |
CLK_FILTER_NEAREST;
So samplerA specifies a sampler that uses normalized coordinates, the repeat addressing mode and a nearest filter. iconique, no notes π
π SPECIFICATION π
OpenCL Specification[1]
π SEE ALSO π
otherDataTypes(3clc), imageFunctions(3clc), classDiagram(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 π
the footnotes, we did not forget them:
OpenCL Specificationβ page 292, section 6.12.14.1 - Samplers
and that's a wrap on SAMPLER_T(3clc) π brought to you by The Khronos Group, dated 01/14/2021, and yes the page really is called SAMPLER_T(3clc) in the corner like a little signature. go forth and sample responsibly, bestie, mwah πβ¨π¦
π¦ where this page comes from
- ubuntu jammy: opencl-1.2-man-doc 1.0~svn33624-5 Β· other
- ubuntu noble: opencl-1.2-man-doc 1.0~svn33624-5 Β· other
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms