Diferenças em relação ao DXR no Windows
Ao criar uma assinatura raiz global, um sinalizador extra deve ser definido na descrição da assinatura raiz: D3D12XBOX_ROOT_SIGNATURE_FLAG_RAYTRACING. Atualmente, esse sinalizador não pode ser definido em uma assinatura raiz especificada em HLSL (linguagem de sombreador de alto nível) e deve ser definido no código antes que a assinatura raiz seja serializada. O XDXR não oferece suporte total à funcionalidade RayQuery.TraceRayInline() do DXR 1.1; no entanto, fornecemos um arquivo de cabeçalho (XDXRStandaloneTraverse) que imita a API RayQuery e deve permitir uma experiência de portabilidade muito simples para a maior parte do código de RayQuery. As diferenças específicas são indicadas em XDXR Standalone Traverse. Atualmente, o XDXR não oferece suporte aRAY_FLAG_SKIP_TRIANGLES, RAY_FLAG_SKIP_PROCEDURAL_PRIMITIVES nem ao sistema D3D12_RAYTRACING_PIPELINE_FLAGS. Isso poderá ser revisado no futuro. Atualmente, builds de TLAS em lote podem ser extremamente rápidos no XBOX e, nesse caso, construir TLASes separadas proporcionará melhor desempenho de travessia do que pular os nós.
O XDXR oferece suporte a várias extensões para consultar o estado diretamente da BVH ou da travessia, sem a necessidade de usar dados de payload para armazenamento.
Para usar essas extensões, declare antecipadamente uma ou mais das seguintes funções no início do seu sombreador de raytracing.
Design do XDXR
Em alto nível, a implementação do XDXR pode ser considerada dividida em duas partes: um núcleo de travessia e o “agendador”.Núcleos de travessia
Um núcleo de travessia é a implementação de travessia da hierarquia de volumes delimitadores (BVH) do XDXR. Sua responsabilidade é tratar a travessia e decisões de alto nível, como quais sombreadores (por exemplo, closest-hit e any-hit) chamar. Ele não lida com a mecânica real de chamar o sombreador. Essa é a responsabilidade do agendador. O XDXR usa uma representação BVH4 para armazenar suas estruturas de aceleração. Embora outros formatos de BVH pudessem ter sido escolhidos, esse formato corresponde àquele para o qual o XBOX Series X|S tem hardware personalizado para realizar testes de interseção entre raio e caixa delimitadora alinhada aos eixos (AABB). Para obter mais detalhes, confira Design de hardware de raytracing.Travessia
Atualmente, o XDXR não implementa nenhuma forma de reempacotamento, classificação ou reordenação de raios. A partir do momento em que um sombreador de geração de raios é invocado, qualquer thread que não esteja rastreando ativamente um raio é uma “lane inativa” na wave e está desperdiçando oportunidades de fazer trabalho útil. Conceitualmente, um raio é gerado em uma determinada thread. Quaisquer invocações subsequentes de sombreadores ou raios recursivos residem nessa mesma thread. Se um sombreador de geração de raios gerar dois raios na lane 0 e nenhum raio em todas as outras lanes de uma wave, a thread 0 precisará concluir sequencialmente seus dois raios enquanto todas as outras threads permanecem inativas. Atualmente, o XDXR expõe dois algoritmos para travessia de BVH. O algoritmo padrão é chamado de travessia “Divergent” e é a solução mais genérica, boa para cargas de trabalho divergentes, como reflexos brilhantes. ParaTraceRayInline(), o cabeçalho equivalente é XDXRStandaloneTraverseShortStack.hlsli. Para cargas de trabalho altamente coerentes, como raios de sombra ou reflexos não brilhantes, o GDK de junho de 2022 fornece um novo algoritmo de travessia “Hybrid”. Esse algoritmo realiza a travessia da TLAS usando ramificação escalar, divergindo apenas ao entrar em uma BLAS. A travessia “Hybrid” pode proporcionar um desempenho significativamente melhor em alguns conteúdos e cargas de trabalho de raytracing.
Para habilitar a travessia “Hybrid”, adicione XBOX_RAY_FLAG_COHERENT_RAYS_HINT aos sinalizadores de raio de TraceRay() do DXR 1.0. Os sinalizadores de raio e o ponteiro da TLAS devem ser uniformes para habilitar esse tipo de travessia. Para TraceRayInline(), o cabeçalho equivalente é XDXRStandaloneTraverseHT.hlsli.
