Compactação de mapas MIP
Dependendo do suporte à camada de recursos lado a lado, os mipmaps com determinadas dimensões não seguem as formas de bloco padrão e são considerados todos empacotados uns com os outros de uma maneira opaca ao aplicativo. Níveis mais altos de suporte têm garantia mais ampla sobre quais tipos de dimensões de superfície se encaixam nas formas de bloco padrão (e, portanto, podem ser mapeados individualmente por apps).
O que pode variar entre implementações é que, considerando as dimensões, o formato, o número de mipmaps e as fatias de matriz de um recurso lado a lado, alguns M de mips (por fatia de matriz) podem ser empacotados em alguns blocos N de número. A API ID3D11Device2::GetResourceTiling existe para permitir que o driver relate ao aplicativo o que são M e N (entre outros detalhes sobre a superfície que essa API relata que são padrão e não variam de acordo com o fornecedor de hardware). O conjunto de blocos para mips compactados ainda tem 64 KB e pode ser mapeado individualmente em locais diferentes no pool de blocos. No entanto, a forma de pixel dos blocos e como os mipmaps se encaixam no conjunto de blocos é específico de um fornecedor de hardware e muito complexo para expor. Assim, os apps devem mapear todos os blocos designados como compactados ou nenhum deles simultaneamente. Caso contrário, o comportamento para acessar o recurso lado a lado é indefinido.
Para superfícies dispostas, o conjunto de mips compactado e a quantidade de blocos compactados que armazenam esses mips (M e N descrito acima) se aplica individualmente a cada fatia de matriz.
APIs dedicadas para copiar blocos (ID3D11DeviceContext2::CopyTiles e ID3D11DeviceContext2::UpdateTiles) não podem acessar mips empacotados. Os aplicativos que desejam copiar dados de e para mips empacotados podem fazer isso usando todas as APIs específicas do recurso não lado a lado para copiar e renderizar em superfícies.
Tópicos relacionados