Does optixAccelComputeMemoryUsage require vertex/index buffer pointers to be filled?

Gaming and Visualization Technologies Visualization OptiX
1

Hi,

I have a question about optixAccelComputeMemoryUsage that if it requires vertex/index buffer pointers of each build input to be filled or not.

I was trying to build a GAS consisting of 381 build inputs, where all of them shares the same vertex buffer, but with different triangle index buffers.

optixAccelComputeMemoryUsage return sizes without any errors regardless I fill the buffer pointers or not.
However, returned BVH and scratch buffer size are significantly different.

When I fill the pointers, BVH and scratch buffer sizes are
18500736, 15047168 bytes respectively, these seem reasonable values for the mesh I used (180,000 vertices and 260,000 triangles).
When I left the pointers nullptr, the sizes are
1575358976, 1280395264 bytes!! (In this case OptiX can’t recognize that the inputs shares the same vertex buffer)

The document notes something that seems related:

Note that optixAccelComputeMemoryUsage does not initiate any activity on the device, and pointers to device memory or contents of input buffers are not required to point to allocated memory.

However I’m not sure this is the answer for me and the behavior actually changes.

Does optixAccelComputeMemoryUsage requires the pointers to be filled? Or at least does it change the behavior?

Thanks,

2

I forgot to note my environment:
Windows 10, 1909
Geforce RTX 2070
Driver 445.87

3

That would be easier to answer if you simply post the code which sets up the OptixBuildInput and calls optixAccelComputeMemoryUsage() for the succeeding and failing case.

Or is that reproducible by changing one of the OptiX SDK examples?

OptiX doesn’t need the pointers themselves, but requires the data around that indicating at least the type and number of primitives per build input.
I’m not sure if it actually needs the other fields like data formats and strides as well at that time. Never tried.

I think there was an issue with having some pointer set to null in the past where it complains about exactly that, which could be worked around by just providing the required alignment value as dummy pointer instead, but that’s probably fixed in currently released drivers already.

For OptiX 7 work I would recommend to keep using R440 drivers and then switch to R450 once those get released.