Das ist neu bei WebGPU (Chrome 133)

François Beaufort
François Beaufort
GitHub

Veröffentlicht am 29. Januar 2025

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

Das "unorm8x4-bgra"-Vertexformat und die folgenden 1-Komponenten-Vertexformate 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 1-Komponenten-Vertexformat 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.

Anfragen mit unbekannten 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

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 Entwicklertools-Konsole protokolliert wird, wenn ein GPU-Zwischenspeicher 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. Unter 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 brauchen, wenn Sie mit Untergruppen experimentieren. 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 aufgrund einer Kombination von Faktoren nicht mehr unterstützt:

  • Redundanz mit maxInterStageShaderVariables: Dieses Limit erfüllt bereits einen ähnlichen Zweck, indem es die Menge der Daten steuert, die zwischen Shader-Phasen übertragen werden.
  • Geringfügige Abweichungen: Die beiden Limits werden zwar leicht unterschiedlich berechnet, die Unterschiede sind aber gering und lassen sich effektiv innerhalb des maxInterStageShaderVariables-Limits verwalten.
  • 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 Absicht zur Einstellung und Problem 364338810.

Aktualisierungen zu Dawn

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, damit der Berechnungsstatus mit den Vertex- und Fragmentstatus übereinstimmt. 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 Highlights. Vollständige Liste der Commits

Neuigkeiten zu WebGPU

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

Chrome 147–148

Chrome 146

Chrome 145

Chrome 144

Chrome 143

Chrome 142

Chrome 141

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