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

François Beaufort
François Beaufort
GitHub

पब्लिश होने की तारीख: 29 जनवरी, 2025

unorm8x4-bgra और 1-कॉम्पोनेंट वर्टेक्स फ़ॉर्मैट के लिए अतिरिक्त फ़ॉर्मैट

"unorm8x4-bgra" वर्टेक्स फ़ॉर्मैट और एक कॉम्पोनेंट वाले ये वर्टेक्स फ़ॉर्मैट जोड़े गए हैं: "uint8", "sint8", "unorm8", "snorm8", "uint16", "sint16", "unorm16", "snorm16", और "float16". "unorm8x4-bgra" वर्टेक्स फ़ॉर्मैट की मदद से, एक ही शेडर का इस्तेमाल करते हुए BGRA-कोड वाले वर्टेक्स रंगों को लोड करना थोड़ा आसान हो जाता है. इसके अलावा, एक कॉम्पोनेंट वाले वर्टेक्स फ़ॉर्मैट से, सिर्फ़ उस डेटा का अनुरोध किया जा सकता है जिसकी ज़रूरत होती है. इससे पहले, 8 और 16-बिट डेटा टाइप के लिए कम से कम दो बार अनुरोध करना पड़ता था. chromestatus एंट्री और समस्या 376924407 देखें.

अनजान सीमाओं के लिए अनुरोध करने की अनुमति दें, जिनकी वैल्यू तय नहीं की गई है

WebGPU API को बेहतर बनाने के लिए, अब जीपीयू डिवाइस का अनुरोध करते समय, undefined वैल्यू के साथ अज्ञात सीमाओं का अनुरोध किया जा सकता है. यह इस तरह के ऐप्लिकेशन कोड में काम आता है. उदाहरण के लिए, अगर someLimit मौजूद नहीं है, तो adapter.limits.someLimit को undefined के तौर पर इस्तेमाल किया जा सकता है. स्पेक पीआर 4781 देखें.

const adapter = await navigator.gpu.requestAdapter();

const device = await adapter.requestDevice({
  requiredLimits: { someLimit: adapter.limits.someLimit }, // someLimit can be undefined
});

WGSL अलाइनमेंट के नियमों में बदलाव

अब किसी स्ट्रक्ट मेंबर के लिए, अलाइनमेंट की बहुत छोटी वैल्यू नहीं दी जा सकती. ऐसा इसलिए है, क्योंकि अब यह ज़रूरी है कि सभी स्ट्रक्ट के लिए, @align(n), RequiredAlignOf को विभाजित करे. इस बड़े बदलाव से, WGSL भाषा का इस्तेमाल करना आसान हो जाता है. साथ ही, यह Firefox और Safari के साथ ज़्यादा बेहतर तरीके से काम करती है. आपको spec PR में, Tint, Naga, और WebKit कंपाइलर के बीच के अंतर दिखाने वाला सैंपल कोड मिल सकता है.

डिस्कार्ड फ़ंक्शन का इस्तेमाल करके WGSL की परफ़ॉर्मेंस को बेहतर बनाना

जटिल स्क्रीन-स्पेस रिफ़्लेक्शन (एसएसआर) इफ़ेक्ट रेंडर करते समय, परफ़ॉर्मेंस में काफ़ी गिरावट देखी गई. इसलिए, डिस्कार्ड स्टेटमेंट को लागू करने के लिए, प्लैटफ़ॉर्म से मिले सिमैंटिक का इस्तेमाल किया जाता है. इससे, उपलब्ध होने पर हेल्पर इनवोकेशन को डिमोट किया जा सकता है. इससे, discard का इस्तेमाल करने वाले शेडर की परफ़ॉर्मेंस बेहतर होती है. समस्या 372714384 देखें.

बाहरी टेक्सचर के लिए, VideoFrame के displaySize का इस्तेमाल करें

WebGPU स्पेसिफ़िकेशन के मुताबिक, VideoFrame इंपोर्ट करते समय displayWidth और displayHeight डाइमेंशन का इस्तेमाल, GPUExternalTexture के साइज़ के तौर पर किया जाना चाहिए. हालांकि, दिखने वाले साइज़ का इस्तेमाल गलत तरीके से किया गया था. इस वजह से, GPUExternalTexture पर textureLoad() का इस्तेमाल करते समय समस्याएं आ रही थीं. अब यह समस्या ठीक कर दी गई है. समस्या 377574981 देखें.

copyExternalImageToTexture का इस्तेमाल करके, नॉन-डिफ़ॉल्ट ओरिएंटेशन वाली इमेज मैनेज करना

copyExternalImageToTexture() GPUQueue तरीके का इस्तेमाल, किसी इमेज या कैनवस के कॉन्टेंट को टेक्सचर में कॉपी करने के लिए किया जाता है. अब यह गैर-डिफ़ॉल्ट ओरिएंटेशन वाली इमेज को सही तरीके से हैंडल करता है. पहले ऐसा नहीं होता था, जब सोर्स imageOrientation "from-image" वाला ImageBitmap या गैर-डिफ़ॉल्ट ओरिएंटेशन वाली इमेज होता था. समस्या 384858956 देखें.

डेवलपर के अनुभव को बेहतर बनाना

ऐसा हो सकता है कि adapter.limits में ज़्यादा वैल्यू दिखने पर आपको हैरानी हो. हालांकि, आपको यह पता नहीं होता कि जीपीयू डिवाइस का अनुरोध करते समय, आपको ज़्यादा सीमा के लिए साफ़ तौर पर अनुरोध करना होता है. ऐसा न करने पर, बाद में आपको अचानक सीमाएं लागू होने की समस्या का सामना करना पड़ सकता है.

आपकी मदद करने के लिए, गड़बड़ी के मैसेज में कुछ सुझाव जोड़े गए हैं. इनमें बताया गया है कि requestDevice() को कॉल करते समय, requiredLimits में कोई सीमा तय नहीं की गई थी. इसलिए, आपको ज़्यादा सीमा का अनुरोध करना होगा. समस्या 42240683 देखें.

नीचे दिए गए उदाहरण में, DevTools कंसोल में लॉग की गई गड़बड़ी का बेहतर मैसेज दिखाया गया है. यह मैसेज, डिवाइस की डिफ़ॉल्ट बफ़र साइज़ की सीमा से ज़्यादा साइज़ वाला GPU बफ़र बनाते समय दिखता है.

const adapter = await navigator.gpu.requestAdapter();
const device = await adapter.requestDevice();

// Create a GPU buffer with a size exceeding the default max buffer size device limit.
const size = device.limits.maxBufferSize + 1;
const buffer = device.createBuffer({ size, usage: GPUBufferUsage.MAP_READ });

device.queue.submit([]);

⚠️ Buffer size (268435457) exceeds the max buffer size limit (268435456). This adapter supports a higher maxBufferSize of 4294967296, which can be specified in requiredLimits when calling requestDevice(). Limits differ by hardware, so always check the adapter limits prior to requesting a higher limit.
- While calling [Device].CreateBuffer([BufferDescriptor]).

featureLevel के साथ कंपैटिबिलिटी मोड चालू करना

एक्सपेरिमेंट के तौर पर उपलब्ध कंपैटिबिलिटी मोड में, जीपीयू अडैप्टर का अनुरोध किया जा सकता है. इसके लिए, स्टैंडर्ड featureLevel विकल्प को "compatibility" पर सेट करें. सिर्फ़ "core" (डिफ़ॉल्ट) और "compatibility" स्ट्रिंग की वैल्यू इस्तेमाल की जा सकती हैं. यहां दिया गया उदाहरण और स्पेसिफ़िकेशन पीआर 4897 देखें.

// Request a GPU adapter in compatibility mode
const adapter = await navigator.gpu.requestAdapter({ featureLevel: "compatibility" });

if (adapter?.featureLevel === "compatibility") {
  // Any devices created from this adapter will support only compatibility mode.
}

featureLevel विकल्प, नॉन-स्टैंडर्ड compatibilityMode विकल्प की जगह लेता है. वहीं, नॉन-स्टैंडर्ड featureLevel एट्रिब्यूट, isCompatibilityMode एट्रिब्यूट की जगह लेता है.

यह सुविधा अभी एक्सपेरिमेंट के तौर पर उपलब्ध है. इसलिए, आपको फ़िलहाल Chrome को chrome://flags/#enable-unsafe-webgpu पर "Unsafe WebGPU Support" फ़्लैग के साथ चलाना होगा. इसे आज़माने के लिए, webgpureport.org पर जाएं.

एक्सपेरिमेंट के तौर पर शुरू की गई सबग्रुप की सुविधाओं को हटाना

एक्सपेरिमेंट के तौर पर उपलब्ध सबग्रुप की "chromium-experimental-subgroups" और "chromium-experimental-subgroup-uniform-control-flow" सुविधाएं बंद कर दी गई हैं. समस्या 377868468 देखें.

सबग्रुप के साथ एक्सपेरिमेंट करते समय, अब आपको "subgroups" एक्सपेरिमेंटल सुविधा की ज़रूरत होगी. "subgroups-f16" एक्सपेरिमेंट के तौर पर उपलब्ध सुविधा अब काम नहीं करती. इसे जल्द ही हटा दिया जाएगा. जब आपका ऐप्लिकेशन, "shader-f16" और "subgroups", दोनों सुविधाओं का अनुरोध करता है, तब सबग्रुप के साथ f16 वैल्यू का इस्तेमाल किया जा सकता है. समस्या 380244620 देखें.

maxInterStageShaderComponents सीमा को बंद करना

maxInterStageShaderComponents की सीमा को इन वजहों से बंद कर दिया गया है:

  • maxInterStageShaderVariables के साथ रिडंडेंसी: यह सीमा पहले से ही इसी तरह के मकसद को पूरा करती है. इससे, शेडर स्टेज के बीच पास किए गए डेटा की मात्रा को कंट्रोल किया जाता है.
  • मामूली अंतर: इन दोनों सीमाओं को कैलकुलेट करने के तरीके में थोड़ा अंतर है. हालांकि, ये अंतर मामूली हैं और इन्हें maxInterStageShaderVariables की सीमा के अंदर मैनेज किया जा सकता है.
  • आसान बनाना: maxInterStageShaderComponents को हटाने से, शेडर इंटरफ़ेस आसान हो जाता है. साथ ही, डेवलपर के लिए इसे इस्तेमाल करना आसान हो जाता है. इन बदलावों के बाद, कारोबारियों या कंपनियों को दो अलग-अलग सीमाओं को मैनेज करने की ज़रूरत नहीं होगी. वे maxInterStageShaderVariables पर ज़्यादा ध्यान दे पाएंगे.

हमारा लक्ष्य, इसे Chrome 135 में पूरी तरह से हटाना है. बंद करने का इरादा और समस्या 364338810 देखें.

सुबह के अपडेट

wgpu::Device::GetAdapterInfo(adapterInfo) की मदद से, wgpu::Device से सीधे तौर पर अडैप्टर की जानकारी पाई जा सकती है. समस्या 376600838 देखें.

WGPUProgrammableStageDescriptor स्ट्रक्चर का नाम बदलकर WGPUComputeState कर दिया गया है, ताकि कंप्यूट स्टेट को वर्टेक्स और फ़्रैगमेंट स्टेट के साथ अलाइन किया जा सके. समस्या 379059434 देखें.

wgpu::VertexStepMode::VertexBufferNotUsed enum वैल्यू को हटा दिया गया है. अब ऐसे वर्टेक्स बफ़र लेआउट को {.stepMode=wgpu::VertexStepMode::Undefined, .attributeCount=0} से दिखाया जा सकता है जिसका इस्तेमाल नहीं किया जाता. समस्या 383147017 देखें.

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

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