Mappages dans un pool de vignettes

Lorsqu’une ressource est créée avec l’indicateur D3D11_RESOURCE_MISC_TILED , les vignettes qui la composent proviennent du pointage 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 - invisibles 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 en mosaïques 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’elle permet à plusieurs ressources de partager et de réutiliser les mêmes vignettes, ainsi que 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é du remplissage des vignettes d’une ressource à partir 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 n’ont pas besoin d’ê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 en mosaïques peuvent être mappées dans un pool de vignettes donné en même temps. Les pools de vignettes peuvent également être agrandis 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 en mosaïque donnée ne peut avoir des mappages que dans un pool de vignettes à la fois (par opposition à un mappage simultané à plusieurs pools de vignettes).

La quantité de stockage associée à une ressource en mosaïque elle-même (c’est-à-dire la mémoire indépendante du pool de vignettes) est approximativement proportionnelle au nombre de vignettes réellement mappées au pool à un 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 qui sont mappées (par exemple, en utilisant un schéma de table de pages à plusieurs niveaux, le cas échéant).

Le pool de vignettes peut être considéré comme une abstraction entièrement logicielle qui permet aux applications Direct3D de 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 pas de niveaux supplémentaires d’indirection dans le matériel. Les optimisations d’une table de pages à un seul niveau à l’aide de constructions telles que les répertoires de pages sont indépendantes du concept de pool de vignettes.

Nous allons explorer ce que la table de pages elle-même peut nécessiter dans le pire des cas (bien que dans la pratique, les implémentations nécessitent un stockage à peu près proportionnel à ce qui est mappé).

Supposons que chaque entrée de table de pages est de 64 bits.

Pour la taille de table de pages la plus défavorable pour une seule surface, étant donné les limites de ressources dans Direct3D 11, supposons qu’une ressource en mosaïque soit créée avec un format de 128 bits par élément (par exemple, un float RGBA), une vignette de 64 Ko ne contient donc 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 mipmaps) à l’aide d’entrées de table de 64 bits. L’ajout de mipmaps augmente le stockage de la table de pages entièrement mappée (dans le pire des cas) d’environ un tiers, à environ 1,3 Go.

Ce cas donnerait accès à environ 10,6 téraoctets de mémoire adressable. Toutefois, 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 ressource en mosaïque Texture2D unique 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 remplie serait d’environ 170 Ko avec des entrées de table de 64 bits.

Enfin, prenons un exemple utilisant un format BC, par exemple BC7 avec 128 bits par vignette de 4 x 4 pixels. C’est un octet par pixel. Un Texture2DArray de 16384*16384*2048, y compris les mipmaps, nécessite environ 85 Mo pour remplir entièrement cette mémoire dans une table de pages. Ce n’est pas mal étant donné que cela permet à une ressource en mosaïque d’étendre 550 gigapixels (512 Go de mémoire dans ce cas).

Dans la pratique, il est impossible de définir ces mappages complets, étant donné que la quantité de mémoire physique disponible n’autoriserait pas autant à être mappée et référencée à la fois. Toutefois, avec un pool de vignettes, les applications peuvent choisir de réutiliser les 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 (autrement dit, les mappages de tables de pages) comme outil de compression de la 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.

Contenu de cette section

Rubriques connexes

Création de ressources en mosaïque