WebGPU (Chrome 155-156) में नया क्या है

WGSL fragment_depth एक्सटेंशन

ज्यामिति-आधारित रेंडर पास में, अर्ली-Z ऑप्टिमाइज़ेशन, डेवलपर के लिए सबसे मददगार होते हैं. ये परफ़ॉर्मेंस को काफ़ी बेहतर बनाते हैं. इसके लिए, ये जीपीयू को महंगे फ़्रैगमेंट शेडर चलाने से पहले, छिपे हुए पिक्सल को खारिज करने की अनुमति देते हैं. अगर रास्टराइज़ की गई डेप्थ, डेप्थ टेस्ट में पास नहीं होती है, तो जीपीयू, फ़्रैगमेंट शेडर को पूरी तरह से छोड़ देता है. हालांकि, इसके लिए ज़रूरी है कि शेडर का कोई अन्य खराब असर न हो.

अगर आपको यह जानना है कि हार्डवेयर इसे कैसे मैनेज करता है, तो एमजेपी ने अर्ली-ज़ेड को कब बंद करना चाहिए? पर एक बेहतरीन लेख लिखा है.

कस्टम डेप्थ मैनिपुलेशन काफ़ी काम का है. हालांकि, फ़्रैगमेंट शेडर में ऐसा करने पर, आपको कुछ छिपे हुए शुल्क देने पड़ सकते हैं. फ़्रैगमेंट शेडर में @builtin(frag_depth) को लिखने से, आम तौर पर ड्राइवर को पूरे ड्रॉ कॉल के लिए, इन अर्ली-Z ऑप्टिमाइज़ेशन को बंद करना पड़ता है. ऐसा इसलिए होता है, क्योंकि ड्राइवर ह्यूरिस्टिक इस बात की गारंटी नहीं दे सकते कि शेडर के कैलकुलेट किए गए आउटपुट की डेप्थ, रास्टराइज़र से इंटरपोलेट की गई डेप्थ से मैच करती है.

परफ़ॉर्मेंस में आई इस कमी को दूर करने के लिए, WGSL एक्सटेंशन fragment_depth आपको @builtin(frag_depth) पर less या greater डेप्थ मोड का नाम तय करने की सुविधा देता है. इससे साफ़ तौर पर पता चलता है कि लिखी गई डेप्थ की तुलना, इंटरपोलेट की गई डेप्थ से कैसे की जाती है. इससे जीपीयू, अर्ली-Z ऑप्टिमाइज़ेशन को सुरक्षित तरीके से लागू कर पाता है.

इस लैंग्वेज एक्सटेंशन को JavaScript में navigator.gpu.wgslLanguageFeatures का इस्तेमाल करके, सुविधा के तौर पर पहचाना जा सकता है. हमारा सुझाव है कि आप अपने WGSL शेडर कोड के सबसे ऊपर, requires fragment_depth; के साथ, पोर्टेबिलिटी न होने की संभावना का सिग्नल देने के लिए, requires-directive का इस्तेमाल करें. नीचे दिया गया उदाहरण और शिप करने का इंटेंट देखें.

if (!navigator.gpu.wgslLanguageFeatures.has("fragment_depth")) {
  throw new Error(`WGSL fragment depth is not available`);
}

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

const shaderModule = device.createShaderModule({ code: `
  requires fragment_depth;

  @fragment
  fn main() -> @builtin(frag_depth, less) f32 {
    // Explicitly states that the output fragment depth is less than early-Z depth,
    // allowing the GPU to safely preserve early-Z optimizations.
    return 0.0f;
  }`,
});

टेक्सचर कंप्रेस करने की सुविधा अलाइन नहीं है

"texture-compression-unaligned" जीपीयू सुविधा की मदद से, कंप्रेस किए गए ऐसे टेक्सचर बनाए जा सकते हैं जिनके डाइमेंशन, ब्लॉक साइज़ के पूर्णांक गुणज नहीं होते. जैसे, BC, ETC2, और ASTC फ़ॉर्मैट के लिए 4x4. पहले, WebGPU के लिए यह ज़रूरी था कि टेक्सचर के साइज़, इन ब्लॉक की सीमाओं के मुताबिक हों. इस सुविधा की मदद से, टेक्सचर को ब्लॉक अलाइनमेंट में फ़िट करने के लिए, पैडिंग या स्केल करने की ज़रूरत नहीं पड़ती. इससे ओरिजनल कंप्रेशन फ़िडेलिटी बनी रहती है और स्केलिंग डिस्टॉर्शन नहीं होता. शिप करने का मकसद देखें.

यहां दिया गया कोड स्निपेट यह जांच करता है कि अडैप्टर, टेक्सचर कंप्रेशन अनअलाइन की सुविधा के साथ काम करता है या नहीं. अगर यह सुविधा उपलब्ध है, तो वह इस सुविधा के साथ काम करने वाले डिवाइस का अनुरोध करता है.

const adapter = await navigator.gpu.requestAdapter();
if (!adapter.features.has("texture-compression-unaligned")) {
  throw new Error("Texture compression unaligned support is not available");
}
// Explicitly request texture compression unaligned support.
const device = await adapter.requestDevice({
  requiredFeatures: ["texture-compression-unaligned"],
});

इस सुविधा, स्पेसिफ़िकेशन, और सीटीएस पर काम करने के लिए, spark.js के बाहरी योगदानकर्ता इग्नासियो कास्टान्यो को बहुत-बहुत धन्यवाद!

srgb-linear और display-p3-linear कलर स्पेस

"srgb-linear" और "display-p3-linear" जैसे पहले से तय कलर स्पेस की मदद से, WebGPU कैनवस कॉन्टेक्स्ट को अब सीधे तौर पर एक्सटेंडेड-रेंज लीनियर कलर स्पेस में रेंडर किया जा सकता है. इससे वाइड-गैमट डिसप्ले को सपोर्ट किया जा सकता है. ये कलर स्पेस, पिक्सल वैल्यू और फ़िज़िकल ल्यूमिनेंस के बीच लीनियर रिलेशनशिप बनाए रखते हैं. इस वजह से, ये गेम में फ़िज़िकल लाइट रेंडरिंग के साथ-साथ, एंटी-एलियासिंग, इंटरपोलेशन, और डेसिमेशन जैसे स्पेशल प्रोसेसिंग टास्क के लिए भी बेहतरीन हैं. intent to ship और Particles (HDR) sample PR #574 देखें.

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

const canvas = document.querySelector("canvas");
const context = canvas.getContext("webgpu");

context.configure({
  device,
  format: "rgba16float",
  colorSpace: "display-p3-linear",
});

अतिरिक्त snorm10-10-10-2 वर्टेक्स फ़ॉर्मैट

"snorm10-10-10-2" वर्टेक्स फ़ॉर्मैट, 32-बिट का एक पैक किया गया फ़ॉर्मैट है. इसमें चार साइन की गई नॉर्मलाइज़ की गई वैल्यू होती हैं: तीन 10-बिट कॉम्पोनेंट (r, g, b) और एक 2-बिट कॉम्पोनेंट (a). इस फ़ॉर्मैट की मदद से, एट्रिब्यूट को बेहतर तरीके से सेव किया जा सकता है. जैसे, अतिरिक्त 2-बिट स्केलर वाले 3D नॉर्मल वेक्टर या अलाइनमेंट फ़्लैग. इससे मेमोरी बैंडविड्थ की बचत होती है. spec PR 6491 देखें.

NVIDIA के लिए Linux पर f16 की सुविधा

"shader-f16" सुविधा का इस्तेमाल करना ज़रूरी नहीं है. यह WGSL में 16-बिट फ़्लोटिंग-पॉइंट वैल्यू के लिए सहायता उपलब्ध कराती है. अब यह सुविधा, NVIDIA के जीपीयू ड्राइवर के नए वर्शन के लिए Linux पर उपलब्ध है. issue chromium:42251215 देखें.

Dawn के अपडेट

अब WGPUAdapterPropertiesD3D स्ट्रक्चर का इस्तेमाल करके, किसी जीपीयू अडैप्टर के लिए, मौजूदा DXGIAdapter के LUID के बारे में क्वेरी की जा सकती है. chromium:562849566 से जुड़ी समस्या देखें.

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

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

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

Chrome 155-156

Chrome 153-154

Chrome 151-152

Chrome का वर्शन 149-150

Chrome 147-148

Chrome का वर्शन 146

Chrome का वर्शन 145

Chrome का वर्शन 144

Chrome का वर्शन 143

Chrome का वर्शन 142

Chrome का वर्शन 141

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