Mappages dans un pool de vignettes
Lorsqu’une ressource est créée en tant que ressource de diffusion en continu, les vignettes qui composent la ressource proviennent de pointer vers des emplacements dans un pool de vignettes. Un pool de vignettes est un pool de mémoire (soutenu par une ou plusieurs allocations en arrière-plan - invisible par l’application). Le système d’exploitation et le pilote d’affichage gèrent ce pool de mémoire, et l’empreinte mémoire est facilement comprise par une application. Les ressources de diffusion en continu mappent des régions de 64 Ko en pointant vers des emplacements dans un pool de vignettes. L’une des conséquences de cette configuration est qu’il permet à plusieurs ressources de partager et réutiliser les mêmes vignettes, et également pour que les mêmes vignettes soient réutilisées à différents emplacements au sein d’une ressource si vous le souhaitez.
Le coût de la flexibilité de remplir les vignettes d’une ressource hors d’un pool de vignettes est que la ressource doit effectuer le travail de définition et de maintenance du mappage des vignettes dans le pool de vignettes qui représentent les vignettes nécessaires à la ressource. Les mappages de vignettes peuvent être modifiés. En outre, toutes les vignettes d’une ressource ne doivent pas être mappées à la fois ; une ressource peut avoir des mappages NULL . Un mappage NULL définit une vignette comme n’étant pas disponible du point de vue de la ressource qui y accède.
Plusieurs pools de vignettes peuvent être créés, et n’importe quel nombre de ressources de diffusion en continu peuvent être mappés en même temps à n’importe quel pool de vignettes donné. Les pools de mosaïques peuvent également être développés ou réduits. Pour plus d’informations, consultez redimensionnement du pool de vignettes. Une contrainte qui existe pour simplifier l’implémentation du pilote d’affichage et du runtime est qu’une ressource de diffusion en continu donnée ne peut avoir que des mappages dans au maximum un pool de vignettes à la fois (par opposition à un mappage simultané à plusieurs pools de vignettes).
La quantité de stockage associée à une ressource de diffusion en continu elle-même (autrement dit, mémoire de pool de vignettes indépendantes) est proportionnelle à peu près au nombre de vignettes réellement mappées au pool à tout moment donné. Dans le matériel, ce fait se résume à la mise à l’échelle de l’empreinte mémoire pour le stockage de tables de pages à peu près avec la quantité de vignettes mappées (par exemple, à l’aide d’un schéma de table de pages à plusieurs niveaux selon les besoins).
Le pool de mosaïques peut être considéré comme une abstraction entièrement logicielle qui permet aux applications Direct3D de pouvoir programmer efficacement les tables de pages sur l’unité de traitement graphique (GPU) sans avoir à connaître les détails d’implémentation de bas niveau (ou traiter directement les adresses de pointeur). Les pools de vignettes n’appliquent aucun niveau supplémentaire d’indirection dans le matériel. Les optimisations d’une table de pages de niveau unique à l’aide de constructions telles que les répertoires de pages sont indépendantes du concept de pool de vignettes.
Nous allons explorer le stockage de la table de pages elle-même peut nécessiter dans le pire des cas (bien que dans les implémentations pratiques, seules les implémentations nécessitent un stockage proportionnelle à ce qui est mappé).
Supposons que chaque entrée de table de pages soit de 64 bits.
Pour la taille de table de la page la plus grave pour une seule surface, étant donné les limites de ressources dans Direct3D 11, supposons qu’une ressource de diffusion en continu soit créée avec un format de 128 bits par élément (par exemple, un float RGBA), donc une vignette de 64 Ko ne contient que 4 096 pixels. La taille maximale de Texture2DArray prise en charge de 16384*16384*2048 (mais avec un seul mipmap) nécessite environ 1 Go de stockage dans la table de pages si elle est entièrement remplie (sans inclure les mipmaps) à l’aide d’entrées de table 64 bits. L’ajout de mipmaps augmente le stockage de table de pages entièrement mappé (le pire des cas) d’environ un tiers, à environ 1,3 Go.
Ce cas donne accès à environ 10,6 téraoctets de mémoire adressable. Il peut y avoir une limite sur la quantité de mémoire adressable, ce qui réduirait ces quantités, peut-être à environ la plage de téraoctets.
Un autre cas à prendre en compte est une seule ressource de diffusion en continu Texture2D de 16384*16384 avec un format de 32 bits par élément, y compris les mipmaps. L’espace nécessaire dans une table de pages entièrement renseignée serait d’environ 170 Ko avec des entrées de table 64 bits.
Enfin, considérez un exemple utilisant un format BC, par exemple BC7 avec 128 bits par vignette de 4 x 4 pixels. Il s’agit d’un octet par pixel. Une texture2DArray de 16384*16384*2048 incluant des mipmaps nécessiterait environ 85 Mo pour remplir entièrement cette mémoire dans une table de pages. Cela n’est pas mauvais compte tenu de cela permet à une ressource de streaming d’étendre 550 gigapixels (512 Go de mémoire dans ce cas).
Dans la pratique, nulle part près de ces mappages complets serait défini, étant donné que la quantité de mémoire physique disponible ne permettrait pas d’être mappée et référencée à la fois. Toutefois, avec un pool de vignettes, les applications peuvent choisir de réutiliser des vignettes (par exemple, réutiliser une vignette de couleur « noire » pour les grandes régions noires d’une image) en utilisant efficacement le pool de vignettes (c’est-à-dire les mappages de tables de pages) en tant qu’outil de compression de mémoire.
Le contenu initial de la table de pages est NULL pour toutes les entrées. Les applications ne peuvent pas non plus transmettre les données initiales pour le contenu de la mémoire de la surface, car elles démarrent sans stockage de mémoire.
Dans cette section
| Sujet | Description |
|---|---|
Les applications peuvent créer un ou plusieurs pools de vignettes par appareil Direct3D. La taille totale de chaque pool de vignettes est limitée à la limite de taille de ressource de Direct3D 11, qui est d’environ 1/4 de LA RAM GPU. |
|
Redimensionnez un pool de vignettes pour développer un pool de vignettes si l’application a besoin d’un ensemble plus fonctionnel pour le mappage des ressources de diffusion en continu, ou pour réduire si moins d’espace est nécessaire. |
|
Pour les ressources hors diffusion en continu, Direct3D peut empêcher certaines conditions de danger pendant le rendu, mais étant donné que le suivi des risques serait à un niveau de vignette pour les ressources de diffusion en continu, le suivi des conditions de danger pendant le rendu des ressources de diffusion en continu peut être trop coûteux. |
Rubriques connexes
Création de ressources de streaming