现代 WebGL 的二次幂纹理性能优势答案

【问题标题】：Power-of-two textures performance benefits with modern WebGL现代 WebGL 的二次幂纹理性能优势
【发布时间】：2016-09-26 22:16:03
【问题描述】：

我们将 PIXI.js 用于内部使用 WebGL 进行渲染的游戏。时不时地，我会偶然发现避免 NPOT 纹理（https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Using_textures_in_WebGL#Non_power-of-two_textures、https://github.com/pixijs/pixi.js/blob/master/src/core/textures/BaseTexture.js#L116）的二次幂和可能的性能优势。令人困惑的是，也有人提到它不再有影响（OpenGL - Power Of Two Textures）。随着 webgl 和浏览器的发展速度如此之快，很难判断这些信息中哪一个是准确的。

具体来说，我想知道填充图像以创建 POT 纹理的开销（更长的下载时间、增加的内存使用量）是否值得性能优势（如果它们确实存在的话）。我找不到任何比较 POT 和 NPOT 纹理的比较或性能基准，遗憾的是我真的不知道如何自己创建一个。

有没有人有这方面的经验或一些最新的数字？有没有衡量 webgl 性能的好方法？

【问题讨论】：

不了解性能，但 NPOT 纹理的主要问题是不支持 mipmapping 和重复。 POT（通常）允许在许多计算中进行优化。我也有一种感觉，GPU 可能会在内部将纹理填充到方形 POT 纹理（基于我所做的无关测试），但我不是 100% 对此。
如果任何现代 GPU 在 pot 和 npot 之间的性能差异，我真的会感到惊讶。我所说的现代是指过去 6 年多来的任何东西，包括手机。但我只是凭直觉。如果您想知道，您必须跨大量 GPU 进行测试。
@WacławJasper “我也感觉到 GPU 可能会在内部将纹理填充到方形 POT 纹理” 想象一下创建 RGBA8 16384 by 8193 纹理，将其填充到 POT 将导致约 1 GB 的内存使用量而不是约 536 MB，抓住您选择的 gpu 分析器并亲自查看。 Afaik 如果应用了填充，它总是在应用程序端完成，以在旧 GPU 上“填充”NPOT 纹理。
至于问题，我没有进行任何性能基准测试，但 afaik NPOT 纹理本身不应该变慢，但是根据场景，没有 mipmap 的渲染可能会慢很多。如果您发现需要将纹理优化为 POT，那么您可能希望在客户端上执行此操作以节省网络流量。

【解决方案1】：

我认为您将得到的大多数答案是“取决于硬件/驱动程序/gpu”、“您必须自己测试”或“它不会慢很多（但需要注意的是，您必须测试所有gpus 以确保）”。

与其担心将图像填充到 POT，不如使用纹理别名（精灵表）。或者请求 Pixi 背后的人来实现它。通过使用具有 POT 尺寸的纹理别名，您真正获得了两全其美：最小的填充浪费，保证 POT 纹理的执行不会比 NPOT 纹理慢，AND减少 GL 状态更改。

我无法强调通过减少 GL 状态更改可以获得多大的改进。通过实现纹理混叠和绘制批处理，我基本上可以在现实环境中绘制尽可能多的 2D 精灵；也就是说，以 60fps 的速度移动、旋转和调整 sprite 的大小约为 150k（受 CPU 约束，以每帧计算每个 sprite 的新变换）

【讨论】：

这个问题的一个原因是我正在研究github.com/Gamevy/pixi-packer，它是一个纹理打包器。它已经针对接近 POT 大小的 spritesheets，但大多数时候它们并没有完全填充。我想知道 webgl 是否会从我四舍五入到下一个 POT 或保留 spritesheets 中受益。抱歉，我应该在帖子中添加一些信息。
您可以保留 spritesheets 原样，但在创建 webgl 纹理时，请在 POT 中创建它们。
其称为纹理ATLAS 不是别名
除了图集也有其缺点：坐标环绕需要手动完成（clamp、repeat、mirror），mipmap 需要手动生成以避免在较小的 mip 级别上出现颜色溢出，幼稚采样会抛出用于自动 mip 级别选择的梯度计算，以及一个仅限于对该图集中的所有纹理进行线性或最近过滤的事实（或者需要手动在像素着色器中手动进行过滤）。
Mip-mapping 工作正常，只需要填充边框。包装模式实现起来很简单。不明白关于“为自动 mip 级别选择抛出梯度计算”的部分。 LINEAR_MIPMAP_LINEAR 适合我。