|
|
This entire documentation assumes a BVH with 32-bit node pointers as that seems to be the most useful for graphics for now. It has not been tested yet if the format is different with the 64-bit node_pointer instruction. It would be very tight to change anything though.
|
|
|
|
|
|
## BVH Intersection instruction (BVH32 A16=0)
|
|
|
|
|
|
| input VGPR | field | description |
|
... | ... | @@ -50,6 +48,15 @@ Box result: |
|
|
|
|
|
(if box sorting is enabled these fields can be returned out of order)
|
|
|
|
|
|
## BVH64
|
|
|
|
|
|
With BVH64, the first argument is extended to 64-bits, allowing for a 42-bit node id ( + the same3 bits node type). The format of the nodes itself and the return values are unchanged so if you need general full 64-bit node ids you need to use some extra memory to store the high bits.
|
|
|
|
|
|
Note that the GPU has 48-bit addressing and the node memory offset is 64 times the node id, so if the descriptor address is zero and the size is the maximum the entire memory space can be addressed with BVH64.
|
|
|
|
|
|
This is very useful for Vulkan/DXR where you can have multiple acceleration structures in top level and bottom level acceleration structures where you want to avoid having to use a different descriptor for each BLAS due to the implied divergence.
|
|
|
|
|
|
|
|
|
## Triangle Node
|
|
|
|
|
|
A triangle node is a BVH node containing triangle data. I have only figured out the encoding for 1 triangle per node, but there are hints that 4 triangles per node are supported.
|
... | ... | |