Glsl 如何确定地检测其2x2像素四边形中的着色器片段位置？

我一直在尝试利用Eric Penner的“着色器使用”中的技术 来自GPU Pro 2第VI.2章的“像素四元消息传递”。基本思想是，现代GPU在2x2片段四元组中处理片段着色器，并且您可以使用ddx（）和ddy（）在所有四个片段中获取某些值，只要以下条件保持不变：

您的GPU支持高质量的衍生产品

您知道正在处理哪个片段（左上、右上、左下、右下）

这为碎片着色器优化（比如在2x2像素的四边形上分布纹理抓取）提供了很多机会，而这需要计算着色器来完成

我的问题是： 我无法确定我在处理哪个片段。理想情况下，每个片段块将从偶数输出像素坐标开始，如（0,0），（2,0）。。。（1024，1024），…，所以您只需要检查输出像素x和y坐标是偶数还是奇数，就可以知道您当前正在处理哪个片段。彭纳在书中使用的方法假设这是可行的……但对我来说似乎是错的

不幸的是，我的2x2碎片四元组似乎是从不确定的地方开始的：我见过它们从（偶数、偶数）、（偶数、奇数）和（奇数、偶数）开始。我不记得我是否见过（奇数，奇数），但无论如何，这种安排似乎取决于许多我不了解的因素，包括输出分辨率和着色器细节。（我正在测试8800 GTS，以防有人怀疑。）

有没有人知道是什么导致了这种不确定性，或者有任何关于它的文档？我知道在这个领域几乎没有官方的标准化，但我更感兴趣的是在现代桌面级GPU的实践中如何工作，我希望有办法让这项技术发挥作用。如果没有人知道如何解释偶数/奇数开始行为，那么有人知道确定当前片段在其2x2四元组中的相对位置的其他方法吗

---

谢谢：）

事实证明，我问题的前提大多是错误的： 2x2片段四元组几乎总是以偶数像素开始…只要输出分辨率为偶数

如果输出分辨率是奇数（我正在使用的底层程序可能是奇数），事情可能会变得更复杂，原因很明显。我也不期望在驱动程序/GPU/等方面有任何一致性，但我目前的测试（本身可能仍然有缺陷）显示2x2像素四边形从奇数分辨率的维度上的奇数像素开始，至少在奇数维度是水平的情况下是如此

所有这些奇怪之处都掩盖了我更大的问题：我用来检测碎片在像素四元组中的位置的代码有缺陷。我通过将纹理坐标设置为在一个像素四元组内相等（设置为像素四元组中心）进行测试…或者我这么认为。但是，我基于全屏四元网格计算了屏幕坐标，其中uv贴图的+v轴指向下方。屏幕空间原点从左下角开始，因为它基于笛卡尔坐标的右上象限，我不小心忘了反转用于查找像素四元中心的uv偏移的v坐标。我的许多不确定的观察结果来自于调试和错误解释事物时没有检查我的假设，特别是结合奇怪的分辨率

这是一个令人尴尬的错误，我本应该早点发现，但我想我会详细说明这一点，作为对其他人的警告，在处理相对坐标系时，始终要仔细检查垂直轴的方向。；）

更新： 我遇到过这样一种情况，2x2像素四边形从偶数像素开始，即使分辨率是奇数。由于奇数决议下的不确定性，我不得不想出另一个解决方案：

如果您是从全屏四元组的uv坐标（用于后处理）导出屏幕像素数，则由此导出的片段位置仅用于在片段之间排列/放置共享样本等，而不是四元组像素通信本身。你需要有与屏幕空间原点相关的屏幕像素数。可以从顶点位置导出这些值，也可以使用基于uv的像素编号上的ddx（）.x和ddy（）.y找出它们的屏幕方向，并从那里以适当的方向镜像片段位置

根据屏幕像素数（相对于真实屏幕空间原点）和假设2x2像素四边形从偶数像素开始计算片段位置。（如果使用基于uv的像素数，现在是镜像的时候了。）

在片段位置上做一个ddx（）.x和ddy（）.y，如果它们在任一方向上都是负数，你知道像素四元组从该方向上的奇数像素开始…所以在该方向镜像

如果计算两个碎片位置，一个基于uv原点，另一个基于屏幕原点，则使用基于uv的位置来推断基于uv的样本放置，并使用基于屏幕的位置来实际获取相邻碎片处变量的值

利润

---

一旦我在Github上发布了我正在使用的麻省理工学院许可代码，我将发布一个链接，并附上使用示例（很遗憾，加速比不是我所期望的，但无论如何；）。我只是在等待完成一个更大的着色器，我将随它一起上传。

已经好几年了，但我不得不重新访问这个着色器进行工作，我注意到我还没有发布链接。这里是我的四像素通信代码的链接（Cg代码，但很容易转换成HLSL）：另外，我应该澄清一些事情：1。当时我正在为OpenGL编写.cg着色器，这就是为什么屏幕坐标从顶部开始-