Why are traversal shaders required? Doesn't inline ray tracing do the same?
No, easy to confuse but big difference.
Inline tracing means to trace from any shader stage, including compute. This has some advantages, e.g. parallel processing of results. But it also prevents potential future HW like reordering to shuffle rays for better coherency.
ImgTec RT GPU already has such coherency engine. This tells us that inline tracing probably becomes secondary at some time. DXR 1.0 ray generation shaders could support such reordering with very little changes. Thus 1.1 feels more like a temporary need.
Traversal shaders means programmable traversal, which would allow things like stochastic LOD. It is listed as optional future DXR feature, so i guessed ther might be HW support on RDNA2 (or Ampere).
Maybe there is such support (AMDs TMU patent would have allowed this), but it turned out too costly to be practical yet. IDK, just speculating, maybe Intel has it then...
Inline ray tracing effectively means using uber shaders (though specialised for inline ray tracing, not necessarily for all pixel shading). I remember that uber shaders were once considered evil. I'm not sure if they still leave a bad taste in the mouth for most developers.
To me, using thousands of shader permutations and switching them for just a few pixels is just as evil. Main downside of Uber shader is wasting registers that are not used most of the time, but cause a constant drop in occupancy.
That's a problem, but we can mix until we get the best of both, until GPUs become flexible enough to do stuff like dynamic register (or memory) allocation, if this ever happens.
What does that mean?
What customisations are missing from the current BVH build capabilities? Are you thinking of something that's neither defined as a primitive nor as a triangle-mesh based acceleration structure?
It sounds like you have ideas for DXR 2.0. Have you seen discussion of these ideas?
Yeah, i have some ideas. But it's difficult to get there on PC because of multiple vendors / different GPU generations.
It's all about BVH, but each vendor is free to figure out what works best for them, and the programmer does not even know what they use.
Still, we have those problems, some are technically solvable right now on any HW:
Streaming BVH means: We have huge open worlds, but we can not stream the BVH for that from disk. Instead we have to stream geometry, build BVH on CPU and upload. That's very expensive but a waste, and we have to do it during gameplay.
For a solution it could work to generate some BVH during install / startup, save to disk, and stream next time. This way each vendor can keep his format and future HW has no problem.
That's doable and i wonder why we do not have this already.
Custom BVH: We might already have a hierarchy for our game worlds, and we could use this to build the BVH faster / better than the driver which knows nothing but the triangles.
But to do this we would need an entire API for BVH build, and it's difficult to design this so it works fer every data structure that might come up in future HW. Vendors might prefer to keep it secret, and probably the feature would not be so widely used yet.
It would be very interesting to extend this to combine progressive mesh ideas with progressive BVH to support dynamic geometry and LOD. Currently, RT is pretty static.
BVH access beyond RT: It would be cool if we could use BVH for other things like region or proximity queries, e.g. for physics. Currently the only way to access BVH is to shoot rays around. Even if there is no HW for region query, the BVH data is there but sadly it's black boxed.
