Open andrejnau opened 3 years ago
The NV mesh shader versions were designed to be close to the actual hardware implementation. But we will keep it in mind for future extensions.
@andrejnau thanks for pointing this out. We've also heard from the vkd3d team about this. For the NV extensions, we will plan to fix it if/when we promote them to EXT or KHR. Fixing TraceRays would require adding a vkCmdTraceRaysIndirect2, which we aren't likely to get to in the near future. We'll keep track of the request though, and are glad to have any feedback we can get on problems with the current RT API.
@TomOlson my notes say we were going to create internal tracking issues around this but I can't find any - do you know if this was done?
@TomOlson seems VK_KHR_ray_tracing_maintenance1 may fix some if not all RT related issues.. but what about ExecuteIndirect functionality? how far from a EXT or KHR version of VK_NV_device_generated_commands are? VKD3D has merged support for ExecuteIndirect via that NV ext and RADV ships support for a "minimally" VK_NV_device_generated_commands ext with enough features for VKD3D executeIndirect.. maybe open a separate issue asking directly for a VK ext exposing ExecuteIndirect functionality..
EDIT: RADV NV DGC "minimal" support: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17269 I opened similar requests for DGC for VKD3D for ANV and AMDVLK in the meanwhile: https://github.com/GPUOpen-Drivers/AMDVLK/issues/283 https://gitlab.freedesktop.org/mesa/mesa/-/issues/6883
thanks..
Vulkan has the different memory layout for
vkCmdTraceRaysIndirectKHR
/vkCmdDrawMeshTasksIndirectNV
in compare with DirectX 12. Is there a chance that ExecuteIndirect (probably KHR version ofVK_NV_device_generated_commands
) will have the compatible layout?