Support for VK_KHR_ray_tracing_pipeline

[Ivan-Kudryavtsev]

I'm interested in contributing towards adding support for VK_KHR_ray_tracing_pipeline, but I don't 100% understand what would be required to make this happen.

VK_KHR_acceleration_structure is already supported, and it's obvious that a RayTracingPipeline struct would be required.
Would anyone be able to advise what other work would need to be done for pipelined ray-tracing support?

Many thanks!

[Rua]

This is something I've been thinking about as well. My current plan is to split this into two separate PRs, each of which implements a subset of the features. First, implement the RayTracingPipeline type and its vkGetRayTracing* methods. Then, in the next PR, implement all the command buffer commands.

Of course, the ray tracing pipeline object is useless without any commands to use it. Splitting the PRs is only to make the problem a bit more manageable, so that the additions are more self-contained and easier to check and test. Divide and conquer, in other words. It also means that the whole thing doesn't have to be added by one person, the work can be divided too.

[Ivan-Kudryavtsev]

That sounds very sensible to me.

To clarify - the vkGetRayTracing* methods are these?

• vkGetRayTracingShaderGroupStackSizeKHR
• vkGetRayTracingShaderGroupHandlesKHR
• vkGetRayTracingCaptureReplayShaderGroupHandlesKHR

I've done a bit more digging - I'm not clear on if the AccelerationStructure is suitable for use at the moment - indeed, in coverage it says "Host acceleration structure operations" are not supported but I'm not clear on what that means precisely.

The shader binding table-related items are also a bit esoteric but I think I should be able to get to work on this soon.

[Ivan-Kudryavtsev]

I'm also noticing that the Ash PipelineBindPoint enum does not contain RAY_TRACING_KHR - is this likely to be a problem?

[Rua]

To clarify - the vkGetRayTracing* methods are these?

* `vkGetRayTracingShaderGroupStackSizeKHR`

* `vkGetRayTracingShaderGroupHandlesKHR`

* `vkGetRayTracingCaptureReplayShaderGroupHandlesKHR`

Yes.

indeed, in coverage it says "Host acceleration structure operations" are not supported but I'm not clear on what that means precisely.

The acceleration structure operations come in two forms: the vkCmd* prefixed ones, which are recorded onto command buffers and then executed on the device, and the vk* prefixed ones, which are executed by the host rather than device. The latter kind is not very well supported by Vulkan drivers, so they were skipped for the moment.

I'm also noticing that the Ash PipelineBindPoint enum does not contain RAY_TRACING_KHR - is this likely to be a problem?

It's listed in the Ash documentation: https://docs.rs/ash/latest/ash/vk/struct.PipelineBindPoint.html. Where were you looking for it?

[Ivan-Kudryavtsev]

Ah thank you, that's my mistake. I was looking in the enums where the graphics and compute enums are defined - slipped my mind it's an extension.

[Ivan-Kudryavtsev]

EDIT: I've just realised it's device features which are distinct from device extensions!

I'm testing creating a pipeline and I've run into a bit of a roadblock with shader compilation:
trying to load a shader module with GL_EXT_ray_tracing : enable is panicking:

called `Result::unwrap()` on an `Err` value: a validation error occurred

Caused by:
    create_info.code: uses the SPIR-V capability `RayTracingKHR`

Requires one of:
    feature `ray_tracing_pipeline`

Vulkan VUIDs:
    VUID-VkShaderModuleCreateInfo-pCode-08742

I'm having some trouble tracking down what kind of "feature" is meant here - khr_ray_tracing_pipeline is enabled on the device. I assume it relates to SPIR-V in some way but I've not been able to track it down.

[Rua]

You're not the first person to be confused about "features", so I'm wondering if naming them "device features" here would help make it clear.

[Ivan-Kudryavtsev]

That seems like a good idea to me.

[Rua]

Yep, someone else just came to the Vulkano discord confused about the same thing! Clearly a rename is in order, haha