Compression de blocs (Direct3D 10)
La compression de blocs est une technique de compression de texture permettant de réduire la taille de la texture. Comparée à une texture avec 32 bits par couleur, une texture compressée en bloc peut être jusqu’à 75 % plus petite. Les applications voient généralement une augmentation des performances lors de l’utilisation de la compression de blocs en raison de l’encombrement de la mémoire plus faible.
Bien qu’elle soit en perte, la compression de 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 en bloc doit être créée en tant que multiple de taille 4 dans toutes les dimensions et ne peut pas être utilisée comme sortie du pipeline.
- Comment fonctionne la compression par blocs ?
- Utilisation de la compression de blocs
- Algorithmes de compression
- Conversion de format à l’aide de Direct3D 10.1
- Rubriques connexes
Comment fonctionne la compression par blocs ?
La compression de blocs est une technique permettant de réduire la quantité de mémoire nécessaire pour stocker les 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 pour stocker l’image. Étant donné que le matériel décode automatiquement les données compressées, il n’y a aucune pénalité de performances pour l’utilisation de textures compressées.
Pour voir le fonctionnement de la compression, consultez 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 deuxième 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
L’illustration suivante représente une texture 4×4 non compressée. Supposons que chaque couleur contient un seul composant de couleur (rouge pour instance) et qu’elle est stockée dans un octet de mémoire.
Les données non compressées sont disposées en mémoire séquentiellement et nécessitent 16 octets, comme illustré dans l’illustration suivante.
Stockage de données compressées
Maintenant que vous avez vu la quantité de mémoire utilisée par une image non compressée, examinez la quantité de mémoire enregistrée par une image compressée. Le format de compression BC4 stocke 2 couleurs (1 octet chacun) et 16 index 3 bits (48 bits, soit 6 octets) qui sont utilisés pour interpoler les couleurs d’origine dans la texture, comme illustré dans 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 plusieurs composants de couleur sont utilisés.
Les économies de mémoire substantielles fournies par la compression de blocs peuvent entraîner une augmentation des performances. Cette performance se fait au détriment de la qualité de l’image (grâce à l’interpolation des couleurs) ; cependant, la qualité inférieure n’est souvent pas perceptible.
La section suivante vous montre comment Direct3D 10 facilite l’utilisation de la compression de blocs dans votre application.
Utilisation de la compression de blocs
Créez une texture compressée en bloc comme une texture non compressée (voir Créer une texture à partir d’un fichier), sauf que vous spécifiez un format compressé par bloc.
loadInfo.Format = DXGI_FORMAT_BC1_UNORM;
D3DX10CreateTextureFromFile(...);
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 que comme entrée dans une étape de nuanceur, vous souhaitez créer une vue nuanceur-ressource en appelant CreateShaderResourceView.
Utilisez une texture compressée de bloc de la même façon que vous utiliseriez une texture non compressée. Si votre application obtient un pointeur mémoire pour bloquer les données compressées, vous devez tenir compte du remplissage de mémoire dans un mipmap qui entraîne une différence de taille déclarée par rapport à la taille réelle.
Taille virtuelle par rapport à taille physique
Si vous avez du code d’application qui utilise un pointeur mémoire pour parcourir la mémoire d’une texture compressée de bloc, il existe une considération importante qui peut nécessiter une modification dans votre code d’application. Une texture compressée en bloc doit être un multiple de 4 dans toutes les dimensions, car les algorithmes de compression de blocs fonctionnent sur des blocs de texel 4x4. Ce sera un problème pour un mipmap dont les dimensions initiales sont divisibles par 4, mais les niveaux subdivisé ne le sont pas. Le diagramme suivant montre la différence de zone entre la taille virtuelle (déclarée) et la taille physique (réelle) de chaque niveau mipmap.
Le côté gauche du diagramme montre les tailles de niveau mipmap générées pour une texture 60×40 non compressée. La taille de niveau supérieur est extraite de l’appel d’API qui génère la texture ; chaque niveau suivant a la moitié de la taille du niveau précédent. Pour une texture non compressée, il n’existe aucune différence entre la taille virtuelle (déclarée) et la taille physique (réelle).
Le côté droit du diagramme montre les tailles de niveau mipmap générées pour la même texture 60×40 avec compression. Notez que les deuxième et troisième niveaux ont un remplissage de mémoire pour faire les facteurs de taille de 4 à chaque niveau. Cela est nécessaire pour que les algorithmes puissent fonctionner sur des blocs de texel 4×4. Cela est manifeste si vous considérez des niveaux de mipmap inférieurs à 4×4; la taille de ces très petits niveaux de mipmap est arrondie au facteur 4 le plus proche lorsque la mémoire de texture est allouée.
Le matériel d’échantillonnage utilise la taille virtuelle ; lorsque la texture est échantillonné, le remplissage de mémoire est ignoré. Pour les niveaux mipmap inférieurs à 4×4, seuls les quatre premiers texels seront utilisés pour une carte 2×2, et seul le premier texel sera utilisé par un bloc 1×1. Toutefois, il n’existe aucune structure d’API qui expose la taille physique (y compris le remplissage de mémoire).
En résumé, veillez à utiliser des blocs de mémoire alignés lors de la copie de régions qui contiennent des données compressées par blocs. Pour ce faire, dans une application qui obtient un pointeur mémoire, assurez-vous que le pointeur utilise le pitch de surface pour tenir compte de la taille de la mémoire physique.
Algorithmes de compression
Les techniques de compression de blocs dans 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 de texture qui sont des multiples de 4.
Le diagramme précédent montre une texture partitionnée en blocs de texel. Le premier bloc montre la disposition des 16 texels étiquetés a-p, mais chaque bloc a la même organization de données.
Direct3D implémente plusieurs schémas de compression, chacun implémente 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 vous aider à choisir le format qui convient le mieux au type de données et à la résolution de données qui correspond le mieux à votre application.
| Données sources | Résolution de compression des données (en bits) | Choisir ce format de compression |
|---|---|---|
| Couleur à trois composants et alpha | Couleur (5:6:5), Alpha (1) ou aucun alpha | BC1 |
| Couleur à trois composants et alpha | Couleur (5:6:5), Alpha (4) | BC2 |
| Couleur à trois composants et alpha | Couleur (5:6:5), Alpha (8) | BC3 |
| Couleur monocomposant | Un composant (8) | BC4 |
| Couleur à deux composants | Deux composants (8:8) | BC5 |
BC1
Utilisez le premier format de compression de blocs (BC1) (DXGI_FORMAT_BC1_TYPELESS, DXGI_FORMAT_BC1_UNORM ou DXGI_BC1_UNORM_SRGB) pour stocker des données de couleur à trois composants à l’aide d’une couleur 5:6:5 (rouge 5 bits, 6 bits vert, 5 bits bleu). Cela est vrai même si les données contiennent également une valeur alpha 1 bits. En supposant 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 composants/couleur × 1 octet/composant) à 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 index de couleurs 2 bits (blocs a à p), comme illustré dans le diagramme suivant.
Les index de couleurs (a–p) sont utilisés pour rechercher les couleurs d’origine à partir d’une table de couleurs. Le tableau de couleurs contient 4 couleurs. Les deux premières couleurs, color_0 et color_1, sont les couleurs minimales et maximales. Les deux autres couleurs, color_2 et color_3, sont des couleurs intermédiaires calculées avec une 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 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 de couleurs, et l’index de la couleur la plus proche est stocké dans les blocs 2 bits.
Cet algorithme se prête également aux données qui contiennent également des données alpha 1 bits. La seule différence est que color_3 est défini sur 0 (qui représente une couleur transparente) et color_2 est un mélange linéaire de color_0 et de color_1.
color_2 = 1/2*color_0 + 1/2*color_1;
color_3 = 0;
Différences entre Direct3D 9 et Direct3D 10 :
Ce format existe dans Direct3D 9 et 10.
- Dans Direct3D 9, le format BC1 est appelé D3DFMT_DXT1.
- Dans Direct3D 10, le format BC1 est représenté par DXGI_FORMAT_BC1_UNORM ou DXGI_FORMAT_BC1_UNORM_SRGB.
BC2
Utilisez le format BC2 (DXGI_FORMAT_BC2_TYPELESS, DXGI_FORMAT_BC2_UNORM ou DXGI_BC2_UNORM_SRGB) pour stocker les données contenant des données de couleur et alpha avec une faible cohérence (utilisez BC3 pour des données alpha hautement cohérentes). Le format BC2 stocke les données RVB sous la forme d’une couleur 5:6:5 (5 bits rouge, 6 bits vert, 5 bits bleu) et alpha sous la forme d’une valeur 4 bits distincte. En supposant une texture 4×4 utilisant le 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/couleur × 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 de données que le format BC1 ; Toutefois, BC2 nécessite 64 bits de mémoire supplémentaires pour stocker les données alpha, comme illustré dans le diagramme suivant.
Différences entre Direct3D 9 et Direct3D 10 :
Ce format existe dans Direct3D 9 et 10.
Dans Direct3D 9, le format BC2 est appelé D3DFMT_DXT2 et D3DFMT_DXT3.
Dans Direct3D 10, le format BC2 est représenté par DXGI_FORMAT_BC2_UNORM ou DXGI_FORMAT_BC2_UNORM_SRGB
BC3
Utilisez le format BC3 (DXGI_FORMAT_BC3_TYPELESS, DXGI_FORMAT_BC3_UNORM ou DXGI_BC3_UNORM_SRGB) pour stocker des données de couleur hautement cohérentes (utilisez BC2 avec des données alpha moins cohérentes). Le format BC3 stocke les données de couleur à l’aide de la couleur 5:6:5 (5 bits rouge, 6 bits vert, 5 bits bleu) et des données alpha à l’aide d’un octet. En supposant une texture 4×4 utilisant le 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/couleur × 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 de données que le format BC1 ; Toutefois, BC3 nécessite 64 bits de mémoire supplémentaire pour stocker les données alpha. Le format BC3 gère l’alpha en stockant deux valeurs de référence et en les interpolant (de la même façon que BC1 stocke la couleur RVB).
L’algorithme fonctionne sur 4×4 blocs de texels. Au lieu de stocker 16 valeurs alpha, l’algorithme stocke 2 alphas de référence (alpha_0 et alpha_1) et 16 indices de couleur 3 bits (alpha a à p), comme illustré dans le diagramme suivant.
Le format BC3 utilise les index alpha (a–p) pour rechercher les couleurs d’origine à partir d’une table de choix qui contient 8 valeurs. Les deux premières valeurs, alpha_0 et alpha_1, sont les valeurs minimales et maximales; les six autres valeurs intermédiaires sont calculées à l’aide d’une 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 interpole 4. Lorsque BC3 interpole seulement 4 valeurs alpha, il définit deux valeurs alpha supplémentaires (0 pour entièrement transparent et 255 pour entièrement opaque). BC3 compresse les valeurs alpha dans la zone texel 4×4 en stockant le code binaire correspondant aux valeurs alpha interpolées qui correspondent le plus étroitement à l’alpha d’origine 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
}
Différences entre Direct3D 9 et Direct3D 10 :
Dans Direct3D 9, le format BC3 est appelé D3DFMT_DXT4 et D3DFMT_DXT5.
Dans Direct3D 10, le format BC3 est représenté par DXGI_FORMAT_BC3_UNORM ou DXGI_FORMAT_BC3_UNORM_SRGB.
BC4
Utilisez le format BC4 pour stocker des données de couleur à un composant à l’aide de 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] à l’aide du format DXGI_FORMAT_BC4_UNORM et de [-1 à +1] à l’aide du format DXGI_FORMAT_BC4_SNORM. En supposant une texture 4×4 utilisant le format de données le plus grand possible, cette technique de compression réduit la mémoire requise de 16 octets (16 couleurs × 1 composants/couleur × 1 octet/composant) à 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 index de couleurs 3 bits (rouge a à p rouge), 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, sont les couleurs minimales et maximales. 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, BC4 interpole 6 valeurs de couleur ; sinon, il interpole 4. Lorsque BC4 interpole uniquement 4 valeurs de couleur, il définit deux valeurs de couleur supplémentaires (0,0f pour entièrement transparent et 1,0f pour entièrement opaque). BC4 compresse les valeurs alpha dans la zone texel 4×4 en stockant le code binaire correspondant aux valeurs alpha interpolées qui correspondent le plus étroitement à l’alpha d’origine pour un texel donné.
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 se voient attribuer des index 3 bits (000 à 111, car il y a 8 valeurs), qui seront enregistrés dans des blocs rouge a à p rouge 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 plage SNORM et lorsque 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 se voient attribuer des index 3 bits (000 à 111, car il y a 8 valeurs), qui seront enregistrés dans des blocs rouge a à p rouge pendant la compression.
BC5
Utilisez le format BC5 pour stocker des données de couleur à deux composants à l’aide de 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] à l’aide du format DXGI_FORMAT_BC5_UNORM et de [-1 à +1] à l’aide du format DXGI_FORMAT_BC5_SNORM. En supposant une texture 4×4 utilisant le format de données le plus grand possible, cette technique de compression réduit la mémoire requise de 32 octets (16 couleurs × 2 composants/couleur × 1 octet/composant) à 16 octets.
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 index de couleurs 3 bits pour chaque composant (rouge à rouge et vert a à vert), 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 minimales et maximales. 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 interpole 4. Lorsque BC5 interpole uniquement 4 valeurs de couleur, il définit les deux valeurs de couleur restantes sur 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 se voient attribuer des index 3 bits (000 à 111, car il y a 8 valeurs), qui seront enregistrés dans des blocs rouge a à p rouge pendant la compression.
BC5_SNORM
La DXGI_FORMAT_BC5_SNORM est exactement la 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 se voient attribuer des index 3 bits (000 à 111, car il y a 8 valeurs), qui seront enregistrés dans des blocs rouge a à p rouge pendant la compression.
Conversion de format à l’aide de Direct3D 10.1
Direct3D 10.1 permet d’effectuer des copies entre des textures préstructurées typées et des textures compressées par bloc de même largeur de bits. Les fonctions qui peuvent effectuer cette opération sont CopyResource et CopySubresourceRegion.
À compter de Direct3D 10.1, vous pouvez utiliser CopyResource et CopySubresourceRegion pour copier 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 en tant que type de format différent. Prenons l’exemple suivant qui montre la différence entre la réinterprétation des données avec le comportement d’un type de conversion plus classique :
FLOAT32 f = 1.0f;
UINT32 u;
Pour réinterpréter 'f' en tant que type '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 float en tant qu’entier non signé.
Pour effectuer le type de conversion le plus classique, 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 de source et de destination autorisés que vous pouvez utiliser dans ce type de conversion de format de réinterprétation. Vous devez encoder correctement les valeurs pour que la réinterprétation fonctionne comme prévu.
| Largeur de bits | Ressource non compressée | ressource Block-Compressed |
|---|---|---|
| 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 |
Rubriques connexes
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour