树莓派4 OpenGLES3.1 glTexImage2D纹理GL_RGB格式读取异常问题

结论 #

这是树莓派4官方V3D OpenGL ES驱动的已知实现限制，并非你的操作错误。Windows、Ubuntu平台的桌面级GPU驱动对GL_RGB格式的帧缓冲区读回支持更完善，所以相同代码可以正常运行。

原因说明 #

• 树莓派4的V3D硬件对像素存储有4字节对齐要求，驱动会把你指定的GL_RGB格式颜色附件，内部隐式转换为GL_RGBA布局存储，因此GL_IMPLEMENTATION_COLOR_READ_FORMAT查询返回GL_RGBA是符合驱动实际实现的。
• OpenGL ES 3.1规范本身没有强制要求驱动必须支持和颜色附件格式完全匹配的glReadPixels格式，仅要求必须支持查询返回的默认格式/类型组合，所以驱动的该行为是合规的。

解决方案 #

方案1（优先推荐，成本最低） #

用GL_RGBA格式读回数据后，CPU端手动丢弃alpha通道即可。16*256的纹理数据量极小，格式转换的开销完全可以忽略，不会影响性能。示例转换逻辑：

// 按RGBA分配临时缓冲
uint8_t temp_buf[16 * 256 * 4];
glReadPixels(0, 0, 16, 256, GL_RGBA, GL_UNSIGNED_BYTE, temp_buf);
// 转成RGB格式写入back_buf
for (int i = 0; i < 16 * 256; i++) {
    back_buf[i*3 + 0] = temp_buf[i*4 + 0];
    back_buf[i*3 + 1] = temp_buf[i*4 + 1];
    back_buf[i*3 + 2] = temp_buf[i*4 + 2];
}

方案2（可先尝试，无需改业务逻辑） #

创建纹理时显式指定内部格式为GL_RGB8，不要用简写的GL_RGB：

// 把原来的glTexImage2D调用第三个参数从GL_RGB改为GL_RGB8
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB8, 16, 256, 0, GL_RGB, GL_UNSIGNED_BYTE, 0);

部分版本的V3D驱动对显式声明的GL_RGB8内部格式，会支持GL_RGB格式的glReadPixels调用，不用额外做格式转换。

方案3（高性能场景可选） #

如果你的业务对性能要求极高，不想做CPU端转换，可以新增一个计算着色器，直接把帧缓冲区的RGBA数据转成RGB格式写入SSBO或者1字节对齐的PBO，该方案实现复杂度更高，仅适合大纹理、高帧率的场景。

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