我的 ray-box-intersection 算法效率有多低？

Question

“我的光线追踪器”最关键的部分之一是计算光线盒之间的碰撞，这是通过以下方式完成的：

inline bool hitsCube(in Ray ray,            in Cube cube, 
                     out float tMin,        out float tMax,
                     out float3 signMin,    out float3 signMax)
{
    float3 biggerThan0 = ray.odir > 0; // ray.odir = (1.0/ray.dir)
    float3 lessThan0 = 1.0f - biggerThan0;
    
    float3 tMinXYZ = cube.center + biggerThan0 * cube.minSize + lessThan0 * cube.maxSize;
    float3 tMaxXZY = cube.center + biggerThan0 * cube.maxSize + lessThan0 * cube.minSize;
    
    float3 rMinXYZ = (tMinXYZ - ray.origin) * ray.odir;
    float3 rMaxXYZ = (tMaxXZY - ray.origin) * ray.odir;
    
    float minV = max(rMinXYZ.x, max(rMinXYZ.y, rMinXYZ.z));
    float maxV = min(rMaxXYZ.x, min(rMaxXYZ.y, rMaxXYZ.z));
    
    tMin = minV;
    tMax = maxV;
    
    signMin = (rMinXYZ == minV) * lessThan0; // important calculation for another algorithm, but no context provided here
    signMax = (rMaxXYZ == maxV) * lessThan0;
    
    return maxV > minV * (minV + maxV >= 0); // last multiplication makes sure the origin of the ray is outside the cube
}

这个函数在 hlsl-shader 中被调用了很多次（对于某些像素至少 200/300 次），但在某些点上会出现延迟。我的碰撞逻辑实现效率低吗？ '我尽量避免分支，因此，作为回报有更多的乘法。这有多低效？

Answer 1

不会提出一个容易回答的“问题”，而且如果不知道周围发生的所有其他事情就很难说，但只是一些随机的想法：

a) 如果您真的想知道这在 GPU 上的样子，我建议将其“移植”到 CUDA 内核，然后使用 CUDA 为现代 GPU 生成 PTX 和 SASS（例如， sm75 用于图灵或 sm86 用于安培）；然后比较 SASS 输出中的两个或三个变体。

b）“将逻辑转换为乘法”可能比您想象的要少 - 如果逻辑不是太复杂，那么您可能最终会得到一些谓词并且根本没有太多的扭曲分歧，所以可能不会太糟糕。唯一的判断方法是查看 PTX 和/或 SASS 输出，参见“a”。

c) 你的 tMinXYZ/tMaxXYZ 公式是（恕我直言）不必要的复杂：只需用最小/最大操作来表达它，这在 GPU 上真的很便宜。另请参阅光线追踪 gems 2 书（可免费下载）中的相应章节“光线/盒子相交”。顺便说一句，数值也更稳定。

d) 重新“滞后...是我的逻辑效率低下” - 实际的组装“效率”很少会产生如此巨大的影响；通常，造成明显“滞后”的罪魁祸首要么是内存停滞（很难猜出发生了什么），要么是由于其他原因出现了可怕的错误（请参阅下一个项目符号）。

e) 只是一个预感：我会检查一些方向分量为 0 的光线。在这种情况下，您将除以 0（这绝不是一个好主意），特别是如果它乘以 0.f (在你的情况下可能会发生）你会得到 NaN，并且由于“与 NaN 的比较总是错误的”你可能会以遍历逻辑总是下降而不是跳过的情况结束。与您的逻辑的“效率”不同，但需要注意。好的解决方法是始终将 0.f 的每个 ray.dir 更改为 1e-6f 左右。