Compactação de bloco (Direct3D 10)
A compactação de bloco é uma técnica de compactação de textura para reduzir o tamanho da textura. Quando comparado com uma textura com 32 bits por cor, uma textura compactada em bloco pode ser até 75% menor. Os apps geralmente ganham um aumento no desempenho ao usar a compactação de bloco devido o menor volume de memória.
Mesmo com perdas, a compactação de bloco funciona bem e é recomendada para todas as texturas que são transformadas e filtradas pelo pipeline. Texturas que são mapeadas diretamente na tela (elementos de interface do usuário como ícones e texto) não são uma ótima opção para compactação porque os artefatos são mais perceptíveis.
Uma textura compactada em bloco deve ser criada como um múltiplo do tamanho de 4 em todas as dimensões e não pode ser usada como uma saída do pipeline.
- Como funciona a compactação de blocos?
- Usando compactação de bloco
- Algoritmos de compactação
- Conversão de formato usando Direct3D 10.1
- Tópicos relacionados
Como funciona a compactação de blocos?
A compactação de bloco é uma técnica para reduzir a quantidade de memória necessária para armazenar dados de cor. Armazenando algumas cores no tamanho original e outras cores usando um esquema de codificação, você pode reduzir significativamente a quantidade de memória necessária para armazenar a imagem. Como o hardware decodifica automaticamente os dados compactados, não há nenhuma penalidade de desempenho para o uso de texturas compactadas.
Para ver como funciona a compactação, examine os dois exemplos a seguir. O primeiro exemplo descreve a quantidade de memória usada para armazenar dados não compactados; o segundo exemplo descreve a quantidade de memória usada para armazenar dados compactados.
Armazenando dados descompactados
A ilustração a seguir representa uma textura de 4 × 4 não compactada. Suponha que cada cor contenha um componente único de cor (vermelho, por exemplo) e é armazenado em um byte de memória.
Os dados não compactados são dispostos na memória sequencialmente e exigem 16 bytes, conforme mostrado na ilustração a seguir.
Armazenando dados compactados
Agora que você já viu quanta memória uma imagem descompactada utiliza, dê uma olhada na quantidade de memória poupada por uma imagem compactada. O formato de compactação BC4 armazena duas cores (1 byte cada) e 16 índices de 3 bits (48 bits ou 6 bytes) que são usados para interpolar as cores originais na textura, conforme mostrado na ilustração a seguir.
O espaço total obrigatório para armazenar os dados compactados é de 8 bytes, que é uma economia de memória de 50% em relação ao exemplo não compactado. A economia é ainda maior quando mais de um componente de cor é usado.
A economia de memória substancial proporcionada pelo compactação de bloco pode causar um aumento no desempenho. Esse desempenho impacta a qualidade da imagem (devido à interpolação de cores); no entanto, a baixa qualidade geralmente não é perceptível.
A próxima seção mostra como o Direct3D 10 facilita o uso da compactação de blocos em seu aplicativo.
Usando compactação de bloco
Crie uma textura compactada em bloco como uma textura descompactada (consulte Criar uma textura de um arquivo), exceto que você especifica um formato compactado em bloco.
loadInfo.Format = DXGI_FORMAT_BC1_UNORM;
D3DX10CreateTextureFromFile(...);
Em seguida, crie uma exibição para associar a textura ao pipeline. Como uma textura compactada em bloco pode ser usada apenas como uma entrada para um estágio de sombreador, você deseja criar uma exibição de recurso de sombreador chamando CreateShaderResourceView.
Use uma textura compactada em bloco da mesma maneira que você usaria uma textura não compactada. Se seu aplicativo receberá um ponteiro de memória para dados compactados em bloco, você precisa levar em conta a memória preenchimento em uma minimapa que faz com que o tamanho declarado ser diferente do tamanho real.
Tamanho virtual versus tamanho físico
Se você tiver o código do app que usa um ponteiro de memória para percorrer a memória de um bloco de textura compactado, há uma consideração importante que pode exigir uma modificação no código do seu app. Uma textura compactada em bloco deve ser um múltiplo de 4 em todas as dimensões porque os algoritmos de compactação de bloco operam em blocos de texel de 4 x 4. Isso será um problema para um mipmap cujas dimensões iniciais são divisíveis por 4, mas os níveis subdivididos não são. O diagrama a seguir mostra a diferença na área entre o tamanho virtual (declarado) e o tamanho físico (real) de cada nível de mipmap.
O lado esquerdo do diagrama mostra os tamanhos de nível de mipmap que são gerados para uma textura de 60 × 40 não compactada. O tamanho de nível superior é retirado da chamada de API que gera a textura; cada nível subsequente é metade do tamanho do nível anterior. Para uma textura descompactada, não há nenhuma diferença entre o tamanho virtual (declarado) e o tamanho físico (real).
O lado direito do diagrama mostra os tamanhos de nível de mipmap que são gerados para a mesma textura de 60 × 40 com compactação. Observe que o segundo e o terceiro nível possuem preenchimento de memória para gerar os fatores de tamanho 4 em cada nível. Isso é necessário para que os algoritmos possam operar em blocos de 4 × 4 texel. Isso é evidente se você considerar os níveis de mipmap menores que 4 × 4; o tamanho desses níveis muito pequenos de mipmap será arredondado para cima para o fator mais próximo de 4 quando a memória de textura for alocada.
O hardware de amostragem usa o tamanho virtual; quando é feito uma amostragem da textura, o preenchimento de memória é ignorado. Para níveis de mipmap menores que 4 × 4, somente os quatro primeiros texels são usados para um mapa 2 x 2, e apenas o primeiro texel é usado por um bloco 1 × 1. No entanto, não há nenhuma estrutura de API que expõe o tamanho físico (incluindo o preenchimento de memória).
Resumindo, tome cuidado ao usar blocos de memória alinhados ao copiar regiões que contêm dados compactados em bloco. Para fazer isso em um app que obtém um ponteiro de memória, certifique-se de que o ponteiro usa a densidade de superfície para levar em conta o tamanho da memória física.
Algoritmos de compactação
As técnicas de compactação de bloco no Direct3D dividem os dados de textura descompactados em blocos de 4 × 4, compactam cada bloco e armazenam os dados. Por esse motivo, as texturas que devem ser compactadas devem ter dimensões de textura múltiplas de 4.
O diagrama acima mostra uma textura particionada em blocos de texel. O primeiro bloco mostra o layout de 16 texels rotulado como a-p, mas todos os blocos tem a mesma organização dos dados.
O Direct3D implementa vários esquemas de compactação, cada um implementa um equilíbrio diferente entre os vários componentes armazenados, o número de bits por componente e a quantidade de memória consumida. Use esta tabela para ajudar a escolher o formato que funciona melhor com o tipo de dados e a resolução de dados que melhor se adapta ao seu app.
| Dados de origem | Resolução de compactação de dados (em bits) | Escolha esse formato de compactação |
|---|---|---|
| Alfa e cor de três componentes | Cor (5:6:5), alfa (1) ou nenhum alfa | BC1 |
| Alfa e cor de três componentes | Cor (5:6:5), alfa (4) | BC2 |
| Alfa e cor de três componentes | Cor (5:6:5), alfa (8) | BC3 |
| Cor de um componente | Um componente (8) | BC4 |
| Cor de dois componentes | Dois componentes (8:8) | BC5 |
BC1
Use o primeiro bc1 (formato de compactação de bloco) (DXGI_FORMAT_BC1_TYPELESS, DXGI_FORMAT_BC1_UNORM ou DXGI_BC1_UNORM_SRGB) para armazenar dados de cor de três componentes usando uma cor de 5:6:5 (5 bits vermelho, 6 bits verde, 5 bits azul). Isso vale até mesmo quando os dados também contêm alfa de 1 bit. Pressupondo uma textura de 4 × 4 usando o formato de dados maior possível, o formato BC1 reduz a memória necessária de 48 bytes (16 cores × 3 componentes/cor × 1 byte/componente) para 8 bytes de memória.
O algoritmo funciona em blocos de texels de 4 × 4. Em vez de armazenar 16 cores, o algoritmo salva duas cores de referência (color_0 e color_1) e 16 índices de cores de 2 bits (bloqueia a-p), conforme mostrado no diagrama a seguir.
Os índices de cor (a–p) são usados para procurar as cores originais em uma tabela de cores. A tabela de cores contém 4 cores. As duas primeiras cores, color_0 e color_1, são as cores mínima e máxima. As outras duas cores, color_2 e color_3, são cores intermediárias calculadas com interpolação linear.
color_2 = 2/3*color_0 + 1/3*color_1
color_3 = 1/3*color_0 + 2/3*color_1
As quatro cores recebem valores de índice de 2 bits que serão salvos em blocos a–p.
color_0 = 00
color_1 = 01
color_2 = 10
color_3 = 11
Por fim, todas as cores nos blocos a–p são comparadas com as quatro cores na tabela de cores e o índice para a cor mais próxima é armazenado nos blocos de 2 bits.
Esse algoritmo se compromete a dados que também contêm alfa de 1 bit. A única diferença é que color_3 é definido como 0 (que representa uma cor transparente) e color_2 é uma mistura linear de color_0 e color_1.
color_2 = 1/2*color_0 + 1/2*color_1;
color_3 = 0;
Diferenças entre o Direct3D 9 e o Direct3D 10:
Esse formato existe no Direct3D 9 e 10.
- No Direct3D 9, o formato BC1 é chamado de D3DFMT_DXT1.
- No Direct3D 10, o formato BC1 é representado por DXGI_FORMAT_BC1_UNORM ou DXGI_FORMAT_BC1_UNORM_SRGB.
BC2
Use o formato BC2 (DXGI_FORMAT_BC2_TYPELESS, DXGI_FORMAT_BC2_UNORM ou DXGI_BC2_UNORM_SRGB) para armazenar dados que contêm dados alfa e de cor com baixa coerência (use BC3 para dados alfa altamente coerentes). O formato BC2 armazena dados RGB como uma cor 5:6:5 (5 bits de vermelho, 6 bits de verde, 5 bits de azul) e alfa como um valor de 4 bits separado. Pressupondo uma textura de 4 × 4 usando o formato de dados maior possível, essa técnica de compactação reduz a memória necessária de 64 bytes (16 cores × 4 componentes/cor × 1 byte/componente) para 16 bytes de memória.
O formato BC2 armazena cores com o mesmo número de bits e dados de layout como o formato BC1, no entanto, o BC2 requer 64-bits adicionais de memória para armazenar os dados alfa, conforme mostrado no diagrama a seguir.
Diferenças entre o Direct3D 9 e o Direct3D 10:
Esse formato existe no Direct3D 9 e 10.
No Direct3D 9, o formato BC2 é chamado de D3DFMT_DXT2 e D3DFMT_DXT3.
No Direct3D 10, o formato BC2 é representado por DXGI_FORMAT_BC2_UNORM ou DXGI_FORMAT_BC2_UNORM_SRGB
BC3
Use o formato BC3 (DXGI_FORMAT_BC3_TYPELESS, DXGI_FORMAT_BC3_UNORM ou DXGI_BC3_UNORM_SRGB) para armazenar dados de cores altamente coerentes (use BC2 com dados alfa menos coerentes). O formato BC3 armazena dados de cor usando cor 5:6:5 (5 bits de vermelho, 6 bits de verde, 5 bits de azul) e dados alfa usando um byte. Pressupondo uma textura de 4 × 4 usando o formato de dados maior possível, essa técnica de compactação reduz a memória necessária de 64 bytes (16 cores × 4 componentes/cor × 1 byte/componente) para 16 bytes de memória.
O formato BC3 armazena cores com o mesmo número de bits e layout de dados que o formato BC1, no entanto, o BC3 requer 64 bits adicionais de memória para armazenar os dados alfa. O formato BC3 manipula o alfa armazenando dois valores de referência e interpolando entre eles (da mesma forma como o BC1 armazena cor RGB).
O algoritmo funciona em blocos de texels de 4 × 4. Em vez de armazenar 16 valores alfa, o algoritmo armazena dois alfas de referência (alpha_0 e alpha_1) e índices de cores de 16 3 bits (alfa a a p), conforme mostrado no diagrama a seguir.
O formato BC3 usa os índices de alfa (a–p) para procurar as cores originais em uma tabela de pesquisa que contém 8 valores. Os dois primeiros valores, alpha_0 e alpha_1, são os valores mínimo e máximo; os outros seis valores intermediários são calculados usando interpolação linear.
O algoritmo determina o número de valores alfa interpolados examinando os dois valores alfa de referência. Se alpha_0 for maior que alpha_1, BC3 interpolará 6 valores alfa; caso contrário, interpolará 4. Quando o BC3 interpola apenas 4 valores alfa, ele define dois valores alfa adicionais (0 para totalmente transparente e 255 para totalmente opaco). O BC3 compacta os valores alfabéticos na área de texel de 4 × 4, armazenando o código de bit correspondente aos valores alfa interpolados que melhor correspondem ao alfa original para um determinado texel.
if( alpha_0 > alpha_1 )
{
// 6 interpolated alpha values.
alpha_2 = 6/7*alpha_0 + 1/7*alpha_1; // bit code 010
alpha_3 = 5/7*alpha_0 + 2/7*alpha_1; // bit code 011
alpha_4 = 4/7*alpha_0 + 3/7*alpha_1; // bit code 100
alpha_5 = 3/7*alpha_0 + 4/7*alpha_1; // bit code 101
alpha_6 = 2/7*alpha_0 + 5/7*alpha_1; // bit code 110
alpha_7 = 1/7*alpha_0 + 6/7*alpha_1; // bit code 111
}
else
{
// 4 interpolated alpha values.
alpha_2 = 4/5*alpha_0 + 1/5*alpha_1; // bit code 010
alpha_3 = 3/5*alpha_0 + 2/5*alpha_1; // bit code 011
alpha_4 = 2/5*alpha_0 + 3/5*alpha_1; // bit code 100
alpha_5 = 1/5*alpha_0 + 4/5*alpha_1; // bit code 101
alpha_6 = 0; // bit code 110
alpha_7 = 255; // bit code 111
}
Diferenças entre o Direct3D 9 e o Direct3D 10:
No Direct3D 9, o formato BC3 é chamado de D3DFMT_DXT4 e D3DFMT_DXT5.
No Direct3D 10, o formato BC3 é representado por DXGI_FORMAT_BC3_UNORM ou DXGI_FORMAT_BC3_UNORM_SRGB.
BC4
Use o formato BC4 para armazenar dados de cor de um componente usando 8 bits para cada cor. Como resultado do aumento da precisão (em comparação com BC1), BC4 é ideal para armazenar dados de ponto flutuante no intervalo de [0 a 1] usando o formato DXGI_FORMAT_BC4_UNORM e [-1 a +1] usando o formato DXGI_FORMAT_BC4_SNORM. Pressupondo uma textura de 4 × 4 usando o formato de dados maior possível, essa técnica de compactação reduz a memória necessária de 16 bytes (16 cores × 1 componentes/cor × 1 byte/componente) para 8 bytes.
O algoritmo funciona em blocos de texels de 4 × 4. Em vez de armazenar 16 cores, o algoritmo armazena duas cores de referência (red_0 e red_1) e 16 índices de cores de 3 bits (vermelho a a vermelho p), conforme mostrado no diagrama a seguir.
O algoritmo usa os índices de 3 bits para procurar as cores em uma tabela de cores que contém 8 cores. As duas primeiras cores, red_0 e red_1, são as cores mínima e máxima. O algoritmo calcula as cores restantes usando interpolação linear.
O algoritmo determina o número de valores de cor interpolados examinando os dois valores de referência. Se red_0 for maior que red_1, BC4 interpolará 6 valores de cor; caso contrário, interpolará 4. Quando o BC4 interpola apenas 4 valores de cor, ele define dois valores de cor adicional (0.0f para totalmente transparente e 1.0f para totalmente opaco). O BC4 compacta os valores alfabéticos na área de texel de 4 × 4, armazenando o código de bit correspondente aos valores alfa interpolados que melhor correspondem ao alfa original para um determinado texel.
BC4_UNORM
A interpolação dos dados de componente único é feita como no exemplo de código a seguir.
unsigned word red_0, red_1;
if( red_0 > red_1 )
{
// 6 interpolated color values
red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
// 4 interpolated color values
red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
red_6 = 0.0f; // bit code 110
red_7 = 1.0f; // bit code 111
}
As cores de referência recebem índices de 3 bits (000 – 111, uma vez que há 8 valores), que serão salvos em blocos na cor vermelha a até a cor vermelha p durante a compactação.
BC4_SNORM
O DXGI_FORMAT_BC4_SNORM é exatamente o mesmo, exceto que os dados são codificados no intervalo SNORM e quando quatro valores de cor são interpolados. A interpolação dos dados de componente único é feita como no exemplo de código a seguir.
signed word red_0, red_1;
if( red_0 > red_1 )
{
// 6 interpolated color values
red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
// 4 interpolated color values
red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
red_6 = -1.0f; // bit code 110
red_7 = 1.0f; // bit code 111
}
As cores de referência recebem índices de 3 bits (000 – 111, uma vez que há 8 valores), que serão salvos em blocos na cor vermelha a até a cor vermelha p durante a compactação.
BC5
Use o formato BC5 para armazenar dados de cor de dois componentes usando 8 bits para cada cor. Como resultado do aumento da precisão (em comparação com BC1), o BC5 é ideal para armazenar dados de ponto flutuante no intervalo de [0 a 1] usando o formato DXGI_FORMAT_BC5_UNORM e [-1 a +1] usando o formato DXGI_FORMAT_BC5_SNORM. Pressupondo uma textura de 4 × 4 usando o formato de dados maior possível, essa técnica de compactação reduz a memória necessária de 32 bytes (16 cores × 2 componentes/cor × 1 byte/componente) para 16 bytes.
O algoritmo funciona em blocos de texels de 4 × 4. Em vez de armazenar 16 cores para ambos os componentes, o algoritmo armazena duas cores de referência para cada componente (red_0, red_1, green_0 e green_1) e índices de cores de 16 3 bits para cada componente (vermelho a a p vermelho e verde a até p verde), conforme mostrado no diagrama a seguir.
O algoritmo usa os índices de 3 bits para procurar as cores em uma tabela de cores que contém 8 cores. As duas primeiras cores— red_0 e red_1 (ou green_0 e green_1)— são as cores mínima e máxima. O algoritmo calcula as cores restantes usando interpolação linear.
O algoritmo determina o número de valores de cor interpolados examinando os dois valores de referência. Se red_0 for maior que red_1, BC5 interpolará 6 valores de cor; caso contrário, interpolará 4. Quando o BC5 interpola apenas 4 valores de cor, ele define os dois valores de cor restantes em 0.0f e 1.0f.
BC5_UNORM
A interpolação dos dados de componente único é feita como no exemplo de código a seguir. Os cálculos para os componentes verdes são semelhantes.
unsigned word red_0, red_1;
if( red_0 > red_1 )
{
// 6 interpolated color values
red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
// 4 interpolated color values
red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
red_6 = 0.0f; // bit code 110
red_7 = 1.0f; // bit code 111
}
As cores de referência recebem índices de 3 bits (000 – 111, uma vez que há 8 valores), que serão salvos em blocos na cor vermelha a até a cor vermelha p durante a compactação.
BC5_SNORM
O DXGI_FORMAT_BC5_SNORM é exatamente o mesmo, exceto que os dados são codificados no intervalo SNORM e, quando quatro valores de dados são interpolados, os dois valores adicionais são -1,0f e 1,0f. A interpolação dos dados de componente único é feita como no exemplo de código a seguir. Os cálculos para os componentes verdes são semelhantes.
signed word red_0, red_1;
if( red_0 > red_1 )
{
// 6 interpolated color values
red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
// 4 interpolated color values
red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
red_6 = -1.0f; // bit code 110
red_7 = 1.0f; // bit code 111
}
As cores de referência recebem índices de 3 bits (000 – 111, uma vez que há 8 valores), que serão salvos em blocos na cor vermelha a até a cor vermelha p durante a compactação.
Conversão de formato usando Direct3D 10.1
O Direct3D 10.1 permite cópias entre texturas pré-estruturadas e texturas compactadas em bloco das mesmas larguras de bit. As funções que podem fazer isso são CopyResource e CopySubresourceRegion.
A partir do Direct3D 10.1, você pode usar CopyResource e CopySubresourceRegion para copiar entre alguns tipos de formato. Esse tipo de operação de cópia executa um tipo de conversão de formato que reinterpreta os dados de recursos como um tipo de formato diferente. Considere este exemplo que mostra a diferença entre a reinterpretação de dados com o comportamento de um tipo mais comum de conversão:
FLOAT32 f = 1.0f;
UINT32 u;
Para reinterpretar 'f' como o tipo de 'u', use memcpy:
memcpy( &u, &f, sizeof( f ) ); // ‘u’ becomes equal to 0x3F800000.
Na reinterpretação anterior, o valor subjacente dos dados não muda; memcpy reinterpreta o flutuante como um inteiro sem sinal.
Para executar o tipo mais comum de conversão, use a atribuição:
u = f; // ‘u’ becomes 1.
Na conversão anterior, o valor subjacente dos dados muda.
A tabela a seguir lista os formatos de destino e origem permitidos que você pode usar nesse tipo de reinterpretação de conversão de formatos. Você deve codificar os valores corretamente para que a reinterpretação funcione conforme esperado.
| Largura de bit | Recurso não compactado | Recurso compactado em bloco |
|---|---|---|
| 32 | DXGI_FORMAT_R32_UINT DXGI_FORMAT_R32_SINT |
DXGI_FORMAT_R9G9B9E5_SHAREDEXP |
| 64 | DXGI_FORMAT_R16G16B16A16_UINT DXGI_FORMAT_R16G16B16A16_SINT DXGI_FORMAT_R32G32_UINT DXGI_FORMAT_R32G32_SINT |
DXGI_FORMAT_BC1_UNORM[_SRGB] DXGI_FORMAT_BC4_UNORM DXGI_FORMAT_BC4_SNORM |
| 128 | DXGI_FORMAT_R32G32B32A32_UINT DXGI_FORMAT_R32G32B32A32_SINT |
DXGI_FORMAT_BC2_UNORM[_SRGB] DXGI_FORMAT_BC3_UNORM[_SRGB] DXGI_FORMAT_BC5_UNORM DXGI_FORMAT_BC5_SNORM |
Tópicos relacionados
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de