<p>If using the new real-time ray tracing functionality is an option for you, it would be worth a try! It might be that getting it to run is less work than porting your CPU data structure into a GPU-compatible format. Furthermore, using the hardware functionality would result in much better performance since BVH traversal (and triangle intersection, if that is relevant to you) are accelerated in hardware.</p>

<p>Official real-time ray tracing support has been announced by Khronos (in the form of an <code>KHR</code> extension) lately, see <a href="https://www.khronos.org/blog/ray-tracing-in-vulkan" rel="nofollow noreferrer">Ray Tracing In Vulkan</a>. With the Vulkan API version 1.2, the option for "Ray Queries" has been added. It could be relevant for your use case since it allows to trace rays against the BVH from arbitrary shaders (i.e., e.g., also from compute shaders or fragment shaders).</p>

<p>Using <a href="https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_ray_tracing.html" rel="nofollow noreferrer">VK_KHR_ray_tracing</a> (or NVIDIA's precursor <a href="https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_NV_ray_tracing.html" rel="nofollow noreferrer">VK_NV_ray_tracing</a>), you would have to update the acceleration structure on the GPU every time after you have updated your CPU data structure. The API supports updating acceleration structures every frame. In NVIDIA's extension this is done via the <code>VkBool32 update</code> flag in <a href="https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkCmdBuildAccelerationStructureNV.html" rel="nofollow noreferrer"><code>vkCmdBuildAccelerationStructureNV</code></a>. In the KHR-extension it is handled a bit differently, but in a very similar fashion: The update-flags are contained in the <a href="https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkAccelerationStructureBuildGeometryInfoKHR.html" rel="nofollow noreferrer"><code>VkAccelerationStructureBuildGeometryInfoKHR</code></a> structures.</p>

CC BY-SA 4.0
2020-04-24T09:55:51.670Z
Would this also work on non-rtx cards that nevertheless have compute capability? And AMD cards?
AnnoyinC
CC BY-SA 4.0
2020-04-24T10:34:18.587Z
I think that's one of the points of `VK_KHR_ray_tracing`: that it will be supported by a variety of cards in the future (this is why it is a `KHR`-type extension). The extension does not demand RTX cores to be available in a GPU. And in fact, there are GPUs without RTX cores that support it as of now --- however, all of them are from NVIDIA (Pascal, Volta, and Turing) if the data on [gpuinfo.org](https://vulkan.gpuinfo.org/listdevicescoverage.php?extension=VK_KHR_ray_tracing&platform=windows) is up to date.
j00hi
CC BY-SA 4.0
2020-04-05T11:48:21.053Z
2020-04-11T07:40:33.940Z
2020-04-11T07:40:33.940Z
j00hi
<p>I want to use Vulkan's rasterization to solve for the visibility problem, but once that is done I want to do shading, reflection and transmission through a raytracer which also runs on the GPU. With a lot of geometry however it's pretty much a need to have some sort of binary partition tree. How can I have C++ and the vulkan shader language communicate this tree? I thought about pushing the tree into GPU memory wrapped in a buffer, but then of course pointers to the left and right bounding box node (it's a binary tree) wouldn't translate.</p>

<p>It seems my only option is to pass an array of bounding boxes, then pass a tree which just keeps indexes of this array instead of absolute pointers, but that really seems like a botch, because I'll need to traverse the entire tree to assemble the linear array and convert the pointers to indexes of that array.</p>

<p>I would also need to keep in mind how the compiler packs structs (and thus how I read them in the shader). For now I won't even consider that certain datatypes of certain sizes may not even exist on some gpus to keep my head from exploding.</p>

<p>Since generating a bsp tree is badly parallelizable I'm not considering doing it on the gpu.</p>

<p>Edit: the objects will also be interacting physically so I need to have a tree available for the CPU as well. I can't just keep all of the geometry on the GPU from the get go.</p>

<raytracing><c++><vulkan>
Feeding acceleration structure to the GPU then raytracing it in a compute shader?
AnnoyinC
# Feeding acceleration structure to the GPU then raytracing it in a compute shader?

(Asked by: username_0 on 2020-04-04)

I want to use Vulkan's rasterization to solve for the visibility problem, but once that is done I want to do shading, reflection and transmission through a raytracer which also runs on the GPU. With a lot of geometry however it's pretty much a need to have some sort of binary partition tree. How can I have C++ and the vulkan shader language communicate this tree? I thought about pushing the tree into GPU memory wrapped in a buffer, but then of course pointers to the left and right bounding box node (it's a binary tree) wouldn't translate.

It seems my only option is to pass an array of bounding boxes, then pass a tree which just keeps indexes of this array instead of absolute pointers, but that really seems like a botch, because I'll need to traverse the entire tree to assemble the linear array and convert the pointers to indexes of that array.

I would also need to keep in mind how the compiler packs structs (and thus how I read them in the shader). For now I won't even consider that certain datatypes of certain sizes may not even exist on some gpus to keep my head from exploding.

Since generating a bsp tree is badly parallelizable I'm not considering doing it on the gpu.

Edit: the objects will also be interacting physically so I need to have a tree available for the CPU as well. I can't just keep all of the geometry on the GPU from the get go.

**Tags:** raytracing, c++, vulkan


---

## 1 answers

### Answer by username_1 on 2020-04-05. Score: 2

If using the new real-time ray tracing functionality is an option for you, it would be worth a try! It might be that getting it to run is less work than porting your CPU data structure into a GPU-compatible format. Furthermore, using the hardware functionality would result in much better performance since BVH traversal (and triangle intersection, if that is relevant to you) are accelerated in hardware.

Official real-time ray tracing support has been announced by Khronos (in the form of an `KHR` extension) lately, see [Ray Tracing In Vulkan](https://www.khronos.org/blog/ray-tracing-in-vulkan). With the Vulkan API version 1.2, the option for "Ray Queries" has been added. It could be relevant for your use case since it allows to trace rays against the BVH from arbitrary shaders (i.e., e.g., also from compute shaders or fragment shaders).

Using [VK\_KHR\_ray\_tracing](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_KHR_ray_tracing.html) (or NVIDIA's precursor [VK\_NV\_ray\_tracing](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VK_NV_ray_tracing.html)), you would have to update the acceleration structure on the GPU every time after you have updated your CPU data structure. The API supports updating acceleration structures every frame. In NVIDIA's extension this is done via the `VkBool32 update` flag in [`vkCmdBuildAccelerationStructureNV`](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/vkCmdBuildAccelerationStructureNV.html). In the KHR-extension it is handled a bit differently, but in a very similar fashion: The update-flags are contained in the [`VkAccelerationStructureBuildGeometryInfoKHR`](https://www.khronos.org/registry/vulkan/specs/1.2-extensions/man/html/VkAccelerationStructureBuildGeometryInfoKHR.html) structures.

> **Comments:**
> **username_0**: Would this also work on non-rtx cards that nevertheless have compute capability? And AMD cards?  
> **username_1**: I think that's one of the points of `VK_KHR_ray_tracing`: that it will be supported by a variety of cards in the future (this is why it is a `KHR`-type extension). The extension does not demand RTX cores to be available in a GPU. And in fact, there are GPUs without RTX cores that support it as of now --- however, all of them are from NVIDIA (Pascal, Volta, and Turing) if the data on [gpuinfo.org](https://vulkan.gpuinfo.org/listdevicescoverage.php?extension=VK_KHR_ray_tracing&platform=windows) is up to date.  

---

