Das ist neu bei WebGPU (Chrome 133)

François Beaufort
François Beaufort

Veröffentlicht: 29. Januar 2025

Zusätzliche Vertex-Formate vom Typ unorm8x4-bgra und 1-Komponente

Das "unorm8x4-bgra"-Eckpunktformat und die folgenden einkomponentigen Eckpunktformate wurden hinzugefügt: "uint8", "sint8", "unorm8", "snorm8", "uint16", "sint16", "unorm16", "snorm16" und "float16". Mit dem "unorm8x4-bgra"-Vertex-Format können BGRA-codierte Vertex-Farben etwas einfacher geladen werden, während derselbe Shader verwendet wird. Außerdem können Sie mit dem 1-Komponenten-Eckpunktformat nur die Daten anfordern, die erforderlich sind, während für 8‑ und 16‑Bit-Datentypen zuvor mindestens doppelt so viele erforderlich waren. Weitere Informationen finden Sie im chromestatus-Eintrag und in Problem 376924407.

Zulassen, dass unbekannte Limits mit einem nicht definierten Wert angefordert werden

Um die WebGPU API im Laufe der Zeit robuster zu machen, können Sie jetzt beim Anfordern eines GPU-Geräts unbekannte Limits mit dem Wert undefined 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 unter spec 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 Regeln für die Ausrichtung von WGSL

Es ist nicht mehr möglich, einen zu kleinen Ausrichtungswert für ein Strukturelement anzugeben, da @align(n) jetzt für alle Strukturen durch RequiredAlignOf teilbar sein muss. Diese gravierende Änderung vereinfacht die Verwendung der WGSL-Sprache und macht sie mit Firefox und Safari kompatibler. Im PR für die Spezifikation finden Sie Beispielcode, der die Unterschiede zwischen den Tint-, Naga- und WebKit-Compilern zeigt.

Leistungssteigerung durch WGSL mit Discard

Aufgrund eines erheblichen Leistungseinbruchs beim Rendern eines komplexen SSR-Effekts (Screen-Space Reflections) wird bei der Implementierung der discard-Anweisung die von der Plattform bereitgestellte Semantik verwendet, um bei Bedarf zu einer Hilfsaufrufung herabzustufen. Dadurch wird die Leistung von Shadern verbessert, die Discard verwenden. Siehe Problem 372714384.

„displaySize“ von VideoFrame für externe Texturen verwenden

Die Dimensionen displayWidth und displayHeight sollten gemäß der WebGPU-Spezifikation als sichtbare Größe der GPUExternalTexture verwendet werden, wenn ein VideoFrame importiert wird. Die sichtbare Größe wurde jedoch fälschlicherweise verwendet, was zu Problemen führte, wenn versucht wurde, textureLoad() auf einer GPUExternalTexture zu verwenden. Dieser Fehler wurde jetzt behoben. Siehe Problem 377574981.

Bilder mit nicht standardmäßigen Ausrichtungen mit copyExternalImageToTexture verarbeiten

Mit der copyExternalImageToTexture()-GPUQueue-Methode wird der Inhalt eines Bilds oder Canvas in eine Textur kopiert. Bilder mit nicht standardmäßigen Ausrichtungen werden jetzt richtig verarbeitet. Das war vorher nicht der Fall, wenn die Quelle eine ImageBitmap mit imageOrientation "from-image" oder ein Bild mit einer anderen als der Standardausrichtung war. Siehe Problem 384858956.

Entwicklerfreundlichkeit verbessern

Es kann überraschend sein, wenn adapter.limits hohe Werte anzeigt, Sie aber nicht wissen, dass Sie bei der Anforderung eines GPU-Geräts ausdrücklich ein höheres Limit anfordern müssen. Andernfalls kann es später zu unerwarteten Grenzwertüberschreitungen kommen.

Zur besseren Orientierung wurden die Fehlermeldungen um Hinweise ergänzt, die Sie darauf hinweisen, ein höheres Limit anzugeben, wenn bei Aufruf von requestDevice() in requiredLimits kein Limit angegeben wurde. Siehe Problem 42240683.

Im folgenden Beispiel wird eine verbesserte Fehlermeldung angezeigt, die in der DevTools-Konsole protokolliert wird, wenn ein GPU-Puffer mit einer Größe erstellt wird, die das standardmäßige Gerätelimit 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

Du kannst jetzt einen GPU-Adapter im experimentellen Kompatibilitätsmodus anfordern, indem du die standardisierte Option featureLevel auf "compatibility" festlegst. Die Strings "core" (Standard) und "compatibility" sind die einzigen zulässigen Werte. Weitere Informationen finden Sie im folgenden Beispiel und in Spezifikations-PR 4897.

// 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 featureLevel-Attribut das isCompatibilityMode-Attribut ersetzt.

Da die Funktion noch experimentell 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 experimenteller Funktionen für 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 eingestellt und bald entfernt. Sie können F16-Werte mit Untergruppen verwenden, wenn Ihre Anwendung sowohl "shader-f16"- als auch "subgroups"-Funktionen anfordert. Siehe Problem 380244620.

Das Limit „maxInterStageShaderComponents“ wird eingestellt

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

  • Redundanz mit maxInterStageShaderVariables: Dieses Limit dient bereits einem ähnlichen Zweck, da es die Menge der Daten steuert, die zwischen den Shader-Phasen übergeben werden.
  • Geringfügige Abweichungen: Es gibt zwar geringfügige Unterschiede bei der Berechnung der beiden Limits, diese Unterschiede sind jedoch gering und können innerhalb des Limits für maxInterStageShaderVariables effektiv verwaltet werden.
  • Vereinfachung: Durch das Entfernen von maxInterStageShaderComponents wird die Shader-Oberfläche optimiert und die Komplexität für Entwickler reduziert. Anstatt zwei separate Limits mit geringfügigen Unterschieden zu verwalten, können sie sich auf die passendere und umfassendere maxInterStageShaderVariables konzentrieren.

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

Dawn-Updates

Mit dem wgpu::Device::GetAdapterInfo(adapterInfo) können Sie Adapterinformationen direkt von einem wgpu::Device abrufen. Siehe Problem 376600838.

Das WGPUProgrammableStageDescriptor-Objekt wurde in WGPUComputeState umbenannt, damit der Berechnungsstatus mit den Vertex- und Fragmentstatus übereinstimmt. Siehe Problem 379059434.

Der Aufzählungswert wgpu::VertexStepMode::VertexBufferNotUsed wurde entfernt. Ein nicht verwendetes Vertex-Buffer-Layout kann jetzt mit {.stepMode=wgpu::VertexStepMode::Undefined, .attributeCount=0} angegeben werden. Siehe Problem 383147017.

Dies sind nur einige der wichtigsten Highlights. Eine vollständige Liste der Commits findest du hier.

Das ist neu bei WebGPU

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

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