WebGPU (Chrome→120) में नया क्या है

François Beaufort
François Beaufort

WGSL में 16-बिट फ़्लोटिंग-पॉइंट वैल्यू के लिए सहायता

WGSL में, f16 type, IEEE-754 binary16 (half precision) फ़ॉर्मैट की 16-बिट फ़्लोटिंग-पॉइंट वैल्यू का सेट होता है. इसका मतलब है कि यह फ़्लोटिंग-पॉइंट नंबर को दिखाने के लिए 16 बिट का इस्तेमाल करता है. वहीं, सामान्य सिंगल-प्रेसिज़न फ़्लोटिंग-पॉइंट (f32) के लिए 32 बिट का इस्तेमाल किया जाता है. इस छोटे साइज़ की वजह से, परफ़ॉर्मेंस में काफ़ी सुधार हो सकता है. खास तौर पर, जब बड़ी मात्रा में डेटा प्रोसेस किया जा रहा हो.

तुलना के लिए, Apple M1 Pro डिवाइस पर WebLLM चैट डेमो में इस्तेमाल किए गए Llama2 7B मॉडल का f16 वर्शन, f32 वर्शन की तुलना में काफ़ी तेज़ है. प्रीफ़िल करने की स्पीड में 28% और डिकोडिंग की स्पीड में 41% का सुधार हुआ है. इसकी जानकारी यहां दिए गए स्क्रीनशॉट में दी गई है.

WebLLM के चैट डेमो का स्क्रीनशॉट. इसमें f32 और f16 Llama2 7B मॉडल दिखाए गए हैं.
WebLLM में चैट के डेमो. इनमें f32 (बाएं) और f16 (दाएं) Llama2 7B मॉडल का इस्तेमाल किया गया है.

सभी जीपीयू, 16-बिट फ़्लोटिंग-पॉइंट वैल्यू के साथ काम नहीं करते. जब GPUAdapter में "shader-f16" सुविधा उपलब्ध होती है, तब इस सुविधा के साथ GPUDevice का अनुरोध किया जा सकता है. साथ ही, एक WGSL शेडर मॉड्यूल बनाया जा सकता है, जो हाफ़-प्रिसिज़न फ़्लोटिंग-पॉइंट टाइप f16 का फ़ायदा उठाता है. इस टाइप का इस्तेमाल WGSL शेडर मॉड्यूल में सिर्फ़ तब किया जा सकता है, जब आपने enable f16; के साथ f16 WGSL एक्सटेंशन चालू किया हो. ऐसा न करने पर, createShaderModule() से पुष्टि करने से जुड़ी गड़बड़ी जनरेट होगी. यहां दिया गया कम से कम शब्दों वाला उदाहरण और 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...

WGSL शेडर मॉड्यूल कोड में alias की मदद से, f16 और f32, दोनों टाइप का इस्तेमाल किया जा सकता है. हालांकि, यह "shader-f16" सुविधा के साथ काम करने पर निर्भर करता है. इसके बारे में यहां दिए गए स्निपेट में बताया गया है.

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);
  }
`;

पूरी कोशिश करना

रेंडर पाइपलाइन के आउटपुट डेटा के एक सैंपल (पिक्सल या सबपिक्सल) को सभी कलर अटैचमेंट में सेव करने के लिए, ज़्यादा से ज़्यादा 32 बाइट की ज़रूरत होती है. अब maxColorAttachmentBytesPerSample की सीमा का इस्तेमाल करके, ज़्यादा से ज़्यादा 64 अनुरोध किए जा सकते हैं. यहां दिया गया उदाहरण और issue 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 },
});

सभी प्लैटफ़ॉर्म पर, इंटर-स्टेज कम्यूनिकेशन के लिए इस्तेमाल की जाने वाली maxInterStageShaderVariables और maxInterStageShaderComponents की सीमाएं बढ़ा दी गई हैं. ज़्यादा जानकारी के लिए, issue dawn:1448 देखें.

हर शेडर स्टेज के लिए, पाइपलाइन लेआउट में बाइंड ग्रुप लेआउट एंट्री की ज़्यादा से ज़्यादा संख्या डिफ़ॉल्ट रूप से 8 होती है. ये एंट्री, स्टोरेज बफ़र होती हैं. अब maxStorageBuffersPerShaderStage की सीमा का इस्तेमाल करके, ज़्यादा से ज़्यादा 10 अनुरोध किए जा सकते हैं. issue dawn:2159 देखें.

maxBindGroupsPlusVertexBuffers की नई सीमा जोड़ी गई है. इसमें एक साथ इस्तेमाल किए गए बाइंड ग्रुप और वर्टेक्स बफ़र स्लॉट की ज़्यादा से ज़्यादा संख्या होती है. इसमें सबसे ज़्यादा इंडेक्स से नीचे के सभी खाली स्लॉट शामिल होते हैं. इसकी डिफ़ॉल्ट वैल्यू 24 होती है. समस्या dawn:1849 देखें.

डेप्थ-स्टेंसिल की स्थिति में बदलाव

डेवलपर के अनुभव को बेहतर बनाने के लिए, अब डेप्थ-स्टेंसिल स्टेट depthWriteEnabled और depthCompare एट्रिब्यूट की हमेशा ज़रूरत नहीं होती: depthWriteEnabled एट्रिब्यूट की ज़रूरत सिर्फ़ डेप्थ वाले फ़ॉर्मैट के लिए होती है. साथ ही, अगर डेप्थ वाले फ़ॉर्मैट का इस्तेमाल नहीं किया जाता है, तो depthCompare एट्रिब्यूट की ज़रूरत नहीं होती. issue dawn:2132 देखें.

अडैप्टर की जानकारी से जुड़े अपडेट

उपयोगकर्ता के chrome://flags/#enable-webgpu-developer-features पर "WebGPU डेवलपर सुविधाएं" फ़्लैग चालू करने पर, अब requestAdapterInfo() को कॉल करने पर, नॉन-स्टैंडर्ड type और backend अडैप्टर की जानकारी वाले एट्रिब्यूट उपलब्ध हैं. type "डिस्क्रीट जीपीयू", "इंटिग्रेटेड जीपीयू", "सीपीयू" या "कोई जानकारी नहीं है" हो सकता है. backend की वैल्यू "WebGPU", "D3D11", "D3D12", "metal", "vulkan", "openGL", "openGLES" या "null" होती है. issue dawn:2112 और issue dawn:2107 देखें.

https://webgpureport.org का स्क्रीनशॉट. इसमें अडैप्टर की जानकारी में बैकएंड और टाइप दिखाया गया है.
अडैप्टर की जानकारी, बैकएंड और टाइप, https://webgpureport.org पर दिखती है.

requestAdapterInfo() में मौजूद, ज़रूरी नहीं unmaskHints सूची पैरामीटर को हटा दिया गया है. समस्या dawn:1427 देखें.

टाइमस्टैंप क्वेरी के क्वांटाइज़ेशन की सुविधा

टाइमस्टैंप क्वेरी की मदद से, ऐप्लिकेशन को नैनोसेकंड की सटीक जानकारी के साथ, GPU कमांड के एक्ज़ीक्यूशन टाइम का आकलन करने की अनुमति मिलती है. हालांकि, WebGPU स्पेसिफ़िकेशन में टाइमस्टैंप क्वेरी को वैकल्पिक बनाया गया है. इसकी वजह, टाइमिंग अटैक से जुड़ी समस्याएं हैं. Chrome टीम का मानना है कि टाइमस्टैंप क्वेरी को क्वांटाइज़ करने से, सटीक जानकारी और सुरक्षा के बीच बेहतर समझौता किया जा सकता है. ऐसा इसलिए, क्योंकि इससे रिज़ॉल्यूशन को 100 माइक्रोसेकंड तक कम किया जा सकता है. issue dawn:1800 देखें.

Chrome में, उपयोगकर्ता chrome://flags/#enable-webgpu-developer-features पर "WebGPU Developer Features" फ़्लैग को चालू करके, टाइमस्टैंप क्वांटाइज़ेशन की सुविधा बंद कर सकते हैं. ध्यान दें कि सिर्फ़ इस फ़्लैग से, "timestamp-query" सुविधा चालू नहीं होती. इसे लागू करने की सुविधा अब भी एक्सपेरिमेंट के तौर पर उपलब्ध है. इसलिए, chrome://flags/#enable-unsafe-webgpu पर "Unsafe WebGPU Support" फ़्लैग की ज़रूरत होती है.

Dawn में, "timestamp_quantization" नाम का एक नया डिवाइस टॉगल जोड़ा गया है. यह डिफ़ॉल्ट रूप से चालू होता है. यहां दिए गए स्निपेट में बताया गया है कि डिवाइस का अनुरोध करते समय, टाइमस्टैंप के क्वानटाइज़ेशन के बिना, एक्सपेरिमेंट के तौर पर उपलब्ध "timestamp-query" सुविधा को कैसे चालू किया जाता है.

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);

समय-समय पर साफ़-सफ़ाई करने की सुविधाएं

"timestamp-query-inside-passes" एक्सपेरिमेंटल सुविधा का नाम बदलकर "chromium-experimental-timestamp-query-inside-passes" कर दिया गया है. इससे डेवलपर को यह साफ़ तौर पर पता चलेगा कि यह सुविधा एक्सपेरिमेंटल है और फ़िलहाल, सिर्फ़ Chromium पर आधारित ब्राउज़र में उपलब्ध है. issue dawn:1193 देखें.

"पाइपलाइन-स्टैटिस्टिक्स-क्वेरी" सुविधा को हटा दिया गया है. यह सुविधा एक्सपेरिमेंट के तौर पर उपलब्ध थी और इसे पूरी तरह से लागू नहीं किया गया था. अब इस पर काम नहीं किया जा रहा है. issue chromium:1177506 देखें.

इसमें सिर्फ़ कुछ मुख्य हाइलाइट शामिल हैं. कमिट की पूरी सूची देखें.

WebGPU में नया क्या है

WebGPU में नया क्या है सीरीज़ में शामिल सभी विषयों की सूची.

Chrome 140

Chrome 139

Chrome 138

Chrome 137

Chrome 136

Chrome 135

Chrome 134

Chrome 133

Chrome 132

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