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 Vertex-Format "unorm8x4-bgra" und die folgenden Vertex-Formate mit einer Komponente 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 chromestatus-Eintrag und in Problem 376924407.

Unbekannte Limits mit undefiniertem Wert anfordern

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 WGSL-Ausrichtungsregeln

Es ist nicht mehr möglich, einen zu kleinen Ausrichtungswert für ein Struct-Element anzugeben, da jetzt für alle Structs 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-Leistungssteigerung mit „discard“

Aufgrund eines erheblichen Leistungsabfalls beim Rendern eines komplexen Screen-Space-Reflections-Effekts (SSR) 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. Weitere Informationen finden Sie unter 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. Weitere Informationen finden Sie unter 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. Weitere Informationen finden Sie unter Problem 384858956.

Entwicklerfreundlichkeit 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, die Sie auffordern, explizit ein höheres Limit anzufordern, wenn beim Aufrufen von requestDevice() kein Limit in requiredLimits angegeben wurde. Weitere Informationen finden Sie unter 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 Standardlimit für die maximale Puffergröße des Geräts ü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 es sich noch um eine experimentelle Funktion handelt, 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 experimenteller Untergruppenfunktionen

Die eingestellten experimentellen Untergruppenfunktionen "chromium-experimental-subgroups" und "chromium-experimental-subgroup-uniform-control-flow" wurden entfernt. Weitere Informationen finden Sie unter Problem 377868468.

Die experimentelle Funktion "subgroups" ist jetzt alles, was Sie für Untergruppen-Tests 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"-Features angefordert werden. Problem 380244620

Einstellung des Limits „maxInterStageShaderComponents“

Das maxInterStageShaderComponents-Limit wird aufgrund einer Kombination von Faktoren eingestellt:

  • Redundanz mit maxInterStageShaderVariables: Dieses Limit erfüllt bereits einen ähnlichen Zweck und steuert die Menge der Daten, die zwischen Shader-Phasen übergeben werden.
  • Geringfügige Abweichungen: Die beiden Limits werden zwar leicht unterschiedlich berechnet, die Unterschiede sind aber gering und können effektiv innerhalb des maxInterStageShaderVariables-Limits berücksichtigt werden.
  • Vereinfachung: Durch das Entfernen von maxInterStageShaderComponents wird die Shader-Schnittstelle optimiert und die Komplexität für Entwickler verringert. 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.

Änderungen bei 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 Status von Vertex und Fragment übereinstimmt. 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

Neu bei WebGPU

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

Chrome 155–156

Chrome 153–154

Chrome 151–152

Chrome 149–150

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