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 Gruppe von 16‑Bit-Gleitkommawerten im IEEE-754-Format „binary16“ (halbe Genauigkeit). Das bedeutet, dass eine Gleitkommazahl mit 16 Bit dargestellt wird, im Gegensatz zu 32 Bit bei herkömmlichen Gleitkommazahlen mit einfacher Genauigkeit (f32). Diese kleinere 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-Chat-Demo verwendet wird, deutlich schneller als die f32-Implementierung. Die Prefill-Geschwindigkeit wurde um 28% und die Dekodierungsgeschwindigkeit um 41% verbessert, 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-Shadermodul erstellen, das den Gleitkommatyp mit halber Genauigkeit f16 nutzt. Dieser Typ kann nur im WGSL-Shadermodul verwendet werden, wenn Sie die f16 WGSL-Erweiterung mit enable f16; aktivieren. Andernfalls generiert createShaderModule() einen Validierungsfehler. Siehe das folgende Minimalbeispiel und Issue 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...

Je nach "shader-f16"-Unterstützung können im WGSL-Shadermodulcode sowohl f16- als auch f32-Typen mit einem alias unterstützt werden, 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);
  }
`;

Grenzen überschreiten

Die maximale Anzahl von Byte, die für ein einzelnes Sample (Pixel oder Subpixel) der Ausgabedaten der Renderpipeline für alle Farbanhänge erforderlich sind, beträgt standardmäßig 32 Byte. Mit dem Limit maxColorAttachmentBytesPerSample können jetzt bis zu 64 Anfragen gestellt werden. Weitere Informationen finden Sie im folgenden Beispiel und unter Problem „dawn:2036“.

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 Limits für die maxInterStageShaderVariables- und maxInterStageShaderComponents-Nachrichten, die für die Kommunikation zwischen den Phasen verwendet werden, wurden auf allen Plattformen erhöht. Weitere Informationen finden Sie unter Problem dawn:1448.

Für jede Shaderphase ist die maximale Anzahl von Bindungsgruppenlayout-Einträgen in einem Pipeline-Layout, die Speicherbuffer sind, standardmäßig 8. Mit dem Limit maxStorageBuffersPerShaderStage können jetzt bis zu zehn angefordert werden. Siehe Problem dawn:2159.

Es wurde ein neues maxBindGroupsPlusVertexBuffers-Limit hinzugefügt. Sie besteht aus der maximalen Anzahl von Bindgruppen- und Vertex-Buffer-Slots, die gleichzeitig verwendet werden, einschließlich aller leeren Slots unter dem höchsten Index. Der Standardwert ist 24. Siehe Problem dawn:1849.

Änderungen am Tiefen-Stencil-Status

Zur Verbesserung der Entwicklerfreundlichkeit sind die Attribute „Depth-Stencil-Status“ depthWriteEnabled und depthCompare nicht mehr immer erforderlich: depthWriteEnabled ist nur für Formate mit Tiefenschärfe erforderlich und depthCompare ist für Formate mit Tiefenschärfe nicht erforderlich, wenn sie nicht verwendet werden. Siehe Problem dawn:2132.

Aktualisierte Informationen zu Adaptern

Nicht standardmäßige type- und backend-Adapter-Infoattribute sind jetzt beim Aufrufen von requestAdapterInfo() verfügbar, wenn der Nutzer die Flagge „WebGPU Developer Features“ unter chrome://flags/#enable-webgpu-developer-features aktiviert hat. type kann „diskrete GPU“, „integrierte GPU“, „CPU“ oder „unbekannt“ sein. backend ist entweder „WebGPU“, „D3D11“, „D3D12“, „metal“, „vulkan“, „openGL“, „openGLES“ oder „null“. Siehe Problem dawn:2112 und Problem dawn:2107.

Screenshot von https://webgpureport.org mit Informationen zum Back-End und zum Adaptertyp
Informationen zum Adapter-Backend und -Typ, die auf https://webgpureport.org angezeigt werden.

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 einer Genauigkeit von Nanosekunden messen. In der WebGPU-Spezifikation sind Zeitstempelabfragen jedoch aufgrund von Bedenken hinsichtlich Timing-Angriffen optional. Das Chrome-Team ist der Ansicht, dass die Quantisierung von TIMESTAMP-Abfragen einen guten Kompromiss zwischen Genauigkeit und Sicherheit bietet, da die Auflösung auf 100 Mikrosekunden reduziert wird. Siehe Problem „dawn:1800“.

In Chrome können Nutzer die Quantisierung von Zeitstempeln deaktivieren, indem sie das Flag „WebGPU-Entwicklerfunktionen“ unter chrome://flags/#enable-webgpu-developer-features aktivieren. Hinweis: 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 die neue Geräteoption „timestamp_quantization“ hinzugefügt. Sie ist standardmäßig aktiviert. Im folgenden Snippet wird gezeigt, wie Sie die experimentelle Funktion „timestamp-query“ ohne Quantisierung von Zeitstempeln zulassen, wenn Sie ein Gerät anfordern.

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 klarzumachen, 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. Siehe Problem chromium:1177506.

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

Das ist neu bei WebGPU

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

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