Mapeamentos estão em um pool de blocos
Quando um recurso é criado como um recurso de streaming, os blocos que compõem o recurso são provenientes do apontamento para locais em um pool de blocos. Um pool de blocos é um pool de memória (sustentado por uma ou mais alocações nos bastidores - nunca vistos pelo app). O sistema operacional e o driver de exibição gerenciam esse pool de memória e o volume de memória é facilmente compreendido por um aplicativo. Os recursos de streaming mapeiam regiões de 64 KB apontando para locais em um pool de blocos. Uma consequência dessa configuração é que ela permite que vários recursos compartilhem e reutilizem os mesmos blocos e também que os mesmos blocos sejam reutilizados em locais diferentes dentro de um recurso, se desejado.
O custo da flexibilidade de preencher os blocos de um recurso fora de um pool de blocos é que o recurso precisa fazer o trabalho de definir e manter o mapeamento de quais blocos no pool de blocos representam os blocos necessários para o recurso. Os mapeamentos de blocos podem ser alterados. Além disso, nem todos os blocos em um recurso precisam ser mapeados por vez; um recurso pode ter mapeamentos NULL . Um mapeamento NULL define um bloco como não estando disponível do ponto de vista do recurso que o acessa.
Vários pools de blocos podem ser criados e qualquer número de recursos de streaming pode ser mapeado em qualquer pool de blocos ao mesmo tempo. As piscinas de ladrilhos também podem ser cultivadas ou reduzidas. Para obter mais informações, consulte Redimensionamento do pool de blocos. Uma restrição que existe para simplificar a implementação do driver de exibição e do runtime é que um determinado recurso de streaming só pode ter mapeamentos em no máximo um pool de blocos por vez (em vez de ter mapeamento simultâneo para vários pools de blocos).
A quantidade de armazenamento associada a um recurso de streaming em si (ou seja, memória independente do pool de blocos) é aproximadamente proporcional ao número de blocos realmente mapeados para o pool em um determinado momento. No hardware, esse fato se resume a dimensionar o volume de memória para armazenamento de tabela de páginas aproximadamente com a quantidade de blocos mapeados (por exemplo, usando um esquema de tabela de páginas de vários níveis, conforme apropriado).
O pool de blocos pode ser considerado como uma abstração totalmente de software que permite que os aplicativos Direct3D sejam efetivamente capazes de programar as tabelas de páginas na GPU (unidade de processamento gráfico) sem precisar conhecer os detalhes de implementação de baixo nível (ou lidar diretamente com endereços de ponteiro). Os pools de blocos não aplicam nenhum nível adicional de indireção no hardware. As otimizações de uma tabela de páginas de nível único usando constructos como diretórios de páginas são independentes do conceito de pool de blocos.
Vamos explorar qual armazenamento a própria tabela de páginas pode exigir no pior caso (embora, na prática, as implementações exijam apenas armazenamento aproximadamente proporcional ao que está mapeado).
Suponha que cada entrada da tabela de páginas tenha 64 bits.
Para o pior caso de ocorrência de tamanho de tabela de página para uma única superfície, considerando os limites de recursos no Direct3D 11, suponha que um recurso de streaming seja criado com um formato de 128 bits por elemento (por exemplo, um float RGBA), portanto, um bloco de 64 KB contém apenas 4096 pixels. O tamanho máximo de Texture2DArray com suporte de 16384*16384*2048 (mas com apenas um único mipmap) exigiria cerca de 1 GB de armazenamento na tabela de páginas se totalmente preenchido (não incluindo mipmaps) usando entradas de tabela de 64 bits. A adição de mipmaps aumentaria o armazenamento de tabela de páginas totalmente mapeado (pior caso) em cerca de um terço, para cerca de 1,3 GB.
Esse caso daria acesso a cerca de 10,6 terabytes de memória endereçável. No entanto, pode haver um limite na quantidade de memória endereçável, o que reduziria essas quantidades, talvez para cerca de terabytes.
Outro caso a ser considerado é um único recurso de streaming Texture2D de 16384*16384 com um formato de 32 bits por elemento, incluindo mipmaps. O espaço necessário em uma tabela de páginas totalmente preenchida seria de aproximadamente 170 KB com entradas de tabela de 64 bits.
Por fim, considere um exemplo usando um formato BC, digamos BC7 com 128 bits por bloco de 4x4 pixels. Isso é um byte por pixel. Um Texture2DArray de 16384*16384*2048, incluindo mipmaps, exigiria aproximadamente 85 MB para preencher totalmente essa memória em uma tabela de páginas. Isso não é ruim, considerando que isso permite que um recurso de streaming abranja 550 gigapixels (512 GB de memória neste caso).
Na prática, nem de longe esses mapeamentos completos seriam definidos, uma vez que a quantidade de memória física disponível não permitiria que tanto fosse mapeado e referenciado por vez. Mas com um pool de blocos, os aplicativos podem optar por reutilizar blocos (como um exemplo simples, reutilizar um bloco colorido "preto" para grandes regiões pretas em uma imagem) - usando efetivamente o pool de blocos (ou seja, mapeamentos de tabela de páginas) como uma ferramenta para compactação de memória.
O conteúdo inicial da tabela de páginas é NULL para todas as entradas. Os aplicativos também não podem passar dados iniciais para o conteúdo da memória da superfície, pois ela começa sem suporte de memória.
Nesta seção
| Tópico | Descrição |
|---|---|
Os apps podem criar um ou mais pools de blocos por dispositivo Direct3D. O tamanho total de cada pool de blocos é restrito ao limite de tamanho de recurso do Direct3D 11, que é aproximadamente 1/4 da RAM da GPU. |
|
Redimensione um pool de blocos para ampliar um pool de blocos se o app precisar de mais trabalho para os recursos de streaming mapeados neles ou reduzir se precisar de menos espaço. |
|
Para recursos não streaming, o Direct3D pode impedir determinadas condições de risco durante a renderização, mas como o controle de risco estaria em um nível de bloco para os recursos de streaming, monitorar as condições de risco durante a renderização de streaming de recursos pode ser muito caro. |
Tópicos relacionados