Neu bei WebGPU (Chrome 120)

François Beaufort
François Beaufort
GitHub

Unterstützung von 16‑Bit-Gleitkommawerten in WGSL

In WGSL ist der Typ f16 die Menge der 16-Bit-Gleitkommawerte des IEEE-754-Formats „binary16“ (halbe Genauigkeit). Das bedeutet, dass 16 Bits zur Darstellung einer Gleitkommazahl verwendet werden, im Gegensatz zu 32 Bits für die herkömmliche Gleitkommazahl mit einfacher Genauigkeit (f32). Diese geringere Größe kann zu erheblichen Leistungsverbesserungen führen, insbesondere bei der Verarbeitung großer Datenmengen.

Zum Vergleich: Auf einem Apple M1 Pro-Gerät ist die f16-Implementierung der Llama2 7B-Modelle, die in der WebLLM-Chatdemo verwendet wird, deutlich schneller als die f32-Implementierung. Die Vorabfüllgeschwindigkeit ist um 28% und die Decodierungsgeschwindigkeit um 41% höher, wie in den folgenden Screenshots zu sehen ist.

Screenshot von WebLLM-Chatdemos mit f32- und f16-Llama2-7B-Modellen.
WebLLM-Chatdemos mit den Llama2 7B-Modellen f32 (links) und f16 (rechts).

Nicht alle GPUs unterstützen 16‑Bit-Gleitkommawerte. Wenn die Funktion "shader-f16" in einem GPUAdapter verfügbar ist, können Sie jetzt einen GPUDevice mit dieser Funktion anfordern und ein WGSL-Shader-Modul erstellen, das den Gleitkommatyp mit halber Genauigkeit f16 nutzt. Dieser Typ kann im WGSL-Shadermodul nur verwendet werden, wenn Sie die f16 WGSL-Erweiterung mit enable f16; aktivieren. Andernfalls wird durch createShaderModule() ein Validierungsfehler generiert. Hier finden Sie ein Minimalbeispiel und das Problem dawn:1510.

const adapter = await navigator.gpu.requestAdapter();
if (!adapter.features.has("shader-f16")) {
  throw new Error("16-bit floating-point value support is not available");
}
// Explicitly request 16-bit floating-point value support.
const device = await adapter.requestDevice({
  requiredFeatures: ["shader-f16"],
});

const code = `
  enable f16;

  @compute @workgroup_size(1)
  fn main() {
    const c : vec3h = vec3<f16>(1.0h, 2.0h, 3.0h);
  }
`;

const shaderModule = device.createShaderModule({ code });
// Create a compute pipeline with this shader module
// and run the shader on the GPU...

Es ist möglich, sowohl f16- als auch f32-Typen im WGSL-Shadermodulcode mit einem alias zu unterstützen, je nach "shader-f16"-Funktionsunterstützung, wie im folgenden Snippet gezeigt.

const adapter = await navigator.gpu.requestAdapter();
const hasShaderF16 = adapter.features.has("shader-f16");

const device = await adapter.requestDevice({
  requiredFeatures: hasShaderF16 ? ["shader-f16"] : [],
});

const header = hasShaderF16
  ? `enable f16;
     alias min16float = f16;`
  : `alias min16float = f32;`;

const code = `
  ${header}

  @compute @workgroup_size(1)
  fn main() {
    const c = vec3<min16float>(1.0, 2.0, 3.0);
  }
`;

An die Grenzen gehen

Die maximale Anzahl von Bytes, die zum Speichern einer Stichprobe (Pixel oder Subpixel) von Ausgabedaten der Renderpipeline über alle Farb-Attachments hinweg erforderlich ist, beträgt standardmäßig 32 Byte. Mit dem Limit maxColorAttachmentBytesPerSample können Sie jetzt bis zu 64 Anfragen stellen. Sehen Sie sich das folgende Beispiel und Problem dawn:2036 an.

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

if (adapter.limits.maxColorAttachmentBytesPerSample < 64) {
  // When the desired limit isn't supported, take action to either fall back to
  // a code path that does not require the higher limit or notify the user that
  // their device does not meet minimum requirements.
}

// Request highest limit of max color attachments bytes per sample.
const device = await adapter.requestDevice({
  requiredLimits: { maxColorAttachmentBytesPerSample: 64 },
});

Die für die Kommunikation zwischen den Phasen verwendeten Limits maxInterStageShaderVariables und maxInterStageShaderComponents wurden auf allen Plattformen erhöht. Weitere Informationen finden Sie unter Problem dawn:1448.

Für jede Shader-Phase beträgt die maximale Anzahl von Bindungsgruppen-Layouteinträgen in einem Pipeline-Layout, die Speicherpuffer sind, standardmäßig 8. Mit dem Limit maxStorageBuffersPerShaderStage können Sie jetzt bis zu 10 Anfragen stellen. Siehe Problem dawn:2159.

Ein neues maxBindGroupsPlusVertexBuffers-Limit wurde hinzugefügt. Sie besteht aus der maximalen Anzahl von Bindungsgruppen- und Vertex-Puffer-Slots, die gleichzeitig verwendet werden, wobei alle leeren Slots unter dem höchsten Index mitgezählt werden. Der Standardwert ist 24. Siehe Problem dawn:1849.

Änderungen am Tiefen-/Stencil-Status

Um die Entwicklerfreundlichkeit zu verbessern, sind die Attribute für den Tiefen-Stencil-Status depthWriteEnabled und depthCompare nicht mehr immer erforderlich: depthWriteEnabled ist nur für Formate mit Tiefe erforderlich und depthCompare ist für Formate mit Tiefe nicht erforderlich, wenn es nicht verwendet wird. Weitere Informationen finden Sie unter Problem dawn:2132.

Aktualisierung von Adapterinformationen

Nicht standardmäßige type- und backend-Adapterinfoattribute sind jetzt verfügbar, wenn requestAdapterInfo() aufgerufen wird und der Nutzer das Flag „WebGPU Developer Features“ (WebGPU-Entwicklerfunktionen) unter chrome://flags/#enable-webgpu-developer-features aktiviert hat. type kann „discrete GPU“ (diskrete GPU), „integrated GPU“ (integrierte GPU), „CPU“ oder „unknown“ (unbekannt) sein. backend ist entweder „WebGPU“, „D3D11“, „D3D12“, „metal“, „vulkan“, „openGL“, „openGLES“ oder „null“. Weitere Informationen finden Sie unter Problem dawn:2112 und Problem dawn:2107.

Screenshot von https://webgpureport.org mit Backend und Typ in den Adapterinformationen.
Adapterinformationen (Backend und Typ) auf https://webgpureport.org.

Der optionale Listenparameter unmaskHints in requestAdapterInfo() wurde entfernt. Siehe Problem dawn:1427.

Quantisierung von Zeitstempelabfragen

Mit Zeitstempelabfragen können Anwendungen die Ausführungszeit von GPU-Befehlen mit Nanosekundenpräzision messen. Die WebGPU-Spezifikation macht Zeitstempelabfragen jedoch aufgrund von Bedenken hinsichtlich Timing-Angriffen optional. Das Chrome-Team ist der Ansicht, dass die Quantisierung von Zeitstempelanfragen einen guten Kompromiss zwischen Genauigkeit und Sicherheit darstellt, da die Auflösung auf 100 Mikrosekunden reduziert wird. Weitere Informationen

In Chrome können Nutzer die Zeitstempelquantisierung deaktivieren, indem sie das Flag „WebGPU Developer Features“ unter chrome://flags/#enable-webgpu-developer-features aktivieren. Dieses Flag allein aktiviert die Funktion "timestamp-query" nicht. Die Implementierung ist noch experimentell und erfordert daher das Flag „Unsafe WebGPU Support“ unter chrome://flags/#enable-unsafe-webgpu.

In Dawn wurde ein neuer Geräteschalter namens „timestamp_quantization“ hinzugefügt, der standardmäßig aktiviert ist. Das folgende Snippet zeigt, wie Sie das experimentelle Feature „timestamp-query“ ohne Zeitstempelquantisierung beim Anfordern eines Geräts zulassen.

wgpu::DawnTogglesDescriptor deviceTogglesDesc = {};

const char* allowUnsafeApisToggle = "allow_unsafe_apis";
deviceTogglesDesc.enabledToggles = &allowUnsafeApisToggle;
deviceTogglesDesc.enabledToggleCount = 1;

const char* timestampQuantizationToggle = "timestamp_quantization";
deviceTogglesDesc.disabledToggles = &timestampQuantizationToggle;
deviceTogglesDesc.disabledToggleCount = 1;

wgpu::DeviceDescriptor desc = {.nextInChain = &deviceTogglesDesc};

// Request a device with no timestamp quantization.
myAdapter.RequestDevice(&desc, myCallback, myUserData);

Funktionen für den Frühjahrsputz

Die experimentelle Funktion „timestamp-query-inside-passes“ wurde in „chromium-experimental-timestamp-query-inside-passes“ umbenannt, um Entwicklern zu verdeutlichen, dass diese Funktion experimentell ist und derzeit nur in Chromium-basierten Browsern verfügbar ist. Siehe Problem dawn:1193.

Die experimentelle Funktion „pipeline-statistics-query“, die nur teilweise implementiert wurde, wurde entfernt, da sie nicht mehr weiterentwickelt wird. Weitere Informationen finden Sie unter chromium:1177506.

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