Diferenças gerais
- O Game OS do Microsoft GDK oferece suporte à serialização/desserialização de objetos de estado de pipeline (PSO) para evitar os custos de construção de PSO em runtime no driver. Essa funcionalidade é a mesma que existia na ERA. O Game OS do Microsoft GDK aceitará shaders pré-compilados, shaders não pré-compilados, shaders derivados e PSOs serializados como entradas válidas. Recomendamos o uso de PSOs serializados para obter velocidade, economia de espaço e melhor controle do usuário.
- O XBOX fornece ESRAM, permitindo que buffers e recursos de textura sejam usados na memória mais rápida possível. Maximizar o uso da ESRAM é fundamental para o alto desempenho. Em Gerenciamento de recursos nativos para XBOX One, confira a subseção “Especificando memória ESRAM rápida para um buffer ou textura” e confira Visão geral da memória XG.
- As filas de comandos no Game OS do Microsoft GDK não são thread-safe. É responsabilidade do título sincronizar explicitamente o acesso em threads às filas de comandos de gráficos, computação e cópia/DMA. Não fazer isso pode levar à corrupção dos comandos emitidos na fila e a subsequentes travamentos ou falhas da GPU.
- Somente uma fila de comandos de cada tipo pode ser criada no XBOX, a menos que a extensão CreateCommandQueueX seja usada para selecionar explicitamente um pipe/mecanismo e (para computação) um índice de fila para a fila de comandos. Somente uma única fila de comandos de gráficos pode ser criada, independentemente da API usada. Uma fila de computação ou de cópia/DMA pode ser criada por pipe/mecanismo de GPU e índice de fila disponíveis.
- As barreiras de recursos do Game OS do Microsoft GDK incentivam o uso amplo das transições D3D12_RESOURCE_BARRIER_FLAG_BEGIN_ONLY e D3D12_RESOURCE_BARRIER_FLAG_END_ONLY, e é recomendável especificar sinalizadores D3D12XBOX_RESOURCE_FLAG_PREFER* adicionais na criação de determinados tipos de recursos (confira D3D12_RESOURCE_FLAGS). Confira a seção “Barreiras de recursos” abaixo e D3D12_RESOURCE_BARRIER_FLAGS.
- O Game OS do Microsoft GDK oferece suporte a um modelo de apresentação diferente do sistema de Presents de cadeia de troca do Direct3D 12 no PC. Para saber mais sobre o novo modelo de apresentação, confira Agendamento e apresentação de quadros no XBOX One.
- O Game OS do Microsoft GDK incentiva o acesso a destinos de renderização com várias amostras em um estado compactado para melhorar o desempenho e também incentiva recursos de profundidade/estêncil compactados. Na seção Barreiras de recursos a seguir, confira Trabalhando diretamente com recursos compactados.
- O Game OS do Microsoft GDK oferece suporte a várias extensões de hardware específicas da GPU.
- As extensões do Direct3D 12.x do Game OS do Microsoft GDK fornecem o seguinte:
- Tipos adicionais de heap de descritores
- Manipulação direta de descritores
- Composição de assinaturas raiz e variantes de difusão
- Execução assíncrona de listas de comandos (executar antes de fechar)
- É responsabilidade do título garantir que a GPU tenha concluído todo o acesso a um recurso antes de destruí-lo. Um título deve inserir limites (fences) após a conclusão do acesso ao recurso e aguardar que esses limites sejam ultrapassados antes de reduzir as contagens de referência do objeto de recurso a 0.
- O Game OS do Microsoft GDK não oferece suporte ao uso do tipo de lista de comandos COPY (D3D12_COMMAND_LIST_TYPE_COPY) com a interface padrão ID3D12GraphicsCommandList. Em vez disso, o Game OS do Microsoft GDK fornece uma interface dedicada para cópia (ID3D12XboxDmaCommandList). Essa interface inclui a funcionalidade de cópia padrão de ID3D12GraphicsCommandList, bem como extensões para o hardware do mecanismo DMA do XBOX, como compactação/descompactação LZ e decodificação JPEG. Se você planeja escrever código multiplataforma para listas de comandos de cópia do Direct3D 12, recomendamos usar um
typedefpara a interface da lista de comandos de cópia, que seria definido como ID3D12XboxDmaCommandList no Game OS do Microsoft GDK e como ID3D12GraphicsCommandList no PC.
Drivers de varejo, instrumentados e de depuração
Com o Gaming eXtensions Development Kit (GXDK), três drivers podem ser usados para ajudar a testar e depurar um título. Driver de varejo: otimizado para desempenho, não para instrumentação ou depuração. Não verifica a exatidão dos parâmetros. Parâmetros incorretos passados ao driver de varejo provavelmente causarão corrupção, falhas ou travamentos da GPU. Os títulos só podem ser lançados com o driver de varejo. Os outros drivers (instrumentado e de depuração) estão presentes somente em kits de desenvolvimento. Driver instrumentado: habilita a instrumentação do PIX. Razoavelmente leve. Pode ser usado para ajudar a depurar problemas de sincronização e outros problemas de tempo. Não verifica a exatidão dos parâmetros. Driver de depuração: executa testes de validação nos parâmetros passados às chamadas de API, o que pode ajudar a depurar problemas de exatidão e desempenho. No entanto, bugs de tempo podem não ser reproduzidos ao usar o driver de depuração, porque o processamento da validação afeta o desempenho em runtime. Para ajustar o nível de validação, chame ID3D12Device::SetDebugFlagsX. Para selecionar qual driver é usado, chame um dos métodos a seguir.Objetos de estado de pipeline (PSOs) offline e derivados
Um objeto de estado de pipeline (PSO) offline permite melhorias de desempenho consideráveis em relação à criação do estado de pipeline em runtime, encapsulando o estado de pipeline (incluindo shaders) em um único objeto que pode ser carregado e definido rapidamente. Um PSO offline armazena o estado para shaders pré-compilados, destino de renderização e estêncil de profundidade. Os objetos PSO offline são armazenados em disco e posteriormente carregados pelo aplicativo quando necessário. No PC, existe um sistema semelhante, mas não idêntico, chamado cache de PSO. Para criar objetos PSO offline, use a ferramenta PSO (fornecida como um exemplo do Microsoft Game Development Kit (GDK) localizado na pasta\bin do GXDK) ou escreva sua própria ferramenta que use as APIs de serialização de estado de pipeline, listadas a seguir.
APIs para PSOs offline
As APIs a seguir manipulam PSOs offline.- ID3D12Device::SerializeGraphicsPipelineStateX: este método serializa um PSO como forma de permitir um carregamento eficiente em runtime. Ele deve ser chamado como parte de um processo de criação de conteúdo offline, executado em um PC (com suporte do driver
umd12_pc.dllouxgs12_pc_xs.dll), e não deve ser chamado em runtime de um título. - ID3D12Device::DeserializeGraphicsPipelineStateX: este método desserializa (carrega) um PSO gráfico serializado anteriormente. Este método nunca invoca a compilação de shaders em runtime, embora, em casos raros, invoque um erro informando que PSOs mais antigos precisam ser recompilados.
- D3D12XBOX_SERIALIZE_SHADER: esta struct contém ponteiros para as instruções de GPU do shader serializado e, possivelmente, metadados serializados.
- D3D12XBOX_DESERIALIZE_SHADER: esta struct contém ponteiros para as instruções de GPU brutas do shader desserializado e metadados desserializados.
- D3D12XBOX_SERIALIZE_FLAGS: este enum define sinalizadores de serialização.
- D3D12XBOX_SERIALIZE_GRAPHICS_PIPELINE_STATE: esta struct contém o estado de pipeline serializado.
- D3D12XBOX_DESERIALIZE_GRAPHICS_PIPELINE_STATE: esta struct contém o estado de pipeline desserializado.
PSOs derivados
Considerando o número de alterações de estado de pipeline maior do que um aplicativo provavelmente exige, não faz sentido criar PSOs offline para cada variação. Em vez disso, crie um PSO offline para um estado básico usado com frequência e, em seguida, use PSOs derivados para fazer modificações limitadas no PSO offline. As modificações feitas no PSO offline não podem envolver alterações no shader ou no destino de renderização. Para um jogo típico, a maioria dos objetos PSO deve ser criada offline, com permutações feitas em runtime usando as APIs a seguir.- ID3D12Device::CreateDerivedGraphicsPipelineStateX: este método fornece uma forma eficiente de criar uma variação de um PSO gráfico derivada de um PSO gráfico de origem. Este método garante que nenhuma recompilação ou aplicação de patch de shader seja feita como parte do processo de criação.
- D3D12XBOX_DERIVED_GRAPHICS_STATE_TYPE: este enum identifica o estado que pode ser alterado (profundidade/estêncil, rasterização, mesclagem e máscara de amostra).
- D3D12XBOX_DERIVED_GRAPHICS_STATE_DESC: esta struct contém as descrições do novo estado necessário.
Exemplos que demonstram PSOs offline e PSOs derivados
O exemplo Deferred Context do Direct3D 12.x usa PSOs offline e PSOs derivados. Os exemplos do Direct3D 12.x a seguir usam PSOs offline.- Bokeh Effect
- Compute Particles
- Deferred Particles
- Draw Bundles
- Dynamic Cube Map
- ESRAM
- Mesh Rendering
- Simple Bezier
- Simple Instancing
- Simple Lighting
- Simple Triangle
Heaps de descritores
No PC com Windows, heaps de descritores criados com D3D12_DESCRIPTOR_HEAP_FLAG_SHADER_VISIBLE não podem ser usados como origem para cópias de descritores. No Microsoft Game Development Kit (GDK), as cópias de descritores criadas com ID3D12Device::CopyDescriptors e ID3D12Device::CopyDescriptorsSimple oferecem suporte a todos os heaps de descritores como heap de origem, e a cópia é realizada por meio de uma exibição somente leitura eficiente e armazenada em cache para o heap de origem.Criação de recursos
Os recursos de argumentos indiretos devem especificar D3D12XBOX_RESOURCE_FLAG_ALLOW_INDIRECT_BUFFER no momento da criação do recurso. Os recursos com esse sinalizador devem ser transicionados para o estado de recurso D3D12_RESOURCE_STATE_INDIRECT_ARGUMENT. D3D12_RESOURCE_STATE_INDIRECT_ARGUMENT não está incluído no estado de recurso de combinação D3D12_RESOURCE_STATE_GENERIC_READ no Game OS do Microsoft GDK. No Game OS do Microsoft GDK, D3D12_RESOURCE_STATE_GENERIC_READ é declarado da seguinte maneira:Barreiras de recursos
Uma barreira de recursos notifica o driver de que pode ser necessária a sincronização de vários acessos a um único recurso, como a sincronização de leitura e gravação na mesma textura. A versão do GXDK do Game OS do Microsoft GDK de ID3D12GraphicsCommandList::ResourceBarrier oferece suporte à combinação dos sinalizadores D3D12_RESOURCE_STATE_COPY_SOURCE e D3D12_RESOURCE_STATE_COPY_DEST, para que cópias intrarrecurso sejam suportadas. Cópias intrarrecurso são aquelas em que a origem e o destino estão no mesmo sub-recurso do mesmo recurso.- APIs para barreiras de recursos
- Barreiras de recursos em transições de uso
- Trabalhando diretamente com recursos compactados
- Barreiras para transição entre estados de uso que incluem e não incluem acesso de gravação
APIs para barreiras de recursos
No Game OS do Microsoft GDK, as barreiras de recursos são implementadas chamando os métodos a seguir.- ID3D12GraphicsCommandList::ResourceBarrier. Este método notifica o driver de que ele precisa sincronizar vários acessos a recursos. Este método está documentado em detalhes (para uso no PC) no Microsoft Docs: ID3D12GraphicsCommandList::ResourceBarrier. Os métodos exclusivos do XBOX de ID3D12GraphicsCommandList estão documentados no GDK.
- ID3D12XboxDmaCommandList::ResourceBarrier
Barreiras de recursos em transições de uso
No PC com Windows, as barreiras de recursos podem executar ociosidades conservadoras da GPU e liberação/invalidação de caches. Por outro lado, no Game OS do Microsoft GDK, as barreiras de recursos executam sincronização, invalidação e descompactação conservadoras em transições de uso. Como parte dessa diferença, há sinalizadores de criação de recursos específicos do XBOX recomendados, mas não essenciais.- D3D12XBOX_RESOURCE_FLAG_PREFER_INDEX_BUFFER
- D3D12XBOX_RESOURCE_FLAG_PREFER_INDIRECT_BUFFER
- D3D12XBOX_RESOURCE_FLAG_PREFER_PREDICATION_BUFFER
- D3D12XBOX_RESOURCE_FLAG_PREFER_STREAM_OUTPUT
- D3D12XBOX_RESOURCE_FLAG_DENY_COMPRESSION_DATA
Trabalhando diretamente com recursos compactados
Os tipos de uso de recursos a seguir inibem a descompactação em transições de barreira de recursos e permitem que os recursos sejam consumidos em um estado compactado.- D3D12XBOX_RESOURCE_STATE_PRESERVE_COMPRESSED_COLOR
- D3D12XBOX_RESOURCE_STATE_PRESERVE_COMPRESSED_DEPTH
- D3D12XBOX_RESOURCE_STATE_PRESERVE_COMPRESSED_STENCIL
- D3D12XBOX_RESOURCE_STATE_PRESERVE_COMPRESSED_DEPTH_STENCIL
- D3D12XBOX_RESOURCE_STATE_PRESERVE_INDIRECT_COLOR_CLEAR
- D3D12XBOX_RESOURCE_STATE_PRESERVE_SCATTERED_COLOR_FMASK
- D3D12XBOX_RESOURCE_STATE_PRESERVE_EXPANDED_COLOR
- D3D12XBOX_RESOURCE_STATE_PRESERVE_EXPANDED_DEPTH
- D3D12XBOX_RESOURCE_STATE_PRESERVE_EXPANDED_STENCIL
- D3D12XBOX_RESOURCE_STATE_PRESERVE_EXPANDED_DEPTH_STENCIL
Barreiras para transição entre estados de uso que incluem e não incluem acesso de gravação
No Game OS do Microsoft GDK, a abordagem recomendada para executar transições de barreira, além da abordagem do Direct3D 12/PC, é identificar as barreiras que envolvem a transição de estados de uso que incluem acesso de gravação para estados de uso que não incluem acesso de gravação. Essas barreiras, quando executadas em D3D12_RESOURCE_BARRIER_ALL_SUBRESOURCES, devem ser divididas em uma barreira dividida, com uma chamada BEGIN_ONLY e uma END_ONLY, quando houver trabalho de GPU independente disponível para execução, da seguinte maneira.- D3D12_RESOURCE_BARRIER_FLAG_BEGIN_ONLY é usado para iniciar uma transição de barreira para um novo estado (mas não concluí-la), colocando o recurso em uma condição temporária sem acesso.
- Adicione o trabalho independente à lista de comandos.
- D3D12_RESOURCE_BARRIER_FLAG_END_ONLY é usado em uma chamada ResourceBarrier subsequente para concluir a transição e passar da condição temporária sem acesso e do estado antigo para o acesso ativo no novo estado.
#define para o Direct3D 12.x e o Direct3D 12/PC.
Confira D3D12_RESOURCE_BARRIER_FLAGS.