Pourquoi les ressources en mosaïque sont-elles nécessaires ?
Les ressources en mosaïque sont nécessaires afin que moins de mémoire d’unité de traitement graphique (GPU) soit gaspille, stockant les régions de surfaces que l’application sait ne pas être accessibles, et le matériel peut comprendre comment filtrer les vignettes adjacentes.
Dans un système graphique (c’est-à-dire le système d’exploitation, le pilote d’affichage et le matériel graphique) sans prise en charge des ressources en mosaïques, le système graphique gère toutes les allocations de mémoire Direct3D à la granularité des sous-ressources. Pour une mémoire tampon, la mémoire tampon entière est la sous-ressource. Pour une texture (par exemple, Texture2D), chaque niveau mip est une sous-ressource ; pour un tableau de textures (par exemple, Texture2DArray), chaque niveau mip d’une tranche de tableau donnée est une sous-ressource. Le système graphique expose uniquement la possibilité de gérer le mappage des allocations à cette granularité de sous-ressource. Dans le contexte des ressources en mosaïques, le « mappage » fait référence à rendre les données visibles pour le GPU.
Supposons qu’une application sache qu’une opération de rendu particulière ne doit accéder qu’à une petite partie d’une chaîne mipmap d’image (peut-être même pas la zone complète d’un mipmap donné). Dans l’idéal, l’application pourrait informer le système graphique de ce besoin. Le système graphique ne ferait alors que s’assurer que la mémoire nécessaire est mappée sur le GPU sans paginer trop de mémoire. En réalité, sans prise en charge des ressources en mosaïques, le système graphique ne peut être informé que de la mémoire qui doit être mappée sur le GPU à la granularité des sous-ressources (par exemple, une plage de niveaux mipmap complets accessibles). Il n’y a pas non plus de défaillance de la demande dans le système graphique. Par conséquent, une grande quantité de mémoire GPU excédentaire doit être utilisée pour mapper des sous-ressources complètes avant l’exécution d’une commande de rendu qui référence n’importe quelle partie de la mémoire. Il ne s’agit que d’un problème qui rend difficile l’utilisation d’allocations de mémoire volumineuses dans Direct3D sans prise en charge des ressources en mosaïques.
Direct3D 11 prend en charge les surfaces Texture2D avec jusqu’à 16384 pixels sur un côté donné. Une image de 16384 de large par 16384 de hauteur et de 4 octets par pixel consommerait 1 Go de mémoire vidéo (et l’ajout de mipmaps doublerait cette quantité). Dans la pratique, les 1 Go doivent rarement être référencés dans une seule opération de rendu.
Certains développeurs de jeux modélisent des surfaces de terrain aussi grandes que 128 000 par 128 000. La façon dont ils obtiennent cela pour fonctionner sur les GPU existants consiste à diviser la surface en vignettes qui sont suffisamment petites pour que le matériel soit géré. L’application doit déterminer quelles vignettes peuvent être nécessaires et les charger dans un cache de textures sur le GPU, un système de pagination logicielle. Un inconvénient important de cette approche vient du fait que le matériel ne sait rien sur la pagination en cours : lorsqu’une partie d’une image doit être affichée sur l’écran qui chevauche les vignettes, le matériel ne sait pas comment effectuer une fonction fixe (c’est-à-dire, efficace) en filtrant entre les vignettes. Cela signifie que l’application qui gère ses propres mosaïques logicielles doit recourir au filtrage manuel de texture dans le code de nuanceur (ce qui devient très coûteux si un filtre anisotropique de bonne qualité est souhaité) et/ou gaspiller la création de la mémoire autour des vignettes qui contiennent des données de vignettes voisines afin que le filtrage matériel de fonction fixe puisse continuer à fournir une assistance.
Si une représentation en mosaïque des allocations de surface peut être une fonctionnalité de première classe dans le système graphique, l’application peut indiquer au matériel quelles vignettes mettre à disposition. De cette façon, moins de mémoire GPU est gaspillée, stockant des régions de surfaces dont l’application sait que l’application ne sera pas accessible, et le matériel peut comprendre comment filtrer sur les vignettes adjacentes, allégeant certaines des douleurs rencontrées par les développeurs qui effectuent le mosaïque de logiciels par eux-mêmes.
Mais pour fournir une solution complète, il faut faire quelque chose pour faire face au fait que, indépendamment de la prise en charge du revêtement au sein d’une surface, la dimension maximale de surface est actuellement de 16384 - loin de la taille de 128 000+ que les applications veulent déjà. Le simple fait d’avoir besoin du matériel pour prendre en charge des tailles de texture plus grandes est une approche, mais il existe des coûts et/ou des compromis importants pour cette voie. Le chemin de filtre de texture et le chemin de rendu de Direct3D 11 sont déjà saturés en termes de précision en termes de prise en charge des textures 16 000 avec les autres exigences, telles que la prise en charge des étendues de fenêtre d’affichage qui tombent de la surface pendant le rendu ou la prise en charge de l’habillage de texture sur le bord de la surface pendant le filtrage. Une possibilité consiste à définir un compromis tel que, lorsque la taille de texture augmente au-delà de 16 000, la fonctionnalité/précision est abandonné d’une certaine manière. Même avec cette concession, cependant, des coûts matériels supplémentaires peuvent être nécessaires en termes de capacité d’adressage dans tout le système matériel pour accéder à des tailles de texture plus grandes.
Un problème qui entre en jeu à mesure que les textures devenent très volumineuses est que les coordonnées de texture à virgule flottante de précision unique (et les interpolateurs associés pour prendre en charge la rastérisation) sont hors de précision pour spécifier des emplacements sur la surface avec précision. Un filtrage de textures nerveux s’ensuivrait. Une option coûteuse consisterait à exiger la prise en charge de l’interpolateur de double précision, même si cela pourrait être excessif compte tenu d’une alternative raisonnable.
Un autre nom pour les ressources en mosaïques est « texture éparse ». « Éparse » exprime à la fois la nature mosaïque des ressources ainsi que peut-être la raison principale de leur mosaïque - que toutes ne sont pas censées être mappées en même temps. En fait, une application peut créer intentionnellement une ressource en mosaïque dans laquelle aucune donnée n’est créée pour toutes les régions+mips de la ressource. Par conséquent, le contenu lui-même pourrait être épars et le mappage du contenu dans la mémoire GPU à un moment donné serait un sous-ensemble de cela (encore plus éparse).
Un autre scénario qui pourrait être pris en charge par des ressources en mosaïques consiste à permettre à plusieurs ressources de dimensions/formats différents de partager la même mémoire. Parfois, les applications ont des ensembles exclusifs de ressources dont on sait qu’elles ne sont pas utilisées en même temps, ou des ressources qui sont créées uniquement pour une utilisation très brève, puis détruites, suivies de la création d’autres ressources. Une forme de généralité qui peut tomber en dehors des « ressources en mosaïques » est qu’il est possible de permettre à l’utilisateur de pointer plusieurs ressources différentes sur la même mémoire (se chevauchant). En d’autres termes, la création et la destruction de « ressources » (qui définissent une dimension/un format, etc.) peuvent être dissociées de la gestion de la mémoire sous-jacente aux ressources du point de vue de l’application.
Rubriques connexes