求助: Kernel 在CUDA 运行时间和程序总运行时间匹配问题

最近参考太极图形课和Ray tracing in one weekend 试着在taichi 利用ti.struct_class 复刻Ray tracing in One Weekend的结果,渲染结果是完全匹配的。唯一不解的是仿佛并没有成功地把加速体现出来,CUDA中运行时间为1秒左右,实际程序运行了30s, 具体可见如下图。整体代码文件可见该链接

Capture_2

Capture_3

谢谢!

@Yonng , 在测试性能的时候,第一次调用 kernel函数是包含了编译时间的,所以你统计出来的时间比较长。

你可以先运行一次之后,再重复多次运行,计算时间的均值看看时间是多少。

1 Like

谢谢解答!不过感觉还挺有趣的,我今天参考Nvidia 的blog,复刻了C++ Cuda 版本的,在Nvidia 3090的机器上,整个程序19s 就跑完了封面的图片。在Taichi中跑的话,从Kernel Profile能看出其实是很接近的,结果这实际程序运行的时间是一个小时多了。

我有看到论坛里有其他相似的帖子提到这个类似问题,我也放到这里:
https://forum.taichi.graphics/t/2-another-ray-tracer/1858
https://github.com/0xrabbyte/TinyRayTracer-Taichi

个人感觉可能涉及CPU和GPU数据之间传输同步相关? 我确实在taichi function的实现中涉及到了不少通过ti.struct_class进行诸如ray和hitting record的反复生成。但确实从实现上的high-level来看,都是基于面向对象设计的代码结构,确实不是很能理解用Taichi加速与用CUDA本身加速这个ray tracing项目的差距

我用taichi example 测试了一下感觉确实如果涉及比较复杂的场景,整体程序的时长完全停留在编译阶段的感觉,那请问如何能够尽量减少这个问题呢,尽量kernel 程序部分缩小化?主要是现在ray tracing 大场景多次运行成本太高了,改一两个语句,可能就涉及一两个小时的编译的话,有一些痛苦 :smiling_face_with_tear:

Hi,你提出的问题很好。目前Taichi在开发大型程序时,确实存在修改一两行代码就要重新编译的问题。社区中提出的一个方案是将未改动的部分放在cache里面,目前该功能正在开发中,具体请看:Issues · taichi-dev/taichi · GitHub

关于你的程序里面为何和CUDA程序差别这么大,恐怕我们还得测试一下。

1 Like

谢谢细心解答!我已经更新了github的这个项目,欢迎测试。对于复刻22x22共484个小球生成的封面场景,目前这个数量级其实已经会造成一个新的问题: Memory Bad Allocation (基于device_memory_fraction=0.8,GPU为Nvidia RTX 3090)。CUDA C++版本运行占据的GPU内存我得到的结论是500MB左右。因此为了保证场景输出,我在上述回复提到的程序运行时间超1小时其实是基于14x14共196个小球生成的封面场景 (可见readme)。