Das ist neu bei WebGPU (Chrome 133)

François Beaufort
François Beaufort
GitHub

Veröffentlicht: 29. Januar 2025

Zusätzliche unorm8x4-bgra- und 1-Komponenten-Vertexformate

Das "unorm8x4-bgra"-Vertex-Format und die folgenden 1-Komponenten-Vertex-Formate wurden hinzugefügt: "uint8", "sint8", "unorm8", "snorm8", "uint16", "sint16", "unorm16", "snorm16" und "float16". Das "unorm8x4-bgra"-Vertexformat erleichtert das Laden von BGRA-codierten Vertexfarben bei Verwendung desselben Shaders. Außerdem können Sie mit dem Vertex-Format mit einer Komponente nur die Daten anfordern, die erforderlich sind. Bisher war für 8- und 16-Bit-Datentypen mindestens die doppelte Menge erforderlich. Weitere Informationen finden Sie im Chrome-Status-Eintrag und in Problem 376924407.

Anfordern unbekannter Limits mit undefiniertem Wert zulassen

Damit die WebGPU API bei der Weiterentwicklung weniger anfällig ist, können Sie jetzt unbekannte Limits mit dem Wert undefined anfordern, wenn Sie ein GPU-Gerät anfordern. Das ist beispielsweise im folgenden Anwendungscode nützlich, in dem adapter.limits.someLimit undefined sein kann, wenn someLimit nicht mehr vorhanden ist. Weitere Informationen finden Sie im Spezifikations-PR 4781.

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

const device = await adapter.requestDevice({
  requiredLimits: { someLimit: adapter.limits.someLimit }, // someLimit can be undefined
});

Änderungen an den WGSL-Ausrichtungsregeln

Es ist nicht mehr möglich, einen zu kleinen Ausrichtungswert für ein Strukturmitglied anzugeben, da jetzt für alle Strukturen gilt, dass @align(n) RequiredAlignOf teilt. Diese wichtige Änderung vereinfacht die Verwendung der WGSL-Sprache und macht sie mit Firefox und Safari kompatibler. Beispielcode, der die Unterschiede zwischen den Compilern Tint, Naga und WebKit zeigt, finden Sie im Spec-PR.

WGSL-Leistungssteigerungen mit „discard“

Aufgrund eines erheblichen Leistungsabfalls beim Rendern eines komplexen SSR-Effekts (Screen-Space Reflections) wird bei der Implementierung der discard-Anweisung die plattformseitig bereitgestellte Semantik für die Herabstufung zu einem Helper-Aufruf verwendet, sofern verfügbar. Dadurch wird die Leistung von Shadern verbessert, die „discard“ verwenden. Siehe Problem 372714384.

VideoFrame.displaySize für externe Texturen verwenden

Die Dimensionen displayWidth und displayHeight sollten als scheinbare Größe der GPUExternalTexture beim Importieren eines VideoFrame gemäß der WebGPU-Spezifikation verwendet werden. Die sichtbare Größe wurde jedoch fälschlicherweise verwendet, was zu Problemen beim Versuch führte, textureLoad() für eine GPUExternalTexture zu verwenden. Dieser Fehler wurde jetzt behoben. Siehe Problem 377574981.

Bilder mit nicht standardmäßigen Ausrichtungen mit „copyExternalImageToTexture“ verarbeiten

Mit der copyExternalImageToTexture()-Methode „GPUQueue“ werden die Inhalte eines Bildes oder Canvas in eine Textur kopiert. Bilder mit nicht standardmäßigen Ausrichtungen werden jetzt richtig verarbeitet. Das war bisher nicht der Fall, wenn die Quelle ein ImageBitmap mit imageOrientation "from-image" oder ein Bild mit einer nicht standardmäßigen Ausrichtung war. Siehe Problem 384858956.

Entwicklererfahrung verbessern

Es kann überraschend sein, wenn adapter.limits hohe Werte aufweist, Sie aber nicht wissen, dass Sie beim Anfordern eines GPU-Geräts explizit ein höheres Limit anfordern müssen. Andernfalls kann es später zu unerwarteten Überschreitungen von Limits kommen.

Die Fehlermeldungen wurden um Hinweise erweitert, in denen Sie aufgefordert werden, explizit ein höheres Limit anzufordern, wenn beim Aufrufen von requestDevice() kein Limit in requiredLimits angegeben wurde. Siehe Problem 42240683.

Das folgende Beispiel zeigt eine verbesserte Fehlermeldung, die in der DevTools-Konsole protokolliert wird, wenn ein GPU-Puffer mit einer Größe erstellt wird, die das standardmäßige Geräte-Limit für die maximale Puffergröße überschreitet.

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

// Create a GPU buffer with a size exceeding the default max buffer size device limit.
const size = device.limits.maxBufferSize + 1;
const buffer = device.createBuffer({ size, usage: GPUBufferUsage.MAP_READ });

device.queue.submit([]);

⚠️ Buffer size (268435457) exceeds the max buffer size limit (268435456). This adapter supports a higher maxBufferSize of 4294967296, which can be specified in requiredLimits when calling requestDevice(). Limits differ by hardware, so always check the adapter limits prior to requesting a higher limit.
- While calling [Device].CreateBuffer([BufferDescriptor]).

Kompatibilitätsmodus mit „featureLevel“ aktivieren

Das Anfordern eines GPU-Adapters im experimentellen Kompatibilitätsmodus ist jetzt möglich, indem die standardisierte Option featureLevel auf "compatibility" gesetzt wird. Die Strings "core" (Standard) und "compatibility" sind die einzigen zulässigen Werte. Sehen Sie sich das folgende Beispiel und Spec PR 4897 an.

// Request a GPU adapter in compatibility mode
const adapter = await navigator.gpu.requestAdapter({ featureLevel: "compatibility" });

if (adapter?.featureLevel === "compatibility") {
  // Any devices created from this adapter will support only compatibility mode.
}

Die Option featureLevel ersetzt die nicht standardisierte Option compatibilityMode, während das nicht standardisierte Attribut featureLevel das Attribut isCompatibilityMode ersetzt.

Da die Funktion noch in der Testphase ist, müssen Sie Chrome vorerst mit dem Flag „Unsafe WebGPU Support“ unter chrome://flags/#enable-unsafe-webgpu ausführen. Auf webgpureport.org können Sie es ausprobieren.

Bereinigung von Funktionen für experimentelle Untergruppen

Die eingestellten experimentellen Untergruppenfunktionen "chromium-experimental-subgroups" und "chromium-experimental-subgroup-uniform-control-flow" wurden entfernt. Siehe Problem 377868468.

Die experimentelle Funktion "subgroups" ist jetzt alles, was Sie für Tests mit Untergruppen benötigen. Die experimentelle Funktion "subgroups-f16" wird nicht mehr unterstützt und bald entfernt. Sie können f16-Werte mit Untergruppen verwenden, wenn in Ihrer Anwendung sowohl "shader-f16"- als auch "subgroups"-Funktionen angefordert werden. Siehe Problem 380244620.

Einstellung des Limits „maxInterStageShaderComponents“

Das maxInterStageShaderComponents-Limit wird aus folgenden Gründen nicht mehr unterstützt:

  • Redundanz mit maxInterStageShaderVariables: Dieses Limit erfüllt bereits einen ähnlichen Zweck und steuert die Datenmenge, die zwischen Shader-Phasen übergeben wird.
  • Geringfügige Abweichungen: Die beiden Limits werden zwar unterschiedlich berechnet, die Unterschiede sind aber gering und können effektiv innerhalb des maxInterStageShaderVariables-Limits verwaltet werden.
  • Vereinfachung: Durch das Entfernen von maxInterStageShaderComponents wird die Shader-Schnittstelle optimiert und die Komplexität für Entwickler reduziert. Statt zwei separate Limits mit geringfügigen Unterschieden zu verwalten, können sie sich auf das umfassendere Limit maxInterStageShaderVariables konzentrieren, dessen Name besser passt.

Das Ziel ist, sie in Chrome 135 vollständig zu entfernen. Weitere Informationen finden Sie unter Geplante Einstellung und Problem 364338810.

Dawn-Updates

Mit wgpu::Device::GetAdapterInfo(adapterInfo) können Sie Adapterinformationen direkt von einem wgpu::Device abrufen. Weitere Informationen finden Sie unter Problem 376600838.

Die WGPUProgrammableStageDescriptor-Struktur wurde in WGPUComputeState umbenannt, um den Berechnungsstatus an den Vertex- und Fragmentstatus anzugleichen. Weitere Informationen finden Sie unter Problem 379059434.

Der Enum-Wert wgpu::VertexStepMode::VertexBufferNotUsed wurde entfernt. Ein Vertex-Pufferlayout, das nicht verwendet wird, kann jetzt mit {.stepMode=wgpu::VertexStepMode::Undefined, .attributeCount=0} ausgedrückt werden. Problem 383147017 ansehen

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