Experiments with Hardware Accelerated SDF Ray Marching

Utilizes the hardware ray-tracing pipeline (specifically the AABB procedural primitives) to accelerate ray-marching the SDF. The scene is completely defined in the SDF, but the bounds are defined on the CPU at initialization. It doesn't need to be this way, as the BLAS generation happens on the device anyways. You could be smarter and instead calculate the AABB bounds on the GPU, directly from the SDF, and feed those to the BLAS, while remaining on the GPU. Could be used for dynamic objects over time. SDF primitives are taken from Iq's site: https://iquilezles.org/articles/distfunctions/ On the traversal side, instead of checking for ray-intersections with triangle geometry, we check against CANDIDATE_PROCEDURAL_PRIMITIVE and run the SDF raymarcher based on that. As of writing this, I have tested using local SDFs (that are defined in the local space of the BLAS instance) instead of defining everything in one function, and it yields pretty interesting results as well. Lots of things you can do with this, assuming bounds are semi-tight (as loose bounds would deteriorate performance compared to tight bounds) Surface normals are calculated using the auto-diff feature of Slang. All primitives and the SDF are marked as [Differentiable]. The ground is made using a 3D texture that is generated on the CPU as well. Just spawns a few spheres with random radii and calculates their union, then this is subtracted from the SDF of the ground plane on the GPU. This is also why the ground is tiled like that. You can probably use textures like that to cache SDF to reduce ray-marching costs as well, though this might incur memory latency issues as well. Unsure. Performance has been amazing for how little work it took. Here are quick dirty measurements done at 1440p on the AMD 780M: 1440p naive: 107ms, 0.11 mrays/s, 387.71 million SDF calls 1440p hwrt: 40ms, 0.30 mray/s, 55.63 million SDF calls This is at 2 bounces (including first hit, so only really 1 bounce), with shadow ray (that is randomized. I am not using the cheap-SDF soft shadows yet with the HWRT path yet) . Note that due to the bounce, the ray incoherence spikes up and reduces the mray throughput by a lot. In an ideal world without GPU divergence problems, that metric would not change at all. Though, at that point, would GPUs really be GPUs? Anyways this seems very promising for how little work it took to get good results.