6

为了提高一个非常大的对象（并填满 GPU 内存）的显示性能，经过一些相当简单的数学运算后，我发现我可以将我的顶点数据从 16 字节顶点压缩到 4 字节顶点（因为数据在概念上可以被认为是一个经过变换的高度图 - 从顶点 id 暗示 x 和 y 位置），我可以将 Z 坐标紧密地打包成 30 位，留下 2 位用于颜色托盘索引。反正就是这个想法。我的问题不在于坐标包装，而在于颜色包装。

颜色托盘将由加载模型的 c++ 代码选择。由于它还加载着色器，我目前正在尝试将颜色查找代码编写为 switch 语句，即：

int colourIndex = (compressedVertex & Mask) >> bitOffset;
switch (colourIndex)
{
case 0: return vec4(....);
case 1: return vec4(....);
case 2: return vec4(....);
case 3: return vec4(....);
}

在模型的颜色多于 4 的情况下，我很乐意牺牲一些高度精度以适应更多的颜色托盘位（无论如何）。我的测量表明，使用 switch 语句绑定 4 色托盘并不比绑定 4 像素 1D 纹理并使用采样器读取它慢。

到目前为止，我已经将它扩展到了 32 种颜色，而且它看起来至少和使用纹理一样快。

何时停止使用 switch 并开始使用纹理查找表？如果它有助于我正在开发的应用程序已经强制执行 OpenGL 3.3 的最低要求。一旦数据在卡上，它就永远不会改变。我可以将它增加到 256 个案例陈述吗？1024？32768？极限在哪里？

（先发制人的回应：是的，我可以继续试验并通过反复试验和一些插值在我的单张现代卡上选择一个适合我的值；但我对什么是最佳实践以及是否其他人尝试过类似的东西并且知道它可以在野外工作吗？）

4

1 回答 1

2

我尽可能避免在着色器中分支。我的建议是使用纹理进行查找。

你问：

我可以将它增加到 256 个案例陈述吗？1024？32768？极限在哪里？

你说：

到目前为止，我已经将它扩展到了 32 种颜色，而且它看起来至少和使用纹理一样快。

OpenGL 擅长查找纹理。它旨在做到这一点。它不是为巨大的 switch case 语句而设计的。正如评论者所说，它不会全面表现良好。64x64 像素纹理可以为您提供 4096 次查找，从长远来看，在我看来，它会比大量查找更快。

于 2014-12-09T09:54:39.940 回答