Optimiser le contenu compressé avec DirectStorage et XBTC

Utilisez cette rubrique pour comprendre certains scénarios de décompression de la nouvelle API DirectStorage du Microsoft Game Development Kit, ainsi que l’outil de compression de textures XBOX (XBTC) utilisé pour ingérer le contenu dans ces scénarios. L’objectif est de vous fournir des conseils pour obtenir des résultats optimaux en fonction des exigences de chaque titre.

Contenu

Clause d’exclusion de responsabilité
Introduction
Architecture
Unité de décompression mémoire
Empaquetage des données pour la MDU
Pavage des textures et Sampler Feedback Streaming (SFS)
Limites du pool de mémoire des opérations DirectStorage
Outil de compression de textures XBOX (XBTC.exe)
Considérations pour des performances optimales

Clause d’exclusion de responsabilité

Les mesures de performances de cette rubrique ont été effectuées avec le GDK de juin 2020 et la récupération correspondante, à l’aide des kits de développement livrés dans le cadre du renouvellement matériel à partir de juillet 2020. Toutes les mesures proviennent de XVC empaquetés installés sur la console en mode de lecteur commercial (retail drive mode). Les mesures effectuées avec des déploiements de fichiers libres (Loose file) devraient être légèrement inférieures, car le lecteur de développement peut présenter une fragmentation des données et ne peut pas utiliser certaines des optimisations de performances qui existent pour les XVC en lecture seule. Les mesures provenant de consoles qui ne sont pas configurées en mode de lecteur commercial présentent des caractéristiques de performances différentes. Tous les nombres indiqués dans cette rubrique utilisent la notation standard du secteur pour différencier les nombres en base 10 et en base 2. Les nombres en base 2 utilisent la notation kibioctet (Kio) ou mébioctet (Mio). Les nombres en base 10 utilisent le préfixe SI, kilooctet (Ko) ou mégaoctet (Mo), comme illustré dans les exemples suivants.

1 Mo == 1 000 000 octets
1 Mio == 1 048 576 octets

Introduction

Cette rubrique explique comment utiliser l’outil de compression de textures XBOX (XBTC) et l’unité de décompression mémoire (MDU) par le biais de l’API DirectStorage, y compris les bonnes pratiques permettant d’obtenir des performances maximales. Avant de lire cette rubrique, vous devez d’abord lire la rubrique Utilisation et détails internes de DirectStorage, qui traite des caractéristiques de débit d’E/S sous-jacentes du SSD NVMe. La MDU des consoles XBOX Series comporte plusieurs étapes et prend en charge plusieurs opérations sur les mêmes données. Elle peut être utilisée isolément pour effectuer une décompression en mémoire ou, plus couramment, au sein du pipeline d’E/S DirectStorage pour décompresser de manière transparente le contenu à mesure qu’il est chargé depuis le stockage. La MDU est conçue pour que son débit dépasse le débit d’E/S NVMe complet de 2 Go/s d’octets compressés provenant du stockage.

Architecture

DirectStorage a été conçu pour atteindre la bande passante la plus élevée avec la plus faible surcharge processeur. Il traite des lots de requêtes selon un modèle de pipeline, comme illustré dans la figure 1 de la section Unité de décompression mémoire de cette rubrique. Pour plus d’informations sur l’architecture sous-jacente de l’ensemble du système, consultez Utilisation et détails internes de DirectStorage. DirectStorage est directement lié à l’unité de décompression mémoire (MDU), de sorte que vous pouvez également décharger le processeur de toutes les tâches de décompression avec un effort minimal. La MDU fonctionne à l’aide d’un pool de mémoire intermédiaire partagé par tous les scénarios DirectStorage, et écrit les résultats directement dans la mémoire tampon de destination fournie par le titre. Chaque requête DirectStorage est mise en file d’attente avec des métadonnées indiquant comment le flux de données doit être traité lors de son passage dans la MDU. Pour utiliser cette fonctionnalité, les ressources doivent être empaquetées de sorte que les flux de données individuels, ainsi que les métadonnées qui les décrivent, puissent être chargés dans des requêtes DirectStorage distinctes. Une fois les métadonnées de flux d’une ressource chargées, les flux de données individuels sont décompressés de manière transparente dans le cadre des requêtes d’E/S adressées au SSD NVMe, en fonction des options associées à chaque requête. Lorsqu’un flux de données a été chargé par une autre méthode, comme une requête réseau, la décompression peut s’effectuer entre des mémoires tampons spécifiées par le titre, à l’aide d’un autre type de file d’attente et de requête DirectStorage. Pour le scénario principal des textures, qui constituent l’essentiel des ressources de la plupart des titres, l’outil XBTC facilite la compression et l’encapsulation des ressources en vue de leur décompression à l’exécution.

Unité de décompression mémoire

L’unité de décompression mémoire (MDU) se compose de deux modules matériels distincts, chacun comportant trois étapes de fonctionnement, comme illustré dans la figure 1. Chaque module matériel a une vitesse de lecture maximale de 1,6 Go/s et un débit sortant de 4 Go/s ; le débit combiné (3,2 Go/s en entrée et 8 Go/s en sortie) dépasse donc le débit de 2 Go/s que le NVMe peut soutenir. Cela signifie que, dans les scénarios classiques, la MDU peut également traiter des requêtes de décompression en mémoire, même si elle sature déjà les E/S du SSD NVMe. Le débit réellement atteignable par un titre dépend du taux de compression du contenu, de la façon dont il est empaqueté, du modèle d’accès et de l’utilisation spécifique de l’API DirectStorage. Les chiffres de débit précédents (3,2 Go/s en entrée et 8 Go/s en sortie) représentent les limites pratiques pour du contenu réel, en présence d’autres E/S. Lorsque la MDU est utilisée pour décompresser des pages parfaitement compressibles comme une forme de memset, la limite absolue est de 12 Go/s en sortie vers la mémoire. L’exemple SimpleMDU illustre les comportements de débit. Figure 1. Présente les trois étapes de fonctionnement de la MDU, notamment la décompression zlib, BCPack et Swizzle Block ; elles sont partagées entre toutes les files d’attente DirectStorage

Capture d'écran de la décomposition des trois étapes de la MDU

Les trois opérations peuvent être effectuées successivement sans réduction de vitesse, et les résultats sont directement stockés dans la mémoire du titre spécifiée dans l’objet de requête mis en file d’attente. N’importe quelle étape peut être ignorée, en fonction de DSTORAGE_REQUEST_OPTIONS. Les ressources autres que les textures n’utilisent normalement que la première étape zlib et sont écrites directement dans la mémoire du titre. Les ressources de texture peuvent utiliser n’importe quelle combinaison des trois étapes, les résultats étant écrits dans la mémoire du titre. Les lectures non compressées ignorent toutes les étapes, mais elles sont tout de même déplacées vers la mémoire du titre par la MDU.

Étape zlib de la MDU

Vous pouvez décompresser des flux de données conformes à IETF RFC 1950 à l’aide de la première étape de la MDU, également appelée compression zlib ou Deflate. Les consoles XBOX Series prennent en charge la taille de fenêtre complète de 32 Kio définie dans la spécification et ne présentent pas la limitation de 4 Kio qui existait sur la famille de consoles XBOX One. Il existe toutefois deux écarts par rapport à la spécification. Premièrement, la taille compressée doit être inférieure à la taille décompressée. Si un flux de données atteint une taille égale ou supérieure en raison de la compression appliquée, il doit plutôt être empaqueté sous forme de données non compressées. Les outils et les chemins de chargement du titre doivent pouvoir distinguer les segments de données compressés des segments non compressés. Deuxièmement, il existe une limite supérieure à la taille des flux de données décompressés, basée sur les tailles de réservation de mémoire effectuées pour le compte du titre (32 Mio). Pour activer cette étape de la MDU pour un flux de données donné, l’indicateur suivant doit être défini sur DSTORAGE_REQUEST::Options. UINT64 DSTORAGE_REQUEST_OPTIONS::ZlibDecompress:1 En outre, si zlib est appliqué par-dessus BCPack pour un flux de données, DSTORAGE_REQUEST::IntermediateSize doit être défini sur la taille attendue du flux de données, après la décompression zlib et avant la décompression BCPack. Sinon, IntermediateSize doit être laissé à zéro. Lors de l’analyse et du chargement d’archives XBTC, la présence d’une compression zlib pour un flux est indiquée lorsque son XBTC_STREAM_INFO a une valeur InflatedSize différente de sa valeur CompressedSize. Le code suivant, tiré du fichier TiledTexture.cpp de l’exemple SimpleSFS, l’illustre.

for (UINT x = 0; x < TilingInfo[mip].WidthInTiles; x++)
{
    auto tileInfo = xbtcFile.GetStreamInfo(tileIndex);
    Tiles[tileIndex].LoadSize = tileInfo->CompressedSize;
    Tiles[tileIndex].OffsetInFile = baseOffset + tileInfo->RelativeOffset;
    Tiles[tileIndex].Coord = { x, y, 0, mip };
    Tiles[tileIndex].ZlibCompressed = (tileInfo->CompressedSize != tileInfo->InflatedSize);   //  <<---
    Tiles[tileIndex].BCPacked = (tileInfo->UncompressedSize != tileInfo->InflatedSize);

    auto parentTileX = x >> 1;
    auto parentTileY = y >> 1;
    Tiles[tileIndex].pParentTile = GetTile(parentTileX, parentTileY, mip + 1);

    tileIndex++;

    // Tiles are required to be 64 KB.
    assert(tileInfo->UncompressedSize == D3D12_TILED_RESOURCE_TILE_SIZE_IN_BYTES);
}

Étape BCPack de la MDU

BCPack est un nouvel algorithme de compression de textures de Microsoft qui cible spécifiquement les formats de texture GPU compressés par blocs (BC1-7) et qui comprend les modèles de swizzle de texture natifs des consoles XBOX Series. Il existe un ensemble de chemins d’encodage et de décodage propres à chaque format compressé par blocs. Pour chaque flux compressé, le type d’encodeur (ou son absence) doit être connu et spécifié au moment de la requête de décompression. BCPack est activé, et le décodeur spécifique est sélectionné pour une DSTORAGE_REQUEST donnée, en définissant l’option suivante.

Lorsque vous combinez avec la compression zlib, IntermediateSize doit être défini. Sinon, il est laissé à zéro.

DSTORAGE_BCPACK_MODE DSTORAGE_REQUEST_OPTIONS::BcpackMode: 4  
enum DSTORAGE_BCPACK_MODE : UINT64 {  
    DSTORAGE_BCPACK_MODE_NONE = 0,
    DSTORAGE_BCPACK_MODE_BC1  = 1,  
    DSTORAGE_BCPACK_MODE_BC2  = 2,  
    DSTORAGE_BCPACK_MODE_BC3  = 3,  
    DSTORAGE_BCPACK_MODE_BC4  = 4,  
    DSTORAGE_BCPACK_MODE_BC5  = 5,  
    DSTORAGE_BCPACK_MODE_BC6H = 6,  
    DSTORAGE_BCPACK_MODE_BC7  = 7,  
};

Lors de l’analyse et du chargement d’archives XBTC, la présence d’une compression zlib pour un flux est indiquée lorsque son XBTC_STREAM_INFO a une valeur InflatedSize différente de sa valeur UncompressedSize. Cela est également illustré dans l’exemple de code SimpleSFS précédent.

Étape Swizzle Block de la MDU

L’étape Swizzle Block peut appliquer des transformations supplémentaires aux données non compressées lors de leur écriture dans la mémoire du titre. À partir du GDK de mars 2024, plusieurs modes sont disponibles ; ils sont conçus pour permettre des réductions supplémentaires de la taille compressée pour BC1, BC3, BC4 et BC5 lorsqu’ils sont utilisés conjointement avec Deflate ou BCPack. Pour plus d’informations sur ces formats, consultez Formats de shuffle DirectStorage. Le swizzle est contrôlé par le code suivant. Il doit être défini sur DSTORAGE_SWIZZLE_MODE_NONE (0) si les formats de shuffle spécialisés ne sont pas utilisés. DSTORAGE_SWIZZLE_MODE DSTORAGE_REQUEST_OPTIONS::SwizzleMode: 16 Si vous avez un scénario qui, selon vous, bénéficierait de transformations de swizzle supplémentaires des texels après décompression non couvertes par nos options actuelles, contactez votre gestionnaire de compte Microsoft.

Empaquetage des données pour la MDU

Lors de la création de flux de données destinés à être décompressés par le matériel MDU, il existe deux chemins principaux : la compression Deflate seule, principalement destinée aux ressources autres que les textures, et la compression Deflate plus BCPack, destinée aux ressources de texture. Dans le premier scénario, vous êtes libre de choisir les tailles de flux de données qui répondent le mieux à vos besoins, tandis que le second scénario prédéfinit les tailles des flux compressés. Dans les deux scénarios, les mêmes exigences de base s’appliquent. Comme pour les autres requêtes adressées au SSD NVMe, les flux de données doivent être alignés sur 16 octets. La MDU prend également en charge un ensemble limité d’options de swizzle ou de shuffle qui fonctionnent conjointement avec Deflate et BCPack. Pour plus d’informations sur ces formats, consultez Formats de shuffle DirectStorage.

Pavage des textures et Sampler Feedback Streaming (SFS)

Le pavage des textures (tiling) est une méthode qui consiste à diviser les grandes textures en petites sous-sections pouvant être chargées individuellement. On parle parfois aussi de textures partiellement résidentes (PRT), de textures virtuelles ou de ressources en mosaïque (Tiled Resources). Avec le pavage des textures, seules les parties des textures nécessaires sont chargées ; les titres peuvent ainsi utiliser plus efficacement la mémoire disponible en ayant un plus grand nombre de ressources de texture en cours d’utilisation à tout moment. Les consoles XBOX Series disposent d’extensions matérielles dans le GPU qui rendent l’implémentation de ce système plus simple et plus efficace à l’exécution. Ce système combiné est appelé Sampler Feedback Streaming (SFS). Les consoles XBOX Series utilisent des tailles de page de 64 Kio pour les ressources graphiques, ce qui correspond à la taille des modèles de swizzle de texture natifs les plus courants lors de l’optimisation du contenu pour la disposition native du GPU. L’objectif principal de SFS est de garantir que votre titre dispose de la plus grande quantité possible de ressources graphiques activement utilisées, en ne conservant pas en mémoire résidente les parties inutilisées de ces ressources. C’est pourquoi 64 Kio a été choisi comme taille de base pour SFS : chaque page de 64 Kio d’une texture est indépendante et peut être chargée et supprimée isolément. Il s’agit de l’utilisation de la mémoire la plus granulaire et la plus efficace. Pour plus d’informations sur les dispositions de texture, consultez Sampler Feedback Streaming et Dispositions de texture XBOX Series X|S (nouveau). Pour illustrer la relation entre les tuiles de texture et SFS, prenons une texture BC7 carrée de 2048 × 2048. Elle se compose des 86 tuiles suivantes (64 Kio chacune). BC7 nécessite 16 octets par bloc de 4 × 4 texels ; mip0 nécessite donc (2048 × 2048) = 4 194 304 octets = 4 096 Kio = 64 pages de 64 Kio chacune. Chaque mip au-delà de mip0 fait un quart de la taille, ou fait partie de la queue de mips (mip tail), comme illustré dans la figure 2. Figure 2. Présente une texture BC7 de 2048 × 2048 composée de 86 pages de 64 Kio chacune ; lorsqu’elle est empaquetée pour SFS, chaque page est une tuile diffusable distincte

Capture d'écran de la disposition d'une texture BC7 2K

Toute implémentation de textures partiellement résidentes peut utiliser n’importe quel multiple entier de la taille de tuile de base de 64 Kio comme plus petite unité de chargement et de suppression. Pour SFS, la taille de base de 64 Kio est utilisée ; la texture mentionnée précédemment est donc transformée en 86 flux compressés utilisés pour une récupération individuelle à l’exécution. Lorsque vous décidez comment empaqueter les ressources du jeu, la compressibilité varie en fonction de l’encodage de ces ressources, de la taille des flux et du contenu de chaque ressource. Deux exemples de pools de contenu sont présentés dans les figures 3 et 4. Ces graphiques représentent le pool de textures 4096 × 4096 livré à l’origine avec la démo HDR et 4K « Insects » de la XBOX One X. Chaque graphique présente ce pool de contenu avec un encodage spécifique (BC1 ou BC7), puis empaqueté selon les scénarios suivants.

Compression Deflate seule, qui divise les données en tailles prédéfinies et compresse chacune individuellement (zlib ou zopfli)
Compression Deflate plus BCPack à l’aide de XBTC
- Pavage SFS de 64 Ko compressé avec zlib, ou zopfli plus BCPack
Compression de mips entiers pour la diffusion en continu de niveaux de détail (LOD) hors SFS, zlib, ou zopfli plus BCPack

Figure 3. Présente la taille compressée selon l’option d’empaquetage du pool de contenu BC7 Insects HDR 4K

Capture d'écran de la taille compressée selon l'option d'empaquetage du pool de contenu BC7 Insects HDR 4K

Figure 4. Présente la taille compressée selon l’option d’empaquetage du pool de contenu BC1 Insects HDR 4K

Capture d'écran de la taille compressée selon l'option d'empaquetage du pool de contenu BC1 Insects HDR 4K

Les deux implémentations de Deflate (zlib et zopfli) obtiennent de meilleurs taux de compression à mesure que la taille des tuiles et des blocs compressés individuellement augmente, mais avec des rendements décroissants (les tuiles plus grandes sont préférables). Les deux options Deflate atteignent leur taux de compression maximal pour des flux d’environ 1 024 Kio, les tailles supérieures n’offrant aucun avantage à cet égard. Zopfli offre de meilleurs taux de compression (1 à 2 %) que zlib, mais avec un coût de calcul du temps de compression bien plus élevé (environ 10 fois). Les options BCPack plus Deflate disponibles via XBTC offrent des taux de compression nettement supérieurs à toute option Deflate seule. Nous recommandons vivement les options BCPack plus Deflate pour les ressources de texture.

L’empaquetage xbtc-mip utilise un seul flux de données par mip et présente donc une taille de flux de données variable. Il est placé à une taille de tuile de 4 Mio à des fins de comparaison, afin de montrer que, bien qu’il renonce à l’avantage d’une taille de tuile plus petite et d’une utilisation plus granulaire de la mémoire, il n’apporte pas d’amélioration de la compression par rapport au scénario SFS principal.

Exigences du pool de mémoire pour les opérations DirectStorage

Lorsque le titre initialise DirectStorage pour la première fois en appelant DStorageGetFactory, 32 Mio de mémoire sont réservés pour la mémoire tampon intermédiaire (Staging Buffer), qui contient les opérations en cours. Cette taille par défaut peut être modifiée après l’initialisation de DirectStorage à l’aide de la méthode SetStagingBuffer, ce qui permet d’économiser de la mémoire pour votre titre. Cette mémoire est partagée avec les autres étapes de la pile DirectStorage. La dernière étape utilisée pour une requête écrit la sortie finale directement dans la mémoire du titre. Voici les limitations du système.

Pour les requêtes de décompression, les tailles compressées doivent être inférieures aux tailles décompressées.
La limite de taille supérieure pour toute requête DirectStorage individuelle est de 1 Gio. Pour les requêtes de décompression, il s’agit de la somme des tailles source et de destination.

Les limites sont appliquées au moment où les requêtes sont mises en file d’attente, et des comportements de débogage supplémentaires sont disponibles pour ces conditions d’erreur à l’aide de la méthode SetDebugFlags.

Outil de compression de textures XBOX (XBTC.exe)

Pour les consoles XBOX Series, vous pouvez importer, exporter et encoder des textures à l’aide de l’outil XBTC du GDK. Cela s’effectue via une interface de ligne de commande dans XBTC.exe, sous forme de bibliothèque XBTC.dll, ou sous forme de code source une fois des exigences NDA supplémentaires remplies. L’ensemble d’outils se trouve, dans une installation par défaut du GDK, dans *C:\Program Files (x86)\Microsoft GDK[version]\GXDK\bin\Scarlett*. Si vous avez besoin d’accéder au code source de l’ensemble d’outils, contactez votre gestionnaire de compte Microsoft.

Importation de contenu

XBTC prend en charge l’importation directe à partir d’une grande variété de formats, notamment .png, .tiff et .jpg, et peut également exporter vers ces types de fichiers. XBTC contient un encodeur pour les formats GPU BC1-BC7 et peut appliquer un swizzle au contenu vers ou depuis les dispositions de texture GPU natives de la XBOX Series X|S. Chaque fois que XBTC effectue une opération avec perte, comme la conversion d’une ressource brute en un format compressé par blocs, il produit des métriques de qualité d’image pour cette conversion. Lors de l’exportation vers un fichier .dds, seules les parties importateur et encodeur BC de XBTC sont utilisées. Aucune compression n’est appliquée.

Compression

XBTC travaille sur une région de texture sélectionnée et compresse cette région dans un sous-flux au sein d’un fichier d’archive plus grand. Par défaut, il compresse chaque région de trois manières différentes (Deflate seul, BCPack seul, BCPack puis Deflate). Le meilleur des trois résultats est enregistré, avec les métadonnées de cette région, et les deux autres sont ignorés. La façon dont une texture est divisée en régions dépend de l’utilisation prévue de cette texture, ainsi que des options --tilemode et --mipstreams transmises à XBTC.

Sélection de régions SFS

Dans l’exemple d’une texture BC7 carrée 2K, la disposition de texture sous-jacente comportait 86 pages de 64 Kio chacune. Il existe deux méthodes de sélection de régions, comme illustré dans la figure 5. À gauche se trouve le mode de pavage SFS, dans lequel chaque page est traitée séparément, avec l’hypothèse par défaut selon laquelle tous les mips doivent pouvoir être diffusés séparément. Le résultat est de 86 régions distinctes. À droite se trouve la même texture, mais en indiquant à XBTC qu’un seul mip doit pouvoir être diffusé. Dans ce cas, il existe 65 flux : 64 pour mip0 et un flux supplémentaire. Ce flux supplémentaire combine tous les autres mips, étant entendu que les mips non diffusables résident toujours en mémoire. Figure 5. Présente (à gauche) des textures BC7 2K avec un pavage SFS de 64 Kio et tous les mips diffusables (86 flux de tuiles), et (à droite) la même texture SFS avec un seul mip diffusable (65 flux de données)

Capture d'écran d'une texture SFS avec tous les mips diffusables, et avec un seul mip diffusable

Sélection de régions hors SFS

Pour tout contenu qui n’est pas destiné à être utilisé dans un contexte de texture virtuelle SFS, ou qui ne charge des LOD que par mips entiers, les mêmes principes s’appliquent, bien qu’il y ait moins de régions. Pour cette même texture BC7 2K, l’utilisation du mode de tuile hors SFS par défaut de 64 Ko entraîne la compression individuelle des cinq régions illustrées dans la figure 6. Si vous souhaitez spécifier que seuls deux mips sont diffusables, les trois régions sont traitées individuellement, les mips 2 à 11 étant combinés dans le flux toujours résident. Figure 6. Présente (à gauche) une texture BC7 2K avec un pavage hors SFS de 64 Kio et tous les mips diffusables (cinq flux de données), et (à droite) la même texture avec deux mips diffusables et un flux de données toujours résident contenant les mips 2 à 11

Capture d'écran d'une texture hors SFS avec tous les mips diffusables, et avec un seul mip diffusable

Pour les textures extrêmement volumineuses, d’une taille supérieure ou égale à 8K, il est possible d’avoir des mips qui dépassent la taille maximale (32 Mio) autorisée par le matériel MDU. Pour résoudre ce problème, une version à venir propose des options permettant de diviser les mips de texture hors SFS en tuiles de taille optimale pour un chargement séquentiel.

Application

Une fois déterminées les régions de la texture compressées individuellement, et l’une des implémentations de Deflate sélectionnée (selon la présence ou l’absence du commutateur --usezopfli), chaque région est compressée trois fois : une fois avec l’implémentation de Deflate, une fois avec BCPack et une fois en appliquant les deux. La MDU peut traiter n’importe laquelle de ces combinaisons (ou du contenu non compressé) à la vitesse d’E/S maximale ; vous pouvez donc sélectionner le meilleur encodage pour une région de données donnée. La structure de données obtenue est empaquetée dans un fichier d’archive XBTC, qui correspond à l’ensemble des flux compressés, accompagnés d’un en-tête qui les décrit. Vous pouvez utiliser le fichier d’archive tel quel et vous appuyer sur le code des exemples du GDK pour les charger, ou extraire les flux compressés et les métadonnées afin de les réempaqueter dans le conteneur le plus adapté. À l’exécution, les données d’en-tête alimentent directement les requêtes DirectStorage pour cette ressource.

Optimisation débit-distorsion (RDO)

Vous pouvez sacrifier une partie de la qualité de compression au profit d’un taux de compression supplémentaire à l’aide de la RDO. Pour les formats compressés par blocs (BC1-7), cela peut se limiter à réencoder les blocs d’une manière différente. Le réencodage vous permet de réduire le nombre de points de couleur distincts, ou de forcer les points de couleur à correspondre à leurs voisins, afin que la compression supplémentaire appliquée à la texture atteigne des taux plus élevés. La version 2006 QFE1 du GDK a ajouté des options RDO à XBTC pour BC1-5, d’autres modes étant prévus dans les versions futures. L’implémentation de la RDO dans XBTC existe uniquement au sein de l’étape d’encodeur BC et peut être utilisée lors de l’exportation vers un fichier .dds. Elle est toutefois conçue en tenant compte du compresseur BCPack. L’application de la RDO ne se limite pas à la sélection d’un paramètre de compression ou de qualité. Différents types et encodages de ressources peuvent avoir des paramètres de qualité idéaux différents. Les paramètres appropriés nécessitent souvent d’itérer sur un système de règles, avec des vérifications ponctuelles et des ajustements si nécessaire. Pour faciliter cela, XBTC propose les sous-commandes supplémentaires compare, view et export. Vous pouvez exécuter une analyse de la qualité d’image à l’aide de la sous-commande compare. Cette sous-commande compare la ressource RDO à l’original ou à la ressource BC antérieure à la RDO. Vous pouvez utiliser ces sous-commandes pour créer diverses règles. Par exemple, une règle pour un titre donné pourrait être qu’une perte de 2 décibels (dB) de rapport signal sur bruit de crête (PSNR) est acceptable pour les cartes normales BC1. Lorsqu’une ressource est ajoutée ou modifiée, une passe unique doit être effectuée pour déterminer quel niveau de qualité correspond à cette perte de qualité acceptable. Vous pouvez charger la ressource pour l’inspecter à l’aide de la sous-commande view. Cela facilite la vérification ponctuelle des ressources traitées et permet de déterminer si des modifications de règles ou des exceptions sont nécessaires. Vous pouvez également conserver ces informations pour les builds futures. Vous pouvez aussi utiliser export pour exporter l’image vers un autre format afin de la traiter avec d’autres outils.

La RDO modifie le taux de compression et peut avoir d’autres implications sur le chargement optimal.

Le contenu BC1 est généralement plus compressible que le BC7 (2:1, contre 1,6:1) ; la taille compressée des tuiles BC1 de 64 Kio est donc d’environ 32 Kio en moyenne. Réduire la taille compressée de 25 % supplémentaires à l’aide de la RDO ne se traduit pas directement par 25 % de débit supplémentaire vers la mémoire, en raison de la surcharge liée au grand nombre de petites requêtes d’E/S. Si vous utilisez un pavage de plus grande taille, le débit de la MDU évolue directement avec le taux de compression. Toutefois, l’effet s’atténue pour le contenu très compressible qui commence à approcher les limites de sortie de 8 Gio/s de la MDU. La figure 7 illustre cette combinaison d’effets à l’aide des textures en résolution 4K de la démo HDR et 4K Insects. Dans ce cas, un paramètre RDO (qualité et compression) a été sélectionné de sorte que les archives XBTC obtenues soient environ 14 % plus petites que les versions par défaut sans RDO, soit 7 % de plus si on les compare à la taille d’origine non compressée. Il convient de noter que l’encodeur RDO de XBTC organise de préférence les données pour une compression optimale avec BCPack dans le cadre de la chaîne de compression XBTC. Ainsi, le scénario SFS bénéficie d’un gain relatif plus élevé que lors de l’utilisation de Deflate dans un scénario hors SFS, comme illustré dans la figure 7. Figure 7. Présente le pool de contenu Insects HDR 4K, taille BC1, comparé à une option RDO

Capture d'écran du pool de contenu Insects HDR 4K, taille BC1, comparé à une option RDO

À l’exécution, la combinaison de ces effets se traduit par les caractéristiques de débit suivantes. Lorsque XBTC est utilisé pour l’encodeur RDO, puis que l’empaquetage est effectué sous une forme hors SFS avec des tailles de flux variables, un débit supérieur d’environ 13 % est observé pour les tailles plus grandes (supérieures ou égales à 128 Kio). Cette différence reflète presque l’avantage de compression. Les tailles de flux de données plus petites (inférieures ou égales à 64 Kio) entraînent des améliorations décroissantes, comme illustré dans la figure 8. Figure 8. Présente le pool de contenu Insects HDR 4K, BC1, avec le débit de la MDU comparé à une option RDO

Capture d'écran du pool de contenu Insects HDR 4K, BC1, avec le débit de la MDU comparé à une option RDO

Restrictions de mode de l’encodeur BC7

BC7 permet d’encoder chaque groupe de 4 × 4 texels selon l’un des 8 modes, en fonction du mode qui préserve la plus grande fidélité pour ce groupe. Grâce à cela, les encodeurs produisent des textures GPU natives de très haute qualité, mais cela signifie également que l’entropie des bits encodés de la texture obtenue est plus élevée, car le modèle d’encodage change souvent d’un mode à l’autre. Les textures BC7 sont intrinsèquement moins compressibles que de nombreux autres formats compressés par blocs. L’encodeur BC7 de XBTC propose des options permettant de limiter les modes disponibles, ce qui sacrifie directement une partie de la fidélité supérieure du format pour unifier le modèle encodé et le rendre ainsi beaucoup plus compressible. L’utilisation de ces options peut modifier considérablement la compressibilité de la texture obtenue ; nous vous encourageons toutefois à effectuer des vérifications ponctuelles et à itérer sur ces paramètres afin de vérifier que la texture obtenue ne présente qu’une perte de qualité faible ou imperceptible. Le pool de données de textures 4K de la démo XBOX One Insects HDR est présenté dans la figure 9. L’encodage BC7 normal, avec tous les modes activés, produit un pool de textures que Zopfli peut compresser à 64 % de sa taille d’origine, ou à 61,5 % s’il est combiné avec BCPack à l’aide de XBTC. Cependant, si seul le Mode 7 est autorisé (--bc7modes 0x80), les textures obtenues sont beaucoup plus compressibles, dépassant un rapport de 2:1, tout en conservant un avantage de 3 à 5 dB de PSNR par rapport aux mêmes textures encodées en BC1 avec une fidélité inférieure. Figure 9. Présente la compressibilité du pool de contenu Insects HDR 4K, BC7 avec tous les modes par rapport au Mode 7 uniquement

Capture d'écran de la compressibilité du pool de contenu Insects HDR 4K, BC7 avec tous les modes par rapport au Mode 7 uniquement

Ce taux de compression supplémentaire se traduit directement par un débit plus élevé vers la mémoire au moment du chargement. Les caractéristiques de débit de ce contenu BC7 encodé avec les paramètres par défaut (modes 0 à 7) et avec le Mode 7 seul activé sont présentées dans la figure 10.

La vitesse de lecture depuis le NVMe est quasiment identique, le contenu en Mode 7 seul offrant un avantage de débit d’environ 20 à 40 %, mesuré à la sortie de la MDU.

Figure 10. Présente le débit de la MDU pour le pool de contenu Insects HDR 4K, BC7, avec tous les modes par rapport au Mode 7 uniquement

Capture d'écran du débit de la MDU pour le pool de contenu Insects HDR 4K, BC7, avec tous les modes par rapport au Mode 7 uniquement

Considérations pour des performances optimales

Les recommandations de la rubrique Utilisation et détails internes de DirectStorage s’appliquent lors de l’utilisation de la MDU pour la décompression.

Maintenez suffisamment de requêtes en cours pour que le pipeline reste plein. Par exemple, si vous alimentez les files d’attente toutes les 16,7 ms, 33,4 Mo de données compressées peuvent être chargés pendant cet intervalle.

Pour que le pipeline reste plein entre deux ajouts, maintenez 33,4 Mo plus 32 Mio de requêtes en cours, soit un total d’environ 64 Mio. Cependant, comme le débit réel du SSD NVMe peut varier dans le temps et que la garantie de 2 000 Mo/s s’applique sur toute période de 250 ms, les titres doivent maintenir en cours plus que ce minimum de 64 Mio pour contribuer à maximiser le débit. Voici d’autres facteurs propres à la nature de l’implémentation matérielle de la MDU.

Chaque tâche soumise au matériel MDU entraîne un léger coût d’initialisation et de configuration. Évitez un grand nombre de petites tâches. En pratique, si vous essayez d’approcher le débit du SSD NVMe, la limite de taille inférieure pour les requêtes est de 32 Kio compressés (64 Kio décompressés).
- Toutefois, le débit maximal n’est atteint qu’avec des tailles de flux deux à quatre fois supérieures. Le débit de lecture du contenu 4K de la démo Insects HDR, selon l’option d’empaquetage, chute fortement pour une taille non compressée inférieure à 64 Kio, comme illustré dans les figures 11 et 12. Figure 11. Présente le débit de chargement du pool de contenu Insects HDR 4K, BC1, selon l’option d’empaquetage Figure 12. Présente le débit de chargement du contenu Insects HDR 4K, BC7, selon l’option d’empaquetage
Les requêtes volumineuses de plus de 512 Kio de données compressées sont divisées en plusieurs requêtes d’E/S, puis soumises à la MDU sous forme de plusieurs requêtes une fois les données récupérées depuis le SSD NVMe. Cela a un effet faible mais mesurable sur le débit des requêtes volumineuses, affectant surtout les flux de données dont la taille compressée dépasse tout juste ce seuil.
Le taux de compression fait évoluer directement le débit final d’octets décompressés vers la mémoire du titre. La RDO, ou les restrictions de mode BC7, produisent un double effet : une taille compressée plus petite et des temps de chargement plus rapides. Pour plus d’informations et d’exemples, consultez les sections Restrictions de mode de l’encodeur BC7 et RDO de cette rubrique.
Pour les données de texture, l’utilisation du pavage SFS de 64 Kio de XBTC, conjointement avec BCPack et Deflate tuile par tuile, offre la meilleure compression prise en charge par le matériel, associée au débit le plus élevé (ou comparable) par rapport aux autres options.

Voir aussi

DirectStorage Utilisation et détails internes de DirectStorage Analyse des performances de DirectStorage Liste des exemples du GDK

Introduction

Onboarding & Access

Setup & Install

Build Your First Title

Optimiser le contenu compressé avec DirectStorage et XBTC

Contenu

Clause d’exclusion de responsabilité

Introduction

Architecture