Debugging cg:顶点输出结构被不同的成员顺序损坏？配置文件冲突还是cg错误？

我一直在为Retroarch修补cg着色器，我在cg工具包的编译器或代码生成器中遇到了一个奇怪的bug…或者其他什么。考虑这里发现的三遍着色器，它模拟CRT TV：

特别是考虑最后一关：

目前，着色器输出按预期工作。如果注释掉该文件顶部的“#定义曲率”（模拟CRT TV的曲率），着色器输出也会按预期工作。但是，此处顶点着色器输出结构的成员顺序非常特殊：

struct out_vertex {
    float4 position : POSITION;
    float4 color : COLOR;
    float2 texCoord : TEXCOORD0;
        float2 one;
        float mod_factor;
        float2 ilfac;
        float3 stretch;
        float2 sinangle;
        float2 cosangle;
};

如果将顺序重新排列为以下顺序，则会得到损坏的输出：

struct out_vertex {
    float4 position : POSITION;
    float4 color : COLOR;
    float2 texCoord : TEXCOORD0;
        float2 cosangle;
        float2 one;
        float mod_factor;
        float2 ilfac;
        float3 stretch;
        float2 sinangle;
};

我的台式电脑的nvidia卡给了我一个黑屏，我的笔记本电脑的ATI卡给了我一个奇怪的工件，其中纹理坐标似乎被破坏了（也许）。因此，错误的确切性质取决于GPU或驱动程序，但错误的存在与供应商/驱动程序无关……因此，cg编译器中似乎存在导致各种属性损坏的错误。你所能得到的那种腐败几乎是永无止境的。例如，其他成员的重新排列会导致诸如“mod_factor”变量（存储输出的x像素坐标）之类的错误，这会导致交替的品红/绿色像素色调在一个或另一个上卡住，从而用相同的色调覆盖整个图像。除光晕/光晕等因素外，还有其他因素会导致黑屏

如果重新启用“#定义曲率”，则此特定着色器中不会出现问题，但这与“平坦”代码路径中的错误无关：事实上，在“#ifdef CURVATURE”块中的片段着色器部分中，您实际上可以用“xy=VAR.texCoord；”替换最终值（与未弯曲版本使用的值相同），您将获得无任何错误的平面输出。（编辑：Oops，对于这个特定着色器，这实际上不是真的，但在我自己的版本中是真的。在对这个“简化”示例进行相同评估之前，我应该先检查一下。）事实上，平面代码路径触发了损坏，但弯曲代码路径似乎并不表明它与弯曲代码路径读取片段着色器中更多不同属性有关（可能读取顺序或使用也很重要…？），但我还没有找到一个押韵或理由。我有我自己的完全不同的分叉WIP，其中同样奇怪的问题也会影响弯曲的代码路径，但我宁愿自己保留它，直到它准备好为止

所以，我想我有几个问题：

• 还有人见过这样的东西吗
• 对于没有显式与任何语义关联的输出结构成员，这种不确定性仅仅是预期的吗
• 这种损坏可能来自我不知道的cg着色器配置文件限制吗？我不知道Retroarch编译着色器配置文件的目的是什么，但是如果顶点输出结构的大小超过允许的最大大小，我可以看到这种损坏发生
• 还有什么我可能忽略的可能性吗？我考虑过驱动程序错误，但当我意识到它同时影响nvidia和ATI硬件时，它就消失了。尽管如此，我想在通知nvidia Cg工具包似乎有一个错误之前做我的功课

---

感谢您的见解！：）

事实证明，问题完全与依赖cg的自动分配语义有关。我将从上面复制/粘贴我的评论：

---

我开始认为这个问题可能与 依靠cg自动分配语义：例如cg associates 一个满浮点范围的值，其语义钳制为[0.0， 1.0]，这显然会引起问题。mod_因子、ilfac和stretch都属于这一类，sinangle和cosangle都属于这一类 可能在[-1,1]中，所以同样的情况可能也适用于它们。这个 语义的赋值可能会受到死代码的影响 消除，这将解释有无差异 “#定义曲率。”不过我必须检验这个假设

根据配置文件的不同，可用的语义数量有限（请参阅），而且（我可能弄错了）Retroarch似乎使用较低的配置文件，其中只有以下内容可用：

• 位置：必须设置为clipspace顶点位置，不仅因为它通知光栅化器，而且因为它显然甚至无法从片段着色器读取
• COLOR0和COLOR1：值被钳制到[0，1]范围
• TEXCOORD0-7：对于任何标量或向量浮点值都是安全的
• FOG：对于任何标量浮点值都是安全的

---

BCOL0/BCOL1语义可能在支持它们的概要文件中也有钳制，而PSIZE和CLP0-5可能没有。总的教训似乎是，让cg编译器为[0，1]范围之外的值自动分配语义就像玩俄罗斯轮盘赌，因为你永远不知道它们是否会最终与钳制语义关联，自动分配将根据着色器代码的具体情况而改变。出于这个原因，您需要仔细管理语义，以便[0，1]之外的值可以与TEXCOORD0-7或FOG（对于标量浮点）之类的值配对.

我开始认为问题可能与依赖cg自动分配语义有关：例如，如果cg将一个满浮点范围的值与一个钳制到[0.0，1.0]的语义相关联，这显然会导致问题。mod_factor、ilfac和stretch都属于这一类，sinangle和cosangle可能在[-1,1]中，因此这可能同样适用于它们。语义的分配可能会受到死代码消除的影响，这将解释与