目录
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
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
