Compression de blocs

La compression de bloc est une technique de compression de texture à perte pour réduire la taille de texture et l’empreinte mémoire, ce qui augmente les performances. Une texture compressée par bloc peut être inférieure à une texture avec 32 bits par couleur.

La compression de blocs est une technique de compression de texture qui permet de réduire la taille de la texture. Comparée à une texture de 32 bits par couleur, une texture compressée par bloc peut être jusqu'à 75 % plus petite. Les applications constatent généralement une augmentation des performances lors de l'utilisation de la compression par bloc en raison de l'empreinte mémoire réduite.

Bien qu'avec perte, la compression par blocs fonctionne bien et est recommandée pour toutes les textures qui sont transformées et filtrées par le pipeline. Les textures qui sont directement mappées à l'écran (éléments d'interface utilisateur tels que les icônes et le texte) ne sont pas de bons choix pour la compression car les artefacts sont plus visibles.

Une texture compressée par bloc doit être créée comme un multiple de la taille 4 dans toutes les dimensions et ne peut pas être utilisée comme sortie du pipeline.

Fonctionnement de la compression de bloc

La compression de blocs est une technique qui permet de réduire la quantité de mémoire nécessaire au stockage des données de couleur. En stockant certaines couleurs dans leur taille d'origine et d'autres couleurs à l'aide d'un schéma d'encodage, vous pouvez réduire considérablement la quantité de mémoire nécessaire au stockage de l'image. Étant donné que le matériel décode automatiquement les données compressées, l'utilisation de textures compressées n'entraîne aucune pénalité en termes de performances.

Pour comprendre comment fonctionne la compression, regardez les deux exemples suivants. Le premier exemple décrit la quantité de mémoire utilisée lors du stockage de données non compressées ; le second exemple décrit la quantité de mémoire utilisée lors du stockage de données compressées.

• Stockage de données non compressées
• Stockage de données compressées

Stockage de données non compressées

L’illustration suivante représente une texture 4×4 non compressée. Supposons que chaque couleur contienne une seule composante de couleur (rouge par exemple) et soit stockée dans un octet de mémoire.

Les données non compressées sont disposées en mémoire de manière séquentielle et nécessitent 16 octets, comme le montre l'illustration suivante.

Stockage de données compressées

Maintenant que vous avez vu combien de mémoire une image non compressée utilise, regardez combien de mémoire une image compressée économise. Le format de compression BC4 stocke 2 couleurs (1 octet chacune) et 16 indices de 3 bits (48 bits, ou 6 octets) qui sont utilisés pour interpoler les couleurs originales dans la texture, comme le montre l'illustration suivante.

L'espace total requis pour stocker les données compressées est de 8 octets, ce qui représente une économie de mémoire de 50 % par rapport à l'exemple non compressé. Les économies sont encore plus importantes lorsque plus d'une composante couleur est utilisée.

Les économies de mémoire substantielles réalisées grâce à la compression de blocs peuvent entraîner une augmentation des performances. Ces performances se font au détriment de la qualité de l'image (en raison de l'interpolation des couleurs), mais la baisse de qualité n'est souvent pas perceptible.

La section suivante montre comment Direct3D permet d’utiliser la compression de bloc dans une application.

Utilisation de la compression de bloc

Créez une texture compressée en bloc comme une texture non compressée, sauf que vous spécifiez un format compressé par bloc.

Ensuite, créez une vue pour lier la texture au pipeline. Étant donné qu'une texture compressée par bloc ne peut être utilisée qu'en tant qu'entrée dans une phase de shader, vous souhaitez créer une vue de ressource de shader.

Utilisez une texture compressée par bloc de la même manière qu'une texture non compressée. Si votre application obtient un pointeur de mémoire sur des données compressées par blocs, vous devez tenir compte du remplissage de la mémoire dans une mipmap qui fait que la taille déclarée diffère de la taille réelle.

• Taille virtuelle par rapport à la taille physique

Taille virtuelle par rapport à la taille physique

Si votre code d'application utilise un pointeur de mémoire pour parcourir la mémoire d'une texture compressée par bloc, il y a une considération importante qui peut nécessiter une modification de votre code d'application. Une texture compressée par bloc doit être un multiple de 4 dans toutes les dimensions, car les algorithmes de compression par bloc fonctionnent sur des blocs de 4x4 texels. Il s’agit d’un problème pour un mipmap dont les dimensions initiales sont divisibles par 4, mais dont les niveaux subdivisés ne le sont pas. Le diagramme suivant montre la différence de surface entre la taille virtuelle (déclarée) et la taille physique (réelle) de chaque niveau de la mipmap.

La partie gauche du diagramme montre les tailles des niveaux de mipmap générés pour une texture 60×40 non compressée. La taille du niveau supérieur provient de l'appel API qui génère la texture ; chaque niveau suivant correspond à la moitié de la taille du niveau précédent. Pour une texture non compressée, il n'y a pas de différence entre la taille virtuelle (déclarée) et la taille physique (réelle).

La partie droite du diagramme montre les tailles des niveaux de mipmap générés pour la même texture 60×40 avec compression. Notez que le deuxième et le troisième niveau ont un remplissage de mémoire pour rendre les facteurs de taille de 4 sur chaque niveau. Cela est nécessaire pour que les algorithmes puissent fonctionner sur des blocs de 4×4 texels. Cela est particulièrement évident si vous envisagez des niveaux mipmap inférieurs à 4×4 ; la taille de ces niveaux de mipmap très petits est arrondie au facteur le plus proche de 4 lorsque la mémoire de texture est allouée.

Le matériel d’échantillonnage utilise la taille virtuelle ; lorsque la texture est échantillonnée, le bourrage mémoire est ignoré. Pour les niveaux mipmap inférieurs à 4×4, seuls les quatre premiers texels seront utilisés dans une carte de 2×2, et seul le premier texel sera utilisé par un bloc 1×1. Cependant, aucune structure API n'expose la taille physique (y compris le remplissage de la mémoire).

En résumé, veillez à utiliser des blocs de mémoire alignés lorsque vous copiez des régions contenant des données compressées par bloc. Pour ce faire dans une application qui obtient un pointeur de mémoire, assurez-vous que le pointeur utilise l'espacement de la surface pour tenir compte de la taille de la mémoire physique.

Algorithmes de compression

Les techniques de compression par bloc de Direct3D décomposent les données de texture non compressées en blocs 4×4, compressent chaque bloc, puis stockent les données. Pour cette raison, les textures qui sont censées être compressées doivent avoir des dimensions qui sont des multiples de 4.

Le diagramme précédent montre une texture partitionnée en blocs de texels. Le premier bloc montre la disposition des 16 texels étiquetés a-p, mais chaque bloc a la même organisation des données.

Direct3D met en œuvre plusieurs schémas de compression, chacun mettant en œuvre un compromis différent entre le nombre de composants stockés, le nombre de bits par composant et la quantité de mémoire consommée. Utilisez ce tableau pour choisir le format qui fonctionne le mieux avec le type de données et la résolution de données qui convient le mieux à votre application.

• BC1
• BC2
• BC3
• BC4
• BC5

BC1

Utilisez le premier format de compression de bloc (BC1) (soit DXGI_FORMAT_BC1_TYPELESS, DXGI_FORMAT_BC1_UNORM, ou DXGI_BC1_UNORM_SRGB) pour stocker des données de couleur à trois composantes en utilisant une couleur 5:6:5 (5 bits de rouge, 6 bits de vert, 5 bits de bleu). Ceci est vrai même si les données contiennent également 1 bit alpha. Dans l'hypothèse d'une texture 4×4 utilisant le plus grand format de données possible, le format BC1 réduit la mémoire requise de 48 octets (16 couleurs × 3 composantes/couleur × 1 octet/composante) à 8 octets de mémoire.

L’algorithme fonctionne sur 4×4 blocs de texels. Au lieu de stocker 16 couleurs, l'algorithme enregistre 2 couleurs de référence (color_0 et color_1) et 16 indices de couleur de 2 bits (blocs a-p), comme le montre le diagramme suivant.

Les indices de couleur (a-p) sont utilisés pour retrouver les couleurs d'origine dans une table de couleurs. La table des couleurs contient 4 couleurs. Les deux premières couleurs - couleur_0 et couleur_1 - sont les couleurs minimale et maximale. Les deux autres couleurs, color_2 et color_3, sont des couleurs intermédiaires calculées par interpolation linéaire.

color_2 = 2/3*color_0 + 1/3*color_1
color_3 = 1/3*color_0 + 2/3*color_1

Les quatre couleurs se voient attribuer des valeurs d'index de 2 bits qui seront enregistrées dans les blocs a-p.

color_0 = 00
color_1 = 01
color_2 = 10
color_3 = 11

Enfin, chacune des couleurs des blocs a-p est comparée aux quatre couleurs de la table des couleurs et l'indice de la couleur la plus proche est enregistré dans les blocs de 2 bits.

Cet algorithme se prête également aux données contenant un canal alpha de 1 bit. La seule différence est que la couleur_3 est fixée à 0 (ce qui représente une couleur transparente) et que la couleur_2 est un mélange linéaire de la couleur_0 et de la couleur_1.

color_2 = 1/2*color_0 + 1/2*color_1;
color_3 = 0;

BC2

Utilisez le format BC2 (soit DXGI_FORMAT_BC2_TYPELESS, DXGI_FORMAT_BC2_UNORM, ou DXGI_BC2_UNORM_SRGB) pour stocker des données qui contiennent des données couleur et alpha avec une faible cohérence (utilisez BC3 pour des données alpha à forte cohérence). Le format BC2 stocke les données RVB sous la forme d'une couleur 5:6:5 (5 bits pour le rouge, 6 bits pour le vert, 5 bits pour le bleu) et l'alpha sous la forme d'une valeur distincte de 4 bits. En supposant une texture de 4×4 à l’aide du format de données le plus grand possible, cette technique de compression réduit la mémoire requise de 64 octets (16 couleurs × 4 composants/couleurs × 1 octet/composant) à 16 octets de mémoire.

Le format BC2 stocke les couleurs avec le même nombre de bits et la même disposition des données que le format BC1; cependant, le format BC2 nécessite 64 bits de mémoire supplémentaires pour stocker les données alpha, comme le montre le diagramme suivant.

BC3

Utilisez le format BC3 (soit DXGI_FORMAT_BC3_TYPELESS, DXGI_FORMAT_BC3_UNORM, ou DXGI_BC3_UNORM_SRGB) pour stocker des données couleur très cohérentes (utilisez BC2 avec des données alpha moins cohérentes). Le format BC3 stocke les données de couleur en utilisant la couleur 5:6:5 (5 bits de rouge, 6 bits de vert, 5 bits de bleu) et les données alpha en utilisant un octet. En supposant une texture de 4×4 à l’aide du format de données le plus grand possible, cette technique de compression réduit la mémoire requise de 64 octets (16 couleurs × 4 composants/couleurs × 1 octet/composant) à 16 octets de mémoire.

Le format BC3 stocke les couleurs avec le même nombre de bits et la même disposition des données que le format BC1 ; cependant, le format BC3 nécessite 64 bits de mémoire supplémentaires pour stocker les données alpha. Le format BC3 traite les données alpha en stockant deux valeurs de référence et en interpolant entre elles (de la même manière que le format BC1 stocke les couleurs RVB).

L’algorithme fonctionne sur 4×4 blocs de texels. Au lieu de stocker 16 valeurs alpha, l'algorithme stocke 2 alpha de référence (alpha_0 et alpha_1) et 16 indices de couleur de 3 bits (alpha a à p), comme le montre le diagramme suivant.

Le format BC3 utilise les indices alpha (a-p) pour retrouver les couleurs d'origine à partir d'une table de recherche contenant 8 valeurs. Les deux premières valeurs - alpha_0 et alpha_1 - sont les valeurs minimale et maximale ; les six autres valeurs intermédiaires sont calculées par interpolation linéaire.

L'algorithme détermine le nombre de valeurs alpha interpolées en examinant les deux valeurs alpha de référence. Si alpha_0 est supérieur à alpha_1, BC3 interpole 6 valeurs alpha ; sinon, il en interpole 4. Lorsque BC3 n'interpole que 4 valeurs alpha, il définit deux valeurs alpha supplémentaires (0 pour une transparence totale et 255 pour une opacité totale). BC3 compresse les valeurs alpha dans la zone de 4×4 texels en stockant le code binaire correspondant aux valeurs alpha interpolées qui se rapproche le plus de l'alpha original pour un texel donné.

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
}

BC4

Utilisez le format BC4 pour stocker des données de couleur à une composante en utilisant 8 bits pour chaque couleur. En raison de la précision accrue (par rapport à BC1), BC4 est idéal pour stocker des données à virgule flottante dans la plage de [0 à 1] en utilisant le format DXGI_FORMAT_BC4_UNORM et [-1 à +1] en utilisant le format DXGI_FORMAT_BC4_SNORM. Dans l'hypothèse d'une texture 4×4 utilisant le plus grand format de données possible, cette technique de compression réduit la mémoire requise de 16 octets (16 couleurs × 1 composante/couleur × 1 octet/composante) à 8 octets.

L’algorithme fonctionne sur 4×4 blocs de texels. Au lieu de stocker 16 couleurs, l’algorithme stocke 2 couleurs de référence (red_0 et red_1) et 16 indices de couleur sur 3 bits (rouge a à rouge p), comme illustré dans le diagramme suivant.

L’algorithme utilise les index 3 bits pour rechercher des couleurs à partir d’une table de couleurs qui contient 8 couleurs. Les deux premières couleurs - rouge_0 et rouge_1 - sont les couleurs minimale et maximale. L’algorithme calcule les couleurs restantes à l’aide de l’interpolation linéaire.

L’algorithme détermine le nombre de valeurs de couleur interpolées en examinant les deux valeurs de référence. Si le rouge_0 est supérieur au rouge_1, BC4 interpole 6 valeurs de couleur ; sinon, il en interpole 4. Lorsque BC4 n'interpole que 4 valeurs de couleur, il définit deux valeurs de couleur supplémentaires (0,0f pour une transparence totale et 1,0f pour une opacité totale). BC4 compresse les valeurs alpha dans la zone de 4×4 texels en stockant le code binaire correspondant aux valeurs alpha interpolées qui se rapprochent le plus de l'alpha original pour un texel donné.

• BC4_UNORM
• BC4_SNORM

BC4_UNORM

L’interpolation des données à composant unique est effectuée comme dans l’exemple de code suivant.

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
}

Les couleurs de référence sont affectées à des indices de 3 bits (000 à 111, car il y a 8 valeurs), qui seront enregistrés dans les blocs rouge a à rouge p pendant la compression.

BC4_SNORM

Le DXGI_FORMAT_BC4_SNORM est exactement le même, sauf que les données sont encodées dans la gamme SNORM et que 4 valeurs de couleur sont interpolées. L’interpolation des données à composant unique est effectuée comme dans l’exemple de code suivant.

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
}

Les couleurs de référence sont affectées à des indices de 3 bits (000 à 111, car il y a 8 valeurs), qui seront enregistrés dans les blocs rouge a à rouge p pendant la compression.

BC5

Utilisez le format BC5 pour stocker des données de couleur à deux composantes en utilisant 8 bits pour chaque couleur. En raison de la précision accrue (par rapport à BC1), BC5 est idéal pour stocker des données à virgule flottante dans la plage de [0 à 1] en utilisant le format DXGI_FORMAT_BC5_UNORM et de [-1 à +1] en utilisant le format DXGI_FORMAT_BC5_SNORM. Dans l'hypothèse d'une texture 4×4 utilisant le plus grand format de données possible, cette technique de compression réduit la mémoire requise de 32 octets (16 couleurs × 2 composantes/couleur × 1 octet/composante) à 16 octets.

• BC5_UNORM
• BC5_SNORM

L’algorithme fonctionne sur 4×4 blocs de texels. Au lieu de stocker 16 couleurs pour les deux composants, l’algorithme stocke 2 couleurs de référence pour chaque composant (red_0, red_1, green_0 et green_1) et 16 indices de couleur de 3 bits pour chaque composant (rouge de a à p et vert de a à p), comme illustré dans le diagramme suivant.

L’algorithme utilise les index 3 bits pour rechercher des couleurs à partir d’une table de couleurs qui contient 8 couleurs. Les deux premières couleurs - red_0 et red_1 (ou green_0 et green_1) - sont les couleurs minimum et maximum. L’algorithme calcule les couleurs restantes à l’aide de l’interpolation linéaire.

L’algorithme détermine le nombre de valeurs de couleur interpolées en examinant les deux valeurs de référence. Si red_0 est supérieur à red_1, BC5 interpole 6 valeurs de couleur ; sinon, il en interpole 4. Lorsque BC5 n'interpole que 4 valeurs de couleur, il fixe les deux valeurs de couleur restantes à 0,0f et 1,0f.

BC5_UNORM

L’interpolation des données à composant unique est effectuée comme dans l’exemple de code suivant. Les calculs des composants verts sont similaires.

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
}

Les couleurs de référence sont affectées à des indices de 3 bits (000 à 111, car il y a 8 valeurs), qui seront enregistrés dans les blocs rouge a à rouge p pendant la compression.

BC5_SNORM

Le format DXGI_FORMAT_BC5_SNORM est exactement le même, sauf que les données sont encodées dans la plage SNORM et que lorsque 4 valeurs de données sont interpolées, les deux valeurs supplémentaires sont -1,0f et 1,0f. L’interpolation des données à composant unique est effectuée comme dans l’exemple de code suivant. Les calculs des composants verts sont similaires.

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
}

Les couleurs de référence sont affectées à des indices de 3 bits (000 à 111, car il y a 8 valeurs), qui seront enregistrés dans les blocs rouge a à rouge p pendant la compression.

conversion de format

Direct3D permet des copies entre les textures préstructurées typées et les textures compressées en bloc des mêmes largeurs de bits.

Vous pouvez copier des ressources entre quelques types de format. Ce type d'opération de copie effectue un type de conversion de format qui réinterprète les données de ressources dans un type de format différent. Examinez cet exemple qui montre la différence entre la réinterprétation des données et le comportement d'un type de conversion plus typique :

FLOAT32 f = 1.0f;
UINT32 u;

Pour réinterpréter 'f' comme le type de 'u', utilisez memcpy :

memcpy( &u, &f, sizeof( f ) ); // 'u' becomes equal to 0x3F800000.

Dans la réinterprétation précédente, la valeur sous-jacente des données ne change pas ; memcpy réinterprète le flottant en un entier non signé.

Pour effectuer le type de conversion le plus courant, utilisez l’affectation :

u = f; // 'u' becomes 1.

Dans la conversion précédente, la valeur sous-jacente des données change.

Le tableau suivant répertorie les formats source et destination autorisés que vous pouvez utiliser dans ce type de conversion de format par réinterprétation. Vous devez coder les valeurs correctement pour que la réinterprétation fonctionne comme prévu.

rubriques connexes

ressources de texture compressées