WebGPU-তে নতুন কি আছে (Chrome 120)

ফ্রাঁসোয়া বোফোর্ট
François Beaufort
GitHub

WGSL-এ ১৬-বিট ফ্লোটিং-পয়েন্ট মানের জন্য সমর্থন

WGSL-এ, f16 টাইপ হলো IEEE-754 বাইনারি১৬ (হাফ প্রিসিশন) ফরম্যাটের ১৬-বিট ফ্লোটিং-পয়েন্ট ভ্যালুর একটি সেট। এর মানে হলো, এটি একটি ফ্লোটিং-পয়েন্ট সংখ্যাকে উপস্থাপন করার জন্য ১৬ বিট ব্যবহার করে, যেখানে প্রচলিত সিঙ্গেল-প্রিসিশন ফ্লোটিং-পয়েন্ট ( f32 ) ৩২ বিট ব্যবহার করে। এই ছোট আকারের কারণে পারফরম্যান্সে উল্লেখযোগ্য উন্নতি হতে পারে, বিশেষ করে যখন বিপুল পরিমাণ ডেটা প্রসেস করা হয়।

তুলনার জন্য, একটি Apple M1 Pro ডিভাইসে, WebLLM চ্যাট ডেমোতে ব্যবহৃত Llama2 7B মডেলের f16 ইমপ্লিমেন্টেশনটি f32 ইমপ্লিমেন্টেশনের চেয়ে উল্লেখযোগ্যভাবে দ্রুততর, যেখানে প্রিফিল স্পিডে ২৮% এবং ডিকোডিং স্পিডে ৪১% উন্নতি দেখা যায়, যা নিম্নলিখিত স্ক্রিনশটগুলিতে দেখানো হয়েছে।

f32 এবং f16 Llama2 7B মডেল ব্যবহার করে WebLLM চ্যাট ডেমোর স্ক্রিনশট।
f32 (বামে) এবং f16 (ডানে) Llama2 7B মডেল ব্যবহার করে WebLLM চ্যাট ডেমো।

সব GPU ১৬-বিট ফ্লোটিং-পয়েন্ট ভ্যালু সাপোর্ট করে না। যখন একটি GPUAdapter এ "shader-f16" ফিচারটি উপলব্ধ থাকে, তখন আপনি এই ফিচারসহ একটি GPUDevice জন্য অনুরোধ করতে পারেন এবং একটি WGSL শেডার মডিউল তৈরি করতে পারেন যা হাফ-প্রিসিশন ফ্লোটিং-পয়েন্ট টাইপ f16 এর সুবিধা গ্রহণ করে। এই টাইপটি WGSL শেডার মডিউলে ব্যবহারের জন্য তখনই বৈধ হবে, যদি আপনি enable f16; ` কমান্ডের মাধ্যমে f16 WGSL এক্সটেনশনটি সক্রিয় করেন। অন্যথায়, `createShaderModule()` একটি ভ্যালিডেশন এরর তৈরি করবে। নিম্নলিখিত মিনিমাল উদাহরণ এবং `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...

নিম্নলিখিত কোড স্নিপেটে দেখানো অনুযায়ী, "shader-f16" ফিচার সাপোর্টের উপর নির্ভর করে একটি alias মাধ্যমে WGSL শেডার মডিউল কোডে f16 এবং f32 উভয় প্রকারকেই সমর্থন করা সম্ভব।

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

সীমা ছাড়িয়ে যান

ডিফল্টরূপে, সমস্ত কালার অ্যাটাচমেন্ট জুড়ে রেন্ডার পাইপলাইন আউটপুট ডেটার একটি স্যাম্পল (পিক্সেল বা সাবপিক্সেল) ধারণ করার জন্য প্রয়োজনীয় সর্বোচ্চ বাইট হলো ৩২ বাইট। এখন maxColorAttachmentBytesPerSample লিমিট ব্যবহার করে ৬৪ বাইট পর্যন্ত অনুরোধ করা সম্ভব। নিম্নলিখিত উদাহরণ এবং ইস্যু 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 সীমা বৃদ্ধি করা হয়েছে। বিস্তারিত জানতে dawn:1448 ইস্যুটি দেখুন।

প্রতিটি শেডার স্টেজের জন্য, একটি পাইপলাইন লেআউট জুড়ে বাইন্ড গ্রুপ লেআউট এন্ট্রিগুলির মধ্যে স্টোরেজ বাফারের সর্বোচ্চ সংখ্যা ডিফল্টরূপে ৮। এখন maxStorageBuffersPerShaderStage লিমিট ব্যবহার করে ১০টি পর্যন্ত অনুরোধ করা সম্ভব। ইস্যু dawn:2159 দেখুন।

একটি নতুন maxBindGroupsPlusVertexBuffers সীমা যোগ করা হয়েছে। এটি সর্বোচ্চ ইনডেক্সের নীচের যেকোনো খালি স্লট গণনা করে, একই সাথে ব্যবহৃত বাইন্ড গ্রুপ এবং ভার্টেক্স বাফার স্লটের সর্বাধিক সংখ্যা নিয়ে গঠিত। এর ডিফল্ট মান হলো ২৪। ইস্যু dawn:1849 দেখুন।

গভীরতা-স্টেনসিল অবস্থার পরিবর্তন

ডেভেলপার অভিজ্ঞতা উন্নত করার জন্য, depth-stencil স্টেটের depthWriteEnabled এবং depthCompare অ্যাট্রিবিউটগুলো এখন থেকে আর সবসময় প্রয়োজন হবে না: depthWriteEnabled শুধুমাত্র depth যুক্ত ফরম্যাটের জন্য প্রয়োজন, এবং depth যুক্ত ফরম্যাট যদি একেবারেই ব্যবহার না করা হয়, তবে depthCompare প্রয়োজন নেই। ইস্যু dawn:2132 দেখুন।

অ্যাডাপ্টার তথ্যের আপডেট

যখন ব্যবহারকারী chrome://flags/#enable-webgpu-developer-features " ফ্ল্যাগটি সক্রিয় করেছেন, তখন requestAdapterInfo() কল করার সময় নন-স্ট্যান্ডার্ড type এবং backend অ্যাডাপ্টার তথ্য অ্যাট্রিবিউটগুলো এখন উপলব্ধ হবে। type হতে পারে "discrete GPU", "integrated GPU", "CPU", অথবা "unknown"। backend হলো "WebGPU", "D3D11", "D3D12", "metal", "vulkan", "openGL", "openGLES", অথবা "null"। ইস্যু dawn:2112 এবং ইস্যু dawn:2107 দেখুন।

https://webgpureport.org-এর স্ক্রিনশট, যেখানে ব্যাকএন্ড এবং অ্যাডাপ্টার তথ্য টাইপ করার সুবিধা রয়েছে।
অ্যাডাপ্টারের তথ্য, ব্যাকএন্ড এবং ধরন https://webgpureport.org -এ দেখানো হয়েছে।

requestAdapterInfo() ফাংশনের ঐচ্ছিক unmaskHints লিস্ট প্যারামিটারটি সরিয়ে ফেলা হয়েছে। ইস্যু dawn:1427 দেখুন।

টাইমস্ট্যাম্প কোয়েরি কোয়ান্টাইজেশন

টাইমস্ট্যাম্প কোয়েরি অ্যাপ্লিকেশনগুলোকে জিপিইউ কমান্ডের নির্বাহের সময় ন্যানোসেকেন্ড নির্ভুলতায় পরিমাপ করতে দেয়। তবে, টাইমিং অ্যাটাকের উদ্বেগের কারণে ওয়েবজিপিইউ স্পেসিফিকেশন টাইমস্ট্যাম্প কোয়েরিকে ঐচ্ছিক রেখেছে। ক্রোম টিম মনে করে যে, রেজোলিউশন ১০০ মাইক্রোসেকেন্ডে কমিয়ে আনার মাধ্যমে টাইমস্ট্যাম্প কোয়েরিকে কোয়ান্টাইজ করা হলে তা নির্ভুলতা এবং নিরাপত্তার মধ্যে একটি ভালো ভারসাম্য প্রদান করে। ইস্যু dawn:1800 দেখুন।

ক্রোমে, ব্যবহারকারীরা chrome://flags/#enable-webgpu-developer-features "WebGPU Developer Features" ফ্ল্যাগটি সক্রিয় করে টাইমস্ট্যাম্প কোয়ান্টাইজেশন নিষ্ক্রিয় করতে পারেন। উল্লেখ্য যে, শুধুমাত্র এই ফ্ল্যাগটি "timestamp-query" ফিচারটি সক্রিয় করে না। এর বাস্তবায়ন এখনও পরীক্ষামূলক পর্যায়ে রয়েছে এবং তাই chrome://flags/#enable-unsafe-webgpu -এ থাকা "Unsafe WebGPU Support" ফ্ল্যাগটি প্রয়োজন।

ডন-এ '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' রাখা হয়েছে, যাতে ডেভেলপারদের কাছে এটি স্পষ্ট হয় যে এই ফিচারটি পরীক্ষামূলক এবং আপাতত শুধুমাত্র ক্রোমিয়াম-ভিত্তিক ব্রাউজারগুলিতেই উপলব্ধ। ইস্যু dawn:1193 দেখুন।

পরীক্ষামূলক 'পাইপলাইন-স্ট্যাটিস্টিকস-কোয়েরি' ফিচারটি, যা কেবল আংশিকভাবে বাস্তবায়িত হয়েছিল, তা সরিয়ে ফেলা হয়েছে কারণ এটির আর উন্নয়ন করা হচ্ছে না। ইস্যু chromium:1177506 দেখুন।

এখানে কেবল কয়েকটি মূল বিষয় তুলে ধরা হয়েছে। কমিটগুলোর বিস্তারিত তালিকাটি দেখুন।

WebGPU-তে নতুন কী আছে

'What's New in WebGPU' সিরিজে যা যা আলোচনা করা হয়েছে, তার একটি তালিকা।

ক্রোম ১৪৭-১৪৮

ক্রোম ১৪৬

ক্রোম ১৪৫

ক্রোম ১৪৪

ক্রোম ১৪৩

ক্রোম ১৪২

ক্রোম ১৪১

ক্রোম ১৪০

ক্রোম ১৩৯

ক্রোম ১৩৮

ক্রোম ১৩৭

ক্রোম ১৩৬

ক্রোম ১৩৫

ক্রোম ১৩৪

ক্রোম ১৩৩

ক্রোম ১৩২

ক্রোম ১৩১

ক্রোম ১৩০

ক্রোম ১২৯

ক্রোম ১২৮

ক্রোম ১২৭

ক্রোম ১২৬

ক্রোম ১২৫

ক্রোম ১২৪

ক্রোম ১২৩

ক্রোম ১২২

ক্রোম ১২১

ক্রোম ১২০

ক্রোম ১১৯

ক্রোম ১১৮

ক্রোম ১১৭

ক্রোম ১১৬

ক্রোম ১১৫

ক্রোম ১১৪

ক্রোম ১১৩