Libérez la puissance du calcul GPU avec WebGPU

Bonjour, je m’appelle Mike, ingénieur de l’équipe Safari. Je vais vous montrer comment WebGPU permet d’exploiter le calcul parallèle sur les GPU à partir du Web. WebGPU fait la même chose que WebGL en matière de graphismes 3D, mais avec des performances et une flexibilité bien supérieures. Il est plus adapté aux graphismes sur le Web. Il est aussi le seul à permettre d’exécuter des calculs à usage général sur le GPU directement dans le navigateur. Si vous connaissez Metal, son environnement vous sera familier. La plupart des appels sont des mappages directs des appels du framework Metal. Il est pris en charge sur les mêmes plates-formes que Metal, notamment : Mac, iPhone, iPad et Vision Pro. Comme il s’agit d’une API web, les sites et les apps web qui l’utilisent fonctionnent partout où il est pris en charge. Sur les systèmes non Apple, WebGPU est implémenté avec des API similaires à Metal. Si vous ne connaissez pas la programmation graphique de bas niveau, de nombreuses bibliothèques graphiques web vous donnent accès à toutes les performances et fonctionnalités offertes par WebGPU. Vous pouvez utiliser threeJS exécutant WebGPU en arrière-plan pour animer ces magnifiques méduses 3D en temps réel. Je pense que c’est un exemple frappant. Il fonctionne si bien dans Safari, grâce à WebGPU qui a été conçu pour tirer pleinement parti du matériel moderne d’aujourd’hui. D’abord, j’explorerai l’API et le mappage entre WebGPU et Metal. Cela expliquera une grande partie du code nécessaire à toute application WebGPU. Puis, j’aborderai la création de programmes de shader WebGPU, le code qui s’exécute directement sur le GPU. Je couvrirai le langage de shading et la nécessité d’un nouveau langage pour le Web.

Après avoir couvert les bases, je parlerai de la façon d’optimiser les performances avec l’API. Si vous connaissez déjà WebGPU, les optimisations spécifiques dont je parlerai pour les plates-formes Apple devraient vous plaire. Commençons donc par jeter un coup d’œil au pipeline graphique.

Considérez comme un flux s’écoulant de gauche à droite. Il commence par un site ou une app web, qui charge du contenu, comme des images, des vidéos ou des données binaires.

Ce contenu est ensuite transmis à WebKit, qui est chargé de le préparer pour le GPU.

WebKit fait appel au framework Metal pour créer les ressources et les programmes qui seront ensuite exécutés directement sur le matériel graphique.

Voyons tout cela de plus près. Dans WebGPU, Metal génère trois types de ressources : les tampons, les textures et les échantillonneurs. Ils sont organisés par WebKit dans un groupe de liaison GPU. Cette manière structurée de regrouper les ressources permet au GPU de les utiliser efficacement. En arrière-plan, elles sont regroupées dans un tampon d’argument qui n’est qu’un tampon Metal contenant les références aux ressources GPU. Les programmes proviennent de chaînes de code et sont compilés en trois types principaux : le calcul, les sommets et les fragments. Ce sont les instructions réelles exécutées sur le GPU, exécutant diverses actions allant du calcul au rendu des pixels à l’écran. Maintenant que vous savez comment les ressources et les programmes s’intègrent dans le pipeline, voyons comment WebGPU définit les différentes interfaces dans son API.

WebGPU est une API plate, mais elle a beaucoup d’interfaces. En haut de la hiérarchie se trouvent les interfaces de l’objet GPU et de l’adaptateur GPU.

Un canevas est souvent utilisé avec WebGPU. Le canevas peut désormais renvoyer un GPUCanvasContext en interrogeant le contexte WebGPU.

Un appareil est le point d’entrée principal pour la plupart des appels d’API. Vous l’utilisez pour créer la plupart des autres interfaces.

Bien qu’il existe de nombreuses interfaces différentes dans l’API, elles se divisent en quelques catégories. Les ressources comme les textures, les tampons et les échantillonneurs.

Les encodeurs, qui émettent des commandes sur les ressources. Les pipelines, qui indiquent comment les encodeurs doivent interpréter les ressources. Les groupes de liaison, qui regroupent les ressources connexes. Et les modules de shader, contenant les instructions d’exécution des calculs sur le GPU. Maintenant que vous connaissez la structure globale de WebGPU, je vais vous montrer comment créer l’appareil et les ressources à l’aide de l’API.

Un appareil est le point d’entrée de la plupart des appels d’API. Si vous connaissez Metal, c’est très similaire à MTLDevice.

En supposant que vous ayez une page avec un canevas, générez l’élément canevas. Puis, utilisez navigator.gpu.requestAdapter() pour créer un adaptateur et appeler requestDevice afin de créer l’appareil GPU.

WebGPU prend en charge plusieurs extensions, dont shader-f16 qui vous permet d’utiliser des flottants à demi-précision.

Elles améliorent les performances en réduisant la bande passante mémoire. Bien que prise en charge sur tous les appareils Apple, elle est facultative. Vérifiez donc sa prise en charge avant de l’utiliser sur d’autres plates-formes.

Ensuite, configurez le contexte du canevas avec l’appareil en appelant configure. Cela relie le canevas à la mémoire dans laquelle le GPU pourra écrire.

Maintenant que l’appareil est prêt, nous pouvons créer des ressources. Dans WebGPU, vous travaillerez beaucoup avec des composants comme les tampons et les textures. Dans Metal, ils sont représentés par MTLBuffer et MTLTexture.

Les tampons sont très flexibles. Ils permettent de stocker diverses données, allant de données simples comme un vecteur de flottants aux types de données complexes que vous définissez vous-même. Par exemple, un tampon peut contenir plusieurs instances d’un type de particule. Imaginez trois particules stockées ici dans le tampon.

Un tampon est créé en appelant createBuffer sur l’appareil. En transmettant la taille du tampon et un mode d’utilisation. Le mode d’utilisation permet à WebGPU d’éviter les courses aux données sans les complexités d’API supplémentaires.

L’appareil a une propriété appelée file d’attente, qui permet d’effectuer des opérations sur les tampons et les textures.

Une fois le tampon créé, remplissez son contenu en appelant writeBuffer, en transmettant le tampon, un décalage et un arrayBuffer JavaScript.

Comme les tampons, les textures sont des blobs de mémoire, mais elles sont associées à des registres de texture et à des instructions spéciales sur le GPU. Elles représentent souvent des données d’image et peuvent être unidimensionnelles, bidimensionnelles, un tableau de textures bidimensionnelles, une carte cubique, qui est un tableau de six textures bidimensionnelles, ou une texture tridimensionnelle.

Pour créer une texture, appelez device.createTexture, transmettez la largeur et la hauteur de la texture, le format de texture 2D et les modes d’utilisation.

Après la création de GPUTexture, nous pouvons charger les données d’image avec device.queue.copyExternalImageToTexture en passant le bitmap de l’image, la texture 2D que nous venons de créer et la taille de l’image.

Une texture est souvent créée à partir de données d’image et représente une image sur le GPU. Après avoir créé un appareil et des ressources, voyons comment créer un pipeline.

Un pipeline spécifie le mode d’utilisation des textures et des tampons sur le GPU. Il existe deux types de pipelines. Les pipelines de rendu, utilisés avec les programmes de sommets et de fragments, et les pipelines de calcul, utilisés avec les programmes de calcul. Ils sont mappés aux objets MTLRenderPipelineState et MTLComputePipelineState dans Metal.

Pour créer un pipeline de calcul, appelez device.createComputePipeline en transmettant une mise en page de groupe de liaison ou l’identifiant automatique de constante, qui génère une mise en page à partir du shader.

Une mise en page est un moyen structuré de transmettre les tampons, les textures et les échantillonneurs de l’API au programme GPU.

Un module de shader est nécessaire pour créer un pipeline. Il est créé à partir d’une chaîne.

Les pipelines de rendu sont créés de la même manière, avec une mise en page automatique, un module de shader sommet et un module de shader fragment.

Une fois l’appareil, les ressources et les pipelines créés, la configuration de base d’une app WebGPU est terminée.

Maintenant que nous avons exploré l’architecture de l’API WebGPU, voyons comment développer les shaders.

Le langage de shading WebGPU, ou WGSL, permet aux sites web d’écrire facilement des programmes exécutés directement sur le GPU. Apple est fortement impliqué dans la conception et la mise en œuvre du langage WGSL. WGSL est entièrement conçu pour être sûr pour le Web. WGSL prend en charge trois types de programmes : les programmes de sommet, de fragment et de calcul.

Je vais expliquer comment créer cet exemple de WebGPU, qui comprend : Un programme de sommet, qui crée des triangles à l’écran avec les données tampons de JavaScript. Un programme de fragment calculant les valeurs de couleur et de profondeur des textures. Et un programme de calcul, qui peut effectuer n’importe quel calcul général, mais nous effectuerons ici une simulation physique.

Le programme de sommet calcule où les triangles apparaissent à l’écran.

Ici, nous pouvons voir les contours des 100 000 triangles utilisés dans cet exemple.

Pour écrire la position de sortie des triangles, utilisez l’attribut @builtin position.

Voici la définition de la fonction principale avec les entrées du shader de sommet. Il écrit juste la position et une couleur. Voyons maintenant un shader de fragment.

Prenons la couleur générée à l’étape du sommet et stockons-la dans la texture. Ce n’est qu’un exemple. Toute logique de calcul des valeurs de couleur et de profondeur est possible. Vous pouvez aussi écrire dans des textures de stockage, des tampons, effectuer des opérations atomiques et bien plus encore. WGSL est très flexible. Voyons quelque chose d’encore plus flexible : les shaders de calcul.

Comme les autres types de programmes, les shaders de calcul peuvent contenir de nombreuses liaisons, qui sont des entrées de JavaScript dans un shader.

Les shaders de calcul sont idéaux, car vous pouvez effectuer tous les calculs que vous voulez, stocker les résultats dans des tampons et relire les tampons dans le code JavaScript. Il n’y a pas de visualisation nécessaire à l’écran. Une autre raison d’utiliser WebGPU pour toute nouvelle app est que les shaders de calcul ne sont pas possibles avec WebGL.

Le programme de calcul nécessite une taille de groupe de travail, qui définit la taille de la grille sur laquelle le shader de calcul s’exécutera.

Nous utilisons aussi le global_invocation_id, qui est la position dans toute la grille. Cette variable intégrée peut être utilisée sans avoir à transmettre quoi que ce soit depuis JavaScript.

Le corps du shader de calcul met à jour la simulation de particules, en appliquant la gravité, la vitesse et le temps écoulé.

Vous pouvez effectuer tous les calculs souhaités dans un shader de calcul. Il s’exécutera en parallèle avec des performances incroyables sur le GPU.

Une fois que la particule a complètement disparu, un nouveau point est choisi en appelant textureLoad sur une carte de probabilité et en sélectionnant une nouvelle position pour la particule.

Enfin, les valeurs des attributs restants de la particule sont réinitialisées, et la particule est stockée dans le tampon.

Et au final, nous avons cette belle animation avec le logo WebGPU. Avec les fonctionnalités de traitement parallèle du GPU, vous pouvez effectuer des calculs arbitraires de tailles auparavant impossibles sur le Web tout en assurant des performances en temps réel.

Génial, non ?

C’était un l’aperçu de la façon de développer des shaders pour les apps WebGPU. Voyons maintenant comment tirer le meilleur parti de WebGPU.

Gardez à l’esprit les directives suivantes pour optimiser l’expérience sur les plates-formes Apple. La clé de performances optimales est d’être attentif à l’utilisation de la mémoire : utilisez des types de données économes en mémoire, enregistrez vos commandes de rendu une fois, puis réutilisez-les et limitez le nombre de ressources. Voyons cela de plus près.

Il existe plusieurs façons de limiter l’utilisation de la mémoire. D’abord, vous pouvez utiliser des flottants à demi-précision. C’est une norme IEEE. Dans WGSL, le type de données est appelé f16. Ils réduisent l’utilisation de la mémoire et améliorent les performances. Cela dit, ils ne sont pas toujours pratiques. Vos algorithmes doivent être stables avec une précision réduite, tandis que leurs valeurs vont à peine plus au-dessus de 65 000, contrairement aux flottants 32 bits dont les valeurs sont bien plus grandes. Sur iOS et visionOS en particulier, le stockage des données au format f16 ou compressé peut vous aider à éviter que le programme ne s’arrête en raison d’une mémoire saturée. Pour utiliser des flottants à demi-précision, activez-les lors de la création de l’appareil et dans le code WGSL. Voyons comment procéder avec un exemple de code rapide.

Activez l’extension shader-f16 dans l’appel à requestDevice, puis ajoutez l’instruction « enable f16 » dans le shader.

Vous pourrez ainsi utiliser les types scalaires et vectoriels f16, et tous les types 32 bits comme avant. Même si vous stockez les données en demi-précision et les décompressez immédiatement en f32, vous bénéficiez d’un avantage mémoire suffisant pour éviter que l’app ne s’arrête en raison d’une mémoire saturée.

Pour limiter l’utilisation de la mémoire, évitez aussi les appels inutiles de mise à jour du tampon et de la texture. Ils nécessitent des copies de données de JavaScript dans la mémoire qui sauvegarde la ressource Metal. La mise à jour des tampons avec des modes d’utilisation d’index et d’utilisation indirecte peut être très coûteuse, car la validation doit avoir lieu avant de pouvoir réutiliser le tampon. Ces tampons indexent directement ou indirectement les tampons de sommets, et WebGPU doit s’assurer que tous leurs décalages sont dans les limites avant l’exécution de commandes de dessin.

Ne mettez à jour ce type de tampon qu’en cas de besoin. Cela s’applique aussi à l’utilisation d’un tampon dans un groupe de liaison avec un accès en écriture ou en lecture/écriture. Comme illustré dans l’exemple de code, préférez l’accès en lecture seule, sauf si vous écrivez dans la ressource du shader, notamment si la ressource est un index ou un tampon indirect. Suivre ces conseils peut avoir un impact clé sur les performances sur les plates-formes d’Apple, mais aussi sur tous les appareils mobiles et de bureau. Parlons maintenant de la réutilisation de vos commandes de rendu.

Les bundles de rendu, qui permettent d’encoder des commandes une fois et de les réutiliser autant de fois que nécessaire, sont utiles à cet effet. WebGPU doit s’assurer que toutes les lectures et écritures sont bien définies et dans les limites. Beaucoup de validation est souvent nécessaire à chaque image. Avec les bundles de rendu, cette validation a lieu une fois, à la création du bundle, pas à chaque fois qu’il s’exécute. Cela fait gagner du temps et rapproche votre app des performances natives, ce qui laisse plus de place à la logique réelle. La création d’un bundle de rendu est assez simple. Créez un encodeur de bundle de rendu, puis encodez les appels de dessin, comme vous le feriez avec un encodeur de rendus. Appelez finish() pour créer le bundle pour la réutilisation.

Vous pouvez désormais exécuter toutes ces commandes de dessin encore et encore avec un appel à executeBundles(), en fonction de vos besoins.

Les bundles de rendu correspondent aux tampons de commande indirecte de Metal et offrent des avantages de performances similaires. Maintenant que nous avons limité l’utilisation de la mémoire et l’effort de validation, voyons comment réduire le nombre de ressources.

Les tampons de commande, les rendus, les calculs, les mises en forme de groupes de liaison et les groupes de liaisons.

Les limites du tampon de commande nécessitent la synchronisation entre la mémoire haute vitesse sur puce et la mémoire unifiée sur l’appareil. Si possible, utilisez un seul tampon de commande par boucle de mise à jour. Sinon, utilisez le moins de tampons de commande possible. Vous ne devez diviser les tampons de commande que lorsque les données doivent être réécrites dans la mémoire unifiée. C’est assez rare.

Contrairement aux tampons de commandes, les rendus et les calculs ne nécessitent pas de synchronisation avec la mémoire unifiée. Ils consomment toujours une bande passante mémoire importante, en fonction de la cible de rendu et de la taille de la distribution de calcul. Il est préférable d’en utiliser le moins possible pour économiser la bande passante mémoire.

Comme de nombreux téléphones mobiles, le GPU des appareils Apple est basé sur un moteur de rendu différé à tuiles. Suivre les bonnes pratiques combinant les rendus et les calculs et économisant la bande passante mémoire aidera votre site ou votre app web à exceller sur le matériel Apple. Pour en savoir plus sur les moteurs de rendu à tuiles, regardez les sessions « Optimize Metal performances for Apple silicon Macs » et « Harness Apple GPUs with Metal » de la WWDC 2020.

Sur ce, passons aux groupes de liaison. Ils sont implémentés avec des tampons d’arguments Metal. La création d’un groupe de liaison génère aussi un MTLBuffer. Avec des décalages dynamiques, un seul groupe de liaison, qui partage la même mise en forme, mais utilise des ressources différentes au moment de l’exécution, peut être créé. Pour utiliser des décalages dynamiques, une mise en forme de groupe de liaison personnalisée doit être créée au lieu d’utiliser une mise en forme automatique à partir du module de shader.

Pour la créer, appelez createBindGroupLayout avec hasDynamicOffset, puis transmettez la nouvelle mise en forme pour créer le groupe de liaison. Les décalages dynamiques sont impliqués dans les appels à setBindGroup. Un décalage par tampon dynamique dans le groupe de liaison est requis.

Ici, le groupe de liaison a un seul tampon utilisant des décalages dynamiques. Un seul décalage est donc transmis à setBindGroup.

Par exemple, au lieu de créer 10 groupes de liaisons, chacun contenant un tampon de 64 octets, il est préférable de créer un tampon de 640 octets pour représenter 10 objets de 64 octets. En procédant ainsi, je viens d’éviter de créer 9 tampons Metal.

En stockant les données similaires dans moins de mémoire, en évitant les validations répétées et en minimisant le nombre d’objets Metal créés, vous pouvez créer des sites et des apps web très performants avec WebGPU. J’espère que vous tiendrez compte de ces considérations lorsque vous utiliserez WebGPU. WebGPU permet d’exécuter des algorithmes personnalisés directement sur le GPU, ce qui n’était pas possible auparavant sur le Web. Je vous encourage à commencer à utiliser WebGPU dès aujourd’hui sur Mac, iPhone, iPad et Vision Pro, et à appliquer les directives d’utilisation optimale.

Vive l’avenir de la programmation GPU sur le Web !