Note: ray tracing pipelines are not yet implemented at all, see #6760 for general design.

Metal, unlike DX12 and Vulkan does not have the concept of a ray tracing pipeline. Instead Metal uses ray queries for everything. However, unlike both DX12 and Vulkan's ray query implementations, Metal has the concept of an intersection function table and an intersection function (which is a combination of Vulkan and DX12's any hit and intersection shaders). This would give at least some of the benefits of ray tracing pipelines, but could make other things more difficult. Here is what I think we would need to do if we wanted to implement ray tracing pipelines on Metal.

1. Add a mini name mangler (I don't think anything more complex than sticking the index of the entry point onto each would be required).
2. Be able to combine arenas (maybe, I'm not entirely sure about this).
3. Add extra write functions into naga's Metal backend for combined any hit and intersection shaders and combined ray generation + closest hit + miss shaders.
4. Make the shader binding table an opaque object instead of a buffer.

We might also need these restrictions

1. No textures in any hit & intersection shaders (unless we use metal argument buffers for them, which I have checked).
2. (might already want) Add an extra limit for maximum number of each resource accessed in a ray tracing pipeline (technically it would only have to be per closest hit shader + miss shader(s) + ray generation shaders and per any hit shader + intersection shader, but this is confusing and the other method could also simplify DX12 too).
3. no barriers in any hit or intersection shaders (non uniform control flow may mean we want to ban these anyway).

If we ever want ray tracing pipelines emulated on ray queries some of these points might also be useful, but whether we want that is a separate issue.

These restrictions could be inconvenient, or these additions required could be unpalatable, which is why I'm opening up an issue for this.