Apple Silicon TBDR : ce que les développeurs d'apps obtiennent réellement

Les GPU Apple silicon ne font pas du rendu comme les autres GPU. La documentation Metal d’Apple décrit l’architecture sans détour : « Les GPU d’Apple silicon mettent en œuvre une technique de rendu appelée tile-based deferred rendering (TBDR) qui optimise les performances et l’efficacité énergétique. »¹ La forme TBDR explique pourquoi l’API Metal 4, la pile ML embarquée et le modèle de programmation imageblock-and-tile-shader existent tels qu’ils sont.

Les sections suivantes parcourent les quatre fonctionnalités documentées par Apple que TBDR rend possibles, et ce que chacune apporte à une app : imageblocks, tile shaders, raster order groups et l’implémentation améliorée du multisample antialiasing. L’article précédent sur les essentiels de Metal 4 couvrait la surface principale de l’API ; l’attention se porte ici sur le substrat GPU que cette surface cible.

TL;DR

• TBDR découpe la destination de rendu en tuiles, en exécute beaucoup en parallèle sur des cœurs GPU distincts, et diffère l’ombrage jusqu’à ce que toute la géométrie soit évaluée pour chaque tuile.¹
• La mémoire de tuile offre une bande passante plusieurs fois supérieure à celle de la mémoire device, une latence plusieurs fois inférieure et un coût énergétique nettement plus bas.¹
• Les GPU Apple A11 et ultérieurs ajoutent les imageblocks, le tile shading, les raster order groups et le contrôle de la couverture d’échantillons d’imageblock. Les apps y accèdent toutes via Metal.¹
• Les imageblocks permettent à une app de définir des structures de données personnalisées par pixel en mémoire de tuile, de persister les données entre draws et dispatches, et de mêler travail de rendu et de calcul dans une seule passe.¹
• Les raster order groups synchronisent les threads de fragments qui visent le même pixel, supprimant la condition de concurrence read-modify-write qui casse le blending dépendant de l’ordre.¹

Ce qu’est réellement TBDR

La formulation d’Apple, mot pour mot : « Le GPU découpe la destination de rendu en une grille de petites régions, appelées tuiles. Il traite chaque tuile avec l’un de ses cœurs GPU, souvent en exécutant plusieurs en même temps. Le GPU diffère, ou reporte, la phase de rendu pour chaque tuile jusqu’à ce qu’il ait évalué toute la géométrie de cette tuile. »¹

Le contraste avec les GPU en mode immédiat (IM) est aussi celui d’Apple : « Un GPU IM traite entièrement les primitives, telles que les lignes et les triangles, qu’elles soient visibles ou non dans le rendu. »¹ TBDR évite ce travail en rassemblant d’abord toute la géométrie d’une tuile, puis en n’ombrant que ce qui survit à l’occlusion. Apple énonce le gain directement : « Un GPU TBDR évite le travail inutile en traitant toute la géométrie d’une passe de rendu en même temps et en n’ombrant que les primitives visibles. »¹

La mémoire de tuile est la récompense. Apple décrit ses avantages par rapport à la mémoire device :¹

• « Une bande passante plusieurs fois supérieure à celle de la mémoire device »
• « Une latence d’accès plusieurs fois inférieure à celle de la mémoire device »
• « Une consommation énergétique nettement inférieure à celle d’un accès à la mémoire device »

Deux passes de rendu peuvent aussi se chevaucher sur le matériel. Apple le note : « Pendant que le GPU exécute les étapes finales d’une passe de rendu vers la mémoire de tuile, il peut commencer l’étape vertex d’une passe de rendu future. Le GPU peut utiliser plus de blocs matériels en même temps en exécutant les deux étapes en parallèle, car elles tendent à mobiliser des composants de calcul et de mémoire différents. »¹

Voilà le substrat. Tout ce qui suit s’appuie dessus.

Imageblocks : données personnalisées par pixel en mémoire de tuile

Définition d’Apple pour un imageblock : « Les imageblocks sont des tuiles de données image structurées stockées en mémoire locale, vous permettant de décrire des données image en mémoire de tuile que les GPU Apple peuvent manipuler efficacement. »¹ Ce sont des structures de données 2D avec une largeur, une hauteur et une profondeur de pixel, et « chaque pixel d’un imageblock peut comporter plusieurs composants, et vous pouvez adresser chaque composant comme sa propre tranche d’image. »¹ Exemple d’Apple : un imageblock qui contient trois tranches d’image pour les composants albedo, specular et normal.

La forme qu’Apple documente :¹

• Disponibles à la fois pour les fonctions kernel et fragment.
• Persistent pendant la durée de vie d’une tuile, à travers draws et dispatches.
• Le code de rendu existant crée automatiquement des imageblocks qui correspondent aux formats des render attachments.
• Les apps peuvent définir des imageblocks personnalisés dans les shaders avec des canaux supplémentaires, des tableaux et des structures imbriquées.
• Un fragment shader ne voit que les données de l’imageblock à la position de ce fragment ; un thread de fonction compute peut accéder à l’imageblock entier.

La persistance entre draws et dispatches est la partie opérationnellement intéressante. Formulation d’Apple : « La persistance des imageblocks signifie que vous pouvez mêler des opérations de rendu et de calcul dans une seule passe de rendu avec les tile shaders, où les deux peuvent accéder à la même mémoire locale. Vous pouvez créer des algorithmes sophistiqués qui restent en mémoire GPU locale en gardant plusieurs opérations à l’intérieur d’une tuile. »¹

Pour une app qui livre un pipeline de rendu multi-étapes (deferred shading, effets en espace écran, blending personnalisé), garder les résultats intermédiaires en mémoire de tuile plutôt que de faire un aller-retour par la mémoire device, c’est le budget par image que TBDR restitue.

Tile shaders : rendu et calcul, même passe

Formulation d’Apple à propos des tile shaders : « Les tile shaders sont des fonctions compute ou fragment qui s’exécutent dans le cadre d’une passe de rendu. Ils permettent à votre app de calculer et de sauvegarder des données en mémoire de tuile qui persistent sur le GPU entre les passes de rendu. »¹

Le modèle GPU traditionnel est ce que les tile shaders contournent. Mots d’Apple : « Les GPU traditionnels séparent les commandes de rendu et de calcul en passes distinctes. Ces passes ne peuvent généralement pas communiquer directement entre elles. Les apps contournent cette limitation en sauvegardant les résultats d’une passe en mémoire device, puis en rechargeant ces données pour la passe suivante. Dans certains scénarios, comme un algorithme de rendu multiphase, les apps peuvent copier les données intermédiaires en mémoire device de nombreuses fois. »¹

Les tile shaders déplacent ces données intermédiaires en mémoire de tuile. Le gain documenté par Apple : « Les apps qui utilisent des tile shaders peuvent éviter de stocker les résultats intermédiaires en mémoire device et gagner du temps en stockant les données en mémoire de tuile, plus rapide. »¹

Pour les apps Metal 4, les tile shaders s’associent à la conception unifiée de MTL4ComputeCommandEncoder couverte dans l’article sur les essentiels de Metal 4. L’unification de l’encoder et le modèle de programmation des tile shaders sont la même décision architecturale lue à deux niveaux : effacer les frontières rendu/calcul qui existent sur les GPU traditionnels parce que le matériel GPU Apple n’en a pas besoin.

Raster order groups : ordonner les threads de fragments concurrents

Le problème que résolvent les raster order groups, dans les mots d’Apple : « Metal garantit que le GPU effectue le blending dans l’ordre des appels de draw, donnant l’illusion que le GPU rend la scène séquentiellement. … Les fragment shaders pour chaque triangle s’exécutent en concurrence sur leur propre thread. Le fragment shader pour le triangle arrière peut ne pas s’exécuter avant celui pour le triangle avant, ce qui peut poser problème pour un shader qui a besoin des résultats du shader d’un autre triangle pour sa fonction de blending personnalisée. À cause de la concurrence, cette séquence read-modify-write peut créer une condition de concurrence. »¹

Le mécanisme : « Les raster order groups surmontent ce conflit d’accès en synchronisant les threads qui visent les mêmes coordonnées de pixel et le même échantillon (si vous activez l’ombrage par échantillon). »¹

La surface d’implémentation : « Pour mettre en œuvre les raster order groups, annotez les pointeurs vers la mémoire avec un qualificateur d’attribut. Les shaders qui accèdent aux pixels via ces pointeurs s’exécutent dans l’ordre de soumission par pixel. Le matériel attend que tous les threads de fragment shader plus anciens qui chevauchent le thread courant aient terminé avant que le thread courant ne progresse. »¹

Les GPU Apple récents étendent le mécanisme. Mots d’Apple : « Metal sur les GPU Apple récents étend les raster order groups avec des capacités supplémentaires. Ils vous permettent de synchroniser les canaux individuels d’un imageblock et la mémoire threadgroup. Vous pouvez également créer plusieurs order groups, ce qui vous donne une synchronisation plus fine et minimise la fréquence d’attente d’accès de vos threads. »¹

L’exemple travaillé d’Apple est le deferred shading. L’approche traditionnelle en deux phases écrit un g-buffer composé de plusieurs textures en mémoire device, puis les relit pour la phase d’éclairage. Formulation d’Apple : « Vous pouvez éliminer le besoin des textures intermédiaires en utilisant plusieurs order groups pour fusionner les deux phases de rendu en une seule. Pour cela, gardez le geometry buffer en blocs de la taille d’une tuile afin qu’ils puissent rester en mémoire imageblock locale. »¹

La répartition recommandée par Apple :¹

• Premier order group : les trois champs du g-buffer (albedo, normal, depth).
• Deuxième order group : le résultat d’éclairage accumulé.
• « Les GPU Apple peuvent ordonner les deux groupes séparément, de sorte que les écritures en attente dans le second groupe n’entravent pas les lectures du premier. »¹

Deux threads se synchronisent toujours à la fin de l’exécution pour accumuler les lumières. Le gain est que les lectures non conflictuelles s’exécutent en concurrence plutôt que sériellement.

Un MSAA qui suit les échantillons uniques par pixel

L’implémentation MSAA documentée par Apple sur les GPU A11+ diffère de la description des manuels. Formulation d’Apple : « Le matériel suit si chaque pixel contient le bord d’une primitive, afin qu’il n’exécute le blending par échantillon que lorsque c’est nécessaire. Si une autre primitive couvre les échantillons d’un pixel, le GPU ne fait le blending qu’une fois pour le pixel entier. »¹

L’exemple d’Apple parcourt l’optimisation. Un pixel couvert par deux bords de triangles superposés a trois couleurs uniques sur quatre positions d’échantillon. Mots d’Apple : « Les GPU Apple antérieurs à A11 effectuent le blending sur chacun des trois échantillons couverts du pixel. À partir d’A11, les GPU Apple n’en font que deux car deux échantillons partagent la même couleur. »¹

La réduction de couleurs va plus loin. Apple : « Les GPU Apple peuvent réduire le nombre de couleurs uniques dans un pixel. Par exemple, si le GPU rend un triangle opaque par-dessus les triangles précédents, il représente le pixel par une seule couleur. »¹

Les apps peuvent étendre l’implémentation avec des tile shaders. Cas d’usage documenté par Apple : « Vous pouvez mettre en œuvre un algorithme de résolution personnalisé en modifiant les données de couverture d’échantillons dans les tile shaders. Par exemple, considérez une scène complexe contenant des phases de rendu séparées pour la géométrie opaque et translucide. Vous pouvez ajouter un tile shader qui résout les données d’échantillons pour la géométrie opaque avant de mélanger la géométrie translucide. »¹

Le tile shader s’exécute sur des données en mémoire locale et peut faire partie de la phase de géométrie opaque, gardant la résolution en mémoire de tuile plutôt qu’en passant par une passe séparée.

Ce que cela signifie pour l’architecture des apps

Trois enseignements qui découlent de la surface documentée par Apple.

1. La mémoire de tuile est le budget. Les quatre fonctionnalités ci-dessus (imageblocks, tile shaders, raster order groups, couverture d’échantillons) existent toutes pour garder le travail en mémoire de tuile et hors de la mémoire device. Chiffres documentés par Apple : bande passante plusieurs fois supérieure à la mémoire device, latence plusieurs fois inférieure, énergie nettement moindre.¹ Une architecture d’app qui respecte ce budget tourne plus vite et plus froid qu’une qui ne le respecte pas.

2. Rendu et calcul ne sont pas des mondes différents. Le GPU d’Apple ne sépare pas le rendu et le calcul en passes distinctes comme le font les GPU traditionnels. La persistance des imageblocks et les tile shaders permettent à une app d’exécuter des algorithmes multiphases dans une seule passe de rendu. L’encoder de calcul unifié de Metal 4 est l’expression au niveau API du même fait architectural.

3. La concurrence est la valeur par défaut ; l’ordonnancement est l’option à activer. Les raster order groups sont le moyen pour une app de dire « cette séquence read-modify-write dépend de l’ordre ». Le défaut est la concurrence non ordonnée, qui est la forme naturelle du GPU. Les apps qui ont besoin d’un accès ordonné pour le blending, la transparence ou les écritures de g-buffer annotent les pointeurs spécifiques et laissent le matériel séquencer les threads.

Le cluster Apple Ecosystem complet : l’API principal de Metal 4 pour la surface API parallèle qui cible ce matériel ; le LLM embarqué Foundation Models pour le framework qui exécute le ML sur le même silicium ; Core ML pour l’inférence embarquée pour la pile ML plus large. Le hub se trouve dans la série Apple Ecosystem.

FAQ

TBDR est-il propre à Metal 4 ?

Non. Les GPU Apple silicon ont mis en œuvre TBDR à travers de nombreuses générations de GPU ; Metal 4 est la nouvelle surface API principale qui les cible. Les fonctionnalités TBDR documentées ici (imageblocks, tile shaders, raster order groups, contrôle de couverture d’échantillons A11+) fonctionnent via Metal à la fois sur l’API original préfixé MTL et sur les types Metal 4 préfixés MTL4.¹

Quelle est la différence entre un imageblock et la mémoire threadgroup ?

Distinction documentée par Apple : « La mémoire threadgroup convient aux données non structurées, mais un imageblock est plus adapté aux données image. »¹ Les imageblocks portent une structure 2D avec largeur, hauteur, profondeur de pixel et composants nommés par pixel ; la mémoire threadgroup est une allocation plate. Les apps qui ont besoin de données image structurées avec des tranches adressables utilisent les imageblocks ; celles qui ont besoin de buffers de scratch pour des kernels compute utilisent la mémoire threadgroup.

Pourquoi les raster order groups existent-ils si Metal garantit déjà le blending dans l’ordre des draw calls ?

Metal garantit l’apparence d’un blending séquentiel, mais le GPU exécute les fragment shaders en concurrence. Formulation d’Apple : un shader qui effectue son propre blending personnalisé contre les résultats d’un autre triangle se heurte à une condition de concurrence parce que les deux threads ne sont pas réellement séquentiels. Les raster order groups sont le mécanisme qui synchronise uniquement les threads visant le même pixel, en laissant le reste concurrent.¹

Quand devrais-je écrire mon propre algorithme de résolution MSAA ?

Apple documente un cas concret : une scène avec des phases séparées pour la géométrie opaque et translucide, où la résolution s’exécute après la phase opaque mais avant le blending translucide.¹ Pour la plupart des apps, l’implémentation MSAA intégrée au matériel gère le travail ; les résolutions personnalisées sont un outil pour les cas particuliers décrits dans la documentation d’Apple.

Comment l’optimisation MSAA d’Apple fait-elle gagner du travail ?

Le matériel d’Apple suit le nombre d’échantillons uniques par pixel à mesure qu’il rend de nouvelles primitives. Exemple d’Apple : un pixel couvert par deux bords de triangle a trois couleurs uniques sur quatre positions d’échantillon ; les GPU A11+ font le blending deux fois plutôt que trois car deux échantillons partagent une couleur, et un triangle opaque ultérieur ramène le pixel à une seule couleur.¹ L’optimisation s’exécute au niveau matériel ; les apps en bénéficient sans modifier l’API.

L’architecture GPU d’Apple est-elle documentée ailleurs que sur la page TBDR ?

Le sujet « Apple silicon » de la documentation Metal d’Apple renvoie à la page TBDR qui sous-tend cet article. Les sessions WWDC d’Apple sur Metal couvrent également des détails d’architecture GPU, et la Metal Shading Language Specification couvre la surface au niveau shader. Apple n’a pas publié les détails sous-jacents au niveau silicium (nombres de clusters, largeurs d’ALU, spécificités du moteur de rasterisation) pour une génération donnée de GPU Apple dans la documentation développeur ; traitez tout chiffre de ce type trouvé en dehors de developer.apple.com comme non vérifié.

Références