Le rendu en mosaïque est utilisé dans les architectures GPU mobiles modernes pour augmenter la cohérence de l'accès à la mémoire en subdivisant l'espace d'image en une grille régulière de petites tuiles (par exemple, 32x32 pixels). Les informations sur les types de structures de données utilisées pour suivre les primitives associées à chaque tuile sont rares, étant donné que de nombreuses primitives peuvent chevaucher arbitrairement une tuile donnée.
Du point de vue d'un développeur de pilotes, quelles structures de données sont couramment utilisées pour représenter les ensembles primitifs qui appartiennent à une tuile, et ces structures sont-elles allouées / redimensionnées dynamiquement en fonction de la géométrie qui chevauche une tuile particulière?
la source
Réponses:
Ce billet de blog que John mentionne est un assez bon début (si je le dis moi-même!), Mais il y a un peu de détails supplémentaires qui pourraient être utiles.
Pour l'architecture PowerVR, la structure de données intermédiaire - diversement appelée liste primitive ou tampon de paramètres (PB) - qui stocke les données par tuile, une fois que l'ombrage des sommets et le processus de tuilage sont terminés, est en fait principalement générée et gérée par le matériel, plutôt que le pilote.
Les structures en mémoire du PB sont physiquement divisées en deux. Premièrement, des blocs de données de sommet transformées, y compris des attributs de sommet. Les blocs sont compressés et, comme vous pouvez l'imaginer, ce sont simplement des données à virgule flottante compressées et compressées pour la plupart. La deuxième structure en mémoire est constituée par les données de mosaïque, qui sont en fait une liste de listes.
La liste de niveau supérieur dans cette structure de données est appelée une région, et elle peut coder un ensemble de tuiles plutôt qu'une seule tuile à la fois, pour un bloc primitif donné. Une région est donc un ensemble d'emplacements de tuiles d'écran, d'états de tuiles, puis une liste des blocs compressés qui contiennent la géométrie dans cette région. Les régions sont ce sur quoi fonctionne le rasteriser, et vous pouvez imaginer que les tuiles vides sont simplement ignorées automatiquement, bien qu'il y ait une bonne raison dans certains cas pour que le rasteriser visite les régions vides.
La mémoire que le GPU utilise pour le PB est allouée dynamiquement dans toutes les implémentations PowerVR modernes. Un pointeur vers cette mémoire est fourni par le pilote et le pilote, avec l'aide du GPU, le dimensionnera selon les besoins. Ce mécanisme est un compromis entre devoir réallouer fréquemment et minimiser la quantité d'espace PB alloué.
Les GPU modernes s'efforcent vraiment de minimiser l'indirection de la mémoire, mais marcher sur le PB pour alimenter l'étape de rastérisation est l'un de ces cas où c'est vraiment difficile et il n'y a pas d'autre choix. Heureusement, la poursuite du pointeur enveloppe de gros blocs qui se cachent bien et sont diffusés dans le noyau.
D'autres architectures ne fonctionnent pas exactement de la même manière que PowerVR, car une partie de la raison pour laquelle le PB est tel qu'il est dans notre architecture est d'aider le concept de pixel shading entièrement différé que nous implémentons, mais le concept général s'applique à tous les autres carreleurs du l'espace mobile que je connais.
la source