Nouveautés de WebGPU (Chrome 120)

François Beaufort
François Beaufort
GitHub

Prise en charge des valeurs à virgule flottante 16 bits dans WGSL

Dans WGSL, le type f16 est l'ensemble des valeurs à virgule flottante 16 bits du format binaire 16 IEEE-754 (demi-précision). Cela signifie qu'il utilise 16 bits pour représenter un nombre à virgule flottante, contre 32 bits pour les nombres à virgule flottante à précision simple conventionnels (f32). Cette taille réduite peut entraîner des améliorations significatives des performances, en particulier lors du traitement de grandes quantités de données.

À titre de comparaison, sur un appareil Apple M1 Pro, l'implémentation f16 des modèles Llama2 7B utilisés dans la démonstration par chat WebLLM est beaucoup plus rapide que l'implémentation de f32, avec une amélioration de 28% de la vitesse de préremplissage et de 41% de la vitesse de décodage, comme illustré sur les captures d'écran suivantes.

Capture d'écran de démonstrations du chat WebLLM avec les modèles f32 et f16 Llama2 7B
Démonstrations de chat WebLLM avec les modèles Llama2 7B f32 (à gauche) et f16 (à droite).

Tous les GPU ne sont pas compatibles avec les valeurs à virgule flottante 16 bits. Lorsque la fonctionnalité "shader-f16" est disponible dans un GPUAdapter, vous pouvez désormais demander un GPUDevice avec cette fonctionnalité et créer un module de nuanceur WGSL qui exploite le type à virgule flottante à demi-précision f16. Ce type n'est valide dans le module de nuanceur WGSL que si vous activez l'extension WGSL f16 avec enable f16;. Sinon, createShaderModule() générera une erreur de validation. Consultez l'exemple minimal suivant et le problème dawn:1510.

const adapter = await navigator.gpu.requestAdapter();
if (!adapter.features.has("shader-f16")) {
  throw new Error("16-bit floating-point value support is not available");
}
// Explicitly request 16-bit floating-point value support.
const device = await adapter.requestDevice({
  requiredFeatures: ["shader-f16"],
});

const code = `
  enable f16;

  @compute @workgroup_size(1)
  fn main() {
    const c : vec3h = vec3<f16>(1.0h, 2.0h, 3.0h);
  }
`;

const shaderModule = device.createShaderModule({ code });
// Create a compute pipeline with this shader module
// and run the shader on the GPU...

Il est possible d'accepter les types f16 et f32 dans le code du module de nuanceur WGSL avec un alias selon la compatibilité de la fonctionnalité "shader-f16", comme indiqué dans l'extrait suivant.

const adapter = await navigator.gpu.requestAdapter();
const hasShaderF16 = adapter.features.has("shader-f16");

const device = await adapter.requestDevice({
  requiredFeatures: hasShaderF16 ? ["shader-f16"] : [],
});

const header = hasShaderF16
  ? `enable f16;
     alias min16float = f16;`
  : `alias min16float = f32;`;

const code = `
  ${header}

  @compute @workgroup_size(1)
  fn main() {
    const c = vec3<min16float>(1.0, 2.0, 3.0);
  }
`;

Repoussez les limites

Par défaut, le nombre maximal d'octets nécessaire pour stocker un échantillon (pixel ou sous-pixel) de données de sortie du pipeline de rendu, pour tous les rattachements de couleur, est de 32 octets. Vous pouvez désormais en demander jusqu'à 64 à l'aide de la limite maxColorAttachmentBytesPerSample. Consultez l'exemple suivant et issue dawn:2036.

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

if (adapter.limits.maxColorAttachmentBytesPerSample < 64) {
  // When the desired limit isn't supported, take action to either fall back to
  // a code path that does not require the higher limit or notify the user that
  // their device does not meet minimum requirements.
}

// Request highest limit of max color attachments bytes per sample.
const device = await adapter.requestDevice({
  requiredLimits: { maxColorAttachmentBytesPerSample: 64 },
});

Les limites maxInterStageShaderVariables et maxInterStageShaderComponents utilisées pour la communication entre les étapes ont été augmentées sur toutes les plates-formes. Pour en savoir plus, consultez le problème dawn:1448.

Pour chaque étape du nuanceur, le nombre maximal d'entrées de mise en page de groupes de liaisons sur une mise en page de pipeline qui sont des tampons de stockage est de 8 par défaut. Vous pouvez désormais en demander jusqu'à 10 à l'aide de la limite maxStorageBuffersPerShaderStage. Voir le problème dawn:2159.

Une nouvelle limite maxBindGroupsPlusVertexBuffers a été ajoutée. Il correspond au nombre maximal d'emplacements de groupe de liaison et de tampon de sommets utilisés simultanément, en comptant les emplacements vides situés en dessous de l'indice le plus élevé. Sa valeur par défaut est 24. Voir le problème dawn:1849.

Modifications apportées à l'état du tampon de profondeur

Pour améliorer l'expérience développeur, les attributs état du stencil de profondeur depthWriteEnabled et depthCompare ne sont plus toujours obligatoires: depthWriteEnabled n'est obligatoire que pour les formats avec une profondeur, et depthCompare n'est pas obligatoire pour les formats avec profondeur s'ils ne sont pas utilisés du tout. Voir issue dawn:2132.

Mises à jour des informations sur l'adaptateur

Les attributs d'informations d'adaptateur type et backend non standards sont désormais disponibles lors de l'appel de requestAdapterInfo() lorsque l'utilisateur a activé l'indicateur "Fonctionnalités de développement WebGPU" dans chrome://flags/#enable-webgpu-developer-features. La valeur type peut être "GPU discret", "GPU intégré", "Processeur" ou "inconnu". backend est "WebGPU", "D3D11", "D3D12", "metal", "vulkan", "openGL", "openGLES" ou "null". Consultez les problèmes dawn:2112 et dawn:2107.

Capture d&#39;écran de https://webgpureport.org montrant le backend et les informations sur l&#39;adaptateur.
Backend et type d'informations sur l'adaptateur affichés sur https://webgpureport.org.

Le paramètre de liste unmaskHints facultatif dans requestAdapterInfo() a été supprimé. Voir issue dawn:1427.

Quantification des requêtes d'horodatage

Les requêtes d'horodatage permettent aux applications de mesurer le temps d'exécution des commandes GPU avec une précision de la nanoseconde. Cependant, la spécification WebGPU rend les requêtes de code temporel facultatives en raison de problèmes d'attaques temporelles. L'équipe Chrome estime que la quantification des requêtes d'horodatage offre un bon compromis entre précision et sécurité, car elle réduit la résolution à 100 microsecondes. Voir problème dawn:1800.

Dans Chrome, les utilisateurs peuvent désactiver la quantification des codes temporels en activant l'indicateur "WebGPU Developer Features" (Fonctionnalités de développement WebGPU) dans chrome://flags/#enable-webgpu-developer-features. Notez que cet indicateur à lui seul n'active pas la fonctionnalité "timestamp-query". Son implémentation en est encore au stade expérimental et nécessite donc l'option "Unsafe WebGPU Support" (Support WebGPU non sécurisé) dans chrome://flags/#enable-unsafe-webgpu.

Dans Dawn, un nouvel boutons d'activation/de désactivation de l'appareil appelé "timestamp_quantization" a été ajouté et est activé par défaut. L'extrait de code suivant montre comment autoriser la fonctionnalité expérimentale "timestamp-query" sans quantification du code temporel lorsque vous demandez un appareil.

wgpu::DawnTogglesDescriptor deviceTogglesDesc = {};

const char* allowUnsafeApisToggle = "allow_unsafe_apis";
deviceTogglesDesc.enabledToggles = &allowUnsafeApisToggle;
deviceTogglesDesc.enabledToggleCount = 1;

const char* timestampQuantizationToggle = "timestamp_quantization";
deviceTogglesDesc.disabledToggles = &timestampQuantizationToggle;
deviceTogglesDesc.disabledToggleCount = 1;

wgpu::DeviceDescriptor desc = {.nextInChain = &deviceTogglesDesc};

// Request a device with no timestamp quantization.
myAdapter.RequestDevice(&desc, myCallback, myUserData);

Fonctionnalités de nettoyage de printemps

La fonctionnalité expérimentale "timestamp-query-inside-passes" a été rebaptisée "chromium-experimental-timestamp-query-inside-passes" pour indiquer clairement aux développeurs qu'elle est expérimentale et qu'elle n'est disponible que dans les navigateurs Chromium pour le moment. Voir le problème dawn:1193.

La fonctionnalité expérimentale "pipeline-statistics-query", qui n'était implémentée qu'en partie, a été supprimée, car elle n'est plus en cours de développement. Consultez le problème chromium:1177506.

Il ne s'agit là que de quelques-uns des points clés. Consultez la liste exhaustive des commits.

Nouveautés de WebGPU

Liste de tout ce qui a été abordé dans la série Nouveautés de WebGPU.

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