Can SER Group Primary Rays with Identical Origins?

Question

In my application, all rays are generated in the ray generation program. The rays share the same direction, but their origins are randomly distributed, and multiple rays may share the same origin.

This leads to a situation where rays within the same warp often have different origins, while rays in different warps may have identical origins. Ideally, I would like to group rays with similar origins (or traversal patterns) together to improve BVH traversal coherence and reduce irregular memory accesses.

However, I am not entirely clear about the exact behavior of Shader Execution Reordering (SER).

My understanding is that SER performs some form of runtime reordering of shader execution, but it is unclear to me whether this reordering is based on ray properties such as direction or spatial locality.

Given this, I would like to ask:

Does SER reorder ray processing based on ray direction or spatial coherence, or is it purely based on shader execution characteristics (e.g., material, shader program, or SBT index)?

If SER does not perform direction-based ray reordering, is there any built-in hardware mechanism (in Ada or earlier architectures) that performs ray reordering based on direction or spatial locality to improve BVH traversal efficiency, especially for secondary rays?

Or is such direction-based ray grouping expected to be implemented entirely at the software level (e.g., via sorting or binning before ray traversal)?

Hi @Russell_ABC,

SER does take into account some spatial locality of your rays, as described in the Shader Execution Reordering Whitepaper.

Here’s the relevant snippet:

The final key used for reordering is then composed from the following components, in
descending order of priority:

  1. Shader ID stored in the HitObject
  2. Coherence hint, with the most significant hint bit having highest priority
  3. Spatial information stored in the HitObject

The exact mechanism for hashing spatial locality is not defined or guaranteed, and can change across driver and architecture versions.

If you have only one shader and no coherence hint, then your sort key will consist of only spatial information. Depending on which API you’re using, you may be able to write a debug feature to measure the divergence of ray origins in each warp after the reorder, and see how much SER reduces that divergence.

If you have ideas for further reducing that divergence, you can use the coherence hint bits to try to get better groupings, and as you can see the coherence hint bits will take priority over the built-in spatial locality hashing. Just note (as the whitepaper mentions) that you should try to be judicious with your use of the coherence hint bits, and try to minimize how many bits you use. The whitepaper doesn’t put a number on it, but in practice I’ve heard some people say that using more that 8 coherence hint bits might start to reduce the effectiveness of SER.