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.
![Screenshot der WebLLM-Chatdemos mit f32- und f16 Llama2 7B-Modellen.](https://developer.chrome.google.cn/static/blog/new-in-webgpu-120/image/webllm-chat-demos.png?authuser=6&hl=de)
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.
![Screenshot von https://webgpureport.org mit Backend und Eingabe der Adapterinformationen](https://developer.chrome.google.cn/static/blog/new-in-webgpu-120/image/webgpureport.png?authuser=6&hl=de)
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 = ×tampQuantizationToggle;
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
- Experimentelle Unterstützung von OpenGL ES unter Android
- GPUAdapter-Infoattribut
- Verbesserungen der WebAssembly-Interoperabilität
- Verbesserte Fehler des Befehls-Encoders
- Updates zur Morgendämmerung
Chrome 126
- Limit für maxTextureArrayLayers erhöhen
- Optimierung des Zwischenspeicheruploads für das Vulkan-Backend
- Schnellere Kompilierungszeiten
- Gesendete Befehlspuffer müssen eindeutig sein
- Updates zur Morgendämmerung
Chrome 125
Chrome 124
- Schreibgeschützte Speichertexturen
- Unterstützung für Service Worker und Shared Worker
- Neue Attribute für Adapterinformationen
- Diverse Fehlerkorrekturen
- Updates zur Morgendämmerung
Chrome 123
- Unterstützung der integrierten DP4a-Funktionen in WGSL
- Uneingeschränkte Zeigerparameter in WGSL
- „Zucker“-Syntax für die Dereferenzierung von zusammengesetzten Daten in WGSL
- Separater schreibgeschützter Status für Schablonen- und Tiefenaspekte
- Updates zur Morgendämmerung
Chrome 122
- Reichweite mit dem Kompatibilitätsmodus erhöhen (Funktion in Entwicklung)
- maxVertexAttributes-Limit erhöhen
- Updates zur Morgendämmerung
Chrome 121
- Unterstützung von WebGPU unter Android
- DXC anstelle von FXC für die Shader-Kompilierung unter Windows verwenden
- Zeitstempelabfragen in Rechen- und Renderingdurchläufen
- Standardeinstiegspunkte für Shader-Module
- Unterstützung von „display-p3“ als GPUExternalTexture-Farbraum
- Informationen zu Arbeitsspeicher-Heaps
- Updates zur Morgendämmerung
Chrome 120
- Unterstützung von 16-Bit-Gleitkommawerten in WGSL
- Gehe an deine Grenzen
- Änderungen am Status der Tiefenschablonen
- Aktualisierung der Adapterinformationen
- Zeitstempelquantisierung von Abfragen
- Frühjahrsputz
Chrome 119
- Filterbare 32-Bit-Float-Texturen
- unorm10-10-10-2 Vertexformat
- rgb10a2uint-Texturformat
- Updates zur Morgendämmerung
Chrome 118
- Unterstützung von HTMLImageElement und ImageData in
copyExternalImageToTexture()
- Experimentelle Unterstützung für nicht schreibgeschützte und schreibgeschützte Speichertexturen
- Updates zur Morgendämmerung
Chrome 117
- Vertex-Zwischenspeicher aufheben
- Bindungsgruppe aufheben
- Fehler bei der asynchronen Pipelineerstellung stummschalten, wenn Gerät verloren geht
- Aktualisierungen beim Erstellen von SPIR-V-Shadermodulen
- Entwicklererfahrung verbessern
- Caching-Pipelines mit automatisch generiertem Layout
- Updates zur Morgendämmerung
Chrome 116
- WebCodecs-Integration
- Verlorenes Gerät, das von GPUAdapter
requestDevice()
zurückgegeben wurde - Videowiedergabe ruckelfrei, wenn
importExternalTexture()
aufgerufen wird - Konformität mit Spezifikationen
- Entwicklererfahrung verbessern
- Updates zur Morgendämmerung
Chrome 115
- Unterstützte WGSL-Spracherweiterungen
- Experimentelle Unterstützung für Direct3D 11
- Separate GPU standardmäßig im Netzbetrieb nutzen
- Entwicklererfahrung verbessern
- Updates zur Morgendämmerung
Chrome 114
- JavaScript-Code optimieren
- getCurrentTexture() bei nicht konfiguriertem Canvas löst InvalidStateError aus
- Wichtige Informationen von WGSL
- Updates zur Morgendämmerung