Compartilhar via

Diferenças encontradas no modelo de associação do Direct3D 11

  • Artigo

Uma das decisões de design main por trás da associação DirectX12 é separá-la de outras tarefas de gerenciamento. Isso coloca alguns requisitos no aplicativo para gerenciar determinados riscos potenciais.

A vantagem main do Modelo de Associação D3D12 é que ele permite que os aplicativos alterem as associações de textura com frequência, sem um enorme custo de desempenho da CPU. Outros benefícios são que os sombreadores têm acesso a um número muito grande de recursos, os sombreadores não precisam saber com antecedência quantos recursos serão associados e que um modelo de associação de recursos unificado pode ser usado independentemente do hardware ou do fluxo de conteúdo dos aplicativos.

Para melhorar o desempenho, o modelo de associação não exige que o sistema acompanhe quais associações um aplicativo solicitou que a GPU use e há uma integração limpo entre associação e listas de comandos de vários threads.

As seções a seguir listam algumas das alterações no modelo de associação de recursos desde D3D11.

Gerenciamento de residência de memória separado da associação

Os aplicativos têm controle explícito sobre quais superfícies precisam estar disponíveis para a GPU usar diretamente (chamada de "residente"). Por outro lado, eles podem aplicar outros estados a recursos, como torná-los explicitamente não residentes ou permitir que o sistema operacional escolha determinadas classes de aplicativos que exigem um volume de memória mínimo. O ponto importante aqui é que o gerenciamento do aplicativo do que é residente é completamente dissociado de como ele dá acesso aos recursos aos sombreadores.

A desacoplamento do gerenciamento de residência do mecanismo para dar aos sombreadores acesso aos recursos reduz o custo do sistema/hardware para renderização, pois o sistema operacional não precisa inspecionar constantemente o estado de associação local para saber o que fazer de residente. Além disso, os sombreadores não precisam mais saber quais superfícies exatas talvez precisem referenciar, desde que todo o conjunto de recursos possivelmente acessíveis tenha sido feito residente com antecedência.

Gerenciamento de tempo de vida do objeto separado da associação

Ao contrário das APIs anteriores, o sistema não controla mais as associações de recursos ao pipeline. Isso usado para permitir que o sistema mantenha ativos os recursos que o aplicativo liberou porque eles ainda são referenciados pelo trabalho de GPU pendente.

Antes de liberar qualquer recurso, como uma textura, os aplicativos agora devem garantir que a GPU tenha concluído a referência a ele. Isso significa que antes que um aplicativo possa liberar com segurança um recurso, a GPU deve ter concluído a execução da lista de comandos referenciando o recurso.

Controle de estado do recurso do driver separado da associação

O sistema não inspeciona mais as associações de recursos para entender quando ocorreram transições de recursos que exigem trabalho adicional de driver ou GPU. Um exemplo comum para muitas GPUs e drivers é ter que saber quando uma superfície faz a transição de ser usada como um RTV (Modo de Exibição de Destino de Renderização) para o SRV (Modo de Exibição de Recurso de Sombreador). Os próprios aplicativos agora devem identificar quando as transições de recursos com as quais o sistema pode se preocupar estão acontecendo por meio de APIs dedicadas.

Sincronização de memória mapeada da GPU da CPU separada da associação

O sistema não inspeciona mais as associações de recursos para entender se a renderização precisa ser atrasada porque depende de um recurso que foi mapeado para acesso à CPU, mas ainda não foi mapeado. Os aplicativos agora têm a responsabilidade de sincronizar acessos de memória de CPU e GPU. Para ajudar com isso, o sistema fornece mecanismos para o aplicativo solicitar o suspensão de um thread de CPU até que o trabalho seja concluído. A sondagem também pode ser feita, mas pode ser menos eficiente.

Associação de Recursos