GPUOpen-LibrariesAndSDKs / HIPRT

Other
83 stars 4 forks source link

Memory usage spike when building a BVH with spatial splits #12

Open TomClabault opened 4 days ago

TomClabault commented 4 days ago

This was all tested on the Bistro.

With the hiprtBuildFlagBitPreferHighQualityBuild build flags: image.

With the hiprtBuildFlagBitPreferHighQualityBuild | hiprtBuildFlagBitDisableSpatialSplits build flags: image

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?

meistdan commented 2 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.

TomClabault commented 2 days ago

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?

meistdan commented 2 days ago

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).

TomClabault commented 1 day ago

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?

meistdan commented 1 day ago

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.