Compartilhar via

Uso avançado de tabelas de descritor

  • Artigo

As seções a seguir fornecem informações sobre o uso avançado de tabelas de descritor.

Alterando entradas de tabela de descritor entre chamadas de renderização

Após listas de comandos que definem tabelas de descritor terem sido enviadas a uma fila para execução, o aplicativo não deve editar da CPU as partes de heaps de descritor que a GPU pode referenciar até que o aplicativo saiba que a GPU terminou de usar as referências.

A conclusão do trabalho pode ser determinada em um limite apertado usando cercas de API para acompanhar o progresso da GPU ou mecanismos mais grosseiros, como esperar para ver que a renderização foi enviada para exibição - o que se adequa ao aplicativo. Se um aplicativo souber que apenas um subconjunto da região para o qual uma tabela de descritor aponta será acessado (por exemplo, devido ao controle de fluxo no sombreador), os outros descritores não referenciados ainda estarão livres para serem alterados. Se um aplicativo precisar alternar entre diferentes tabelas de descritor entre chamadas de renderização, haverá algumas abordagens que o aplicativo pode escolher:

  • Controle de versão de tabela do descritor: crie (ou reutilize) uma tabela de descritor separada para cada coleção exclusiva de descritores que deve ser referenciada por uma lista de comandos. Ao editar e reutilizar áreas preenchidas anteriormente em heaps de descritor, os aplicativos devem primeiro garantir que a GPU tenha terminado de usar qualquer parte de um heap de descritor que será reciclado.
  • Indexação dinâmica: os aplicativos podem organizar objetos que variam entre desenho/expedição (ou até mesmo variar dentro de um desenho) em um intervalo de um heap de descritor, definir uma tabela de descritor que abrange todos eles e, do sombreador, usar a indexação dinâmica da tabela durante a execução do sombreador para selecionar qual objeto usar.
  • Colocando descritores na assinatura raiz diretamente. Apenas um número muito pequeno de descritores pode ser gerenciado dessa forma porque o espaço de assinatura raiz é limitado.

A implicação do uso do controle de versão de tabela de descritor é que a memória do descritor de um heap de descritor deve ser queimada para cada conjunto exclusivo de descritores referenciados pelo pipeline de gráficos para cada lista de comandos que possam estar executando, enfileirados para execução ou sendo gravados a qualquer momento.

D3D12 deixa a responsabilidade de gerenciar o controle de versão para o aplicativo para os tipos de objeto gerenciados por meio de heaps de descritor e tabelas de descritor. Um benefício disso é que os aplicativos podem optar por reutilizar o conteúdo da tabela de descritor o máximo possível, em vez de sempre definir uma nova versão de tabela de descritor para cada envio de lista de comandos. A assinatura raiz é um espaço que o driver D3D12 versão automaticamente.

A capacidade de associar várias tabelas de descritor à assinatura raiz (e, portanto, ao pipeline) por vez permite que os aplicativos agrupem e alternem conjuntos de referências de descritor em frequências diferentes, se desejado. Por exemplo, um aplicativo pode usar um pequeno número (talvez apenas um) de tabelas de descritor estático grandes que raramente são alteradas ou em quais regiões na memória de heap do descritor subjacente estão sendo preenchidas conforme necessário, com o uso da indexação dinâmica do sombreador para selecionar texturas. Ao mesmo tempo, o aplicativo pode manter outra classe de recursos em que o conjunto referenciado por cada chamada de desenho é alternado da CPU usando a técnica de controle de versão da tabela de descritor.

Indexação fora dos limites

A indexação fora dos limites de qualquer tabela de descritor do sombreador resulta em um acesso de memória em grande parte indefinido, incluindo a possibilidade de ler memória arbitrária em processo como se fosse um descritor de estado de hardware e conviver com a consequência do que o hardware faz com isso. Isso pode produzir uma redefinição de dispositivo, mas não falhará no Windows.

Derivados de sombreador e indexação divergente

Se as invocações de sombreador de pixel que estão sendo executadas em um carimbo 2x2 (para dar suporte a cálculos derivados) escolherem diferentes índices de textura para amostrar de uma tabela de descritor e, se a configuração e textura do sampler selecionado para qualquer pixel específico exigir um cálculo LOD de derivativos de coordenadas de textura, o processo de amostragem de textura e cálculo LOD será feito pelo hardware independentemente para cada pesquisa de textura no carimbo 2x2, que afetará o desempenho.

Tabelas de descritores