That is not really “sharing” since each device has its own copy afterwards, but yes, that is exactly one use case.
This check is also exactly what I’m doing in the two code lines I posted above, just that I don’t copy and relocate the GAS because I share it across the NVLINK bridge. In all other cases I simply build the GAS on each device.
So if you take an
OptixAccelRelocationInfo from a GAS on device A and if
optixAccelCheckRelocationCompatibility with that on device B passes, you can copy the data from A to B (pointer needs to be aligned to
OPTIX_ACCEL_BUFFER_BYTE_ALIGNMENT), and because that resides at a different 64-bit address afterwards, you need to call
optixAccelRelocate on device B with the
OptixAccelRelocationInfo from A and the new CUdeviceptr to be able to use the copied GAS on device B with the new returned traversable handle.
Mind that this relocation always must be done if you copy the AS somewhere else than it had been built to initially, even on the same GPU.
Check the API reference on the optixAccelRelocate call which explains that:
In the end this all works because these are just 64-bit CUdeviceptr and the CUDA allocations are all distinct because of the Unified Virtual Address (UVA) space under 64-bit systems.
The question is if this is worth it. The GAS are built on the GPU and you could also build the AS in parallel on both devices and have the same result. Just saying.