Nouveautés de WebGPU (Chrome 133)

François Beaufort
François Beaufort
GitHub

Publié le 29 janvier 2025

Formats de vertex unorm8x4-bgra et à un seul composant supplémentaires

Le format de vertex "unorm8x4-bgra" et les formats de vertex à un composant suivants ont été ajoutés : "uint8", "sint8", "unorm8", "snorm8", "uint16", "sint16", "unorm16", "snorm16" et "float16". Le format de vertex "unorm8x4-bgra" permet de charger plus facilement les couleurs de vertex encodées au format BGRA tout en conservant le même nuanceur. De plus, le format de vertex à un seul composant vous permet de ne demander que les données nécessaires, alors qu'auparavant, il en fallait au moins le double pour les types de données 8 et 16 bits. Consultez l'entrée Chromestatus et le problème 376924407.

Autoriser les limites inconnues à être demandées avec une valeur indéfinie

Pour rendre l'API WebGPU moins fragile à mesure qu'elle évolue, vous pouvez désormais demander des limites inconnues avec la valeur undefined lorsque vous demandez un appareil GPU. Cela est utile dans le code d'application suivant, par exemple, où adapter.limits.someLimit peut être undefined si someLimit n'existe plus. Consultez la demande d'extraction de spécifications 4781.

const adapter = await navigator.gpu.requestAdapter();

const device = await adapter.requestDevice({
  requiredLimits: { someLimit: adapter.limits.someLimit }, // someLimit can be undefined
});

Modifications apportées aux règles d'alignement WGSL

Il n'est plus possible de fournir une valeur d'alignement trop petite pour un membre de struct, car il est désormais obligatoire que @align(n) divise RequiredAlignOf pour tous les structs. Cette modification incompatible simplifie l'utilisation du langage WGSL et le rend plus compatible avec Firefox et Safari. Vous trouverez un exemple de code montrant les différences entre les compilateurs Tint, Naga et WebKit dans la demande d'extraction de spécifications.

Gains de performances WGSL avec discard

En raison d'une baisse significative des performances observée lors du rendu d'un effet de réflexion complexe dans l'espace écran (SSR), l'implémentation de l'instruction discard utilise la sémantique fournie par la plate-forme pour la rétrogradation vers un appel d'assistance, le cas échéant. Cela améliore les performances des nuanceurs qui utilisent la fonction "discard". Consultez le problème 372714384.

Utiliser displaySize VideoFrame pour les textures externes

Les dimensions displayWidth et displayHeight doivent être utilisées comme taille apparente de GPUExternalTexture lors de l'importation d'un VideoFrame conformément à la spécification WebGPU. Toutefois, la taille visible était utilisée de manière incorrecte, ce qui entraînait des problèmes lors de l'utilisation de textureLoad() sur un GPUExternalTexture. Ce problème est désormais résolu. Consultez le problème 377574981.

Gérer les images avec des orientations non définies par défaut à l'aide de copyExternalImageToTexture

La méthode copyExternalImageToTexture() GPUQueue permet de copier le contenu d'une image ou d'un canevas dans une texture. Il gère désormais correctement les images dont l'orientation n'est pas celle par défaut. Ce n'était pas le cas auparavant lorsque la source était une ImageBitmap avec imageOrientation "from-image" ou une image avec une orientation non définie par défaut. Consultez le problème 384858956.

Améliorer l'expérience des développeurs

Il peut être surprenant de voir des valeurs élevées pour adapter.limits, mais vous ne réalisez pas que vous devez demander explicitement une limite plus élevée lorsque vous demandez un appareil GPU. Si vous ne le faites pas, vous risquez d'atteindre les limites de manière inattendue par la suite.

Pour vous aider, les messages d'erreur ont été enrichis d'indices vous indiquant de demander explicitement une limite plus élevée lorsqu'aucune limite n'a été spécifiée dans requiredLimits lors de l'appel de requestDevice(). Consultez le problème 42240683.

L'exemple suivant montre un message d'erreur amélioré consigné dans la console DevTools lors de la création d'un tampon GPU dont la taille dépasse la limite de taille de tampon maximale par défaut de l'appareil.

const adapter = await navigator.gpu.requestAdapter();
const device = await adapter.requestDevice();

// Create a GPU buffer with a size exceeding the default max buffer size device limit.
const size = device.limits.maxBufferSize + 1;
const buffer = device.createBuffer({ size, usage: GPUBufferUsage.MAP_READ });

device.queue.submit([]);

⚠️ Buffer size (268435457) exceeds the max buffer size limit (268435456). This adapter supports a higher maxBufferSize of 4294967296, which can be specified in requiredLimits when calling requestDevice(). Limits differ by hardware, so always check the adapter limits prior to requesting a higher limit.
- While calling [Device].CreateBuffer([BufferDescriptor]).

Activer le mode de compatibilité avec featureLevel

Il est désormais possible de demander une carte GPU en mode de compatibilité expérimental en définissant l'option standardisée featureLevel sur "compatibility". Les chaînes "core" (par défaut) et "compatibility" sont les seules valeurs autorisées. Consultez l'exemple suivant et la demande d'extraction de spécifications 4897.

// Request a GPU adapter in compatibility mode
const adapter = await navigator.gpu.requestAdapter({ featureLevel: "compatibility" });

if (adapter?.featureLevel === "compatibility") {
  // Any devices created from this adapter will support only compatibility mode.
}

L'option featureLevel remplace l'option compatibilityMode non standardisée, tandis que l'attribut featureLevel non standardisé remplace l'attribut isCompatibilityMode.

Comme il est encore expérimental, vous devez exécuter Chrome avec l'indicateur "Unsafe WebGPU Support" (Prise en charge non sécurisée de WebGPU) à l'adresse chrome://flags/#enable-unsafe-webgpu pour le moment. Consultez webgpureport.org pour l'essayer.

Nettoyage des fonctionnalités expérimentales des sous-groupes

Les fonctionnalités expérimentales de sous-groupes "chromium-experimental-subgroups" et "chromium-experimental-subgroup-uniform-control-flow" obsolètes ont été supprimées. Consultez le problème 377868468.

La fonctionnalité expérimentale "subgroups" est désormais tout ce dont vous avez besoin pour tester les sous-groupes. La fonctionnalité expérimentale "subgroups-f16" est obsolète et sera bientôt supprimée. Vous pouvez utiliser des valeurs f16 avec des sous-groupes lorsque votre application demande les fonctionnalités "shader-f16" et "subgroups". Consultez le problème 380244620.

Obsolétion de la limite maxInterStageShaderComponents

La limite de maxInterStageShaderComponents est obsolète en raison de plusieurs facteurs :

  • Redondance avec maxInterStageShaderVariables : cette limite a déjà un objectif similaire, qui consiste à contrôler la quantité de données transmises entre les étapes du nuanceur.
  • Écarts mineurs : bien que les deux limites soient calculées légèrement différemment, ces différences sont mineures et peuvent être gérées efficacement dans la limite de maxInterStageShaderVariables.
  • Simplification : la suppression de maxInterStageShaderComponents simplifie l'interface du nuanceur et réduit la complexité pour les développeurs. Au lieu de gérer deux limites distinctes avec de subtiles différences, ils peuvent se concentrer sur la limite maxInterStageShaderVariables, dont le nom est plus approprié et qui est plus complète.

L'objectif est de la supprimer complètement dans Chrome 135. Consultez l'intention d'abandon et le problème 364338810.

Nouveautés de l'application Aube

wgpu::Device::GetAdapterInfo(adapterInfo) vous permet d'obtenir des informations sur l'adaptateur directement à partir d'un wgpu::Device. Consultez le problème 376600838.

La struct WGPUProgrammableStageDescriptor a été renommée WGPUComputeState pour que l'état de calcul soit cohérent avec les états de vertex et de fragment. Voir le problème 379059434.

La valeur d'énumération wgpu::VertexStepMode::VertexBufferNotUsed a été supprimée. Une mise en page de mémoire tampon de vertex qui n'est pas utilisée peut désormais être exprimée avec {.stepMode=wgpu::VertexStepMode::Undefined, .attributeCount=0}. Consultez le problème 383147017.

Il ne s'agit que de quelques-uns des principaux points à retenir. Consultez la liste exhaustive des commits.

Nouveautés de WebGPU

Liste de tous les sujets abordés dans la série Nouveautés de WebGPU.

Chrome 155-156

Chrome 153-154

Chrome 151-152

Chrome 149-150

Chrome 147-148

Chrome 146

Chrome 145

Chrome 144

Chrome 143

Chrome 142

Chrome 141

Chrome 140

Chrome 139

Chrome 138

Chrome 137

Chrome 136

Chrome 135

Chrome 134

Chrome 133

Chrome 132

Chrome 131

Chrome 130

Chrome 129

Chrome 128

Chrome 127

Chrome 126

Chrome 125

Chrome 124

Chrome 123

Chrome 122

Chrome 121

Chrome 120

Chrome 119

Chrome 118

Chrome 117

Chrome 116

Chrome 115

Chrome 114

Chrome 113