Virtual texturing: gerenciar residência, feedback e páginas ausentes

Separe o espaço de endereçamento virtual do armazenamento físico

O virtual texturing divide o conteúdo da textura em páginas e mantém na memória física apenas um conjunto de trabalho selecionado. Assim, uma textura lógica grande não precisa ter todas as suas regiões detalhadas residentes ao mesmo tempo. A documentação de tiled resources da Microsoft descreve essa distinção. [1] A implementação ainda precisa de armazenamento, largura de banda de transferência e de uma política que decida o que manter.

Page tables em software e recursos esparsos (sparse) em hardware oferecem opções de implementação diferentes. Verifique o comportamento de recursos e de amostragem suportado pelo caminho escolhido; o termo virtual texture não implica as mesmas garantias em todos os lugares.

Distinga o detalhe solicitado do detalhe disponível

O sampling feedback informa quais regiões da textura e quais níveis de detalhe uma visão deseja. Isso não significa que essas páginas já estejam disponíveis. O design de sampler feedback da Microsoft separa explicitamente a informação de mip desejado do mapa usado para limitar a amostragem ao detalhe residente. [2]

Mantenha um fallback grosseiro válido e direcione para ele as solicitações de detalhe fino que não puderem ser atendidas. Processe o feedback de forma assíncrona, elimine solicitações duplicadas e priorize os uploads. Leve em conta o atraso entre observar a demanda, ler do armazenamento e tornar um upload utilizável. Uma virada brusca da câmera pode revelar regiões que a visão anterior nunca solicitou.

Exemplo prático: reserve o cache antes de contar a demanda

Suponha um cache ilustrativo com 64 slots de página, cada um ocupando 64 KiB. O armazenamento de páginas totaliza 4 MiB. Se 8 slots forem reservados para as páginas de fallback grosseiro obrigatórias, restam 56 para o conjunto de trabalho de detalhe fino atual.

Uma visão que solicite 80 páginas finas distintas não consegue encaixar todas nesses 56 slots. Pelo menos 24 solicitações precisam permanecer no detalhe de fallback, ser adiadas ou ser evitadas por uma política de detalhe mais grosseiro. Fazer todas as páginas solicitadas circularem pelo cache não resolve essa incompatibilidade de capacidade. Esses valores excluem page tables, buffers de feedback, memória de staging e overhead de alocação; são um exemplo de capacidade, não um orçamento de textura medido.

Torne seguras as atualizações de mapeamento e a remoção

Publique o mapeamento na page table somente quando os dados estiverem prontos para os draws que podem usá-lo. Ao reutilizar um slot físico, garanta que trabalho anterior da GPU não possa mais ler o conteúdo antigo. Registre a identidade e a geração da página, para que solicitações ou conclusões atrasadas não atualizem por engano um slot que pertence a outra página.

Visualize separadamente as páginas solicitadas, residentes e em fallback. Teste viagem rápida, teletransportes e movimentos repetidos entre áreas. Inclua as bordas de filtragem e todas as camadas de material na contabilização das páginas físicas. Verifique que o fallback continue utilizável durante cancelamentos e falhas de upload.

Reconheça a pressão em vez de escondê-la

Uma demanda sustentada acima da capacidade do cache provoca remoções e carregamentos repetidos, muitas vezes visíveis como detalhe instável. A documentação de memory pools da Epic descreve esse comportamento e a troca de qualidade ao reduzir o detalhe solicitado. [3] Meça juntos a ocupação, as solicitações não atendidas, a latência de upload e a residência útil. Mais throughput de armazenamento não corrige um orçamento de conjunto de trabalho subdimensionado, e uma resolução virtual maior, por si só, não torna a imagem final mais nítida.

Fontes

• [1] Tiled Resources — Microsoft, documentação do Direct3D.
• [2] Sampler Feedback — Microsoft, especificação do DirectX.
• [3] Virtual Texture Memory Pools — Epic Games, documentação oficial.