Neuerungen bei WebGPU (Chrome 126)

François Beaufort
François Beaufort
GitHub

<ph type="x-smartling-placeholder">

MaxTextureArrayLayers-Limit erhöhen

Der maximal zulässige Wert für die Tiefe oder Ebenenanzahl einer 2D-Textur ist standardmäßig 256. Es ist jetzt möglich, mithilfe des maxTextureArrayLayers-Limits, sofern unterstützt, bis zu 2048 Anfragen anzufordern. Sehen Sie sich das folgende Beispiel und Problem 42241514 an.

const adapter = await navigator.gpu.requestAdapter();
if (adapter.limits.maxTextureArrayLayers < 30) {
  // 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 texture array layers attributes.
const device = await adapter.requestDevice({
  requiredLimits: { maxTextureArrayLayers: 2048 }
});

Optimierung des Zwischenspeicheruploads für das Vulkan-Backend

Wenn Sie die Methode writeBuffer() der GPUQueue für das Vulkan-Back-End aufrufen, steht jetzt ein schneller Pfad zur Verfügung. Die Daten können jetzt direkt in den Zielpuffer geschrieben werden, wodurch die Notwendigkeit einer zusätzlichen Kopie und Synchronisierung entfällt. Diese Optimierung reduziert Arbeitsspeicher-Traffic, der für das Hochladen von Daten in die GPU erforderlich ist.

Für die Fast Path-Optimierung muss der Arbeitsspeicher des Zwischenspeichers für den Zwischenspeicher sichtbar sein und keine ausstehenden GPU-Vorgänge enthalten. Siehe Problem 42242084.

Verbesserungen bei der Shader-Kompilierung

Das Chrome-Team verbessert die Effizienz von Tint, dem Compiler der WebGPU-Shader-Sprache. Tint ändert derzeit den abstrakten Syntaxbaum (AST) des Shader-Codes mehrmals, bevor Maschinencode generiert wird. Dieser Prozess ist auf einigen Plattformen ressourcenintensiv. Um dies zu optimieren, werden eine neue Zwischendarstellung (IR) sowie neu gestaltete Back-Ends eingeführt, die diese verwenden. Mit dieser Änderung soll die Shader-Kompilierung beschleunigt werden.

<ph type="x-smartling-placeholder">
</ph> Zur Erstellung einer Rendering-Pipeline wird WGSL mit dem Tint-Compiler in SPIR-V und dann mit dem Treiber-Compiler in ISA konvertiert.
Erstellung einer Renderingpipeline in ChromeOS

Diese Verbesserungen, die bereits für Android verfügbar sind, werden nach und nach auch für ChromeOS-Geräte ausgeweitet, die WebGPU mit dem Vulkan-Backend unterstützen. Siehe Problem 42250751.

Eingereichte Befehlspuffer müssen eindeutig sein

Jeder GPUCommandBuffer, der mit der Methode submit() an die GPUQueue gesendet wird, muss eindeutig sein. Andernfalls wird ein Validierungsfehler generiert. Dies war ein Fehler in den Spezifikationen. Siehe Problem 42241492.

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

const commandEncoder = device.createCommandEncoder();
const commandBuffer = commandEncoder.finish();

device.queue.submit([commandBuffer, commandBuffer]);
// ⚠️ Validation fails because command buffers are not unique.

Updates zur Morgendämmerung

Der C++-Wrapper webgpu_cpp.h ist jetzt nur im Header verfügbar. Dies vereinfacht seine Verwendung und ermöglicht eine einfachere Integration mit alternativen C++-Wrappern. Siehe Problem 40195122.

In der C API webgpu.h ist das Konzept von Swapchain-Objekten nicht mehr verfügbar. Diese Änderung erfolgt eng mit der JavaScript API. Die interne Konfiguration erfolgt nun über die Methode Configure() des neuen wgpu::Surface-Objekts, das in Zukunft geändert werden kann. Ein Beispiel finden Sie in der Dokumentation App mit WebGPU erstellen. Siehe Problem 42241264.

Vollständige Liste der Commits

Das ist neu bei WebGPU

Eine Liste aller behandelten Themen der Reihe What's New in WebGPU.

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