Besoin en ressources de diffusion en continu
Les ressources de diffusion en continu sont nécessaires afin que la mémoire GPU ne soit pas gaspille en stockant des zones de surfaces qui ne seront pas accessibles et pour indiquer au matériel comment filtrer sur les vignettes adjacentes.
Ressources de diffusion en continu ou textures éparses
Les ressources de streaming (appelées ressources en mosaïques dans Direct3D 11) sont des ressources logiques volumineuses qui utilisent de petites quantités de mémoire physique.
Un autre nom pour les ressources de streaming est des textures éparses. « Éparse » transmet à la fois la nature mosaïque des ressources et peut-être la raison principale de leur mosaïque - que tous ne sont pas censés être mappés à la fois. En fait, une application peut concevoir une ressource de diffusion en continu dans laquelle aucune donnée n’est créée pour toutes les régions+mips de la ressource, intentionnellement. Par conséquent, le contenu lui-même peut être épars et le mappage du contenu dans la mémoire de l’unité de traitement graphique (GPU) à un moment donné serait un sous-ensemble de ce (encore plus éparse).
Sans mosaïques, les allocations de mémoire sont gérées à une granularité de sous-ressource
Dans un système graphique (autrement dit, le système d’exploitation, le pilote d’affichage et le matériel graphique) sans prise en charge des ressources de diffusion en continu, 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-source ; pour un tableau de textures (par exemple, Texture2DArray) chaque niveau mip à 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 de diffusion en continu, le « mappage » fait référence à rendre les données visibles par le GPU.
Sans mosaïne, ne peut pas accéder qu’à une petite partie de la chaîne mipmap
Supposons qu’une application sache qu’une opération de rendu particulière doit uniquement accéder à une petite partie d’une chaîne mipmap d’image (peut-être pas même la zone complète d’un mipmap donné). Dans l’idéal, l’application peut informer le système graphique de ce besoin. Le système graphique ne dérangerait alors que pour 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 de diffusion en continu, le système graphique ne peut être informé que de la mémoire qui doit être mappée sur le GPU au niveau de la granularité des sous-ressources (par exemple, une plage de niveaux mipmap complets accessibles). Il n’y a aucune demande d’erreur dans le système graphique, donc potentiellement beaucoup de mémoire GPU excédentaire doivent être utilisées pour rendre les sous-ressources complètes mappées avant qu’une commande de rendu qui référence n’importe quelle partie de la mémoire soit exécutée. Il s’agit simplement d’un problème qui rend difficile l’utilisation d’allocations de mémoire volumineuses dans Direct3D sans prise en charge des ressources de diffusion en continu.
Pagination logicielle pour décomposer la surface en vignettes plus petites
La pagination logicielle peut être utilisée pour décomposer la surface en vignettes suffisamment petites pour que le matériel puisse être géré.
Direct3D prend en charge les surfaces Texture2D avec jusqu’à 16384 pixels sur un côté donné. Une image de 16384 large de 16384 de hauteur et de 4 octets par pixel consomme 1 Go de mémoire vidéo (et l’ajout de mipmaps double cette quantité). Dans la pratique, toutes les 1 Go doivent rarement être référencées dans une seule opération de rendu.
Certains développeurs de jeux modélisent des surfaces de terrain aussi grandes que 128K par 128K. La façon dont ils obtiennent cela pour travailler sur des GPU existants consiste à décomposer la surface en vignettes 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 provient du matériel qui ne connaît 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 un filtrage de fonction fixe (c’est-à-dire efficace) sur les vignettes. Cela signifie que l’application qui gère son propre mosaïque logicielle doit recourir au filtrage manuel de texture dans le code du nuanceur (ce qui devient très coûteux si un filtre anisotropique de bonne qualité est souhaité) et/ou gaspille les coupes de création de mémoire autour des vignettes qui contiennent des données des vignettes voisines afin que le filtrage matériel de fonction fixe puisse continuer à fournir une assistance.
Création d’une représentation en mosaïque des allocations de surface d’une fonctionnalité de première classe
Si une représentation en mosaïque des allocations de surface est une fonctionnalité de première classe dans le système graphique, l’application peut indiquer au matériel les vignettes à rendre disponibles. De cette façon, moins de mémoire GPU est gaspillée en stockant des régions de surfaces que l’application sait ne sera pas accessible, et le matériel peut comprendre comment filtrer sur des vignettes adjacentes, réduisant certaines des douleurs rencontrées par les développeurs qui effectuent des mosaïques logicielles sur leur propre.
Mais pour fournir une solution complète, quelque chose doit être fait pour traiter le fait que, indépendamment du fait que, indépendamment du mosaïque dans une surface est pris en charge, la dimension de surface maximale est actuellement 16384 - nulle part près des 128K+ que les applications veulent déjà. Il suffit que le matériel prennent en charge les tailles de texture plus grandes est une approche, mais il existe des coûts importants et/ou des compromis pour aller sur cet itinéraire.
Le chemin de filtre de texture et le chemin de rendu de Direct3D sont déjà saturés en termes de précision pour prendre en charge les textures 16K avec les autres exigences, telles que la prise en charge des étendues de la fenêtre d’affichage qui tombent hors de la surface pendant le rendu, ou la prise en charge de l’habillage de texture hors du bord de la surface pendant le filtrage. Une possibilité est de définir un compromis tel que la taille de texture augmente au-delà de 16K, la fonctionnalité/précision est donnée d’une certaine manière. Même avec cette concession, des coûts matériels supplémentaires peuvent être nécessaires en termes de capacité d’adressage tout au long du système matériel pour atteindre des tailles de texture plus grandes.
Problème avec les textures volumineuses : précision pour les emplacements sur la surface
L’un des problèmes qui entrent en jeu lorsque les textures sont très volumineuses est que les coordonnées de texture à virgule flottante simple précision (et les interpolateurs associés pour prendre en charge la rastérisation) dépassent la précision pour spécifier des emplacements sur la surface avec précision. Le filtrage de textures gigue s’ensuivrait. Une option coûteuse consisterait à exiger une prise en charge d’interpolateur double précision, bien que cela puisse être excessivement possible en raison d’une alternative raisonnable.
Activation de plusieurs ressources de différentes dimensions pour partager la mémoire
Un autre scénario qui peut être servi par les ressources de diffusion en continu permet à plusieurs ressources de différentes dimensions/formats de partager la même mémoire. Parfois, les applications ont des ensembles exclusifs de ressources qui ne sont pas connues pour être utilisées en même temps, ou des ressources créées uniquement pour une utilisation très brève, puis détruites, suivie de la création d’autres ressources. Une forme de généralité qui peut sortir de « ressources de streaming » est qu’il est possible d’autoriser l’utilisateur à pointer plusieurs ressources différentes à la même mémoire (qui se chevauche). En d’autres termes, la création et la destruction de « ressources » (qui définissent une dimension/format, et ainsi de suite) peuvent être découplées de la gestion de la mémoire sous-jacente aux ressources du point de vue de l’application.
Rubriques connexes
Ressources de diffusion en continu