Neu bei WebGPU (Chrome 120)

François Beaufort
François Beaufort
GitHub

Unterstützung für 16-Bit-Gleitkommawerte in WGSL

In WGSL ist der f16-Typ die Menge von 16-Bit-Gleitkommawerten im IEEE-754-Binärformat 16 (Halbpräzision). Das bedeutet, dass für eine Gleitkommazahl 16 Bit verwendet werden, im Gegensatz zu 32 Bit für einen herkömmlichen Gleitkommawert mit einfacher Genauigkeit (f32). Diese kleinere Größe kann insbesondere bei der Verarbeitung großer Datenmengen zu erheblichen Leistungsverbesserungen führen.

Auf einem Apple M1 Pro-Gerät ist die f16-Implementierung von Llama2 7B-Modellen, die in der WebLLM-Chat-Demo verwendet werden, deutlich schneller als die f32-Implementierung. Die Vorabfüllgeschwindigkeit ist um 28% und die Dekodierungsgeschwindigkeit um 41% verbessert, wie in den folgenden Screenshots dargestellt.

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

Nicht alle GPUs unterstützen 16-Bit-Gleitkommawerte. Wenn die Funktion "shader-f16" in einer GPUAdapter verfügbar ist, können Sie jetzt mit dieser Funktion ein GPUDevice anfordern und ein WGSL-Shader-Modul erstellen, das den Gleitkommatyp f16 mit halber Genauigkeit nutzt. Dieser Typ kann nur dann im WGSL-Shader-Modul verwendet werden, wenn Sie die WGSL-Erweiterung f16 mit enable f16; aktivieren. Andernfalls generiert createShaderModule() einen Validierungsfehler. Sehen Sie sich das folgende Beispiel und issue dawn:1510 an.

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-Shader-Modulcode mit einem alias zu unterstützen, das von der "shader-f16"-Featureunterstützung abhängt, 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);
  }
`;

Geh an die Grenzen

Die maximale Anzahl von Byte, die zur Aufnahme einer Stichprobe (Pixel oder Subpixel) von Ausgabedaten der Rendering-Pipeline über alle Farbanhänge hinweg erforderlich ist, beträgt standardmäßig 32 Byte. Über das Limit maxColorAttachmentBytesPerSample können jetzt bis zu 64 angefordert werden. Sehen Sie sich das folgende Beispiel und issue 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 Limits für maxInterStageShaderVariables und maxInterStageShaderComponents für die Kommunikation zwischen den Phasen 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 Bindgruppen-Layouteinträgen in einem Pipeline-Layout, die Speicherpuffer sind, standardmäßig 8. Über das Limit maxStorageBuffersPerShaderStage können jetzt bis zu zehn Anfragen gesendet werden. Weitere Informationen finden Sie unter Problem dawn:2159.

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

Änderungen am Status der Tiefenschablone

Um die Entwicklung für Entwickler zu verbessern, sind die Attribute „Schablonenstatus“ depthWriteEnabled und depthCompare nicht mehr erforderlich: depthWriteEnabled ist nur für Formate mit Tiefe erforderlich und depthCompare ist nicht mehr für Formate mit Tiefe erforderlich, wenn sie gar nicht verwendet werden. Weitere Informationen finden Sie unter Problem dawn:2132.

Aktualisierung der Adapterinformationen

Nicht standardmäßige type- und backend-Adapterinformationen sind jetzt beim Aufrufen von requestAdapterInfo() verfügbar, wenn der Nutzer die Kennzeichnung „WebGPU Developer Features“ bei chrome://flags/#enable-webgpu-developer-features aktiviert hat. Die type kann eine „diskrete GPU“, „integrierte GPU“, „CPU“ oder „unbekannt“ sein. backend ist entweder "WebGPU", "D3D11", "D3D12", "metal", "vulkan", "openGL", "openGLES" oder "null". Weitere Informationen finden Sie unter Ausgabe:2112 und Ausgabe:2107.

Screenshot von https://webgpureport.org mit Backend und Adapterinformationen
Back-End und Typ für Adapterinformationen auf https://webgpureport.org.

Der optionale Listenparameter unmaskHints in requestAdapterInfo() wurde entfernt. Weitere Informationen finden Sie unter Problem dawn:1427.

Quantisierung von Zeitstempelabfragen

Mit Zeitstempelabfragen können Anwendungen die Ausführungszeit von GPU-Befehlen auf Nanosekunden genau messen. Die WebGPU-Spezifikation macht Zeitstempelabfragen jedoch aufgrund von Bedenken hinsichtlich zeitlicher Angriffen optional. Das Chrome-Team ist der Meinung, dass die Quantisierung von Zeitstempelabfragen einen guten Kompromiss zwischen Präzision und Sicherheit darstellt, da die Auflösung auf 100 Mikrosekunden reduziert wird. Weitere Informationen finden Sie unter Problem dawn:1800.

In Chrome können Nutzer die Zeitstempelquantisierung deaktivieren, indem sie das Flag „WebGPU Developer Features“ auf chrome://flags/#enable-webgpu-developer-features aktivieren. Durch dieses Flag wird die Funktion "timestamp-query" nicht aktiviert. Seine Implementierung befindet sich noch in der Testphase und erfordert daher das Flag „Unsafe WebGPU Support“ bei chrome://flags/#enable-unsafe-webgpu.

In „Dawn“ wurde eine neue Geräteauswahl namens „timestamp_quantization“ hinzugefügt, die standardmäßig aktiviert ist. Das folgende Snippet zeigt, wie Sie die experimentelle Funktion „Zeitstempel-Abfrage“ ohne Zeitstempel-Quantisierung 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);

Frühjahrsputz-Funktionen

Die experimentelle Funktion „timestamp-query-inside-passes“ wurde in „chromium-experimental-timestamp-query-inside-passes“ umbenannt, um Entwicklern zu verdeutlichen, dass diese Funktion sich noch in der Testphase befindet und derzeit nur in Chromium-basierten Browsern verfügbar ist. Weitere Informationen finden Sie unter Problem dawn:1193.

Die experimentelle Funktion „pipeline-statistics-query“, die nur teilweise implementiert wurde, wurde entfernt, da sie sich nicht mehr in der Entwicklung befindet. Siehe Problem „chromium:1177506“.

Dies sind nur einige der wichtigsten Punkte. Hier finden Sie eine vollständige Liste der Commits.

Neu bei WebGPU

Hier finden Sie eine Liste aller Inhalte, die in der Reihe What's New in WebGPU behandelt wurden.

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