Neuerungen in WebGPU (Chrome 124)

François Beaufort
François Beaufort
GitHub

Schreibgeschützte und Lese-/Schreibspeicher-Texturen

Mit dem Speichertextur-Bindungstyp können Shader Daten aus Speichertexturen lesen, ohne die TEXTURE_BINDING-Nutzung hinzuzufügen, und gemischte Lese- und Schreibvorgänge für bestimmte Formate ausführen. Wenn die "readonly_and_readwrite_storage_textures" WGSL-Spracherweiterung in navigator.gpu.wgslLanguageFeatures vorhanden ist, können Sie beim Erstellen eines Bindungsgruppenlayouts jetzt den GPUStorageTexture-Zugriff auf "read-write" oder "read-only" festlegen. Bisher war dies auf "write-only" beschränkt.

In Ihrem WGSL-Shader-Code können Sie dann den Zugriffsklassifizierer read_write und read für Speichertexturen verwenden. Die integrierten Funktionen textureLoad() und textureStore() verhalten sich entsprechend und es ist eine neue integrierte Funktion textureBarrier() verfügbar, um Texturspeicherzugriffe in einer Arbeitsgruppe zu synchronisieren.

Es wird empfohlen, oben im WGSL-Shader-Code eine requires-Anweisung zu verwenden, um auf die potenzielle Nicht-Portabilität mit requires readonly_and_readwrite_storage_textures; hinzuweisen. Hier finden Sie ein Beispiel.

if (!navigator.gpu.wgslLanguageFeatures.has("readonly_and_readwrite_storage_textures")) {
  throw new Error("Read-only and read-write storage textures are not available");
}

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

const bindGroupLayout = device.createBindGroupLayout({
  entries: [{
    binding: 0,
    visibility: GPUShaderStage.COMPUTE,
    storageTexture: {
      access: "read-write", // <-- New!
      format: "r32uint",
    },
  }],
});

const shaderModule = device.createShaderModule({ code: `
  requires readonly_and_readwrite_storage_textures;

  @group(0) @binding(0) var tex : texture_storage_2d<r32uint, read_write>;

  @compute @workgroup_size(1, 1)
  fn main(@builtin(local_invocation_id) local_id: vec3u) {
    var data = textureLoad(tex, vec2i(local_id.xy));
    data.x *= 2;
    textureStore(tex, vec2i(local_id.xy), data);
  }`
});

// You can now create a compute pipeline with this shader module and
// send the appropriate commands to the GPU.

Unterstützung für Service Worker und Shared Worker

WebGPU in Chrome bietet eine verbesserte Unterstützung für Web-Worker und unterstützt jetzt sowohl Service Worker als auch Shared Worker. Mit Service Workern können Sie Hintergrundaufgaben und Offlinefunktionen verbessern und mit Shared Workern Ressourcen effizient über Skripts hinweg freigeben. Siehe chromium:41494731.

Im Chrome-Erweiterungsbeispiel und in der WebLLM-Chrome-Erweiterung sehen Sie, wie Sie WebGPU in einem Erweiterungs-Service-Worker verwenden.

Screenshot der WebLLM-Chrome-Erweiterung.
WebLLM-Chrome-Erweiterung

Neue Attribute für Adapterinformationen

Nicht standardmäßige d3dShaderModel- und vkDriverVersion-Adapterinformationsattribute sind jetzt beim Aufrufen von requestAdapterInfo() verfügbar, wenn der Nutzer das Flag „WebGPU Developer Features“ unter chrome://flags/#enable-webgpu-developer-features aktiviert hat. Wenn unterstützt:

  • d3dShaderModel ist die maximal unterstützte D3D-Shadermodellnummer. Der Wert 62 gibt beispielsweise an, dass der aktuelle Treiber HLSL SM 6.2 unterstützt. Weitere Informationen finden Sie in der Dokumentation und im Problem dawn:1254.

  • vkDriverVersion ist die vom Anbieter angegebene Versionsnummer des Vulkan-Treibers. Weitere Informationen finden Sie in der Dokumentation und im Chromium-Problem 327457605.

Screenshot von https://webgpureport.org mit vkDriverVersion in den Adapterinformationen.
AdapterinfovkDriverVersion auf https://webgpureport.org.

Fehlerkorrekturen

Wenn Sie zwei Pipelines mit übereinstimmenden Bindungsgruppen mit layout: "auto" erstellen, dann eine Bindungsgruppe mit der ersten Pipeline erstellen und sie in der zweiten Pipeline verwenden, wird jetzt ein GPUValidationError ausgelöst. Dass dies möglich war, war ein Implementierungsfehler, der jetzt mit entsprechenden Tests behoben wurde. Siehe Problem dawn:2402.

Dawn-Updates

In der Dawn API wird der mit wgpuDeviceSetUncapturedErrorCallback festgelegte Callback für nicht abgefangene Fehler nicht mehr aufgerufen, nachdem das GPU-Gerät verloren gegangen ist. Mit dieser Korrektur wird Dawn an die JavaScript API-Spezifikation und die Blink-Implementierung angepasst. Siehe Problem dawn:2459.

Dies sind nur einige der wichtigsten Neuerungen. Vollständige Liste der Commits

Neues zu WebGPU

Eine Liste mit allen Themen, die in der Reihe Neu in WebGPU behandelt wurden.

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