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 Typ f16 die Menge von 16-Bit-Gleitkommawerten im IEEE-754-Binärformat (mit halber Genauigkeit). Es werden also 16 Bit zur Darstellung einer Gleitkommazahl verwendet, im Gegensatz zu 32 Bits für herkömmliche Gleitkommazahlen mit einfacher Genauigkeit (f32). Diese kleinere Größe kann insbesondere bei der Verarbeitung großer Datenmengen zu erheblichen Leistungsverbesserungen führen.

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, mit einer um 28% schnelleren Vorausfüllung und einer um 41% schnelleren Decodierungsgeschwindigkeit, wie in den folgenden Screenshots gezeigt.

<ph type="x-smartling-placeholder">
</ph> Screenshot der 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 mit dieser Funktion eine GPUDevice anfordern und ein WGSL-Shadermodul erstellen, das den Gleitkommatyp mit halber Genauigkeit f16 verwendet. Dieser Typ kann im WGSL-Shader-Modul nur verwendet werden, wenn Sie die f16 WGSL-Erweiterung mit enable f16; aktivieren. Andernfalls erzeugt createShaderModule() einen Validierungsfehler. Hier ein minimales Beispiel 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...

Es ist möglich, sowohl den Typ f16 als auch den Typ f32 im Code des WGSL-Shadermoduls mit einem alias zu unterstützen, abhängig von der "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);
  }
`;

Grenzen setzen

Die maximale Anzahl von Byte, die für eine Stichprobe (Pixel oder Subpixel) der Ausgabedaten der Renderingpipeline in allen Farbanhängen erforderlich ist, beträgt standardmäßig 32 Byte. Über das Limit maxColorAttachmentBytesPerSample können jetzt bis zu 64 Anfragen gestellt 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 findest du unter issue dawn:1448.

Für jede Shader-Phase ist die maximale Anzahl von Layouteinträgen für Bindungsgruppen in einem Pipeline-Layout, bei denen es sich um Speicherpuffer handelt, standardmäßig 8. Über das Limit maxStorageBuffersPerShaderStage können jetzt bis zu zehn Anfragen angefordert werden. Siehe issue dawn:2159.

Das neue Limit maxBindGroupsPlusVertexBuffers wurde hinzugefügt. Sie besteht aus der maximalen Anzahl von gleichzeitig verwendeten Bind-Gruppen- und Vertex-Zwischenspeicher-Slots, wobei alle leeren Slots unter dem höchsten Index gezählt werden. Der Standardwert ist 24. Siehe issue dawn:1849.

Änderungen am Tiefenschablonenstatus

Zur Verbesserung der Entwicklerumgebung sind die Attribute „Tiefenschablonenstatus“ depthWriteEnabled und depthCompare nicht mehr erforderlich: depthWriteEnabled ist nur für Formate mit Tiefe erforderlich. Für Formate mit Tiefe ist depthCompare nicht erforderlich, wenn sie nicht verwendet werden. Siehe issue dawn:2132.

Aktualisierung der Adapterinformationen

Nicht standardmäßige Attribute für type- und backend-Adapterinformationen sind jetzt nach dem Aufrufen von requestAdapterInfo() verfügbar, wenn der Nutzer die WebGPU-Entwicklerfunktionen aktiviert hat flagge unter chrome://flags/#enable-webgpu-developer-features. Der type kann „Diskrete GPU“, „integrierte GPU“, „CPU“ oder „unbekannt“ sein. backend ist entweder „WebGPU“, „D3D11“, „D3D12“, „Metal“, „vulkan“, „openGL“, „openGLES“ oder „null“. Siehe issue dawn:2112 und issue dawn:2107.

<ph type="x-smartling-placeholder">
</ph> Screenshot von https://webgpureport.org mit Backend und Eingabe der Adapterinformationen
Backend und Typ der Adapterinformationen unter https://webgpureport.org

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

Zeitstempelabfragen – Quantisierung

Zeitstempelabfragen ermöglichen es Anwendungen, die Ausführungszeit von GPU-Befehlen mit einer Genauigkeit bis auf Nanosekunden zu messen. Die WebGPU-Spezifikation macht Zeitstempelabfragen jedoch aufgrund von Bedenken bezüglich zeitlicher Angriffe 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. Siehe issue dawn:1800.

In Chrome können Nutzer die Quantisierung von Zeitstempeln deaktivieren, indem sie „WebGPU Developer Features“ aktivieren flag bei chrome://flags/#enable-webgpu-developer-features. Durch dieses Flag wird allein die Funktion "timestamp-query" nicht aktiviert. Ihre Implementierung ist noch experimentell und erfordert daher die „Unsichere WebGPU-Unterstützung“ Flag bei chrome://flags/#enable-unsafe-webgpu.

In „Dawn“ gibt es eine neue Geräte-Ein/Aus-Schaltfläche namens „timestamp_quantization“. wurde hinzugefügt und ist standardmäßig aktiviert. Im folgenden Snippet sehen Sie, wie Sie die experimentelle Funktion „timestamp-query“ ohne Zeitstempelquantisierung, wenn ein Gerät angefordert wird.

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

Die experimentelle Funktion "timestamp-query-inside-passes" wurde in „chromium-experimental-timestamp-query-inside-passes“ umbenannt , um Entwicklern klar zu machen, dass sich diese Funktion noch in der Testphase befindet und vorerst nur in Chromium-basierten Browsern verfügbar ist. Siehe issue dawn:1193.

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

Hier werden nur einige der wichtigsten Vorteile behandelt. Vollständige Liste der Commits

Das ist neu bei WebGPU

Eine Liste aller behandelten Themen der Reihe What's New in WebGPU.

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