带采样器与不带采样器的image_readf处理次正规数的行为差异

规范表述的实际差异 #

先明确规范的核心逻辑：不带采样器的读取函数（除次正规数场景外），行为等价于使用CLK_FILTER_NEAREST滤波模式、非归一化坐标、CLK_ADDRESS_NONE寻址模式的带采样器版本；当image_channel_data_type为浮点类型时，两者的次正规数处理存在倾向性差异，而非完全无区别：

规范原文核心：不带采样器的函数可能返回次正规数，带采样器的函数可能将其清零。

这里的“可能”并非指行为随机，而是规范给实现留的灵活性：

• 不带采样器的函数：规范不强制清零次正规数，实现默认倾向于保留次正规数，清零属于可选行为
• 带采样器的函数：规范建议清零次正规数，实现通常会遵循这个建议，但少数场景下也可能保留

规范设计的底层逻辑 #

这种差异和采样器的定位有关：带采样器的读取路径通常涉及纹理过滤、坐标转换等硬件加速操作，这类操作在GPU硬件上普遍会开启“次正规数清零（FTZ）”来提升计算性能；而不带采样器的读取更接近直接内存访问，硬件不会自动触发FTZ，因此允许保留次正规数。

各OpenCL实现的实际处理情况 #

• AMD GPU：不带采样器的浮点图像读取会保留次正规数，带采样器的则强制清零
• NVIDIA GPU：与AMD逻辑一致，带采样器路径默认开启FTZ，不带采样器的路径不开启
• Intel CPU/GPU：多数场景下，带采样器的读取清零次正规数，不带的保留；低端GPU可能为简化逻辑，两者均清零
• ARM Mali等嵌入式GPU：带采样器的读取通常清零次正规数，不带的保留；资源受限的小型设备可能两者都保留次正规数

总结 #

规范中的“可能”是弹性空间，实际行为差异明确：带采样器的读取大概率清零次正规数，不带的倾向于保留。如果需要严格的次正规数处理逻辑，建议在代码中手动控制（如读取后判断清零，或编译时指定FTZ/DAZ编译选项）。

内容的提问来源于stack exchange，提问作者einpoklum