Optimiser le contenu compressé avec DirectStorage et XBTC

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

Contenu

Avis de non-responsabilité
Introduction
Architecture
Unité de décompression de 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

Avis de non-responsabilité

Les mesures de performances de cette rubrique ont été prises avec le GDK et la récupération de juin 2020, à l’aide de kits de développement livrés dans le cadre du renouvellement matériel amorcé en 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 de l’industrie 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 le montrent 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 de mémoire (MDU) au moyen de l’API DirectStorage, y compris les meilleures pratiques pour obtenir des performances maximales. Avant de lire cette rubrique, vous devriez d’abord lire la rubrique Utilisation et détails internes de DirectStorage, qui couvre les 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 seule pour effectuer une décompression en mémoire, ou plus couramment, dans le pipeline d’E/S de DirectStorage pour décompresser de manière transparente le contenu pendant son chargement à partir du stockage. La MDU est conçue de sorte que son débit dépasse le plein débit d’E/S NVMe 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 du processeur. Il traite des lots de requêtes selon un modèle de pipeline, comme le montre la figure 1 de la section Unité de décompression de mémoire de cette rubrique. Pour plus d’information 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 de mémoire (MDU), de sorte que vous pouvez aussi 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 vers le SSD NVMe, selon les options associées à chaque requête. Dans les situations où un flux de données a été chargé par une autre méthode, comme une requête réseau, la décompression peut se faire entre des mémoires tampons spécifiées par un titre en utilisant un autre type de file d’attente et de requête DirectStorage. Pour le scénario principal des textures, qui constituent la majeure partie 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 de mémoire

L’unité de décompression de mémoire (MDU) est composée de deux modules matériels individuels, chacun comportant trois étapes de fonctionnement, comme le montre 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, de sorte que le débit combiné (3,2 Go/s en entrée et 8 Go/s en sortie) dépasse le débit de 2 Go/s que le NVMe peut soutenir. Cela signifie que dans des scénarios typiques, la MDU peut aussi 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éel qu’un titre peut atteindre 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 précise 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. Illustre les trois étapes de fonctionnement de la MDU, soit la décompression zlib, BCPack et Swizzle block; celles-ci sont partagées par toutes les files d’attente DirectStorage

Capture d'écran de la répartition des trois étapes de la MDU

Les trois opérations peuvent être effectuées en séquence sans réduction de vitesse, et les résultats sont stockés directement 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, selon les DSTORAGE_REQUEST_OPTIONS. Les ressources autres que des 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, aussi appelée compression zlib ou Deflate. Les consoles XBOX Series prennent en charge la taille de fenêtre complète de 32 Kio prévue par la spécification, et n’ont pas la limite de 4 Kio qui existait sur la famille de consoles XBOX One. Deux écarts par rapport à la spécification existent toutefois. D’abord, la taille compressée doit être inférieure à la taille décompressée. Si vous avez un flux de données qui atteint une taille égale ou supérieure en raison de la compression appliquée, il devrait plutôt être empaqueté en tant que 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. Ensuite, il existe une limite supérieure à la taille d’un flux de données décompressé, fondée sur les tailles de réservation de mémoire effectuées au nom 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 dans DSTORAGE_REQUEST::Options. UINT64 DSTORAGE_REQUEST_OPTIONS::ZlibDecompress:1 De plus, si zlib est appliqué par-dessus BCPack pour un flux de données, DSTORAGE_REQUEST::IntermediateSize doit être défini à la taille attendue du flux de données, après la décompression zlib et avant la décompression BCPack. Sinon, IntermediateSize devrait ê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 à compression par blocs (BC1-7), et qui comprend les modèles de réorganisation (swizzle) de textures natifs des consoles XBOX Series. Il existe un ensemble de chemins d’encodage et de décodage propres à chaque format à compression 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 précis est sélectionné pour une DSTORAGE_REQUEST donnée, en définissant l’option suivante.

Lorsque vous le 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 aussi 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 pendant leur écriture dans la mémoire du titre. À partir du GDK de mars 2024, plusieurs modes sont offerts afin de 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. Consultez Formats de brassage DirectStorage pour obtenir de l’information sur ces formats. Le swizzle est contrôlé par le code suivant. Il devrait être défini à DSTORAGE_SWIZZLE_MODE_NONE (0) si les formats de brassage 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 swizzle supplémentaires des texels après la décompression et qui n’est pas couvert par nos options actuelles, communiquez avec 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 pour les ressources autres que des textures, et la compression Deflate plus BCPack, pour les ressources de texture. Dans le premier scénario, vous êtes libre de choisir les tailles de flux de données qui conviennent le mieux à vos besoins, tandis que le second scénario prédéfinit les tailles des flux compressés. Pour l’un ou l’autre scénario, les mêmes exigences de base s’appliquent. Comme pour les autres requêtes vers le SSD NVMe, les flux de données doivent être alignés sur 16 octets. La MDU prend aussi en charge un ensemble limité d’options de réorganisation (swizzle) ou de brassage qui fonctionnent conjointement avec Deflate et BCPack. Consultez Formats de brassage DirectStorage pour obtenir de l’information sur ces formats.

Pavage des textures et Sampler Feedback Streaming (SFS)

Le pavage des textures est une méthode qui consiste à diviser de 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 portions de 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 la mise en œuvre de ce système plus facile 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 réorganisation de textures natifs les plus courants lors de l’optimisation du contenu selon la disposition native du GPU. L’objectif principal de SFS est de faire en sorte 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 portions inutilisées de ces ressources. C’est pourquoi 64 Kio a été retenu comme taille de base pour SFS, puisque 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’information sur les dispositions de textures, consultez Sampler Feedback Streaming et Dispositions de textures 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 est composée des 86 tuiles suivantes (64 Kio chacune). BC7 nécessite 16 octets par bloc de 4 × 4 texels; ainsi, mip0 nécessite (2048 × 2048) = 4 194 304 octets = 4 096 Kio = 64 pages de 64 Kio chacune. Chaque mip au-delà de mip0 fait le quart de la taille, ou fait partie de la queue de mips (mip tail), comme le montre la figure 2. Figure 2. Illustre 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 mise en œuvre de textures partiellement résidentes peut fonctionner avec n’importe quel multiple entier de la taille de tuile de base de 64 Kio comme plus petite action 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 traitée en 86 flux compressés qui sont récupérés individuellement à l’exécution. Lorsque vous décidez comment empaqueter les ressources du jeu, la compressibilité varie selon l’encodage de ces ressources, la taille des flux et le contenu de chaque ressource. Deux exemples de pools de contenu sont présentés à la figure 3 et à la figure 4. Ces graphiques représentent le pool de textures de 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 précis (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 chaque partie 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 des niveaux de détail (LOD) non basée sur SFS, zlib, ou zopfli plus BCPack

Figure 3. Illustre 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. Illustre 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 mises en œuvre 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 plus grandes n’offrant aucun avantage à cet égard. Zopfli offre de meilleurs taux de compression (1 à 2 pour cent) que zlib, mais au prix d’un temps de calcul de compression beaucoup plus élevé (environ 10 fois). Les options BCPack plus Deflate offertes par XBTC donnent des taux de compression nettement supérieurs à toute option Deflate seule. Nous recommandons fortement les options BCPack plus Deflate pour les ressources de texture.

L’empaquetage xbtc-mip consiste en un seul flux de données par mip, et a donc une taille de flux de données variable. Il est placé à une taille de tuile de 4 Mio à des fins de comparaison afin d’illustrer 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 limites du système.

Pour les requêtes de décompression, les tailles compressées doivent être inférieures aux tailles décompressées.
La taille maximale de 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 offerts 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 se fait au moyen d’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, sous *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, communiquez avec 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 aussi exporter vers ces types de fichiers. XBTC contient un encodeur pour les formats GPU BC1-BC7, et peut réorganiser (swizzle) le contenu vers ou depuis les dispositions de textures 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 vers un format à compression par blocs, il produit des mesures de qualité d’image pour cette conversion. Lors de l’exportation vers un fichier .dds, seules les portions importation et encodeur BC de XBTC sont utilisées. Aucune compression n’est appliquée.

Compression

XBTC travaille avec 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 façons différentes (Deflate seul, BCPack seul, BCPack puis Deflate). Le meilleur des trois résultats est conservé, avec les métadonnées de cette région, et les deux autres sont abandonné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 de 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 le montre la figure 5. À gauche se trouve le mode de pavage SFS, où chaque page est traitée séparément, avec l’hypothèse par défaut que 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. Le flux supplémentaire regroupe tous les autres mips, étant entendu que les mips non diffusables sont toujours résidents en mémoire. Figure 5. Illustre (à 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 non SFS

Pour tout contenu qui n’est pas destiné à être utilisé dans un contexte de texture virtuelle SFS, ou qui charge uniquement des LOD par mip entier, 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 tuiles non SFS par défaut de 64 Ko fait en sorte que les cinq régions illustrées à la figure 6 sont compressées individuellement. Si vous vouliez indiquer que seuls deux mips sont diffusables, les trois régions sont traitées individuellement, les mips 2 à 11 étant regroupés dans le flux toujours résident. Figure 6. Illustre (à gauche) une texture BC7 2K avec un pavage non 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 qui contient les mips 2 à 11

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

Pour les textures extrêmement grandes, de 8K ou plus, il est possible d’avoir des mips qui dépassent la taille maximale (32 Mio) permise par le matériel MDU. Pour régler ce problème, une version à venir offrira des options pour diviser les mips de textures non SFS en tuiles de taille optimale pour un chargement séquentiel.

Application

Une fois déterminées les régions de la texture qui sont compressées individuellement, et une fois sélectionnée l’une des mises en œuvre de Deflate (par la présence ou l’absence du commutateur --usezopfli), chaque région est compressée trois fois : une fois avec la mise en œuvre 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 pleine vitesse d’E/S; vous pouvez donc sélectionner le meilleur encodage pour une région de données donnée. La structure de données résultante est emballée dans un fichier d’archive XBTC, qui regroupe l’ensemble des flux compressés ainsi qu’un en-tête qui les décrit. Vous pouvez utiliser le fichier d’archive tel quel et vous servir du code des exemples du GDK comme base pour le charger, ou extraire les flux compressés et les métadonnées pour les réempaqueter dans le conteneur qui vous convient le mieux. À 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 échanger de la qualité de compression contre un taux de compression supplémentaire à l’aide de la RDO. Pour les formats à compression par blocs (BC1-7), cela peut être aussi simple que de réencoder les blocs d’une autre façon. En réencodant, vous pouvez réduire le nombre de points de couleur distincts, ou forcer des 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 devant arriver dans des versions futures. La mise en œuvre de la RDO dans XBTC existe uniquement à l’étape de l’encodeur BC, et elle peut être utilisée lors de l’exportation vers un fichier .dds. Elle est toutefois conçue en fonction 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 bons paramètres exigent souvent d’itérer sur un système de règles, avec des vérifications ponctuelles et des ajustements au besoin. Pour faciliter cela, XBTC dispose des sous-commandes supplémentaires compare, view et export. Vous pouvez effectuer 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 avant 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) du rapport signal sur bruit de crête (PSNR) est acceptable pour les cartes de 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é admissible. 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 aussi conserver cette information pour les builds futurs. Vous pouvez aussi exporter (export) l’image vers un autre format pour la traiter avec d’autres outils.

La RDO modifie le taux de compression, et elle peut avoir d’autres répercussions 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 pour cent de plus à l’aide de la RDO ne se traduit pas directement par 25 pour cent 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 en fonction du taux de compression. Toutefois, l’effet s’atténue pour le contenu très compressible qui commence à s’approcher des 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 Insects HDR et 4K. Dans ce cas, un paramètre RDO (qualité et compression) a été sélectionné de sorte que les archives XBTC résultantes soient environ 14 pour cent plus petites que les versions par défaut sans RDO, soit 7 pour cent de plus par rapport à la taille non compressée d’origine. 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 présente un gain relatif plus élevé que lorsque Deflate est utilisé dans un scénario non SFS, comme le montre la figure 7. Figure 7. Illustre le pool de contenu Insects HDR 4K, taille BC1, comparée à une option RDO

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

À l’exécution, la combinaison de ces effets entraîne les caractéristiques de débit suivantes. Lorsque XBTC est utilisé pour l’encodeur RDO, puis que l’empaquetage se fait sous une forme non SFS avec des tailles de flux variables, on observe environ 13 pour cent de débit supplémentaire pour les tailles plus grandes (128 Kio ou plus). Cette différence reflète presque exactement l’avantage de compression. Les tailles de flux de données plus petites (64 Kio ou moins) entraînent des améliorations décroissantes, comme le montre la figure 8. Figure 8. Illustre le pool de contenu Insects HDR 4K, BC1, selon le débit de la MDU comparé à une option RDO

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

Restrictions des modes de l’encodeur BC7

BC7 permet d’encoder chaque groupe de 4 × 4 texels selon l’un des 8 modes, selon le 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 aussi que l’entropie des bits encodés de la texture résultante 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 à compression par blocs. L’encodeur BC7 de XBTC comporte des options permettant de limiter les modes utilisés, ce qui sacrifie directement une partie de la fidélité supérieure du format pour uniformiser le modèle d’encodage et le rendre ainsi plus compressible. L’utilisation de ces options peut modifier radicalement la compressibilité de la texture résultante, mais nous vous encourageons à vérifier ponctuellement ces paramètres et à les ajuster de façon itérative afin de vous assurer que la texture résultante présente peu ou pas de perte de qualité perceptible. Le pool de données de textures 4K de la démo Insects HDR de la XBOX One est présenté à la figure 9. L’encodage BC7 normal, avec tous les modes activés, donne un pool de textures que Zopfli peut compresser à 64 pour cent de sa taille d’origine, ou à 61,5 pour cent s’il est combiné avec BCPack à l’aide de XBTC. Toutefois, si seul le mode 7 est autorisé (--bc7modes 0x80), les textures résultantes 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. Illustre la compressibilité du pool de contenu Insects HDR 4K, BC7 avec tous les modes par rapport au mode 7 seulement

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

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 modes par défaut (modes 0 à 7) et avec seulement le mode 7 activé sont présentées à la figure 10.

La vitesse de lecture à partir du NVMe est presque identique, le contenu en mode 7 seulement offrant un avantage de débit d’environ 20 à 40 pour cent, mesuré à la sortie de la MDU.

Figure 10. Illustre le débit de la MDU du pool de contenu Insects HDR 4K, BC7, débit de la MDU, avec tous les modes par rapport au mode 7 seulement

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

Considérations pour des performances optimales

Les directives de la rubrique Utilisation et détails internes de DirectStorage s’appliquent lorsque la MDU est utilisée pour la décompression.

Gardez suffisamment de requêtes en cours pour que le pipeline reste plein. Par exemple, si vous ajoutez des éléments aux 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 les intervalles d’ajout, gardez 33,4 Mo plus 32 Mio de requêtes en cours, soit un total d’environ 64 Mio. Toutefois, comme le débit réel du SSD NVMe peut varier au fil du temps et que la garantie de 2 000 Mo/s s’applique à toute période de 250 ms, les titres devraient garder en cours plus que ce minimum de 64 Mio afin de maximiser le débit. Voici d’autres facteurs propres à la nature de la mise en œuvre 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 taille minimale des 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 brusquement pour une taille non compressée inférieure à 64 Kio, comme le montrent la figure 11 et la figure 12. Figure 11. Illustre le débit de chargement du pool de contenu Insects HDR 4K, BC1, selon l’option d’empaquetage Figure 12. Illustre 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 après la récupération des données à partir du SSD NVMe. Cela a un effet faible, mais mesurable, sur le débit des requêtes volumineuses, touchant surtout les flux de données dont la taille compressée dépasse tout juste ce seuil.
Le taux de compression détermine directement le débit final des octets décompressés vers la mémoire du titre. La RDO, ou les restrictions des modes BC7, produisent un double effet : une taille compressée plus petite et des temps de chargement plus rapides. Pour plus d’information et des exemples, consultez la section Restrictions des modes de l’encodeur BC7 et la section 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 pour chaque tuile, produit la meilleure compression prise en charge par le matériel, combiné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

Avis de non-responsabilité

Introduction

Architecture