Geração de alias de memória e herança de dados
O recurso colocado e reservado pode ser um alias de memória física dentro de um heap. Os recursos colocados permitem mais cenários de herança de dados do que os recursos reservados quando o heap tem o sinalizador compartilhado definido ou quando os recursos com alias têm layouts de memória totalmente definidos.
Atribuição de alias
Uma barreira de alias deve ser emitida entre o uso de dois recursos que compartilham a mesma memória física, mesmo que a herança de dados não seja desejada. Modelos de uso simples devem denotar, pelo menos, o recurso de destino envolvido em tal operação. Consulte CreatePlacedResource para obter mais detalhes e modelos de uso avançados.
Depois que um recurso é acessado, todos os recursos que compartilham memória física com esse recurso são invalidados, a menos que a herança de dados seja permitida. Leituras de recursos invalidados resultam em conteúdos de recursos indefinidos. As gravações em recursos invalidados também resultam em conteúdo de recurso indefinido, a menos que ocorram duas condições:
- O recurso não tem D3D12_RESOURCE_FLAG_ALLOW_RENDER_TARGET ou D3D12_RESOURCE_FLAG_ALLOW_DEPTH_STENCIL.
- A gravação é uma operação de cópia ou limpeza de um sub-recurso ou bloco inteiro. A inicialização de blocos só está disponível para recursos com 64KB_TILE_UNDEFINED_SWIZZLE e 64KB_TILE_STANDARD_SWIZZLE.
As invalidações sobrepostas têm como escopo granularidades menores, quando os layouts fornecem informações sobre a localização dos dados texel e quando os recursos estão em determinados estados de barreira de transição. No entanto, as invalidações não podem ser menores do que as granularidades de alinhamento de recursos.
Uma granularidade de alinhamento de buffer é de 64 KB e uma granularidade de alinhamento maior tem precedência. Isso é importante ao considerar texturas de 4 KB, pois várias texturas de 4 KB podem residir em uma região de 64 KB sem se sobreporem. Porém, um buffer com alias da mesma região de 64 KB não pode ser usado em conjunto com nenhuma dessas texturas de 4 KB. O aplicativo não consegue impedir de forma confiável que o acesso ao buffer cruze as texturas de 4 KB, pois as GPUs podem alternar dados de textura de 4 KB dentro da região de 64 KB em um padrão indefinido.
Os layouts de textura 64KB_TILE_UNDEFINED_SWIZZLE, 64KB_TILE_STANDARD_SWIZZLE e ROW_MAJOR informam ao aplicativo quais granularidades de alinhamento sobrepostas se tornaram inválidas. Por exemplo: um aplicativo pode criar uma matriz de textura de destino de renderização 2D com 2 fatias de matriz, um único nível mip e o layout 64KB_TILE_UNDEFINED_SWIZZLE. Suponha que o aplicativo entenda que cada fatia de matriz ocupa 100 blocos de 64 KB. O aplicativo pode deixar de usar a fatia de matriz 0 e reutilizar essa memória para um buffer de ~6 MB, uma textura de ~6 MB com layout indefinido, etc. Indo além, suponha que o aplicativo não precise mais do primeiro bloco da fatia de matriz 1. Em seguida, o aplicativo também pode localizar um buffer de 64 KB até que a renderização exija novamente o primeiro bloco da fatia de matriz 1. O aplicativo teria que limpar ou copiar todo o bloco para reutilizar o primeiro bloco com a matriz de texturas novamente.
No entanto, mesmo texturas com layouts definidos ainda têm casos problemáticos. Os tamanhos dos recursos de textura podem diferir significativamente do que o aplicativo pode calcular, pois algumas arquiteturas de adaptador alocam memória adicional para texturas para reduzir a largura de banda efetiva durante cenários comuns de renderização. Qualquer invalidação nessa região de memória adicional faz com que todo o recurso seja invalidado. Consulte GetResourceAllocationInfo para obter mais detalhes.
Herança de dados
Os recursos colocados permitem a maior herança de dados para texturas, mesmo com layouts de memória indefinidos. Os aplicativos podem imitar os recursos de herança de dados que os recursos comprometidos compartilhados permitem, localizando duas texturas com propriedades de recursos idênticas no mesmo deslocamento em um heap compartilhado. Toda a descrição do recurso deve ser idêntica, incluindo o valor claro otimizado e o tipo de método de criação de recursos (colocado ou reservado). Mas, os dois recursos podem ter tido diferentes estados de barreira de transição inicial.
Recursos reservados permitem herança de dados por bloco, mas geralmente existem restrições para estados de barreira de transição de recursos.
Para herdar dados, os dois recursos devem estar em um estado de barreira de transição de recursos compatível:
- Para buffers, texturas de acesso simultâneo e texturas de adaptador cruzado, o estado de transição de recursos não é importante e todos os estados são “compatíveis”.
- Para texturas reservadas sem as propriedades anteriores ou outra herança de dados por bloco por meio de 64KB_TILE_UNDEFINED_SWIZZLE ou 64KB_TILE_STANDARD_SWIZZLE, o estado da barreira de transição de recursos, incluindo o bloco, deve estar no estado comum.
- Para todas as outras texturas, onde as descrições dos recursos correspondem exatamente, o estado da barreira de transição de recursos para cada par correspondente de sub-recursos deve:
- Estar no estado comum.
- Ser igual quando o estado tiver o mesmo sinalizador de gravação de GPU.
Quando a GPU oferece suporte ao swizzle padrão, os buffers e as texturas do swizzle padrão podem ser atribuídos como alias à mesma memória e herdar dados entre eles. O aplicativo pode manipular texels da representação de buffer, pois o padrão de swizzle padrão descreve como os texels são dispostos na memória. O padrão de swizzle visível para CPU é equivalente ao padrão de swizzle visível para GPU visto em buffers.
Tópicos relacionados