Neuerungen in WebGPU (Chrome 124)

François Beaufort
François Beaufort

Schreibgeschützte Speichertexturen

Mit diesem Bindungstyp können Shader aus Speichertextur 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 den GPUStorageTexture-Zugriff jetzt auf "read-write" oder "read-only" festlegen. Bisher war dies auf "write-only" beschränkt.

Anschließend können Sie in Ihrem WGSL-Shadercode den Zugriffsqualifizierer read_write und read für Speichertextur verwenden. Die integrierten Funktionen textureLoad() und textureStore() verhalten sich entsprechend und es gibt eine neue integrierte Funktion textureBarrier(), mit der sich Texturenspeicherzugriffe in einer Arbeitsgruppe synchronisieren lassen.

Es wird empfohlen, eine requires-Anweisung zu verwenden, um das Potenzial für die Nicht-Portierbarkeit mit requires readonly_and_readwrite_storage_textures; oben im WGSL-Shadercode anzugeben. Sieh dir das folgende Beispiel und issue dawn:1972 an.

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- und Shared Workers

Mit WebGPU in Chrome wird der Support für Web-Worker jetzt noch weiterentwickelt. Jetzt werden sowohl Service-Worker als auch gemeinsam genutzte Worker unterstützt. Sie können Dienst-Worker verwenden, um Hintergrundaufgaben und Offlinefunktionen zu verbessern, und freigegebene Worker für eine effiziente Ressourcenfreigabe zwischen Scripts. Siehe Problem chromium:41494731.

Im Beispiel für eine Chrome-Erweiterung und in der Chrome-Erweiterung WebLLM erfahren Sie, wie Sie WebGPU in einem Erweiterungs-Dienstworker verwenden.

Screenshot der Chrome-Erweiterung „WebLLM“
WebLLM-Chrome-Erweiterung

Neue Attribute für Adapterinformationen

Nicht standardmäßige d3dShaderModel- und vkDriverVersion-Adapter-Informationsattribute sind jetzt beim Aufruf von requestAdapterInfo() verfügbar, wenn der Nutzer die Flagge „WebGPU-Entwicklerfunktionen“ unter chrome://flags/#enable-webgpu-developer-features aktiviert hat. Wenn unterstützt:

  • d3dShaderModel ist die maximal unterstützte D3D-Shader-Modellnummer. 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 Problembericht dawn:1254.

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

Screenshot von https://webgpureport.org mit „vkDriverVersion“ in den Adapterinformationen.
Adapter-Informationen vkDriverVersion auf https://webgpureport.org.

Fehlerkorrekturen

Wenn Sie mit layout: "auto" zwei Pipelines mit übereinstimmenden Bindgruppen erstellen, dann eine Bindgruppe mit der ersten Pipeline erstellen und diese für die zweite Pipeline verwenden, wird jetzt eine GPUValidationError ausgegeben. Das war ein Implementierungsfehler, der jetzt durch entsprechende Tests behoben wurde. Siehe Problem dawn:2402.

Updates zur Morgendämmerung

In der Dawn API wird der mit wgpuDeviceSetUncapturedErrorCallback festgelegte Rückruf für nicht erfasste Fehler nicht mehr aufgerufen, nachdem das GPU-Gerät verloren gegangen ist. Dadurch wird Dawn an die JavaScript API-Spezifikation und die Blink-Implementierung angeglichen. Siehe Problem dawn:2459.

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

Das ist neu bei WebGPU

Eine Liste aller Themen, die in der Reihe Was ist neu in WebGPU? behandelt wurden.

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