0
$\begingroup$

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.

$\endgroup$
2
$\begingroup$

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. 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 (or NVIDIA's precursor VK_NV_ray_tracing), 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. In the KHR-extension it is handled a bit differently, but in a very similar fashion: The update-flags are contained in the VkAccelerationStructureBuildGeometryInfoKHR structures.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Would this also work on non-rtx cards that nevertheless have compute capability? And AMD cards? $\endgroup$ – AnnoyinC Apr 24 at 9:55
  • $\begingroup$ 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 is up to date. $\endgroup$ – j00hi Apr 24 at 10:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.