0

有没有人在任何光线追踪碰撞测试内核（Cuda、Opencl）中尝试过用于 GPU 计算的自定义分支预测算法？

我是否应该担心低深度（2-5）的性能？

例子：

 trace for the first group of rays
     check for previous ray depth predictor, if zero, guess zero.
                                   if gt one, guess d>=1
           go one level deeper in tracing kernel.(with pseudo stack & recursivity)

                           recursively repeat

                     go out of one depth after saving guess state

                  recursively go out of depths.

这可以击败硬件级别的预测吗？这甚至可以使总跟踪时间更好吗？

此伪代码中的 "if" 语句不应包含任何 "if" 。所以它只是根据预测值计算零值或实际值。

谢谢。

4

1 回答 1

1

这是来自OpenCL 优化手册：

使用预测而不是控制流。预测允许 GPU 并行执行两条执行路径，这比尝试通过巧妙的控制流最小化工作要快。这样做的原因是，如果 ?: 运算符（也称为三元运算符）中不存在内存操作，则该操作被转换为单个 cmov_logical 指令，该指令在单个周期内执行。这方面的一个例子是：

If (A>B) { C += D; } else { C -= D; }

将此替换为：

int factor = (A>B) ? 1:-1; C += factor*D;

在第一个代码块中，这转换为条件代码的 IF/ELSE/ENDIF 序列，每个需要约 8 个周期。如果发散，此代码将在 ~36 个时钟内执行；否则，大约 28 个时钟。未采用的分支需要四个周期（一个指令槽）；一个分支增加了 4 个从指令缓存中获取指令的延迟，总共 16 个时钟。由于执行掩码被保存，然后修改，然后为分支恢复，发散时添加约 12 个时钟，不发散时添加约 8 个时钟。

在第二个代码块中，?: 运算符在向量单元中执行，因此不会生成额外的 CF 指令。由于指令是顺序相关的，因此该代码块在 12 个周期内执行，速度提高了 1.3 倍。看这个，第一个循环是（A>B）比较，其结果输入到第二个循环，也就是cmov_logical因子，bool, 1, -1。最后一个循环是一条 MAD 指令，即：mad C, factor, D, C。如果条件代码和 ALU 指令之间的比率很低，这是一个去除控制流的好模式。

似乎您的 0/1 选择可能基于预测。不确定这是否是您正在寻找的。

来源：http: //developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk/opencl-optimization-guide/

于 2014-08-28T20:00:34.500 回答