GPU, accélérateurs hexagonaux et algèbre linéaire

Tous ces mots sont beaucoup plus étroitement liés au développement mobile qu'il n'y paraît à première vue: les accélérateurs hexagonaux aident déjà à former des réseaux de neurones sur des appareils mobiles; l'algèbre et le matan sont utiles pour obtenir un emploi chez Apple; et la programmation GPU vous permet non seulement d'accélérer les applications, mais vous apprend également à voir l'essence des choses.

En tout cas, dit le responsable du développement mobile de Prisma Andrey Volodin . Et aussi sur la façon dont les idées se développent dans le développement mobile à partir de GameDev, comment les paradigmes diffèrent, pourquoi Android n'a pas de flou natif - et bien plus encore, une version productive d'AppsCast a été publiée. Sous la coupe, nous parlerons du rapport d'Andrey sur AppsConf sans spoilers.



AppsCast est le podcast de la conférence des développeurs mobiles AppsConf . Chaque numéro est un nouvel invité. Chaque invité est un conférencier de la conférence avec lequel nous discutons de son rapport et discutons de sujets liés à celui-ci. Le podcast est hébergé par les membres du comité du programme AppsConf, Alexei Kudryavtsev et Daniil Popov.

Alexey Kudryavtsev: Bonjour à tous! Andrey, parlez-nous de votre expérience.

Andrey Volodin : Chez Prisma, nous développons des produits qui sont principalement liés au traitement des photos et des vidéos. Notre application phare est Prisma. Nous créons maintenant une autre application Lensa pour des fonctionnalités de type Facetune.

Je dirige le développement mobile, mais je suis coach de jeu. J'ai toute la partie centrale, j'écris des pipelines GPU pour toutes ces applications. Je développe des frameworks de base pour que les algorithmes et les neurones développés par l'équipe R&D fonctionnent sur des appareils mobiles, fonctionnent en temps réel. Bref, pour tuer l'informatique serveur et tout ça.

Alexei Kudryavtsev: Cela ne ressemble pas à un développement iOS régulier.

Andrey Volodin: Oui, j'ai de telles spécificités - j'écris sur Swift tous les jours, mais en même temps, c'est très loin de ce qui est considéré comme un développement iOS.

Daniil Popov: Vous avez mentionné les pipelines GPU, de quoi s'agit-il?

Andrey Volodin: Lorsque vous faites des éditeurs de photos, vous devez également configurer l'architecture et décomposer la logique, car l'application dispose de différents outils. Par exemple, à Lensa, il y a un outil de bokeh qui brouille l'arrière-plan à l'aide d'un neurone, il y a un outil de retouche qui rend une personne plus belle. Tout cela doit fonctionner plus efficacement sur le GPU. De plus, il est conseillé de ne pas transférer de données entre le processeur et la carte vidéo à chaque fois, mais de pré-construire un ensemble d'opérations, de les exécuter en une seule fois et de montrer à l'utilisateur le résultat final.

Les pipelines GPU sont des «petits morceaux» à partir desquels les instructions pour une carte vidéo sont assemblées. Ensuite, elle fait tout cela très rapidement et efficacement, et vous prenez le résultat à la fois, et non après chaque instrument. Je m'assure que nos pipelines GPU sont aussi rapides que possible, efficaces et existent généralement en principe.

Alexey Kudryavtsev: Dites-moi, comment en êtes-vous arrivé là? Un développeur iOS régulier commence par riveter et mouler, puis va quelque part par l'API et est content. Comment est-il arrivé que vous fassiez quelque chose de complètement différent?

Andrey Volodin: Pour la plupart, c'est une coïncidence. Avant de décrocher un emploi, j'ai créé des jeux pour iOS. Cela a toujours été intéressant pour moi, mais j'ai compris qu'en Russie, il n'y a surtout nulle part où se développer dans cette direction. Il se trouve que nous nous sommes rencontrés avec Prisma. Ils avaient besoin d'un développeur iOS capable d'écrire sur Swift et connaissant en même temps le GPU, en particulier Metal, qui vient de sortir à l'époque, et je correspond définitivement à cette description.

J'ai répondu à la vacance, nous avions une synergie, et pour la troisième année maintenant, je suis allé de plus en plus profondément dans cette chose. Si quelque chose ne va pas maintenant, alors j'ai déjà tous ces Viper et MVVM - je ne sais même pas comment ça décrypte - je devrai comprendre dès le début.

Que fait l'ingénieur GPU

Daniil Popov: votre profil AppsConf indique le GPU Engineer. Que fait le GPU Engineer la plupart de la journée en plus de boire du café?

Andrey Volodin: Ici, il est nécessaire de mentionner en quoi le processeur est fondamentalement différent du GPU. Le processeur exécute les opérations comme si séquentiellement. Même le multithreading que nous avons est souvent faux: le processeur s'arrête et bascule pour faire de petits morceaux de tâches différentes, et les exécute en quelques tranches. Le GPU fonctionne exactement de la manière opposée. Il existe n processeurs qui fonctionnent réellement en parallèle, et il existe un parallélisme entre les processus et le parallélisme au sein du GPU.

Mon travail principal, en plus d'optimiser le travail avec la mémoire et d'organiser la réutilisation du code, est de porter les algorithmes écrits pour le CPU sur les cartes vidéo afin qu'ils soient parallèles. Ce n'est pas toujours une tâche banale, car il existe des algorithmes très efficaces qui sont complètement liés à l'exécution séquentielle des instructions. Mon travail consiste à trouver, par exemple, une approximation pour un tel algorithme qui ne fait peut-être pas exactement la même chose, mais visuellement le résultat ne peut pas être distingué. Nous pouvons donc obtenir une accélération 100 fois, sacrifiant un peu la qualité.

Je porte également des neurones. Soit dit en passant, nous ferons bientôt une version majeure de l'Open Source. Avant même l'apparition de Core ML, nous avions notre propre homologue, et nous avons finalement mûri pour le mettre en Open Source. Son paradigme est légèrement différent de Core ML. Moi, notamment, j'élabore sa partie centrale.

En général, je fais tout ce qui concerne les algorithmes de vision par ordinateur et l'informatique.

Alexey Kudryavtsev: Une annonce intéressante.

Andrey Volodin: Ce n'est pas un secret, nous ne l'annoncerons pas avec une sorte de fanfare, il sera juste possible de voir un exemple des frameworks utilisés à l'intérieur de Prisma.

Pourquoi optimiser pour le GPU

Alexei Kudryavtsev: Dites-moi, s'il vous plaît, pourquoi optimisons-nous les algorithmes pour le GPU en général? Il peut sembler suffisant d'ajouter des cœurs au processeur ou d'optimiser l'algorithme. Pourquoi exactement le GPU?

Andrey Volodin: Le travail sur le GPU peut considérablement accélérer les algorithmes. Par exemple, nous avons des neurones qui fonctionneront sur le processeur central Samsung S10 pendant 30 s, et sur le GPU, il y aura 1 trame, soit 1/60 s. C'est une expérience utilisateur incroyablement changeante. Il n'y a pas d'écran de chargement éternel, vous pouvez voir le résultat de l'algorithme travaillant sur le flux vidéo, ou tourner le curseur et voir les effets là.

Ce n'est pas du tout que nous sommes trop cool pour écrire sur le CPU, donc nous réécrivons tout sur le GPU. L'utilisation d'un GPU a un objectif transparent - accélérer les choses.

Alexei Kudryavtsev: Le GPU gère bien des opérations similaires les unes aux autres en parallèle. Avez-vous de telles opérations et par conséquent réussissez-vous à obtenir un tel succès?

Andrey Volodin: Oui, la principale difficulté n'est pas de coder, mais de créer de tels algorithmes qui sont bien transférés au GPU. Ce n'est pas toujours trivial. Il arrive que vous ayez compris comment tout faire cool, mais pour cela, vous avez besoin de trop de points de synchronisation. Par exemple, vous écrivez tout dans une seule propriété, et c'est un signe clair que ce sera mal parallèle. Si vous écrivez beaucoup au même endroit, tous les threads devront se synchroniser pour cela. Notre tâche est d'approximer les algorithmes pour qu'ils soient bien parallèles.

Alexei Kudryavtsev: Pour moi, en tant que développeur mobile, cela ressemble à de la science des fusées.

Andrey Volodin: En fait, ce n'est pas si difficile. Pour moi, la science des fusées est VIPER.

Troisième puce

Daniil Popov: Il semble qu'à la dernière conférence Google I / O, ils aient annoncé un morceau de fer pour TensorFlow et d'autres choses. Quand la troisième puce apparaîtra-t-elle enfin dans les téléphones mobiles, en TPU ou comment s'appellera-t-elle, qui fera également toute la magie ML sur l'appareil?

Andrey Volodin: Nous avons ce truc, il se connecte via USB, et vous pouvez y conduire des neurones de Google. Huawei a déjà cela, nous avons même écrit un logiciel pour leurs accélérateurs hexagonaux, afin que les neurones de segmentation chassent rapidement le P20.

Je dois dire que dans l'iPhone, ils existent déjà. Par exemple, dans le dernier iPhone XS, il existe un coprocesseur appelé NPU (Neural Processing Unit), mais jusqu'à présent, seul Apple y a accès. Ce coprocesseur coupe déjà le GPU dans l'iPhone. Certains modèles Core ML utilisent des NPU et sont donc plus rapides que le métal nu.

Ceci est important, étant donné qu'en plus des neurones à inférence la plus faible, Core ML nécessite beaucoup d'actions supplémentaires. Vous devez d'abord convertir les données d'entrée au format Core ML, il les traitera, puis les renverra dans leur format - vous devez les reconvertir et ensuite les montrer à l'utilisateur. Tout cela prend un certain temps. Nous écrivons des pipelines sans frais généraux qui fonctionnent du début à la fin sur le GPU, tandis que les modèles Core ML sont plus rapides précisément en raison de ce processus matériel.

Très probablement, lors de la WWDC en juin, ils présenteront un cadre pour travailler avec NPU.

Autrement dit, comme vous l'avez dit, il existe déjà des appareils, seuls les développeurs ne peuvent pas encore les utiliser pleinement. Mon hypothèse est que les entreprises elles-mêmes ne comprennent pas encore comment procéder soigneusement sous la forme d'un cadre. Ou ils ne veulent tout simplement pas donner pour avoir un avantage sur le marché.

Alexei Kudryavtsev: Avec le scanner d'empreintes digitales, la même chose était dans l'iPhone, si je me souviens bien.

Andrey Volodin: Il n'est pas si abordable que ça maintenant. Vous pouvez l'utiliser au niveau supérieur, mais vous ne pouvez pas obtenir l'impression elle-même. Vous pouvez simplement demander à Apple de laisser l'utilisateur l'utiliser. Ce n'est toujours pas un accès complet au scanner lui-même.

Accélérateurs hexagonaux

Daniil Popov: Vous avez mentionné le terme accélérateurs hexagonaux. Je pense que tout le monde ne sait pas ce que c'est.

Andrey Volodin: Ce n'est qu'un morceau d'architecture matérielle que Huawei utilise. Je dois dire qu'elle est plutôt sophistiquée. Peu de gens le savent, mais dans certains Huawei, ces processeurs sont, mais ne sont pas utilisés, car ils ont un bug matériel. Huawei les a libérés, puis a trouvé un problème, maintenant dans certains téléphones, les puces spéciales sont mortes. Dans les nouvelles versions, tout fonctionne déjà.

En programmation, il y a le paradigme SIMD (Single Instruction, Multiple Data), lorsque les mêmes instructions sont exécutées en parallèle sur des données différentes. La puce est conçue de manière à pouvoir traiter une opération en parallèle sur plusieurs flux de données à la fois. En particulier, hexagonal signifie que sur 6 éléments en parallèle.

Alexei Kudryavtsev: Je pensais que le GPU fonctionne comme ceci: il vectorise une tâche et effectue la même opération sur différentes données. Quelle est la différence?

Andrey Volodin : Le GPU est plus polyvalent. Malgré le fait que la programmation pour le GPU soit plutôt bas, en ce qui concerne le travail avec les coprocesseurs, c'est assez haut niveau. Pour la programmation sur le GPU, un langage de type C est utilisé. Sur iOS, le code est toujours compilé avec LLVM dans les instructions de la machine. Et ces choses pour les coprocesseurs sont le plus souvent écrites directement hardcore - dans l'assembleur, sur les instructions de la machine. Par conséquent, l'augmentation de la productivité est beaucoup plus notable, car ils sont affûtés pour des opérations spécifiques. Vous ne pouvez rien compter du tout sur eux, mais vous ne pouvez compter que ce à quoi ils étaient initialement destinés.

Alexei Kudryavtsev: Et pourquoi sont-ils généralement conçus?

Andrey Volodin: Maintenant principalement pour les opérations les plus courantes dans les réseaux de neurones: convolution - convolution ou une sorte d'activation intermédiaire. Ils ont une fonctionnalité précâblée qui fonctionne très rapidement. Ils sont donc beaucoup plus rapides sur certaines tâches que le GPU, mais dans tout le reste, ils ne sont tout simplement pas applicables.

Alexei Kudryavtsev: Cela ressemble à des processeurs DSP, qui étaient autrefois utilisés pour l'audio, et tous les plugins et effets y ont fonctionné très rapidement. Du matériel cher et spécial a été vendu, mais les processeurs ont grandi, et maintenant nous enregistrons et traitons les podcasts directement sur les ordinateurs portables.

Andrey Volodin: Oui, à peu près la même chose.

GPU non seulement pour les graphiques

Daniil Popov: Je comprends bien que maintenant, sur le GPU, vous pouvez traiter des données qui ne sont pas directement liées aux graphiques? Il s'avère que le GPU perd son objectif d'origine.

Andrey Volodin: Exactement. J'en parle souvent lors de conférences. Le premier était NVidia, qui a présenté CUDA. Il s'agit d'une technologie qui simplifie le GPGPU (General-purpose computing on graphics processing units). Vous pouvez y écrire un sur-ensemble d'algorithmes C ++ parallélisés sur le GPU.

Mais les gens l'ont déjà fait. Par exemple, les artisans d'OpenGL ou de DirectX encore plus ancien ont simplement écrit des données dans la texture - chaque pixel a été interprété comme des données: les 4 premiers octets du premier pixel, les 4 derniers octets du second. Ils ont traité les textures, puis les données de la texture ont été extraites et interprétées. C'était très compliqué et compliqué. Les cartes vidéo prennent désormais en charge la logique à usage général. Vous pouvez alimenter n'importe quel tampon dans le GPU, décrire vos structures, même la hiérarchie des structures dans lesquelles elles se référeront, calculer quelque chose et le renvoyer au processeur.

Daniil Popov: Autrement dit, nous pouvons dire que le GPU est désormais Data PU.

Andrey Volodin: Oui, les graphiques sur le GPU sont parfois moins traités que les calculs généraux.

Alexei Kudryavtsev: L' architecture du CPU et du GPU est différente dans son essence, mais vous pouvez la considérer à la fois là et là.

Andrey Volodin : En effet, à certains égards, le CPU est plus rapide, à certains égards le GPU. Cela ne veut pas dire que le GPU est toujours plus rapide.

Daniil Popov: Si je me souviens bien, si la tâche consiste à calculer quelque chose de très différent, alors sur le CPU, cela peut être beaucoup plus rapide.

Andrey Volodin: Cela dépend aussi de la quantité de données. Il y a toujours la surcharge de transfert de données du CPU vers le GPU et vice versa. Si vous considérez, par exemple, un million d'éléments, l'utilisation d'un GPU est généralement justifiée. Mais compter un millier d'éléments sur un processeur peut être plus rapide que de simplement les copier sur une carte graphique. Par conséquent, vous devez toujours choisir la tâche.

Soit dit en passant, Core ML le fait. Core ML peut exécuter, selon Apple, pour choisir où il est plus rapide à calculer: sur le processeur ou sur la carte vidéo. Je ne sais pas si cela fonctionne en réalité, mais ils disent oui.

Connaissances d'ingénieur GPU hardcore pour un développeur mobile

Alexey Kudryavtsev: Revenons au développement mobile. Vous êtes un ingénieur GPU, vous avez des tonnes de connaissances hardcore. Comment ces connaissances peuvent-elles être appliquées à un développeur mobile? Par exemple, que voyez-vous dans UIKit que les autres ne voient pas?

Andrey Volodin: Je vais en parler en détail à AppsConf. Vous pouvez appliquer beaucoup où. Quand je vois, par exemple, comment fonctionne l'API UIKit, je peux immédiatement comprendre pourquoi cela est fait et pourquoi. En observant la baisse des performances lors du rendu de certaines vues, je peux comprendre la raison, car je sais comment le rendu est écrit à l'intérieur. Je comprends: pour afficher les effets du flou gaussien sur le tampon de trame, vous devez d'abord mettre en cache l'intégralité de la texture, lui appliquer une opération de flou intense, renvoyer le résultat, terminer le rendu du reste des vues, puis l'afficher uniquement à l'écran. Tout cela doit tenir en 1/60 de seconde, sinon cela ralentira.

Il est absolument évident pour moi que ce soit si long, mais pour mes collègues ce n'est pas clair. C'est pourquoi je veux partager les astuces de conception que nous utilisons souvent dans GameDev, et mes idées sur la façon dont je regarde les problèmes et essaie de les résoudre. Ce sera une expérience, mais je pense que cela devrait être intéressant.

Pourquoi Android n'a pas de flou natif

Daniil Popov: Vous avez mentionné le flou, et j'avais une question qui inquiète, je pense, tous les développeurs Android: pourquoi y a-t-il un natif plus bleu dans iOS et pas dans Android.

Andrei Volodin: Je pense que c'est à cause de l'architecture. Les plates-formes Apple utilisent l'architecture de rendu Tiled Shading. Avec cette approche, non pas le cadre entier est rendu, mais de petites tuiles - carrés, parties de l'écran. Cela vous permet d'optimiser le fonctionnement de l'algorithme, car le gain de performances principal lors de l'utilisation du GPU permet une utilisation efficace du cache. Sur iOS, le cadre est souvent rendu afin qu'il n'occupe pas du tout de mémoire. Par exemple, sur l'iPhone 7 Plus, la résolution est de 1920 * 1080, soit environ 2 millions de pixels. On multiplie par 4 octets par canal, cela donne environ 20 mégaoctets par trame. 20 Mo pour simplement stocker le tampon de trame système.

L'approche Tiled Shading vous permet de diviser ce tampon en petits morceaux et de le rendre un peu. Cela augmente considérablement le nombre d'accès au cache, car pour flouter, vous devez lire les pixels déjà dessinés et calculer la distribution gaussienne sur eux. Si vous lisez la trame entière, le taux de cache sera très faible, car chaque flux lira des endroits différents. Mais si vous lisez de petits morceaux, le taux de cache sera très élevé et la productivité sera également élevée.

Il me semble que le manque de flou natif dans Android est lié aux caractéristiques architecturales. Bien qu'il s'agisse peut-être d'une solution de produit.

Daniil Popov: Dans Android, il y a RenderScript pour cela, mais là, vous devez mélanger, dessiner, intégrer avec vos mains. C'est beaucoup plus compliqué que de cocher une case dans iOS.

Andrey Volodin: Très probablement, les performances sont également inférieures.

Daniil Popov: Oui, afin de satisfaire la liste de souhaits du concepteur, nous devons réduire l'échelle de l'image, la bleuir, puis la redimensionner afin de la sauvegarder d'une manière ou d'une autre.

Andrey Volodin: Soit dit en passant, avec cela, vous pouvez faire différentes astuces. La distribution gaussienne est un cercle flou. Le sigma de Gauss dépend du nombre de pixels que vous souhaitez qu'ils collectent. Souvent, en tant qu'optimisation, vous pouvez réduire l'échelle d'une image et rétrécir légèrement le sigma, et lorsque vous retournez l'échelle d'origine, il n'y aura pas de différence, car le sigma dépend directement de la taille de l'image. Nous utilisons souvent cette astuce à l'intérieur pour accélérer le flou.

Daniil Popov: Cependant, RenderScript dans Android ne vous permet pas de créer un rayon supérieur à 30.

Andrey Volodin: En fait, un rayon de 30, c'est beaucoup. Encore une fois, je comprends que la collecte de 30 pixels à l'aide d'un GPU sur chaque thread est très coûteuse.

Quelles sont les similitudes entre le développement mobile et GameDev

Alexei Kudryavtsev: Dans les thèses de votre rapport, vous dites que le développement mobile et GameDev ont beaucoup en commun. Dites-moi un peu, quoi exactement?

Andrey Volodin: L' architecture d'UIKit n'est pas sans rappeler les moteurs de jeu, et les anciens. Les modernes sont allés dans le sens du système de composants d'entité, et cela figurera également dans le rapport. Cela vient également d'UIKit, il y a des articles qui écrivent comment vous pouvez concevoir des vues sur les composants. GameDev, Component System Thief 98 .

, , Cocos2d, , , , . , Scene graph — , -, , iOS CGAffineTransform. 4*4, , . .

, UIKit . - — . : GameDev , UIKit setNeedsLayout, layoutIfNeeded.

— , - , , Apple. AppsConf .

: , API Cocos2d iOS ( UI). , ?

: , - . Cocos2d 2008-2009 , UIKit UIKit, . , - , , .

, : core- Cocos2d Apple, Apple Cocos2d, . SpriteKit , Cocos2d. Apple .

: , , UIKit 2009, MacOS, . setNeedsLayout, layoutIfNeeded , .

: , GameDev , MacOS.

: !

: Cocos2d Apple, , GameDev. GameDev , — . , GameDev , , . , , .

: , - , — .

: , , , , — . Protocol-Oriented Programming Swift, , - . GameDev .

: : , . , , , .

GameDev

: : GameDev , GameDev ?

: , , . « , ». , . : , , .

GameDev- . : 30 60 , , , . , . — . -- 1/60 1/30 . , , , GPU , CPU . , .

: ?

: . - , , , . — . , , , — - , - , . , , .

. , GPU float, double, - . , , , . CPU , , , GPU .

, , — .

GameDev,

: , « GameDev, ». , , . , GameDev — . , . GameDev.

: , enterprise- , GameDev . . , , GameDev, .

, . , 4*4. CGAffineTransform — , - , .

, , , , .

: ? , UIKit, , ? , , , . , ?

: — pet project.

, : GPU , . iOS GPU , . iOS , - NVidia AMD- . . API , , .

: API, , Cocos2d Unity, — - . , , , UIKit ?

: Cocos2d — Open Source . , , , , . objective-C, .

pet project, , , API, , , -. , API, VHS-. , GPU. , . , . , : « saturation Instagram, lightroom!» , , 4 — .

, .

— , , . , , - , , , .

: , - . , Cocos2d - — 5 , , , , . , , , ..

: . , . , , , , , , , , , .

: , . , , .

: . , , . , Apple, ARKit. , , . , , , , .

, , : «, IDE, , , , . ».

: — ?

: , , , .

: , , .

: , , , VR . Project Template Xcode, , , - . , .

: .

: - , GameDev GPU.

: . - , , , . , , , , , UI: , , runtime Objective-C — , , . . , : , — , X Y, !

, , - , GameDev GPU- — .

, . AppsConf 22 23 .