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

[Jason Ekstrand]

Quick clarification about VK_NV_ray_tracing:  I have no intention of
supporting VK_NV_ray_tracing in ANV.  If new games want cross-vendor
ray-tracing, they should use the KHR extension.  However, there are
some games which have already shipped which I'm sure Linux gamers
would like to be able to play with the shiney new features.  I'd like
to support them somehow but it likely won't be directly in the driver.
Making a layer sounds like a fantastic GSOC project.

--Jason

On Wed, Oct 28, 2020 at 5:26 PM Jason Ekstrand <jason at jlekstrand.net> wrote:
>
> 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