Le Consortium W3C a présenté les premières ébauches des spécifications WebGPU et WebGPU Shading Language (WGSL), définissant une API pour réaliser des opérations sur le GPU, telles que le rendu et les calculs, ainsi qu'un langage de shaders pour écrire des programmes exécutés côté GPU, conceptuellement similaire aux API Vulkan, Metal et Direct3D 12. Les spécifications ont été préparées par un groupe de travail composé d'ingénieurs de Mozilla, Google, Apple et Microsoft.
Conceptuellement, WebGPU diffère de WebGL à peu près de la même manière que l'API graphique Vulkan diffère de OpenGL, mais contrairement à cela, il ne repose pas sur une API graphique spécifique, mais représente une couche universelle utilisant les mêmes primitives basse-niveau que celles présentes dans Vulkan, Metal et Direct3D. WebGPU fournit aux applications JavaScript les moyens de contrôler de manière basse-niveau l'organisation, le traitement et la transmission des commandes au GPU, ainsi que la gestion des ressources associées, de la mémoire, des buffers, des objets de textures et des shaders graphiques compilés. Une telle approche permet d'obtenir une meilleure performance des applications graphiques en réduisant les frais généraux et en améliorant l'efficacité du travail avec le GPU.
WebGPU permet de créer sur le Web des projets 3D complexes qui fonctionnent aussi bien que des programmes autonomes interagissant directement avec Vulkan, Metal ou Direct3D, sans être liés à des plateformes spécifiques. WebGPU offre également des fonctionnalités supplémentaires lors du portage d'applications graphiques natives sous une forme capable de fonctionner sur des technologies web, grâce à la compilation en WebAssembly. En plus de la 3D, WebGPU couvre également les possibilités liées à l'exécution de calculs sur le GPU et à l'exécution de shaders.
Caractéristiques clés de WebGPU :
- Gestion séparée des ressources, des travaux préparatoires et de l'envoi de commandes au GPU (dans WebGL, un seul objet gérait tout cela). Trois contextes séparés sont fournis : GPUDevice pour la création de ressources telles que des textures et des tampons ; GPUCommandEncoder pour l'encodage de commandes individuelles, y compris les phases de rendu et de calcul ; GPUCommandBuffer pour être mis en file d'attente pour exécution sur le GPU. Le résultat peut être dessiné dans une zone associée à un ou plusieurs éléments canvas, ou traité sans affichage (par exemple, lors de l'exécution de tâches de calcul). La séparation des étapes facilite la dissociation de la création de ressources et des opérations préparatoires dans différents gestionnaires, qui peuvent être exécutés dans des threads différents.
- Une approche différente dans le traitement des états. Dans WebGPU, deux objets sont proposés — GPURenderPipeline et GPUComputePipeline, permettant de combiner divers états définis à l'avance par le développeur, ce qui permet au navigateur de ne pas consacrer de ressources à des travaux supplémentaires, comme la recompilation des shaders. Parmi les états pris en charge : shaders, dispositions des tampons de vertex et d'attributs, dispositions des groupes attachés, mélange, profondeur et modèles, formats de sortie après rendu.
- Un modèle d'association, semblable aux mécanismes de regroupement de ressources présents dans Vulkan. Pour regrouper des ressources dans WebGPU, un objet GPUBindGroup est fourni, qui peut être lié à d'autres objets similaires lors de l'enregistrement des commandes pour être utilisé dans les shaders. La création de tels groupes permet au pilote d'effectuer à l'avance les préparatifs nécessaires, et au navigateur de changer les liaisons de ressources beaucoup plus rapidement entre les appels de rendu. La disposition des liaisons de ressources peut être définie à l'avance à l'aide de l'objet GPUBindGroupLayout.
Source : opennet.ru
