Optimisation du rendu pour mobile, partie 2. Les principales familles de GPU mobiles modernes

Salutations, chers amoureux et professionnels, programmeurs graphiques! Commençons la deuxième partie de notre série d'articles sur l'optimisation du rendu pour mobile. Dans cette partie, nous considérerons les principales familles de GPU présentées par les joueurs sur Mobile.


Pour commencer, considérez un certain nombre de critères selon lesquels les GPU mobiles peuvent être classés.

Noyaux de shader unifiés ou spécialisés


À l'ère des premières cartes vidéo mobiles, avant la propagation d'effets complexes, il existait un point de vue selon lequel pour les shaders de fragments, la prise en charge de calculs avec une précision réduite était suffisante. En effet, dans un mode d'affichage typique, 8 bits voire moins sont utilisés pour chaque canal de couleur. Cette vue a conduit à l'utilisation de noyaux de shader spécialisés. Pour les sommets, nous avons utilisé des noyaux optimisés pour les transformations matricielles avec une précision accrue FP24 / FP32 ( highp ). Pour les pixels, noyaux qui fonctionnent plus efficacement avec une précision réduite FP16 ( mediump ). Avec ce highpils n'étaient pas pris en charge. À première vue, cette spécialisation nous permet d'obtenir une répartition plus rationnelle des transistors sur la puce. Cependant, en pratique, cela conduit à des difficultés à développer des effets complexes, ainsi qu'à utiliser des textures haute résolution. De plus, la spécialisation de base peut conduire à un goulot d'étranglement de sommet / fragment . Ce terme fait référence à la situation où, en raison de la charge asymétrique sur les noyaux des sommets et des pixels, certains des noyaux étaient «inactifs». 


Par conséquent, les architectures modernes utilisent des cœurs unifiés. Ces noyaux peuvent prendre en charge le sommet, le pixel et d'autres tâches de calcul en fonction de la charge.


Jeu d'instructions vectorielles (SIMD) ou scalaires


Dans l'esprit du désir d'économiser sur les transistors décrits ci-dessus, spécialisé dans les noyaux, la conception d'un ensemble d'instructions de shader a eu lieu. La plupart des transformations typiques des graphiques tridimensionnels fonctionnent avec 4 vecteurs composants. Par conséquent, les premiers GPU fonctionnaient spécifiquement avec de tels opérandes. Si le code du shader contenait des opérations scalaires hétérogènes qui ne pouvaient pas être regroupées en opérations vectorielles par l'optimiseur, une partie de la puissance de calcul n'était pas utilisée. Ce phénomène peut être illustré comme suit:


Il existe un shader qui implémente l'opération d'ajout de multiplication commune: multipliez 2 opérandes, puis ajoutez le troisième. Lors de la compilation sur une architecture vectorielle conditionnelle (Vector ISA = Vector Instruction Set Architecture), nous obtenons une instruction vectorielle vMADD , qui fonctionne pour 1 horloge. Sur l'architecture scalaire conditionnelle, nous obtenons 4 instructions scalaires qui, grâce à un pipeline amélioré, s'exécutent également en 1 cycle d'horloge. Considérons maintenant un shader sophistiqué qui effectue 2 opérations, mais sur 2 opérandes composants.


Dans le cas de l'architecture vectorielle, nous obtenons déjà 2 instructions qui nécessitent 2 cycles d'horloge pour s'exécuter. Cependant, aucune action n'est prise sur les composants .zw et la puissance de traitement est inactive. Dans le cas d'une architecture scalaire, ces mêmes opérations peuvent être regroupées dans 4 sMADD scalaires qui s'exécutent dans le même cycle d'horloge. Ainsi, sur l'architecture scalaire du fait de l'amélioration du pipeline, une densité de calculs plus élevée est atteinte. Cependant, comme cela sera montré ci-dessous, le vecteur ISA est toujours pertinent. Il est donc logique d'appliquer des techniques de vectorisation pour le code de shader. Ils vous permettent d'obtenir des performances accrues sur les cartes vidéo avec le vecteur ISA . En même temps, en règle générale, cela ne nuit pas aux performances sur des scalaires plus modernesL'ISA .

Sur la base des caractéristiques ci-dessus, nous considérerons les familles de GPU mobiles qui sont courantes à notre époque. Commençons par la famille la plus courante. Beaucoup de gens savent que nous parlons de cartes graphiques Mali de la société britannique ARM . ARM n'est pas directement impliqué dans la production de puces, offrant plutôt la propriété intellectuelle. Comme les autres cartes vidéo mobiles, le Mali fait partie de System on Chip (SoC) , c'est-à-dire fonctionne avec la mémoire partagée pour le CPU et le GPU et le bus. 

Mali utgard


En 2008, les premiers représentants de l'architecture Mali Utgard sont nés , pertinents jusqu'à nos jours. Ces cartes vidéo sont nommées selon le schéma Mali-4 xx MP n , où xx est le numéro de modèle et n est le nombre de cœurs de fragments. Au Mali , la spécialité du noyau de shader Utgard , et tous les modèles sont livrés avec un sommet seulement 1 noyau.

Autres caractéristiques de l'architecture Mali Utgard:

  • OpenGL ES 2.0 
  • Manque de support highp dans les noyaux fragmentés
  • Jeu d'instructions vectorielles (il est logique de vectoriser les calculs)

Malgré la spécification OpenGL ES , les pilotes de cartes vidéo Mali Utgard compilent avec succès des shaders de fragments qui utilisent une précision haute résolution (par exemple, la précision est définie par défaut à l'aide de la précision flottante haute précision ). Mais la précision de mediump est effectivement utilisée . Par conséquent, il est conseillé de tester en outre tous les shaders pour les jeux mobiles sur ces cartes vidéo. Selon les données recueillies par Unity , fin 2019, Mali Utgard a travaillé sur des appareils pour environ 10% des joueurs. Et si vous définissez les filtres appropriés sur market.yandex.ru , vous pouvez voir qu'en 2019 plus de 10 nouveaux téléphones avec des cartes vidéo de cette architecture ont été annoncés.


Si vous êtes prêt à abandonner cette audience, il suffit de définir l'exigence de prise en charge d'OpenGL ES 3.0 dans AndroidManifest.xml:

<uses-feature android:glEsVersion="0x00030000" android:required="true"⁄>

En plus de Mali Utgard , il n'y a actuellement aucun GPU mobile répandu sans prise en charge d'OpenGL ES 3.0.

Il convient de noter en particulier l'utilisation de textures haute résolution sur le Mali Utgard . Dix bits de la mantisse avec une précision moyenne ne suffisent pas pour une texturation de haute qualité avec une résolution de texture supérieure à 1024 d'un côté. Cependant, bien qu'il ne prenne en charge que la précision mediump dans les cœurs de fragments Mali Utgard , vous pouvez obtenir une précision des coordonnées de texture fp24 lorsque vous utilisez directement la variation .

// vertex shader
varying highp vec2 v_texc;
void main()
{
    v_texc = …;
}

//  fragment shader
...
varying highp vec2 v_texc;
void main()
{
    gl_FragColor = texture2D(u_sampler, v_texc); //  v_texc 
                                                 //  
}

En prime sur certaines architectures, cette approche vous permet de pré- extraire le contenu de la texture avant d'exécuter un fragment shader , ce qui minimise les blocages en attendant les résultats de l'échantillonnage de texture.

Mali midgard


Le Mali Utgard a été remplacé par l'architecture Mali Midgard . Il existe plusieurs générations de cette architecture avec les noms des espèces Mali-6xx , Mali-7xx et Mali-8xx . Malgré l'âge de 8 ans, Mali Midgard peut être qualifié d'architecture moderne qui prend en charge la plupart des nouvelles fonctionnalités:

  • noyaux de shader unifiés
  • OpenGL ES 3.2 (shaders de calcul et de géométrie, tesselation ...)

Cependant, le Mali Midgard conserve le vecteur ISA . Compte tenu de l'utilisation généralisée de Mali Midgard (environ 25% de notre audience), la vectorisation de l'informatique devient appropriée.

Une autre caractéristique de Mali Midgard est la technologie Forward Pixel Kill . Chaque pixel est calculé dans un flux séparé du noyau du fragment. Si, pendant l'exécution du flux, il devient connu que le pixel résultant sera bloqué par un pixel opaque d'une autre primitive, le flux se termine prématurément et les ressources libérées sont utilisées pour d'autres calculs.

Bifrost du Mali


A côté de Midgard, l' architecture Bifrost se distingue par sa transition vers l' ISA scalaire . Par rapport à l'architecture précédente, le nombre maximal de cœurs a été augmenté (de 16 à 32) et une interface améliorée avec un processeur est prise en charge, ce qui permet un accès cohérent à la mémoire partagée: les modifications du contenu de la mémoire du processeur / GPU deviennent immédiatement «visibles» les unes aux autres malgré les caches, qui vous permet de simplifier la synchronisation.

De non officiel


De nombreuses tentatives ont été faites pour désosser les cartes vidéo du Mali afin de créer des pilotes Open Source pour Linux . Les travaux des personnes dévouées qui tentent de le faire nous permettent de jeter un coup d'œil aux fonctionnalités non documentées des cartes vidéo du Mali . Ainsi, dans le projet PanFrost , il existe un désassembleur pour Mali Midgard / Bifrost , avec lequel vous pouvez vous familiariser avec un ensemble d'instructions de shader (il n'y a pas d'informations officielles ouvertes sur ce sujet).


Adreno


Adreno est la deuxième famille de GPU mobiles la plus courante . Cette carte vidéo est installée sur le SoC , connu sous la marque Snapdragon , de la société américaine Qualcomm . Snapdragon est installé dans les smartphones haut de gamme de notre époque de Samsung , Sony et autres.Les cartes vidéo Adreno actuelles sont les familles de la série 3xx - 6xx. Toutes ces séries combinent les fonctionnalités suivantes:



  • noyaux de shader unifiés
  • Pseudo TBR (grandes tailles de tuiles situées dans une mémoire GPU dédiée traditionnelle)
  • Commutation automatique en mode de rendu immédiat en fonction de la nature de la scène ( FlexRender )
  • Jeu d'instructions scalaire

À partir d' Adreno 4xx , la prise en charge d' OpenGL ES 3.1 est introduite et d' Adreno 5xx - Vulkan et OpenGL ES 3.2 .

Rendu basé sur les tuiles Adreno


Les cartes vidéo Adreno ont un GPU «traditionnel» appelé GMEM . Des volumes de 128 Ko à 1536 Ko s'appliquent. Cela vous permet d'utiliser une taille de tuile plus grande par rapport aux architectures d'autres développeurs de GPU mobiles. Sur Adreno, la taille des tuiles est dynamique et dépend du format de couleur utilisé, du tampon de profondeur et du pochoir. Lorsque vous travaillez en mode immédiat, le rendu se produit dans la mémoire système. Il existe une extension GL ES qui vous permet de spécifier le mode préféré: QCOM_binning_control . Cependant, les dernières recommandations de Qualcomm suggèrent de s'appuyer entièrement sur les pilotes GPU, qui déterminent eux-mêmes le mode le plus préféré pour le tampon de commande généré par l'application. 

Lorsque vous travaillez en mode TBR Adreno fait 2 passes de vertex:

  1. Passe de binning - distribution des primitives par bin ( bacs , synonyme de tuiles)
  2. Passe de sommet complète pour rendre uniquement les primitives qui tombent dans le chutier actuel

Pendant la passe Binning, Adreno ne calcule que les positions des sommets. Les autres attributs ne sont pas calculés et le code inutile est supprimé par l'optimiseur. Dans la documentation officielle (9.2 Optimiser le traitement des sommets), il est recommandé de stocker les informations sur les sommets nécessaires pour calculer les positions séparément du reste des données. Cela rend la mise en cache des données de sommet plus efficace.

Freedreno


Contrairement aux technologies ARM et Imagination, Qualcomm hésite à partager les détails de la structure interne de ses GPU. Cependant, grâce aux efforts de l'ingénieur inverse Rob Clark, on peut apprendre beaucoup du projet Freedreno , le pilote open source Adreno pour Linux.

Rob Clark par Freedreno

PowerVR par Imagination Technologies


Imagination Technologies est une société britannique sans usine célèbre pour le développement de GPU pour les produits Apple. La société a joué ce rôle jusqu'à l'avènement de l'iPhone 8 / X, qui utilise le développement interne d'Apple. Bien que les recommandations sur les optimisations pour ces puces qui sont restées inchangées, ainsi que les revendications de brevet contre Apple d'Imagination suggèrent qu'Apple a continué à développer l'architecture PowerVR, un développement original d'Imagination. Au début de 2020, Apple est revenu aux pratiques de licence avec Imagination Technologies. En plus des appareils avec iOS / iPadOS, les cartes vidéo PowerVR sont installées dans un grand nombre de smartphones et tablettes Android.


Considérez la famille de cartes graphiques PowerVR que l'on trouve encore parmi les utilisateurs.

PowerVR SGX


Les premières cartes graphiques PowerVR SGX sont apparues en 2009. Il existe plusieurs générations de cette architecture: Series5, Series5XT et Series5XE. Apple a utilisé ces GPU jusqu'à l'iPAD 4 / iPhone 5 / iPOD Touch 5. Les fonctionnalités SGX suivantes peuvent être citées:

  • noyaux de shader unifiés
  • OpenGL ES 2.0
  • jeu d'instructions vectorielles
  • prise en charge de la précision lowp 10 bits dans les shaders
  • faible performance des lectures de texture dépendante

Arrêtons-nous sur certains d'entre eux plus en détail. 

Précision Lowp


PowerVR SGX sont les seuls GPU mobiles à jour avec
prise en charge matérielle lowp . Les modèles PowerVR plus récents, ainsi que tous les GPU modernes d'autres fournisseurs, utilisent en fait une précision moyenne . L'utilisation de
lowp sur le PowerVR SXG vous permet d'obtenir une densité de calcul plus élevée (plus d'opérations par cycle). Dans le même temps, l'opération swizzle (permutation des composantes vectorielles) pour lowp , contrairement à d'autres précisions, n'est pas gratuite. Cette fonctionnalité, ainsi que la gamme étroite de valeurs fournies par lowp ([-2,2]), limitent sa portée. Dans le même temps, le lowp mal régléentraînant des artefacts sur la famille SGX ne sera pas visible sur toutes les autres cartes graphiques où la précision mediump sera réellement utilisée . Pour cette raison, vous devriez envisager de refuser d'utiliser lowp dans les shaders.

La texture dépendante se lit


Comme vous le savez, les opérations d'échantillonnage de texture sont les plus lentes en raison de la nécessité d'attendre les résultats de lecture de la mémoire. Dans le cas du SoC mobile, nous parlons de mémoire système partagée avec un CPU. Pour réduire le nombre d'accès à la mémoire lente, des caches de texture sont utilisés. Pour éviter les temps d'arrêt au début de la pixellisation à l'aide d'une texture, il est judicieux de mettre en cache les zones utilisées à l'avance. Si le shader de fragment utilise les coordonnées de texture transmises depuis le vertex shader sans modifications, la section de texture nécessaire à la mise en cache peut être déterminée avant l'exécution du shader de fragment. Si le shader de fragment change la coordonnée de texture ou la calcule en utilisant les données d'une autre texture, alors ce n'est pas toujours possible. Par conséquent, l'exécution du fragment shader peut ralentir.Les cartes graphiques PowerVR SGX sont particulièrement douloureuses dans ce scénario. De plus, même l'utilisation d'une permutation des composantes de la coordonnée de texture (swizzle) conduit àtexture dépendante lue . Voici un exemple de programme de shader sans lecture de texture dépendante .

programme vertex

attribute highp vec2 a_texc;
varying highp vec2 v_texc;

void main()
{
	gl_Position = …
	v_texc = a_texc;
}


programme de fragment

precision mediump float;
uniform sampler u_sampler;
varying highp vec2 v_texc;

void main()
{
	gl_FragColor = texture2D( u_sampler, v_texc ); //  dependent texture read
}

Dans ce cas:

programme de fragment

precision mediump float;
uniform sampler u_sampler;
varying highp vec2 v_texc;

void main()
{
	gl_FragColor = texture2D( u_sampler, v_texc.yx ); // dependent texture read!
}

PowerVR Rogue


Les cartes vidéo PowerVR ont été développées dans l'architecture Rogue . Il existe plusieurs générations de cette architecture: de la série 6 à la série 9. Tous les PowerVR Rogue ont ces caractéristiques:

  • noyaux de shader unifiés
  • architecture d'instruction scalaire
  • prise en charge d'OpenGL ES 3.0+ (jusqu'à 3.2, ainsi que de l'API Vulkan pour les nouvelles règles) 

PowerVR TBDR


Comme tous les GPU mobiles courants, PowerVR utilise un pipeline de tuiles. Mais contrairement à ses concurrents, Imagination est allé plus loin et a mis en œuvre une pixellisation différée des primitives, permettant d'ignorer l'ombrage des pixels invisibles quel que soit l'ordre de rendu. Cette approche est appelée rendu différé basé sur les tuiles , et le processus d'élimination des pixels invisibles est appelé suppression de surface cachée (HSR).


Suppression de la surface cachée

Il est recommandé de dessiner la géométrie opaque sur transparent et de ne pas utiliser Z Prepass, ce qui dans le cas des cartes vidéo PowerVR dans la plupart des scénarios entraînera un travail inutile. Cependant, plusieurs pixels transparents consécutifs se chevauchant sont complètement ombrés pour obtenir la bonne couleur, en tenant compte du mélange. Le dernier pixel transparent peut être supprimé s'il est suivi d'un pixel opaque. 

Technologies d'imagination d'ouverture


Les créateurs de PowerVR ont fourni un accès ouvert à plus de documentation que les autres développeurs de GPU. L'architecture du pipeline graphique est décrite en détail, ainsi qu'un ensemble d'instructions pour l'architecture Rogue . Il existe un outil pratique PVRShaderEditor , qui vous permet de recevoir instantanément des informations de profilage sur le shader, ainsi que sa liste démontée pour Rogue.


Malgré la présence limitée des cartes vidéo PowerVR dans l'environnement des appareils basés sur Android, il est logique d'étudier leur architecture pour la programmation compétente des graphiques pour iOS.

GPU mobiles en mode immédiat


Nous avons examiné les familles de cartes vidéo mobiles les plus courantes. Toutes ces familles utilisaient une architecture de rendu de tuiles. Cependant, il existe des cartes vidéo mobiles qui utilisent l' approche traditionnelle en mode immédiat . En voici quelques uns:

  • nVIdia (Tegra SoC)
  • Toute la famille Intel à l'exception de la récente génération 11
  • Vivante GCxxxx (+ Arcturus GC8000)

Une caractéristique des cartes vidéo mobiles fonctionnant en mode immédiat est l'opération de nettoyage FBO coûteuse. Rappelons que sur l'architecture de tuile, le nettoyage en plein écran accélère le rendu, permettant au pilote de ne pas ajouter l'opération de chargement de l'ancien contenu à la mémoire de tuile. Sur les GPU en mode immédiat mobile , le nettoyage plein écran est une opération longue qui permet, entre autres, à ces GPU de «calculer». Si l'ajout de nettoyage n'accélère pas, mais ralentit le rendu, alors nous travaillons très probablement avec un GPU en mode immédiat . Bien sûr, n'oublions pas de mentionner que sur les GPU en mode immédiat, changer une cible est une procédure «conditionnellement libre».

Répartition des différentes familles de GPU mobiles parmi nos joueurs


Voici les statistiques sur les GPU mobiles collectées auprès de nos joueurs fin 2019:


Ci-dessous, nous ouvrons le segment «Autres»


Sur la base de ces données, nous examinons la distribution du GPU en termes de leurs principales caractéristiques.


Les ALU vectorielles (unité de logique arithmétique) deviennent obsolètes et remplacées par des unités scalaires. Aujourd'hui, l'essentiel des GPU mobiles avec un jeu d'instructions vectorielles est le Mali Midgard , qui peut être considéré comme moyen en termes de performances. Parce que la vectorisation, en règle générale, ne ralentit pas l'exécution sur les ALU scalaires; il convient de considérer la vectorisation comme une technique réelle pour optimiser les shaders pour mobile. 

Les noyaux de shaders spécialisés sont obsolètes et remplacés par des noyaux unifiés. Le goulot d'étranglement du sommet du maillage squelettique n'est plus effrayant. Les noyaux spécialisés sont utilisés uniquement sur la famille Mali-4xx (Utgard) . Rappelez-vous que ces GPU ne prennent en charge que OpenGL ES 2.0 . Notre audience en compte environ 3,5%.

Enfin, la grande majorité des GPU mobiles utilisent l'approche des tuiles. Le mode immédiat est devenu marginalisé et est rapidement éliminé avec les cartes vidéo qui l'utilisent. La part des GPU en mode immédiat dans nos lecteurs est d'environ 0,7%.

Liens utiles:


Merci pour l'attention! Dans le prochain article de la série, nous examinerons les techniques d'optimisation des shaders pour Mobile.

All Articles