OpenGL ES着色器语言规范 10 常见问题（14-16）

目录

10.14 预处理器

10.15 编译制阶段

10.16 易变变量的最大个数

---

10.14 预处理器

预处理器是否必要？ 扩展机制依赖于预处理器，因此需要更换。＃define，＃ifdef，＃ifdef，#elsif和#endif结构通常用于管理不同版本和包含防护。宏，特别是参数化宏被认为没什么用，因为它们应该被常量和函数替换。它们仍然常用于C程序中，因此在GLSL ES中可能存在类似的情况，尽管包含它们的论据并不那么坚挺。预处理器的其他部分已被删除。

A:保留基本的预处理器。

 

行尾继续符号'\'是否应包含在规范中？

A:不，这不是必需的，因为我们不期望搞一个复杂的宏定义。

 

10.15 编译制阶段

预处理器应该像编译的第一阶段一样运行，还是像C / C ++一样转换为预处理器令牌？

结果不同的情况并不常见。

#define e +1

int n = 1e;

根据c ++标准，'1e'应转换为预处理器令牌，然后转换为数字失败。 如果首先运行预处理器，则'1e'将扩展为'1 + 1'，然后成功解析。

A:遵循c ++规则。（也就是会转成1+1后进行计算）

 

10.16 易变变量的最大个数

Q:应该如何定义gl_MaxVaryingFloats？最初这被指定为32个浮点数，但目前一些桌面实现无法正确实现。许多实现使用8个vec4寄存器，很难在不损失性能的情况下在多个寄存器之间拆分易变变量。

选项1：将最大值指定为8个4向量。 然后由应用程序来打包易变变量。其他语言要求由应用程序来打包完成。开发人员尚未将此报告为问题。

选项2：根据打包规则指定最大值。开发人员可能使用非最佳打包方法，因此最好在驱动程序中执行此操作。 当自动生成着色器时，要求应用程序打包变换是有问题的。驱动程序更容易实现它。

A:将根据打包规则指定最大值。

 

Q:属性变量和统一变量是否应遵循此规则？

A:属性变量不应遵循此规则。 它们将继续被指定为vec4s。

A:统一变量应遵循此规则，但顶点统一变量的数量应增加到128个4向量，以适应打包算法的低效率。

 

Q:内置特殊变量（gl_FragCoord，gl_FrontFacing，gl_PointCoord）是否应包含在此打包算法中？内置的特殊变量以多种方式实现。有些实现将它们保存在单独的硬件中，有些则不然。

A:色器中引用的任何内置特殊变量都应包含在打包算法中。

 

Q:gl_FragCoord应该包含在打包算法中吗？光栅化时始终需要x和y分量。 通常需要z和w组件也会比需要。

A:gl_FragCoord包含在易变变量中。

 

Q:如何打包mat2易变变量呢？

选项1：将它们打包为2x2。

选项2：将它们打包为4列x 1行。 这通常对于实现更有效。

选项3：分配4列x 2行空间。 这是低效的，但允许实现如何将它们映射到寄存器的灵活性。

选项4：如上所述，但将2个mat2变化包装到每个4列x 2行块中。 任何不成对的mat2需要整个4x2块。

A:选项3。

 

Q:mat3应该占3整行吗？

这将再次允许实现的灵活性，但它浪费了可用于浮点数或浮点数组的空间。

A:不，mat3应该采取3x3块。

 

Q:vec3应该占一整行吗？

A:不。

 

Q:是否应更改gl_MaxVertexUniformsComponents以反射打包规则？

A:将gl_MaxVertexUniformComponents重命名为gl_MaxVertexUniformVectors。 将gl_MaxFragmentUniformComponents重命名为gl_MaxFragmentUniformVectors。

 

版权：https://blog.csdn.net/flycatdeng/article/details/88630104

Android,OpenGL ES,图形学