射线迹算法中的分支预测函数
有没有人在任何射线追踪碰撞测试内核(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”。因此，它只根据预测值计算零或实际值。
谢谢。
回答 1
Stack Overflow用户
发布于 2014-08-28 20:00:34
这是来自OpenCL优化手册的
使用预测而不是控制流。预测允许GPU并行执行两条执行路径，这比试图通过巧妙的控制流最小化工作要快。这样做的原因是，如果在?：操作符(也称为三元操作符)中不存在内存操作，则将此操作转换为单个cmov_logical指令，该指令在一个周期内执行。这方面的一个例子是：
If (A>B) { C += D; } else { C -= D; }将此替换为：int factor = (A>B) ? 1:-1; C += factor*D;在第一个代码块中，这将转换为条件代码的IF/ each /ENDIF序列，每个序列需要8个循环。如果发散，则该代码在~36个时钟中执行；否则，在~28个时钟中执行。一个未被占用的分支需要四个周期(一个指令时隙)；一个分支需要增加四个延迟时隙来从指令缓存中获取指令，总共需要16个时钟。由于保存了执行掩码，然后修改，然后对分支进行恢复，因此在发散时增加了12个时钟，当不发散时增加了8个时钟。 在第二个代码块中，?：操作符在向量单元中执行，因此不会生成额外的CF指令。由于指令是顺序依赖的，这段代码在12个周期内执行，以提高1.3x的速度。要了解这一点，第一个周期是(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/
https://stackoverflow.com/questions/25535216
复制相似问题
腾讯云开发者
