Neu in WebGPU (Chrome 155–156)

WGSL-Erweiterung „fragment_depth“

Bei rendernintensiven Renderdurchgängen sind Early-Z-Optimierungen sehr hilfreich. Sie sorgen für eine enorme Leistungssteigerung, da die GPU verborgene Pixel verwirft, bevor sie rechenintensive Fragment-Shader ausführt. Wenn ein gerasterter Tiefenwert den Tiefentest nicht besteht, überspringt die GPU den Fragment-Shader vollständig, sofern der Shader keine anderen Nebeneffekte hat.

Wenn Sie mehr darüber erfahren möchten, wie die Hardware damit umgeht, finden Sie einen ausgezeichneten Artikel von MJP unter When Does Early-Z Have to be Disabled?.

Die benutzerdefinierte Tiefenbearbeitung ist zwar nützlich, aber die Ausführung im Fragment-Shader hat einen versteckten Nachteil. Wenn Sie in einem Fragment-Shader in @builtin(frag_depth) schreiben, müssen Treiber diese Early-Z-Optimierungen in der Regel für den gesamten Zeichenaufruf deaktivieren. Das liegt daran, dass die Heuristik des Treibers nicht garantieren kann, dass die vom Shader berechnete Ausgabetiefe mit der vom Rasterizer interpolierten Tiefe übereinstimmt.

Um diese Leistungseinbußen zu vermeiden, können Sie mit der WGSL-Erweiterung fragment_depth einen less- oder greater-Tiefenmodusnamen für @builtin(frag_depth) angeben, um explizit anzugeben, wie die geschriebene Tiefe mit der interpolierten Tiefe verglichen wird. So kann die GPU Early-Z-Optimierungen sicher anwenden.

Diese Spracherweiterung kann in JavaScript mit navigator.gpu.wgslLanguageFeatures erkannt werden. Es wird empfohlen, eine „requires“-Anweisung zu verwenden, um die potenzielle Nicht-Portabilität mit requires fragment_depth; oben im WGSL-Shadercode zu signalisieren. Sehen Sie sich das folgende Beispiel und die Absicht zur Auslieferung an.

if (!navigator.gpu.wgslLanguageFeatures.has("fragment_depth")) {
  throw new Error(`WGSL fragment depth is not available`);
}

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

const shaderModule = device.createShaderModule({ code: `
  requires fragment_depth;

  @fragment
  fn main() -> @builtin(frag_depth, less) f32 {
    // Explicitly states that the output fragment depth is less than early-Z depth,
    // allowing the GPU to safely preserve early-Z optimizations.
    return 0.0f;
  }`,
});

Texturkomprimierung nicht ausgerichtet

Mit der GPU-Funktion „texture-compression-unaligned“ können komprimierte Texturen mit Abmessungen erstellt werden, die keine ganzzahligen Vielfachen der Blockgröße sind (z. B. 4 × 4 für die Formate BC, ETC2 und ASTC). Bisher mussten Texturgrößen bei WebGPU genau an diesen Blockgrenzen ausgerichtet sein. Da Texturen nicht mehr an Blockausrichtungen angepasst oder skaliert werden müssen, bleibt die ursprüngliche Komprimierungstreue erhalten und es kommt nicht zu Skalierungsverzerrungen. Weitere Informationen

Im folgenden Code-Snippet wird geprüft, ob der Adapter die nicht ausgerichtete Texturkomprimierung unterstützt. Falls ja, wird ein Gerät mit dieser Funktion angefordert.

const adapter = await navigator.gpu.requestAdapter();
if (!adapter.features.has("texture-compression-unaligned")) {
  throw new Error("Texture compression unaligned support is not available");
}
// Explicitly request texture compression unaligned support.
const device = await adapter.requestDevice({
  requiredFeatures: ["texture-compression-unaligned"],
});

Vielen Dank an den externen Mitwirkenden Ignacio Castaño, der diese Funktion entwickelt hat.

srgb-linearer und display-p3-linearer Farbraum

Mit den vordefinierten Farbräumen „srgb-linear“ und „display-p3-linear“ kann der WebGPU-Canvas-Kontext jetzt direkt in linearen Farbräumen mit erweitertem Bereich gerendert werden, um Displays mit großem Farbumfang zu unterstützen. In diesen Farbräumen besteht eine lineare Beziehung zwischen Pixelwerten und physischer Leuchtdichte. Sie eignen sich daher ideal für das Rendern von physischem Licht in Spielen sowie für räumliche Verarbeitungsaufgaben wie Antialiasing, Interpolation und Dezimierung. Weitere Informationen finden Sie unter intent to ship und im Beispiel-PR #574 für Partikel (HDR).

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

const canvas = document.querySelector("canvas");
const context = canvas.getContext("webgpu");

context.configure({
  device,
  format: "rgba16float",
  colorSpace: "display-p3-linear",
});

Zusätzliches snorm10-10-10-2-Vertexformat

Das Vertex-Format „snorm10-10-10-2“ ist ein gepacktes 32-Bit-Format mit vier vorzeichenbehafteten normalisierten Werten: drei 10-Bit-Komponenten (r, g, b) und einer 2-Bit-Komponente (a). Mit diesem Format können Sie Attribute wie 3D-Normalvektoren mit einem zusätzlichen 2-Bit-Skalar oder einem Ausrichtungsflag effizient speichern und gleichzeitig Speicherbandbreite sparen. Weitere Informationen finden Sie in Spezifikation PR 6491.

Unterstützung von f16 auf Linux für NVIDIA

Die optionale Funktion „shader-f16“, die Unterstützung für 16‑Bit-Gleitkommawerte in WGSL bietet, wird jetzt unter Linux für aktuelle NVIDIA-GPU-Treiber unterstützt. Weitere Informationen finden Sie unter chromium:42251215.

Änderungen bei Dawn

Sie können jetzt die LUID des zugrunde liegenden DXGIAdapter für einen bestimmten GPU-Adapter mit der WGPUAdapterPropertiesD3D-Struktur abfragen. Weitere Informationen finden Sie unter chromium:562849566.

Hier sind 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