W3C hat einen Entwurf des WebGPU-Standards veröffentlicht.

Der W3C-Konsortium hat die ersten Entwürfe der Spezifikationen für WebGPU und die WebGPU Shading Language (WGSL) vorgestellt. Diese definieren ein API für die Ausführung von Operationen auf GPUs, wie Rendering und Berechnungen, sowie eine Shading-Sprache zur Erstellung von Programmen, die auf der GPU laufen. Konzeptionell ähnlich wie die APIs von Vulkan, Metal und Direct3D 12, wurden die Spezifikationen von einer Arbeitsgruppe vorbereitet, die Ingenieure von Mozilla, Google, Apple und Microsoft umfasst.

Konzeptionell unterscheidet sich WebGPU von WebGL ähnlich wie die Grafik-API Vulkan sich von OpenGL unterscheidet, basiert jedoch nicht auf einer bestimmten Grafik-API. Stattdessen bildet es eine universelle Schicht, die dieselben niedrigstufigen Primitiven verwendet, die in Vulkan, Metal und Direct3D vorhanden sind. WebGPU bietet JavaScript-Anwendungen die Möglichkeit, niedrigstufige Kontrolle über die Organisation, Verarbeitung und Übertragung von Befehlen an die GPU zu erlangen sowie den Umgang mit zugehörigen Ressourcen, Speicher, Puffer, Texturobjekten und kompilierten Grafik-Shadern zu steuern. Ein solcher Ansatz ermöglicht eine höhere Leistung grafischer Anwendungen durch die Verringerung von Overhead und die Steigerung der Effizienz im Umgang mit der GPU.

WebGPU ermöglicht es, komplexe 3D-Projekte für das Web zu erstellen, die ebenso leistungsfähig sind wie eigenständige Programme, die direkt mit Vulkan, Metal oder Direct3D kommunizieren, jedoch nicht an spezifische Plattformen gebunden sind. WebGPU bietet auch erweiterte Möglichkeiten für die Portierung nativer Grafikprogramme in Formate, die auf Web-Technologien basieren, dank der Kompilierung in WebAssembly. Neben 3D-Grafiken umfasst WebGPU auch die Möglichkeiten des Auslagerns von Berechnungen auf die GPU und der Ausführung von Shaders.

Hauptmerkmale von WebGPU:

• Die getrennte Verwaltung von Ressourcen, Vorbereitungsarbeiten und das Übertragen von Befehlen an die GPU (in WebGL war ein Objekt für alles verantwortlich). Es stehen drei separate Kontexte zur Verfügung: GPUDevice zur Erstellung von Ressourcen wie Texturen und Buffern; GPUCommandEncoder für das Codieren einzelner Befehle, einschließlich der Render- und Berechnungsphasen; GPUCommandBuffer zum Anstehen von Aufgaben zur Ausführung auf der GPU. Das Ergebnis kann in einem Bereich, der mit einem oder mehreren Canvas-Elementen verbunden ist, gerendert oder ohne Ausgabe verarbeitet werden (z. B. bei der Ausführung von Berechnungsaufgaben). Die Trennung der Phasen vereinfacht die Aufteilung von Ressourcencreation und Vorbereitungsarbeiten auf verschiedene Handler, die in unterschiedlichen Threads ausgeführt werden können.
• Ein anderer Ansatz zur Verarbeitung von Zuständen. In WebGPU werden zwei Objekte angeboten – GPURenderPipeline und GPUComputePipeline, die es ermöglichen, verschiedene vom Entwickler vordefinierte Zustände zu kombinieren. Dadurch kann der Browser Ressourcen sparen, indem er zusätzliche Aufgaben wie die Neukompilierung von Shadern vermeidet. Unterstützte Zustände umfassen: Shader, Layouts von Vertex-Puffern und Attributen, Layouts von angehängten Gruppen, Mischen, Tiefe und Vorlagen sowie Ausgabeformate nach dem Rendering.
• Das Bindungsmodell erinnert stark an die in Vulkan vorhandenen Mittel zur Gruppierung von Ressourcen. Um Ressourcen in Gruppen zu bündeln, bietet WebGPU das Objekt GPUBindGroup, das während des Kommandoschreibens mit anderen ähnlichen Objekten verknüpft werden kann, um in Shadern verwendet zu werden. Die Erstellung solcher Gruppen ermöglicht es dem Treiber, die erforderlichen Vorbereitungen im Voraus zu treffen, und ermöglicht es dem Browser, die Bindungen von Ressourcen zwischen den Renderaufrufen erheblich schneller zu wechseln. Das Layout der Ressourcenbindungen kann im Voraus mit dem Objekt GPUBindGroupLayout definiert werden.

Quelle: opennet.ru