Construtor offline
O XDXR permite que BVHs sejam construídas offline, opcionalmente compactadas e carregadas do disco em runtime. Isso pode produzir BVHs de maior qualidade para um melhor desempenho de travessia e requer muito menos tempo de GPU em comparação com o construtor de runtime. Atualmente, o construtor de BVH offline oferece suporte apenas a builds de BLAS, incluindo BLASes atualizáveis e BLASes estáticas. Espera-se que um jogo típico construa a maioria das BLASes offline e execute apenas builds de TLAS e atualizações de BLAS durante um quadro em runtime. O construtor offline pode realizar a divisão de triângulos para evitar os custos de triângulos longos, finos e inclinados, que podem ter caixas delimitadoras significativamente maiores do que sua área de superfície. Além disso, ele pode realizar uma melhor “quadificação” de triângulos nos nós folha; consulte a seção “Quads” abaixo. Consulte o exemplo OfflineRT para obter informações sobre como construir BVHs offline, bem como sobre serialização, desserialização e compactação de BVHs offline. Além disso, consulte a página Compactação de BVH do XDXR para obter mais detalhes. Observe que as BVHs construídas offline são válidas apenas para a versão do GDK com a qual foram construídas. As BVHs precisarão ser reconstruídas após a atualização de versões do GDK.Builds em lote
O XDXR oferece suporte a builds de BVH “em lote”. Construir ou atualizar várias BVHs em paralelo pode ser de 10 a 25 vezes mais rápido do que fazê-lo sequencialmente. Consulte BuildRaytracingAccelerationStructureBatched2X. Além disso, considere usar computação assíncrona para sobrepor os builds de BVH a cargas de trabalho como sombras. Talvez seja possível compensar todo o custo do build ou habilitar opções adicionais de qualidade de build para uma travessia mais rápida.FP16
O teste de interseção de BVH da RDNA2 oferece suporte a dois tipos de nós AABB: variedades de float de 32 bits e de 16 bits. Os nós de caixa FP16 só podem ser usados quando as extensões da AABB estiverem dentro do intervalo representável por FP16. Para permitir mais oportunidades de economia de memória, a geometria pode ser redimensionada por potências de dois para caber no intervalo de FP16. Esse recurso pode ser habilitado comD3D12_RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_MINIMIZE_MEMORY. Embora as caixas FP16 sejam menores, elas podem degradar o desempenho da travessia, pois a precisão é reduzida, fazendo com que as AABBs se inflem. Uma heurística de inflação de caixas é usada para determinar quando a inflação é aceitável. Para substituir a heurística padrão, especifique D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS1:: FP16BoxInflationThreshold. Um valor maior que 10.0f forçará todas as AABBs a usar FP16 e reduzirá alocações pessimistas de BVH. Um valor menor que 1.0f forçará todas as AABBs a usar FP32. Isso também pode ser obtido especificando D3D12_RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_PREFER_FAST_TRACE e não D3D12_RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_MINIMIZE_MEMORY.
TAPU
O XDXR compartilha as mesmas práticas recomendadas de desempenho e armadilhas da maioria dos outros construtores de BVH de dois níveis (TLAS + BLAS). Uma área de preocupação comum são caixas delimitadoras de BLAS grandes, cheias de espaço vazio ou com muita interseção com outras instâncias de BLAS. Se duas instâncias tiverem caixas delimitadoras que se cruzam, talvez seja impossível para a travessia determinar a posição de acerto mais próxima sem percorrer ambas as instâncias. Isso fica ainda pior quando mais instâncias se sobrepõem ou quando a origem do raio está dentro das caixas delimitadoras, caso em que nenhuma ordenação pode ser realizada. Exemplos de objetos particularmente ruins são coisas como fios de energia pendurados, que provavelmente têm caixas delimitadoras muito grandes em comparação com o volume da malha original e tendem a cobrir grandes áreas da cena. Outro exemplo é quando vários objetos pequenos são combinados em uma única BLAS: os limites serão estendidos para conter cada malha, mas provavelmente haverá grandes áreas de espaço vazio entre elas. Às vezes, a solução mais adequada para esses problemas é dividir ou combinar objetos durante as fases de criação ou edição de conteúdo. No entanto, isso pode ser difícil ou impossível ao adicionar efeitos de ray tracing a títulos existentes ou em etapas posteriores do pipeline de criação do jogo. Para permitir algum grau de controle nesse caso, o XDXR implementa a opção “TAPU” (TLAS-Pull-Up) em nosso construtor de BVH. Isso permite que o usuário marque instâncias individuais como exigindo “pull-up” para a TLAS. Ao especificar o flagD3D12XBOX_RAYTRACING_INSTANCE_FLAG_TAPU4 ou D3D12XBOX_RAYTRACING_INSTANCE_FLAG_TAPU16 em uma desc de instância, o construtor fará o “pull-up” do primeiro (TAPU4) ou do segundo (TAPU16) nível da hierarquia da BLAS diretamente para a TLAS. Isso permite efetivamente dividir uma instância de BLAS grande em 4 ou 16 nós, que podem ser particionados de forma mais eficaz na hierarquia da TLAS, removendo áreas de espaço vazio.
Para obter informações sobre “Instance Splitting” ou “Rebraiding”, que é uma versão automatizada do TAPU, consulte D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS3.
Além de especificar o flag TAPU, nós extras devem ser alocados na TLAS. Veja um exemplo de código a seguir.
Opções e flags de build
Além de oferecer suporte aos flags normais do construtor DXR, comoD3D12_RAYTRACING_ACCELERATION_STRUCTURE_BUILD_FLAG_PREFER_FAST_TRACE, o XDXR oferece uma API para especificar opções adicionais aos construtores de BVH.
Consulte D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS1, D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS2, D3D12XBOX_BUILD_RAYTRACING_ACCELERATION_STRUCTURE_PARAMS3.
Pode ser vantajoso trocar tempo de build da TLAS por desempenho de travessia, especialmente se o build da TLAS puder ser executado em computação assíncrona. Consulte o Exemplo 1 na seção Comentários de BuildRaytracingAccelerationStructureBatched2X para ver um exemplo de código que aumenta o número de iterações de treelets durante o build da TLAS. Isso pode melhorar significativamente o desempenho da travessia, ao custo de tempos de build da TLAS muito mais longos.
