CrossRT: A cross platform programming technology for hardware-accelerated ray tracing in CG and CV applications

TL;DR

This work proposes a programming technology that bridges cross-platform compatibility and hardware acceleration in ray tracing applications and outperformed existing Path Tracing implementations.

Abstract

We propose a programming technology that bridges cross-platform compatibility and hardware acceleration in ray tracing applications. Our methodology enables developers to define algorithms while our translator manages implementation specifics for different hardware or APIs. Features include: generating hardware-accelerated code from hardware-agnostic, object-oriented C++ algorithm descriptions; enabling users to define software fallbacks for non-hardware-accelerated CPUs and GPUs; producing GPU programming API-based algorithm implementations resembling manually ported C++ versions. The generated code is editable and readable, allowing for additional hardware acceleration. Our translator supports single megakernel and multiple kernel path tracing implementations without altering the programming model or input source code. Wavefront mode is crucial for NeRF and SDF, ensuring efficient evaluation with multiple kernels. Validation on tasks such as BVH tree build/traversal, ray-surface intersection for SDF, ray-volume intersection for 3D Gaussian Splatting, and complex Path Tracing models showed comparable performance levels to expert-written implementations for GPUs. Our technology outperformed existing Path Tracing implementations.

Figures (12)

• Figure S1: The workflow with the proposed technology follows these steps. In the first stage, the programmer develops their algorithm in C++ without any restrictions. In the second stage, the code is incrementally modified to make the algorithm parallelizable. In the third stage, the programmer runs the translator and adjusts the code based on its recommendations to ensure error-free translation. At this point, a functional GPU version of the algorithm is available, and the process can be considered complete. If needed, in the fourth stage, the programmer refines the generated version by replacing individual computational kernels or virtual functions of the generated class.
• Figure S2: The generated class interacts with the external environment (the rest of the C++ program) through the API used by the base class (dashed arrows). In the generated code, these functions will be overridden. Therefore, in our programming technology, some virtual functions of the user class naturally serve as a boundary between the CPU and GPU address spaces.
• Figure S3: Left: interaction of generated code with user-defined ordinary C++ code, right: interaction of generated code with user-defined Vulkan code. Both options are available. Black arrows denote virtual functions in the user class, which are overridden by our translator in the generated code. This allows the generated class to be seamlessly integrated into the user code without any modifications.
• Figure S4: The flowchart of the proposed translator. Note that in the generated Vulkan code, the class includes member functions ("SetVulkanInOut_Bloom" and "BloomCmd") designed to interact with existing data in GPU memory.
• Figure S5: Images of the test scenes from the viewpoint used in the LBVH tree construction and traversal. The images themselves were generated using Monte Carlo Path Tracing.