All, Some of you may be curious about what I've been up to for most of 2020, why I've not been working on IBC, and why I suddenly decided to start caring about ray-tracing. Well... it's all because I've been working on this little project to implement VK_KHR_ray_tracing in ANV. I finally have the approval to start talking publicly about the Intel ray-tracing implementation and can start landing code upstream.
To kick things off, I've posted a merge request which contains the bulk of the compiler work required to transform ray-tracing shaders into Intel's upcoming bindless dispatch model and compile them: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7356 This is only the first of what will likely be many MRs. I've also created a tracking issue which will be used to help link it all together and keep me sane. You can find it here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3709 Apart from the core ray-tracing compiler bits, my next focus for upstream will be landing more OpenCL support patches. In order to do GPU-side BVH building, I've got a pile of kernels written in OpenCL C that we need to be able to compile with our stack. In order for those to work, we need a few more things: - Generic pointer support (!6332) - SPV_INTEL_subgroups (!7145) - ANV support for compiling and dispatching OpenCL kernels (coming soon) - Misc NIR clean-ups and fixes. The API bits for ray-tracing will be coming later. I've got most of the API implemented but it's currently all written against the latest version of the KHR ray-tracing spec which hasn't been released publicly. Once that spec goes public, I can start dropping patches. If the public KHR gets delayed too long and I run out of other bits to upstream, I may rebase the API bits on the provisional KHR from January or even the NV spec but I'd really rather not do that as it'd be a pile of churn in my internal branch for very little benefit. LAQ (Likely Asked Questions): Q: Do the patches work? Have you tested them? A: Yes. Don't worry, I'm not sending a bunch of untested garbage. Out of several thousand CTS tests, I've got 3 that are failing due to undiagnosed compiler bugs. I'd say that's pretty good. :-) Q: Will this work on older Intel GPUs? A: No. While a pure SW emulation on top of compute shaders would be possible, this is not it. This implementation requires new Xe HPG hardware that has not yet been released. Q: Which upcoming Intel GPUs will support ray-tracing and when can I buy one? A: We’ve previously disclosed plans to release Xe HPG GPUs with dedicated hardware for ray tracing in 2021. I’m not authorized to tell you more. Sorry. Please don't ask. It just makes for an awkward conversation. Q: Most of the new compiler code is in src/intel. Can it be generalized for implementing ray-tracing in RADV or other Mesa Vulkan drivers? A: Yes, likely some of it can. In particular, there is a shader splitting pass (for splitting shader calls into continuations) as well as a pass to inline any-hit shaders into intersection shaders. With a little work, both of those could be generalized and pulled into src/compiler/nir. The rest is mostly lowering code to translate to Intel's ray-tracing model. Likely other hardware vendors models will be different enough that those passes won't be directly applicable. Q: What about games that have already shipped ray-tracing support using VK_NV_ray_tracing? Will you support those? A: I would eventually like to support any Vulkan games that support ray-tracing. However, it's still a bit TBD just how we'll deal with games that use the NV extension. Ideally, once VK_KHR_ray_tracing ships publicly, we would convince the game vendors who have already shipped ray-tracing support to push an update that switches their game over to the KHR extension. If that fails, it would be pretty easy to write a layer which translates from the NV extension to the KHR one. That's all for now, folks! I'll be on IRC and e-mail if you have any questions. I'd love to get some outside review on the compiler patches if I could. The shader splitting pass, in particular, is a bit on the gnarley side. --Jason _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
