Go SIMD 如何批量处理 RGBA 像素通道

Go SIMD 处理 RGBA 的关键，不是把 []uint8 直接塞进向量，而是先明确像素布局。本文把一个像素整理为 R 的 uint32，然后用 Go 1.27 实验性的可移植 simd 包一次加载多个像素，批量提高 RGB 亮度，Alpha 通道原样保留。最后不足一个向量的尾部交给 LoadUint32sPart 和 StorePart，避免越界。

先把 RGBA 从交错字节变成可批处理的像素

image.RGBA.Pix 通常是 R、G、B、A 连续排列。若直接按字节加载，向量里的相邻元素会混合不同通道，无法用一次加法只调整 RGB。工程上更稳妥的做法是预先把每四个字节打包成一个 uint32；下面的函数假定缓冲区已经采用这个布局，打包成本可以在整张图的多次滤镜之间复用。

用掩码拆通道，只让 RGB 参与亮度调整

Go 1.27 的 simd 提供尺寸无关的向量类型；代码在支持的硬件上使用对应指令，在不支持的平台上可以走模拟实现。下面示例把每个 RGB 通道增加固定值，并把结果限制在 255。示例关注数据关系，实际项目应先用标量版本建立正确性基线。

package main

import "simd"

// brightenRGBA 批量提高 RGB 亮度，Alpha 通道保持不变。
func brightenRGBA(pixels []uint32, delta uint32) {
	mask := simd.BroadcastUint32s(0xff)
	limit := simd.BroadcastUint32s(255)
	bias := simd.BroadcastUint32s(delta)

	for i := 0; i 

这里的 Min 不是装饰：如果直接对 uint32 做加法，通道超过 255 会继续进入高位，重新打包时可能污染相邻通道。Alpha 独立保留，也意味着透明度不会因为亮度滤镜被误改。

尾部、布局和实验开关是三个边界

构建示例：

# 启用 Go 的实验性 SIMD API；生产构建前应固定工具链版本。
GOEXPERIMENT=simd go run .

可移植 simd 会隐藏不同向量宽度；不要把某台机器上的“每批几个像素”写死到业务逻辑。若项目需要特定架构独有指令，再考虑 simd/archsimd，同时用构建标签隔离它。

什么时候值得用 SIMD

先比较三条路径：标量循环、打包后 SIMD、以及针对单一架构的 archsimd。如果图片很小，转换布局的成本可能抵消向量收益；如果同一缓冲区会连续执行亮度、对比度和阈值等多个滤镜，统一的 uint32 布局才更有价值。基准测试应覆盖小图、大图、尾部长度、透明像素和不同 CPU，并用像素级结果与标量基线比较。

常见问题

能不能直接对 image.RGBA.Pix 使用 Uint8s？

可以用于“所有字节同样处理”的操作，但 RGB 与 Alpha 规则不同的滤镜不应直接这么做；应先按通道拆分，或采用本文的打包像素布局。

simd 一定比普通循环快吗？

不一定。数据转换、内存带宽、图片尺寸和硬件支持都会改变结果，必须用目标机器上的基准测试决定是否保留 SIMD 路径。

结论是：先统一像素表示，再批量运算，最后用 Part API 收尾。这样 SIMD 优化解决的是明确的像素吞吐问题，而不是把布局和边界错误藏进更快的代码里。