[Mesa-dev] Landing ray-tracing support in ANV

[Jason Ekstrand]

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