Open TomClabault opened 4 days ago
This is rather inherent property of spatial splits rather than a bug. With spatial splits we use up to 1.5x references (this can be changed here, 1 corresponds to no spatial splits), which impacts the size of other auxiliary buffers. We also need two sets of bins (one for spatial splits and one for regular object splits). I guess this causes the spike. You can also try to decrease the number of bins here. It is always trade-off between the quality and memory usage.
I'll try playing with the parameters, they look interesting. Alternatively, I assume building a two-level BVH would alleviate the issue since each SBVH for each mesh would only need a temporary buffer sized big enough for its one mesh, and not the entire scene.
However, multi-level BVH have an associated traversal cost when compared to a single BVH for the whole scene right? How big of a performance difference is expected there?
Of course, there is some extra overhead introduced by two-level hierarchy, but this is actually the most optimized and tested scenario. Two-level hierarchy is employed by modern renderers (e.g., Blender Cycles), allowing instancing or better material management. Definitely, the slowest is if you use more than two levels (multi-level instancing).
Just out of curiosity and unrelated to the issue, what do you mean by "better material management"? What can be done in this regards with two levels BVHs?
What I meant is that you can easily map different materials (e.g., textures) to different geometries (or instances). While if you have the whole scene represented as a single geometry, ray tracing is faster but this material management is not that straightforward.
This was all tested on the Bistro.
With the
.
hiprtBuildFlagBitPreferHighQualityBuild
build flags:With the![image](https://github.com/GPUOpen-LibrariesAndSDKs/HIPRT/assets/61839853/0673ff51-cc5d-4169-bedc-6ee45112234b)
hiprtBuildFlagBitPreferHighQualityBuild | hiprtBuildFlagBitDisableSpatialSplits
build flags:This seems to "simply" come from the geometry temporary buffer that needs to be allocated before calling
hiprtBuildGeometry
. This is very limiting for large scenes (the Bistro only has 2.8M triangles) as this basically doubles the memory requirement for a given scene if using spatial splits (the memory usage drops back to 4.1GB from 8.6GB when freeing the temporary geometry buffer).Is there a workaround/fix for that?