Partilhar via

Diferenças no modelo de vinculação do Direct3D 11

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

A principal vantagem do D3D12 Binding Model é que ele permite que os aplicativos alterem as ligaçõ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 vinculados e que um modelo unificado de vinculação de recursos pode ser usado independentemente do hardware ou do fluxo de conteúdo dos aplicativos.

Para melhorar o desempenho, o modelo de vinculação não exige que o sistema mantenha o controlo sobre quais ligações uma aplicação solicitou que a GPU utilizasse, e há uma integração clara entre a vinculação e as listas de comandos multithread.

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

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

As aplicações têm controlo explícito sobre quais áreas precisam estar disponíveis para a GPU utilizar diretamente (chamado de "residente"). Por outro lado, eles podem aplicar outros estados em recursos, como explicitamente torná-los não residentes, ou deixar o sistema operacional escolher para certas classes de aplicativos que exigem um espaço mínimo de memória. O ponto importante aqui é que a gestão do aplicativo do que está em memória é completamente dissociada de como ele dá acesso a recursos para shaders.

A dissociação do gerenciamento de residência do mecanismo para dar aos sombreadores acesso aos recursos reduz o custo do sistema/hardware para renderização, uma vez que o sistema operacional não precisa inspecionar constantemente o estado de vinculação local para saber o que tornar residente. Além disso, os sombreadores não precisam mais saber quais superfícies exatas será necessário referenciar, desde que todo o conjunto de recursos possivelmente acessíveis tenha sido tornado residente antecipadamente.

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

Ao contrário das APIs anteriores, o sistema não rastreia mais as ligações de recursos ao pipeline. Isso usado para permitir que o sistema mantenha vivos os recursos que o aplicativo lançou porque eles ainda são referenciados pelo excelente trabalho da GPU.

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

Rastreamento do estado do recurso do driver separado da vinculaçã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 passa de ser usada como RTV (Render Target View) para SRV (Shader Resource View). Os próprios aplicativos agora devem identificar quando quaisquer transições de recursos com as quais o sistema possa se preocupar estão acontecendo por meio de APIs dedicadas.

Sincronização de memória mapeada da CPU e GPU separada da ligaçã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 desmapeado. Os aplicativos agora têm a responsabilidade de sincronizar os acessos à memória da CPU e GPU. Para ajudar com isso, o sistema fornece mecanismos para que o aplicativo solicite a suspensão de um thread da CPU até que o trabalho seja concluído. As sondagens também podem ser feitas, mas podem ser menos eficientes.

Vinculação de Recursos

 

 

  • Last updated on