着色器编译器通常是否知道不查找未使用的纹理通道?

我有一个来自OpenGL ES 2.0中的FBO的颜色附件的纹理,所以我对图像中的通道数目进行了有限的控制。

假设我只需要这个纹理的R通道的颜色。 如果我立刻在这样的片段着色器中调出R:

float brightness = texture2D(u_texture, v_texCoord).r; 

我可以期待GPU知道不打扰G,B和A吗?

我认为这是不同的设备,这取决于着色器编译器的优化,但对我来说,这看起来像一个非常明显的和容易的优化。

我想知道我是否可以有把握地相信,几乎所有的GPU都会进行优化。 这个着色器是一个多纹理的着色器,我不想让一些运行它的设备比我testing的慢很多。 如果我不能,那么我可能会想要使用一种不同的方法来生成我的图像,这样我就可以确保纹理通道较less。

从许多方面来看,你不会看到有什么不同。 没有优化。

更长的解释:

Texure被存储,你可以毫无疑问地猜测,内存中的像素。 也就是说,r,g,b,a在同一个地方挤在一起。 (即通道交错)。 从内存中获取内容大致可以分为DDR格式,这可能相当大,不止一个像素。 幸运的是,由于着色器通常只获取一个像素,所以更多的传输不会在开销中丢失,因此用于填充纹理单元高速caching。 这通常是因为着色器单元核心局部性和纹理空间局部性之间的相关性。
主存储器中使用Z-阶曲线存储确保了这一点。 (又名莫顿代码)。
对于琐事来说,这实际上也被称为swizzling,但是与着色器歪斜的访问器无关。

由于stream水线指令体系结构,debugging操作不需要补充时间,但它也不允许优化。

人们可以认为,在ALU与像这样的标量一起工作的情况下,nvidia卡(标量着色器单元)将优于ATI卡(向量着色单元)。 但这与编译或优化无关。

编译器将执行的一些优化:

在着色器中移动纹理尽可能高,有时甚至超过任何计算。 如果tex2d指令不依赖于variablesuvs(纯粹改变逐字传递),这是可能的。 请注意,即使tex2d指令在条件内,情况也是如此!

这样做的目标是试图充当预取者。 通过ALU速度隐藏总线延迟。