Cette page a été traduite par l'API Cloud Translation.

Nouveautés de WebGPU (Chrome 120)

François Beaufort

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

Dans WGSL, le type f16 correspond à l'ensemble des valeurs à virgule flottante 16 bits du format IEEE-754 binary16 (demi-précision). Cela signifie qu'il utilise 16 bits pour représenter un nombre à virgule flottante, contre 32 bits pour la virgule flottante à simple précision conventionnelle (f32). Cette taille plus petite 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 de chat WebLLM est nettement plus rapide que l'implémentation f32, avec une amélioration de 28 % de la vitesse de préremplissage et de 41 % de la vitesse de décodage, comme le montrent les captures d'écran suivantes.

Capture d'écran des démos de chat WebLLM avec les modèles Llama2 7B f32 et f16. — Démos 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 tire parti du type à virgule flottante à demi-précision f16. Ce type peut être utilisé dans le module de nuanceur WGSL uniquement 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 de prendre en charge les types f16 et f32 dans le code du module de nuanceur WGSL avec un alias en fonction de la prise en charge 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 vos limites

Le nombre maximal d'octets nécessaires pour contenir 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 par défaut. Il est désormais possible de demander jusqu'à 64 éléments en utilisant 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 du groupe de liaison dans une mise en page de pipeline qui sont des tampons de stockage est de 8 par défaut. Il est désormais possible de demander jusqu'à 10 éléments en utilisant la limite maxStorageBuffersPerShaderStage. Consultez le problème dawn:2159.

Une nouvelle limite maxBindGroupsPlusVertexBuffers a été ajoutée. Il s'agit du nombre maximal d'emplacements de groupes de liaison et de tampons de vertex utilisés simultanément, en comptant les emplacements vides en dessous de l'index le plus élevé. Sa valeur par défaut est 24. Consultez le problème dawn:1849.

Modifications apportées à l'état de profondeur et de stencil

Pour améliorer l'expérience des développeurs, les attributs d'état du stencil de profondeur depthWriteEnabled et depthCompare ne sont plus toujours obligatoires : depthWriteEnabled n'est requis que pour les formats avec profondeur, et depthCompare n'est pas requis pour les formats avec profondeur s'il n'est pas utilisé du tout. Consultez le problème 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é le flag "WebGPU Developer Features" (Fonctionnalités pour les développeurs WebGPU) sur chrome://flags/#enable-webgpu-developer-features. La valeur type peut être "discrete GPU", "integrated GPU", "CPU" ou "unknown". backend peut être "WebGPU", "D3D11", "D3D12", "metal", "vulkan", "openGL", "openGLES" ou "null". Consultez les problèmes dawn:2112 et dawn:2107.

Capture d'écran de https://webgpureport.org avec des informations sur le backend et le type d'adaptateur. — Informations sur le backend et le type d'adaptateur affichés sur https://webgpureport.org.

Le paramètre de liste unmaskHints facultatif de requestAdapterInfo() a été supprimé. Consultez le problème 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 à la nanoseconde près. Toutefois, la spécification WebGPU rend les requêtes d'horodatage facultatives en raison des préoccupations liées aux attaques par temporisation. L'équipe Chrome estime que la quantification des requêtes d'horodatage constitue un bon compromis entre précision et sécurité, en réduisant la résolution à 100 microsecondes. Consultez le problème dawn:1800.

Dans Chrome, les utilisateurs peuvent désactiver la quantification des codes temporels en activant le flag "Fonctionnalités pour les développeurs WebGPU" sur chrome://flags/#enable-webgpu-developer-features. Notez que cet indicateur seul n'active pas la fonctionnalité "timestamp-query". Son implémentation est encore expérimentale et nécessite donc l'indicateur "Unsafe WebGPU Support" (Prise en charge WebGPU non sécurisée) à l'adresse chrome://flags/#enable-unsafe-webgpu.

Dans Dawn, un nouveau paramètre d'appareil appelé "timestamp_quantization" a été ajouté et est activé par défaut. L'extrait suivant montre comment autoriser la fonctionnalité expérimentale "timestamp-query" sans quantification du code temporel lors de la demande d'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é renommé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 basés sur Chromium pour le moment. Consultez le problème dawn:1193.

La fonctionnalité expérimentale "pipeline-statistics-query", qui n'était que partiellement implémentée, a été supprimée, car elle n'est plus développée. Consultez le problème chromium:1177506.