Compresión en bloques (Direct3D 10)
La compresión en bloques es una técnica de compresión de texturas para reducir el tamaño de la textura. En comparación con una textura con 32 bits por color, una textura comprimida por bloque puede ser hasta un 75 % más pequeña. Las aplicaciones suelen recibir un aumento del rendimiento al usar la compresión en bloques debido a una superficie de memoria más pequeña.
Aunque hay pérdidas, la compresión en bloques funciona bien y se recomienda para todas las texturas que se transforman y filtran mediante la canalización. Las texturas que se asignan directamente a la pantalla (elementos de la interfaz de usuario como iconos y texto) no son buenas opciones para la compresión, ya que los artefactos se hacen más evidentes.
Una textura comprimida por bloques debe crearse como un múltiplo 4 de tamaño en todas las dimensiones y no se puede usar como resultado final de la canalización.
- ¿Cómo funciona la compresión en bloques?
- Uso de la compresión en bloques
- Algoritmos de compresión
- Conversión de formato mediante Direct3D 10.1
- Temas relacionados
¿Cómo funciona la compresión en bloques?
La compresión en bloques es una técnica que sirve para reducir la cantidad de memoria necesaria para almacenar datos de color. Al almacenar algunos colores en su tamaño original y otros colores mediante un esquema de codificación, puede reducir considerablemente el volumen de memoria necesario para almacenar la imagen. Dado que el hardware descodifica automáticamente los datos comprimidos, no hay ninguna merma en el rendimiento para usar texturas comprimidas.
Para ver cómo funciona la compresión, vea los dos ejemplos siguientes. En el primer ejemplo se presenta la cantidad de memoria utilizada al almacenar datos sin comprimir; en el segundo ejemplo se presenta la cantidad de memoria usada al almacenar datos comprimidos.
Almacenar datos sin comprimir
La siguiente ilustración representa una textura de 4×4 sin comprimir. Supongamos que cada color contiene un único componente de color (rojo, por ejemplo) y se almacena en un byte de memoria.
Los datos sin comprimir se distribuyen en memoria en forma secuencial y requieren 16 bytes, tal como se muestra en la ilustración siguiente.
Almacenar datos comprimidos
Ahora que ha visto cuánta memoria usa una imagen sin comprimir, fíjese en la cantidad de memoria que guarda una imagen comprimida. El formato de compresión BC4 almacena 2 colores (1 byte cada uno) y 16 índices de 3 bits (48 bits o 6 bytes) que se usan para interpolar los colores originales en la textura, tal como se muestra en la ilustración siguiente.
El espacio total necesario para almacenar los datos comprimidos es de 8 bytes, lo que supone un 50 por ciento menos de memoria que en el ejemplo sin comprimir. Esta reducción es aún mayor cuando se usa más de un componente de color.
El menor volumen de memoria utilizado por la compresión en bloques puede hacer que aumente el rendimiento. Este rendimiento afecta a la calidad de la imagen (debido a la interpolación del color); sin embargo, ese merma de la calidad es a menudo imperceptible.
En la sección siguiente se indica cómo Direct3D 10 hace más sencilla la compresión en bloques en la aplicación.
Uso de la compresión en bloques
Cree una textura comprimida por bloques como una textura sin comprimir (consulte Crear una textura a partir de un archivo), a no ser que indique un formato comprimido en bloques.
loadInfo.Format = DXGI_FORMAT_BC1_UNORM;
D3DX10CreateTextureFromFile(...);
A continuación, cree una vista para vincular la textura con la canalización. Como una textura comprimida en bloques solo se puede usar como entrada para la fase del sombreador, es aconsejable crear una vista de recursos del sombreador llamando a CreateShaderResourceView.
Use una textura comprimida en bloques de la misma manera que usaría una textura sin comprimir. Si la aplicación recibe un puntero de memoria para bloquear los datos comprimidos, debe tener en cuenta el relleno de memoria en un mapa MIP que hace que el tamaño declarado sea diferente del tamaño real.
Tamaño virtual frente a tamaño físico
Si el código de la aplicación usa un puntero de memoria para recorrer la memoria de una textura comprimida en bloques, hay algo importante para lo que se necesitaría modificar el código de la aplicación. Una textura comprimida en bloques debe ser un múltiplo de 4 en todas las dimensiones, ya que los algoritmos de compresión en bloques funcionan en bloques de textura 4x4. Este es un problema para un mapa MIP cuyas dimensiones iniciales sean divisibles de 4, pero los niveles subdivididos no. En el diagrama siguiente se ve la diferencia en el área entre el tamaño virtual (declarado) y el tamaño físico (real) de cada nivel de mapa MIP.
En el lado izquierdo del diagrama se ven los tamaños de nivel de los mapa MIP que se generan para una textura 60×40 sin comprimir. El tamaño de nivel superior se captura de la llamada de la API que genera la textura; cada nivel siguiente es la mitad del tamaño del nivel anterior. En el caso de una textura sin comprimir, no hay ninguna diferencia entre el tamaño virtual (declarado) y el tamaño físico (real).
En el lado derecho del diagrama se ven los tamaños de nivel de mapas MIP que se generan para la misma textura de 60×40 con compresión. Tenga en cuenta que tanto el segundo como el tercer nivel tienen relleno de memoria para hacer que los tamaños sean divisores de 4 en cada nivel. Esto es necesario para que los algoritmos puedan funcionar en bloques de texturas de 4×4. Esto es evidente de manera especial si se tienen en cuenta niveles de mapas MIP más pequeños que 4×4; el tamaño de estos niveles de mapas MIP muy pequeños redondeará hasta el divisor más cercano de 4 cuando se asigne memoria de textura.
El hardware de muestreo usa el tamaño virtual; cuando se muestrea la textura, se ignora el relleno de memoria. En el caso de los niveles de mapas MIP más pequeños que 4×4, solo se usarán los cuatro primeros elementos de textura en un mapa de 2×2 y solo un bloque de 1×1 usará el primer elemento de textura. Sin embargo, no hay ninguna estructura de API que exponga el tamaño físico (incluido el relleno de memoria).
En resumen, tenga cuidado a la hora de usar bloques de memoria alineados al copiar regiones que contenga datos comprimidos en bloques. Para hacerlo en una aplicación que recibe un puntero de memoria, asegúrese de que este usa la superficie para tener en cuenta el tamaño de memoria física.
Algoritmos de compresión
Las técnicas de compresión en bloques en Direct3D dividen los datos de las texturas sin comprimir en bloques de 4×4, comprimen cada bloque y después almacenan los datos. Por este motivo, las texturas que se espera que se compriman deben tener dimensiones de textura que sean múltiplos de 4.
En el diagrama anterior se muestra una textura particionada en bloques de elementos de textura. En el primer bloque aparece la distribución de 16 elementos de textura etiquetados de la "a" la "p", pero cada bloque tiene la misma organización de datos.
Direct3D implementa varios esquemas de compresión, cada uno implementa una compensación diferente entre el número de componentes almacenados, el número de bits por componente y la cantidad de memoria consumida. Use esta tabla para elegir el formato que mejor funcione con el tipo de datos y la resolución de datos que mejor se adapte a la aplicación.
| Datos de origen | Resolución de compresión de datos (en bits) | Elija este formato de compresión |
|---|---|---|
| Color de tres componentes y alfa | Color (5:6:5), alfa (1) o ningún alfa | BC1 |
| Color de tres componentes y alfa | Color (5:6:5), alfa (4) | BC2 |
| Color de tres componentes y alfa | Color (5:6:5), alfa (8) | BC3 |
| Color de un componente | Un componente (8) | BC4 |
| Color de dos componentes | Dos componentes (8:8) | BC5 |
BC1
Use el primer formato de compresión en bloques (BC1) (ya sea DXGI_FORMAT_BC1_TYPELESS, DXGI_FORMAT_BC1_UNORM o DXGI_BC1_UNORM_SRGB) para almacenar los datos de color de tres componentes mediante un color 5:6:5 (5 bits rojo, 6 bits verde, 5 bits azul). Esto es cierto incluso si los datos incluyen también alfa de 1 bits. Suponiendo que una textura de 4×4 con el formato de datos más grande posible, el formato BC1 reduce la memoria necesaria de 48 bytes (16 colores × 3 componentes/color × 1 byte/componente) a 8 bytes de memoria.
El algoritmo funciona en bloques de elementos de textura de 4×4. En lugar de almacenar 16 colores, el algoritmo guarda dos colores de referencia (color_0 y color_1) y 16 índices de color de 2 bits (bloques a-p), tal como se muestra en el diagrama siguiente.
Los índices de color (a-p) se usan para buscar los colores originales en una tabla de colores. La tabla de colores contiene 4 colores. Los dos primeros colores, color_0 y color_1, son los valores de color mínimos y máximos. Los otros dos colores, color_2 y color_3, son colores intermedios calculados con interpolación lineal.
color_2 = 2/3*color_0 + 1/3*color_1
color_3 = 1/3*color_0 + 2/3*color_1
A los cuatro colores se les asignan valores de índice de 2 bits que se guardarán en los bloques a-p.
color_0 = 00
color_1 = 01
color_2 = 10
color_3 = 11
Por último, cada uno de los colores de los bloques a-p se compara con los cuatro colores de la tabla de colores y el índice del color más cercano se almacena en los bloques de 2 bits.
Este algoritmo se presta a los datos que también incluyen alfa de 1 bits. La única diferencia es que color_3 tiene el valor 0 (que representa un color transparente) y color_2 es una combinación lineal de color_0 y color_1.
color_2 = 1/2*color_0 + 1/2*color_1;
color_3 = 0;
Diferencias entre Direct3D 9 y Direct3D 10:
Este formato existe en Direct3D 9 y 10.
- En Direct3D 9, el formato BC1 se denomina D3DFMT_DXT1.
- En Direct3D 10, el formato BC1 se representa mediante DXGI_FORMAT_BC1_UNORM o DXGI_FORMAT_BC1_UNORM_SRGB.
BC2
Use el formato BC2 (ya sea DXGI_FORMAT_BC2_TYPELESS, DXGI_FORMAT_BC2_UNORM o DXGI_BC2_UNORM_SRGB) para almacenar datos que contengan datos de color y alfa de baja coherencia (use BC3 para datos alfa que sean altamente coherentes). El formato BC2 almacena datos RGB como un color 5:6:5 (5 bits rojo, 6 bits verde, 5 bits azul) y alfa como un valor independiente de 4 bits. Suponiendo que una textura de 4×4 usando el formato de datos más grande posible, esta técnica de compresión reduce la memoria necesaria de 64 bytes (16 colores × 4 componentes/color × 1 byte/componente) a 16 bytes de memoria.
El formato BC2 almacena colores con el mismo número de bits y distribución de datos que el formato BC1; sin embargo, BC2 necesita más de 64 bits de memoria para almacenar los datos de alfa, tal como se muestra en el diagrama siguiente.
Diferencias entre Direct3D 9 y Direct3D 10:
Este formato existe en Direct3D 9 y 10.
En Direct3D 9, el formato BC2 se denomina D3DFMT_DXT2 y D3DFMT_DXT3.
En Direct3D 10, el formato BC2 se representa mediante DXGI_FORMAT_BC2_UNORM o DXGI_FORMAT_BC2_UNORM_SRGB.
BC3
Use el formato BC3 (ya sea DXGI_FORMAT_BC3_TYPELESS, DXGI_FORMAT_BC3_UNORM o DXGI_BC3_UNORM_SRGB) para almacenar datos de color altamente coherentes (use BC2 con datos de alfa menos coherentes). El formato BC3 almacena datos de color mediante el color 5:6:5 (5 bits rojo, 6 bits verde, 5 bits azul) y datos de alfa con un byte. Suponiendo que una textura de 4×4 usando el formato de datos más grande posible, esta técnica de compresión reduce la memoria necesaria de 64 bytes (16 colores × 4 componentes/color × 1 byte/componente) a 16 bytes de memoria.
El formato BC3 almacena colores con el mismo número de bits y distribución de datos que el formato BC1; sin embargo, BC3 necesita más de 64 bits de memoria para almacenar los datos de alfa. El formato BC3 almacena dos valores de referencia y los interpolan entre ellos para controlar alfa (de forma similar a cómo BC1 almacena el color RGB).
El algoritmo funciona en bloques de elementos de textura de 4×4. En lugar de almacenar 16 valores alfa, el algoritmo almacena 2 alfas de referencia (alpha_0 y alpha_1) y 16 índices de color de 3 bits (alfa de la "a" a la "p"), tal como se muestra en el diagrama siguiente.
El formato BC3 usa los índices alfa (a–p) para buscar los colores originales en una tabla de búsqueda que contiene 8 valores. Los dos primeros valores (alpha_0 y alpha_1) son los valores mínimo y máximo; los otros seis valores intermedios se calculan mediante interpolación lineal.
El algoritmo determina el número de valores alfa interpolados examinando los dos valores alfa de referencia. Si alpha_0 es mayor que alpha_1, BC3 interpola 6 valores alfa; si no, interpola 4. Cuando BC3 interpola solo 4 valores alfa, se crean dos valores alfa adicionales (0 para totalmente transparente y 255 para totalmente opaco). BC3 comprime los valores alfa en el área de textura de 4×4 almacenando el código de bits correspondiente a los valores alfa interpolados que coinciden con el alfa original de un elemento de textura determinado.
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
}
Diferencias entre Direct3D 9 y Direct3D 10:
En Direct3D 9, el formato BC3 se denomina D3DFMT_DXT4 y D3DFMT_DXT5.
En Direct3D 10, el formato BC3 se representa mediante DXGI_FORMAT_BC3_UNORM o DXGI_FORMAT_BC3_UNORM_SRGB.
BC4
Use el formato BC4 para almacenar datos de color de un componente con 8 bits para cada color. Como resultado del aumento de la definición (en comparación con BC1), BC4 es ideal para almacenar datos de punto flotante en el intervalo de [0 a 1] con el formato DXGI_FORMAT_BC4_UNORM y de [-1 a +1] con el formato DXGI_FORMAT_BC4_SNORM. Suponiendo que una textura de 4×4 usando el formato de datos más grande posible, esta técnica de compresión reduce la memoria necesaria de 16 bytes (16 colores × 1 componente/color × 1 byte/componente) a 8 bytes de memoria.
El algoritmo funciona en bloques de elementos de textura de 4×4. En lugar de almacenar 16 colores, el algoritmo almacena 2 colores de referencia (red_0 y red_1) e 6 índices de color de 3 bits (de "a" rojo a "p" rojo), tal como se muestra en el diagrama siguiente.
El algoritmo usa los índices de 3 bits para buscar colores de una tabla de colores que contiene 8 colores. Los dos primeros colores, red_0 y red_1, son los valores de color mínimos y máximos. El algoritmo calcula los colores restantes mediante la interpolación lineal.
El algoritmo determina el número de valores de color interpolados examinando los dos valores de referencia. Si red_0 es mayor que red_1, BC4 interpola 6 valores de color; si no, interpola 4. Cuando BC4 interpola solo 4 valores de color, se crean dos valores de color adicionales (0.0f para totalmente transparente y 1.0f para totalmente opaco). BC4 comprime los valores alfa en el área de textura de 4×4 almacenando el código de bits correspondiente a los valores alfa interpolados que coinciden con el alfa original de un elemento de textura determinado.
BC4_UNORM
La interpolación de los datos de un solo componente se realiza como en el ejemplo de código siguiente.
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
}
A los colores de referencia se les asignan índices de 3 bits (000–111, ya que hay 8 valores), que se guardarán en bloques de "a" rojo a "p" rojo durante la compresión.
BC4_SNORM
El DXGI_FORMAT_BC4_SNORM es exactamente el mismo, excepto que los datos se codifican en el intervalo SNORM y cuando se interpolan 4 valores de color. La interpolación de los datos de un solo componente se realiza como en el ejemplo de código siguiente.
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
}
A los colores de referencia se les asignan índices de 3 bits (000–111, ya que hay 8 valores), que se guardarán en bloques de "a" rojo a "p" rojo durante la compresión.
BC5
Use el formato BC5 para almacenar datos de color de dos componentes con 8 bits para cada color. Como resultado del aumento de la definición (en comparación con BC1), BC5 es ideal para almacenar datos de punto flotante en el intervalo de [0 a 1] con el formato DXGI_FORMAT_BC5_UNORM y de [-1 a +1] con el formato DXGI_FORMAT_BC5_SNORM. Suponiendo que una textura de 4×4 usando el formato de datos más grande posible, esta técnica de compresión reduce la memoria necesaria de 32 bytes (16 colores × 2 componente/color × 1 byte/componente) a 16 bytes de memoria.
El algoritmo funciona en bloques de elementos de textura de 4×4. En lugar de almacenar 16 colores para ambos componentes, el algoritmo almacena 2 colores de referencia por cada componente (red_0, red_1, green_0 y green_1) y 16 índices de color de 3 bits por cada componente (de "a" rojo a "p" rojo y de "a" verde a "p" verde), tal como se muestra en el diagrama siguiente.
El algoritmo usa los índices de 3 bits para buscar colores de una tabla de colores que contiene 8 colores. Los dos primeros colores (red_0 y red_1 (o green_0 y green_1) son los valores de color mínimos y máximos. El algoritmo calcula los colores restantes mediante la interpolación lineal.
El algoritmo determina el número de valores de color interpolados examinando los dos valores de referencia. Si red_0 es mayor que red_1, BC5 interpola 6 valores de color; si no, interpola 4. Cuando BC5 interpola solo 4 valores de color, se crean los dos valores de color restantes en 0.0f y 1.0f.
BC5_UNORM
La interpolación de los datos de un solo componente se realiza como en el ejemplo de código siguiente. Las cifras de los componentes verdes son similares.
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
}
A los colores de referencia se les asignan índices de 3 bits (000–111, ya que hay 8 valores), que se guardarán en bloques de "a" rojo a "p" rojo durante la compresión.
BC5_SNORM
El DXGI_FORMAT_BC5_SNORM es exactamente el mismo, excepto que los datos se codifican en el intervalo de SNORM y cuando se interpolan 4 valores de datos, los dos valores adicionales son -1.0f y 1.0f. La interpolación de los datos de un solo componente se realiza como en el ejemplo de código siguiente. Las cifras de los componentes verdes son similares.
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
}
A los colores de referencia se les asignan índices de 3 bits (000–111, ya que hay 8 valores), que se guardarán en bloques de "a" rojo a "p" rojo durante la compresión.
Conversión de formato mediante Direct3D 10.1
Direct3D 10.1 permite copias entre texturas preestructuradas y texturas comprimidas por bloques de los mismos anchos de bits. Las funciones que pueden conseguir esto son CopyResource y CopySubresourceRegion.
A partir de Direct3D 10.1, puede usar CopyResource y CopySubresourceRegion para copiar entre algunos tipos de formato. Este tipo de operación de copia realiza un tipo de conversión de formato que reinterpreta los datos de los recursos como un tipo de formato diferente. Consulte este ejemplo donde se ve la diferencia entre la reinterpretación de los datos y la forma en que funciona un tipo de conversión más normal:
FLOAT32 f = 1.0f;
UINT32 u;
Para reinterpretar 'f' como el tipo de 'u', use memcpy:
memcpy( &u, &f, sizeof( f ) ); // ‘u’ becomes equal to 0x3F800000.
En la reinterpretación anterior, el valor subyacente de los datos no cambia; memcpy reinterpreta el decimal como un entero sin signo.
Para realizar el tipo de conversión más típico, use la asignación:
u = f; // ‘u’ becomes 1.
En la conversión anterior, el valor subyacente de los datos cambia.
En la tabla siguiente figuran los formatos de origen y destino permitidos que puede usar en este tipo de reinterpretación de conversión de formato. Debe codificar los valores correctamente para que la reinterpretación funcione según lo previsto.
| Ancho de bits | Recurso sin comprimir | Recurso comprimido en bloques |
|---|---|---|
| 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 |
Temas relacionados