详细纹理需要更长的渲染时间吗？

假设我要渲染一个正方形；它的纹理是“ square.png”。

如果纹理只是纯色，计算机是否更容易渲染它？

如果它是一个非常嘈杂的纹理，到处都是完全随机的颜色，那该怎么办？

或者，如果该纹理在每个像素之间都不同，但只有一点点不同的意义上又是嘈杂的，该怎么办？

就像游戏开发中的大多数事情，尤其是游戏图形中的大多数事情一样，答案是“取决于”

纹理大小

纹理的分辨率可能会影响渲染速度。它包含的像素越多，要上传到GPU的原始数据就越多，一次可以容纳在缓存中的纹理就越少，因此，着色器在等待纹理的正确部分时可能会遇到更多的暂停进入缓存。

使用mipmapping可以减少这种影响。借助mipmap，我们存储了一系列缩小版本的纹理，乍一看听起来好像需要更多内存。但是，当纹理在屏幕上以较小的尺寸显示时（例如透视中的远处的对象），它使我们能够从较小的版本中读取内容，因此我们的示例更好地利用了纹理缓存，而不是全盘跳过。这也减少了混叠。

纹理细节

大部分时候，纹理的内容对渲染效率没有影响。

就GPU而言，颜色只是一堆数字，因此它并不在乎这些数字是什么，它只是以相同的方式通过数学将其分布。它并没有像想起“哦，我以前看过这个绿色的像素，我只是重复使用上次看到此输入时计算出的相同输出”那样的花哨，所以您的纹理是否全是一种颜色或随机闪光，您的GPU正在执行相同的工作。

与PNG和JPG之类的格式在图像的可预测区域更有效地压缩，并在复杂区域中吞噬更多位不同，BTC，ETC，PVRTC甚至原始RGBA等GPU纹理格式每块像素使用固定数量的位像素。因此，在保持相同压缩格式的同时使纹理更详细或更细，不会改变其数据大小，也不会影响数据传输和与缓存相关的效率。

但是，如果您使用以前无法很好地保留压缩的特定种类的细节，则可能会被迫将整个图像更改为使用其他格式，这可能会再次更改其数据大小。

着色器分支和间接

这是这种情况下最大的星号：您可能正在使用此纹理颜色输入来做出决策，例如if()分支。在这里，细节对于速度至关重要。

GPU阴影单元批量处理像素块，对多个数据流并行运行相同的指令。因此，当块中的某些像素占据的一个分支，if而其他像素占据另一个的分支时，整个批次必须经过两个分支（掩盖不适用于一组像素或另一组像素的结果）

如果您的输入以一种平滑/可预测的方式更改，那么您可能会有很多只需要采用一个分支的块，并且这两种情况都将被限制在过渡边界周围的窄带上。但是，如果您输入的内容是随机的，我们希望大多数块都采用两个分支并减慢渲染速度。

如果您使用一个纹理来控制对第二个纹理的查找，例如失真或索引贴图，也会发生这种情况。如果第一个纹理随机跳动，那么我们将从第二个纹理的分散的，类似随机斑点中采样，从而降低了对纹理缓存的使用一致性，平均等待更长的时间来获取所需的数据。

因此，总体而言：不，纹理的内容对渲染速度的影响不大，除非有这种情况。;）

连同上述DMGregory的出色答案，也许存在一种情况，其中“纹理”的复杂性可能会影响渲染性能，也就是以前的渲染结果在后续的渲染中用作源（例如阴影贴图） / reflections /环境地图。

某些现代硬件可能会对这些缓冲区应用无损压缩：例如PowerVR具有PVRIC，AMD，Delta颜色压缩，而ARM具有类似的东西。这些压缩技术的目的是减少总带宽，进而可以提高渲染性能。

数据越简单（深度或颜色（整数或浮点）），这些方案就越有效。当然，我不建议您只是为了简化这些渲染功能而故意简化渲染输出，但是在某些情况下避免使用嘈杂的数据可能会有所帮助。

同样，对这些格式的帧/深度缓冲区进行稀疏采样，徒然尝试降低带宽，也无济于事，因为它们很可能是基于块的。

此外，您可能会发现这两个SE Computer Graphics问题和感兴趣的答案：

• 硬件纹理压缩如何工作？ 这涵盖了许多流行的硬件方案使用的算法。
• 使用许多纹理贴图是否对缓存不利？ 其中描述了使用纹理时的一些折衷及其对纹理缓存的影响，以及渲染成本。