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 回答