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

WGSL fragment_depth एक्सटेंशन

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

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

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

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

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

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" GPU सुविधा की मदद से, कंप्रेस किए गए ऐसे टेक्सचर बनाए जा सकते हैं जिनके डाइमेंशन, ब्लॉक साइज़ के पूर्णांक गुणक नहीं होते. जैसे, 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"],
});

इस सुविधा को उपलब्ध कराने के लिए, बाहरी योगदानकर्ता इग्नासिओ कास्टानो का बहुत-बहुत धन्यवाद!

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

पहले से तय किए गए "srgb-linear" और "display-p3-linear" कलर स्पेस को जोड़ने के बाद, WebGPU कैनवस कॉन्टेक्स्ट अब सीधे तौर पर एक्सटेंडेड-रेंज वाले लीनियर कलर स्पेस में रेंडर कर सकता है. इससे वाइड-गैमट डिसप्ले को सपोर्ट किया जा सकेगा. इन कलर स्पेस में, पिक्सल वैल्यू और फ़िज़िकल ल्यूमिनेंस के बीच लीनियर संबंध होता है. इस वजह से, ये गेम में फ़िज़िकल लाइट रेंडरिंग के साथ-साथ, एंटी-एलियासिंग, इंटरपोलेशन, और डेसिमेशन जैसे स्पेशल प्रोसेसिंग टास्क के लिए सबसे सही होते हैं. शिपिंग का इरादा और Particles (HDR) का सैंपल पीआर #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). इस फ़ॉर्मैट की मदद से, एट्रिब्यूट को असरदार तरीके से सेव किया जा सकता है. जैसे, 3D नॉर्मल वेक्टर को अतिरिक्त 2-बिट स्केलर या अलाइनमेंट फ़्लैग के साथ सेव किया जा सकता है. इससे मेमोरी बैंडविड्थ को सेव करने में मदद मिलती है. स्पेसिफ़िकेशन पीआर 6491 देखें.

NVIDIA के लिए Linux पर f16 का इस्तेमाल करने की सुविधा

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

सूरज निकलने के समय के अपडेट

अब WGPUAdapterPropertiesD3D स्ट्रक्चर का इस्तेमाल करके, किसी दिए गए GPU अडैप्टर के लिए, DXGIAdapter के LUID के बारे में क्वेरी की जा सकती है. issue 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