Hi Jason, this is really cool! Very happy to see that support for ray tracing is in the works!
Iago On Wed, 2020-10-28 at 17:26 -0500, Jason Ekstrand 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 > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
