WebGL থেকে WebGPU-তে স্থানান্তরিত হচ্ছে

আসন্ন WebGPU-তে যাওয়ার মানে শুধু গ্রাফিক্স এপিআই স্যুইচ করার চেয়েও বেশি কিছু। এটি ওয়েব গ্রাফিক্সের ভবিষ্যতের দিকেও একটি পদক্ষেপ। তবে এই স্থানান্তর প্রস্তুতি এবং বোঝার সাথে আরও ভাল হয়ে উঠবে — এবং এই নিবন্ধটি আপনাকে প্রস্তুত করবে।

সবাইকে হ্যালো, আমার নাম দিমিত্রি ইভাশচেঙ্কো এবং আমি MY.GAMES-এর একজন সফটওয়্যার ইঞ্জিনিয়ার। এই নিবন্ধে, আমরা WebGL এবং আসন্ন WebGPU-এর মধ্যে পার্থক্যগুলি নিয়ে আলোচনা করব এবং কীভাবে আপনার প্রকল্পকে মাইগ্রেশনের জন্য প্রস্তুত করবেন তা আমরা ব্যাখ্যা করব৷

বিষয়বস্তু ওভারভিউ

1. WebGL এবং WebGPU এর টাইমলাইন
2. ওয়েবজিপিইউ-এর বর্তমান অবস্থা এবং কী হতে চলেছে
3. উচ্চ-স্তরের ধারণাগত পার্থক্য
4. আরম্ভ ওয়েবজিএল: প্রসঙ্গ মডেল • WebGPU: ডিভাইস মডেল
5. প্রোগ্রাম এবং পাইপলাইন ওয়েবজিএল: প্রোগ্রাম • WebGPU: পাইপলাইন
6. ইউনিফর্ম • WebGL 1-এ ইউনিফর্ম • WebGL 2-এ ইউনিফর্ম • WebGPU-তে ইউনিফর্ম
7. শেডার্স • শেডার ভাষা: GLSL বনাম WGSL • ডেটা প্রকারের তুলনা • কাঠামো • ফাংশন ঘোষণা • অন্তর্নির্মিত ফাংশন • Shader রূপান্তর
8. কনভেনশন পার্থক্য
9. টেক্সচার • ভিউপোর্ট স্পেস • ক্লিপ স্পেস
10. WebGPU টিপস এবং কৌশল • আপনার ব্যবহার করা পাইপলাইনের সংখ্যা কমিয়ে দিন। • আগে থেকেই পাইপলাইন তৈরি করুন • RenderBundles ব্যবহার করুন
11. সারসংক্ষেপ

WebGL এবং WebGPU এর টাইমলাইন

WebGL , অন্যান্য অনেক ওয়েব প্রযুক্তির মতো, এর শিকড় রয়েছে যা অতীতে অনেক দূরে প্রসারিত। WebGPU-এর দিকে অগ্রসর হওয়ার পিছনে গতিশীলতা এবং অনুপ্রেরণা বোঝার জন্য, প্রথমে WebGL বিকাশের ইতিহাসে দ্রুত নজর দেওয়া সহায়ক:

• OpenGL ডেস্কটপ (1993) OpenGL এর ডেস্কটপ সংস্করণ আত্মপ্রকাশ করে।
• WebGL 1.0 (2011) : OpenGL ES 2.0-এর উপর ভিত্তি করে এটি WebGL-এর প্রথম স্থিতিশীল রিলিজ, যেটি নিজেই 2007 সালে চালু হয়েছিল। এটি ওয়েব ডেভেলপারদের অতিরিক্ত প্লাগইনগুলির প্রয়োজন ছাড়াই সরাসরি ব্রাউজারে 3D গ্রাফিক্স ব্যবহার করার ক্ষমতা প্রদান করে।
• WebGL 2.0 (2017) : প্রথম সংস্করণের ছয় বছর পর চালু করা হয়েছে, WebGL 2.0 OpenGL ES 3.0 (2012) এর উপর ভিত্তি করে তৈরি হয়েছিল। এই সংস্করণটি এটির সাথে অনেকগুলি উন্নতি এবং নতুন ক্ষমতা নিয়ে এসেছে, যা ওয়েবে 3D গ্রাফিক্সকে আরও শক্তিশালী করে তুলেছে৷

সাম্প্রতিক বছরগুলিতে, নতুন গ্রাফিক্স এপিআইগুলির প্রতি আগ্রহের বৃদ্ধি ঘটেছে যা বিকাশকারীদের আরও নিয়ন্ত্রণ এবং নমনীয়তা প্রদান করে:

• Vulkan (2016) : Khronos গ্রুপ দ্বারা তৈরি, এই ক্রস-প্ল্যাটফর্ম API হল OpenGL-এর "উত্তরাধিকারী"। ভলকান গ্রাফিক্স হার্ডওয়্যার সংস্থানগুলিতে নিম্ন-স্তরের অ্যাক্সেস সরবরাহ করে, গ্রাফিক্স হার্ডওয়্যারের উপর আরও ভাল নিয়ন্ত্রণ সহ উচ্চ-পারফরম্যান্স অ্যাপ্লিকেশনগুলির জন্য অনুমতি দেয়।
• D3D12 (2015) : এই API Microsoft দ্বারা তৈরি করা হয়েছে এবং এটি শুধুমাত্র Windows এবং Xbox-এর জন্য। D3D12 হল D3D10/11-এর উত্তরসূরী এবং গ্রাফিক্স রিসোর্সগুলির উপর গভীর নিয়ন্ত্রণ সহ ডেভেলপারদের প্রদান করে।
• মেটাল (2014) : অ্যাপল দ্বারা তৈরি, মেটাল অ্যাপল ডিভাইসের জন্য একটি এক্সক্লুসিভ API। এটি অ্যাপল হার্ডওয়্যারের সর্বোচ্চ কর্মক্ষমতা মাথায় রেখে ডিজাইন করা হয়েছে।

ওয়েবজিপিইউ-এর বর্তমান অবস্থা এবং কী হতে চলেছে

আজ, WebGPU একাধিক প্ল্যাটফর্ম যেমন Windows, Mac, এবং ChromeOS-এ Google Chrome এবং Microsoft Edge ব্রাউজারগুলির মাধ্যমে উপলব্ধ, সংস্করণ 113 দিয়ে শুরু হয়। অদূর ভবিষ্যতে Linux এবং Android-এর জন্য সমর্থন আশা করা হচ্ছে।

এখানে কিছু ইঞ্জিন রয়েছে যা ইতিমধ্যেই WebGPU-এর জন্য সমর্থন করে (বা পরীক্ষামূলক সহায়তা প্রদান করে)

• ব্যাবিলন জেএস : WebGPU এর জন্য সম্পূর্ণ সমর্থন।
• থ্রিজেএস : এই মুহূর্তে পরীক্ষামূলক সমর্থন।
• প্লেক্যানভাস : উন্নয়নে, কিন্তু খুব আশাব্যঞ্জক সম্ভাবনার সাথে।
• ইউনিটি : খুব প্রাথমিক এবং পরীক্ষামূলক WebGPU সমর্থন 2023.2 আলফা সংস্করণে ঘোষণা করা হয়েছিল।
• Cocos ক্রিয়েটর 3.6.2 : অফিসিয়ালি WebGPU সমর্থন করে, এটিকে এই এলাকার অন্যতম অগ্রগামী করে তোলে।
• গঠন : বর্তমানে শুধুমাত্র Windows, macOS এবং ChromeOS-এর জন্য v113+ এ সমর্থিত।

এটি বিবেচনা করে, WebGPU-তে স্থানান্তরিত হওয়া বা অন্ততপক্ষে এই ধরনের পরিবর্তনের জন্য প্রকল্পগুলি প্রস্তুত করা নিকট ভবিষ্যতে একটি সময়োপযোগী পদক্ষেপ বলে মনে হচ্ছে।

উচ্চ-স্তরের ধারণাগত পার্থক্য

আসুন জুম আউট করি এবং প্রারম্ভিকতার সাথে শুরু করে WebGL এবং WebGPU-এর মধ্যে কিছু উচ্চ-স্তরের ধারণাগত পার্থক্য দেখে নেওয়া যাক।

আরম্ভ

গ্রাফিক্স API-এর সাথে কাজ শুরু করার সময়, প্রথম ধাপগুলির মধ্যে একটি হল ইন্টারঅ্যাকশনের জন্য মূল অবজেক্টটি শুরু করা। এই প্রক্রিয়াটি WebGL এবং WebGPU-এর মধ্যে আলাদা, উভয় সিস্টেমের জন্য কিছু বিশেষত্ব সহ।

ওয়েবজিএল: প্রসঙ্গ মডেল

WebGL-এ, এই বস্তুটি "প্রসঙ্গ" নামে পরিচিত, যা মূলত একটি HTML5 ক্যানভাস উপাদানে আঁকার জন্য একটি ইন্টারফেস উপস্থাপন করে। এই প্রসঙ্গ প্রাপ্ত করা বেশ সহজ:

 const gl = canvas.getContext('webgl');

WebGL এর প্রসঙ্গ আসলে একটি নির্দিষ্ট ক্যানভাসের সাথে আবদ্ধ। এর মানে হল যে আপনি যদি একাধিক ক্যানভাসে রেন্ডার করতে চান তবে আপনার একাধিক প্রসঙ্গের প্রয়োজন হবে।

WebGPU: ডিভাইস মডেল

WebGPU "ডিভাইস" নামে একটি নতুন ধারণা চালু করেছে। এই ডিভাইসটি একটি GPU বিমূর্ততা উপস্থাপন করে যার সাথে আপনি ইন্টারঅ্যাক্ট করবেন। প্রারম্ভিক প্রক্রিয়াটি WebGL এর তুলনায় একটু বেশি জটিল, কিন্তু এটি আরও নমনীয়তা প্রদান করে:

 const adapter = await navigator.gpu.requestAdapter(); const device = await adapter.requestDevice(); const context = canvas.getContext('webgpu'); context.configure({ device, format: 'bgra8unorm', });

এই মডেলের সুবিধাগুলির মধ্যে একটি হল যে একটি ডিভাইস একাধিক ক্যানভাসে রেন্ডার করতে পারে এমনকি কোনোটিও নয়। এটি অতিরিক্ত নমনীয়তা প্রদান করে; উদাহরণস্বরূপ, একটি ডিভাইস একাধিক উইন্ডো বা প্রসঙ্গে রেন্ডারিং নিয়ন্ত্রণ করতে পারে।

প্রোগ্রাম এবং পাইপলাইন

WebGL এবং WebGPU গ্রাফিক্স পাইপলাইন পরিচালনা এবং সংগঠিত করার জন্য বিভিন্ন পদ্ধতির প্রতিনিধিত্ব করে।

ওয়েবজিএল: প্রোগ্রাম

ওয়েবজিএল-এ, প্রধান ফোকাস শেডার প্রোগ্রামের উপর। প্রোগ্রামটি শীর্ষবিন্দু এবং ফ্র্যাগমেন্ট শেডারগুলিকে একত্রিত করে, কীভাবে শীর্ষবিন্দুগুলিকে রূপান্তরিত করা উচিত এবং প্রতিটি পিক্সেলকে কীভাবে রঙিন করা উচিত তা নির্ধারণ করে।

 const program = gl.createProgram(); gl.attachShader(program, vertShader); gl.attachShader(program, fragShader); gl.bindAttribLocation(program, 'position', 0); gl.linkProgram(program);

ওয়েবজিএল-এ একটি প্রোগ্রাম তৈরি করার পদক্ষেপ:

1. শেডার্স তৈরি করা : শেডারগুলির জন্য সোর্স কোড লেখা এবং সংকলিত হয়।
2. প্রোগ্রাম তৈরি করা : কম্পাইল করা শেডার্স প্রোগ্রামের সাথে সংযুক্ত এবং তারপর লিঙ্ক করা হয়।
3. প্রোগ্রাম ব্যবহার : রেন্ডারিং আগে প্রোগ্রাম সক্রিয় করা হয়.
4. ডেটা ট্রান্সমিশন : সক্রিয় প্রোগ্রামে ডেটা প্রেরণ করা হয়।

এই প্রক্রিয়াটি নমনীয় গ্রাফিক্স নিয়ন্ত্রণের অনুমতি দেয়, তবে এটি জটিল এবং ত্রুটির প্রবণও হতে পারে, বিশেষত বড় এবং জটিল প্রকল্পগুলির জন্য।

ওয়েবজিপিইউ: পাইপলাইন

WebGPU একটি পৃথক প্রোগ্রামের পরিবর্তে একটি "পাইপলাইন" ধারণা প্রবর্তন করে। এই পাইপলাইনটি শুধুমাত্র শেডার নয়, অন্যান্য তথ্যও একত্রিত করে, যা WebGL-এ রাজ্য হিসেবে প্রতিষ্ঠিত। সুতরাং, WebGPU-তে একটি পাইপলাইন তৈরি করা আরও জটিল দেখায়:

 const pipeline = device.createRenderPipeline({ layout: 'auto', vertex: { module: shaderModule, entryPoint: 'vertexMain', buffers: [{ arrayStride: 12, attributes: [{ shaderLocation: 0, offset: 0, format: 'float32x3' }] }], }, fragment: { module: shaderModule, entryPoint: 'fragmentMain', targets: [{ format, }], }, });

WebGPU-তে একটি পাইপলাইন তৈরি করার পদক্ষেপ:

1. শেডারের সংজ্ঞা : শেডার সোর্স কোড লেখা ও সংকলিত হয়, যেমন WebGL-এ করা হয়।
2. পাইপলাইন তৈরি : শেডার্স এবং অন্যান্য রেন্ডারিং প্যারামিটারগুলি একটি পাইপলাইনে একত্রিত হয়।
3. পাইপলাইন ব্যবহার : রেন্ডার করার আগে পাইপলাইন সক্রিয় করা হয়।

যখন WebGL রেন্ডারিংয়ের প্রতিটি দিককে আলাদা করে, WebGPU একটি একক বস্তুতে আরও দিকগুলিকে এনক্যাপসুলেট করার চেষ্টা করে, সিস্টেমটিকে আরও মডুলার এবং নমনীয় করে তোলে। শেডার এবং রেন্ডারিং স্টেটগুলিকে আলাদাভাবে পরিচালনা করার পরিবর্তে, যেমন WebGL এ করা হয়, WebGPU সবকিছুকে একটি পাইপলাইন অবজেক্টে একত্রিত করে। এটি প্রক্রিয়াটিকে আরও অনুমানযোগ্য এবং ত্রুটির কম প্রবণ করে তোলে:

ইউনিফর্ম

ইউনিফর্ম ভেরিয়েবলগুলি ধ্রুবক ডেটা সরবরাহ করে যা সমস্ত শেডার উদাহরণে উপলব্ধ।

WebGL 1-এ ইউনিফর্ম

বেসিক ওয়েবজিএল-এ, এপিআই কলের মাধ্যমে সরাসরি uniform ভেরিয়েবল সেট করার ক্ষমতা আমাদের আছে।

GLSL :

 uniform vec3 u_LightPos; uniform vec3 u_LightDir; uniform vec3 u_LightColor;

জাভাস্ক্রিপ্ট :

 const location = gl.getUniformLocation(p, "u_LightPos"); gl.uniform3fv(location, [100, 300, 500]);

এই পদ্ধতিটি সহজ, কিন্তু প্রতিটি uniform ভেরিয়েবলের জন্য একাধিক API কল প্রয়োজন।

WebGL 2-এ ইউনিফর্ম

WebGL 2 এর আগমনের সাথে, আমরা এখন uniform ভেরিয়েবলগুলিকে বাফারগুলিতে গোষ্ঠীভুক্ত করার ক্ষমতা পেয়েছি। যদিও আপনি এখনও আলাদা ইউনিফর্ম শেডার ব্যবহার করতে পারেন, তবে একটি ভাল বিকল্প হল ইউনিফর্ম বাফার ব্যবহার করে বিভিন্ন ইউনিফর্মকে একটি বড় কাঠামোতে গ্রুপ করা। তারপরে আপনি এই সমস্ত ইউনিফর্ম ডেটা একবারে GPU-তে পাঠান, যেভাবে আপনি WebGL 1-এ একটি ভার্টেক্স বাফার লোড করতে পারেন। এতে বেশ কিছু কর্মক্ষমতা সুবিধা রয়েছে, যেমন API কল হ্রাস করা এবং আধুনিক GPU কীভাবে কাজ করে তার কাছাকাছি থাকা।

GLSL :

 layout(std140) uniform ub_Params { vec4 u_LightPos; vec4 u_LightDir; vec4 u_LightColor; };

জাভাস্ক্রিপ্ট :

 gl.bindBufferBase(gl.UNIFORM_BUFFER, 1, gl.createBuffer());

WebGL 2 এ একটি বৃহৎ ইউনিফর্ম বাফারের উপসেটগুলিকে আবদ্ধ করতে, আপনি একটি বিশেষ API কল ব্যবহার করতে পারেন যা bindBufferRange নামে পরিচিত। WebGPU-তে, ডায়নামিক ইউনিফর্ম বাফার অফসেট নামে একই রকম কিছু আছে যেখানে আপনি setBindGroup এপিআই কল করার সময় অফসেটের একটি তালিকা পাস করতে পারেন।

WebGPU-তে ইউনিফর্ম

WebGPU আমাদেরকে আরও ভালো পদ্ধতি অফার করে। এই প্রসঙ্গে, পৃথক uniform ভেরিয়েবল আর সমর্থিত নয়, এবং কাজটি একচেটিয়াভাবে uniform বাফারের মাধ্যমে করা হয়।

WGSL :

 [[block]] struct Params { u_LightPos : vec4<f32>; u_LightColor : vec4<f32>; u_LightDirection : vec4<f32>; }; [[group(0), binding(0)]] var<uniform> ub_Params : Params;

জাভাস্ক্রিপ্ট :

 const buffer = device.createBuffer({ usage: GPUBufferUsage.UNIFORM, size: 8 });

আধুনিক জিপিইউ অনেক ছোট ব্লকের পরিবর্তে একটি বড় ব্লকে ডেটা লোড করা পছন্দ করে। প্রতিবার ছোট বাফারগুলিকে পুনরায় তৈরি এবং পুনর্বিন্যাস করার পরিবর্তে, একটি বড় বাফার তৈরি করার এবং বিভিন্ন ড্র কলের জন্য এর বিভিন্ন অংশ ব্যবহার করার কথা বিবেচনা করুন। এই পদ্ধতি উল্লেখযোগ্যভাবে কর্মক্ষমতা বৃদ্ধি করতে পারেন.

WebGL আরও জরুরি, প্রতিটি কলের সাথে বিশ্বব্যাপী অবস্থা রিসেট করা এবং যতটা সম্ভব সহজ হওয়ার চেষ্টা করা। অন্যদিকে, WebGPU-এর লক্ষ্য আরও বেশি অবজেক্ট-ভিত্তিক এবং রিসোর্স পুনঃব্যবহারের উপর দৃষ্টি নিবদ্ধ করা, যা দক্ষতার দিকে নিয়ে যায়।

পদ্ধতির পার্থক্যের কারণে WebGL থেকে WebGPU-তে রূপান্তর করা কঠিন বলে মনে হতে পারে। যাইহোক, একটি মধ্যবর্তী পদক্ষেপ হিসাবে WebGL 2-এ পরিবর্তনের মাধ্যমে শুরু করা আপনার জীবনকে সহজ করতে পারে।

শেডার্স

WebGL থেকে WebGPU-তে স্থানান্তরিত করার জন্য শুধুমাত্র API নয়, শেডারেও পরিবর্তন প্রয়োজন। WGSL স্পেসিফিকেশন আধুনিক GPU-এর জন্য দক্ষতা এবং কর্মক্ষমতা বজায় রেখে এই রূপান্তরটিকে মসৃণ এবং স্বজ্ঞাত করার জন্য ডিজাইন করা হয়েছে।

শেডার ভাষা: GLSL বনাম WGSL

WGSL কে WebGPU এবং নেটিভ গ্রাফিক্স API-এর মধ্যে একটি সেতু হিসেবে ডিজাইন করা হয়েছে। জিএলএসএলের তুলনায়, ডাব্লুজিএসএল একটু বেশি ভার্বোস দেখায়, তবে গঠনটি পরিচিত রয়ে গেছে।

টেক্সচারের জন্য এখানে একটি উদাহরণ শেডার রয়েছে:

GLSL :

 sampler2D myTexture; varying vec2 vTexCoord; void main() { return texture(myTexture, vTexCoord); }

WGSL :

 [[group(0), binding(0)]] var mySampler: sampler; [[group(0), binding(1)]] var myTexture: texture_2d<f32>; [[stage(fragment)]] fn main([[location(0)]] vTexCoord: vec2<f32>) -> [[location(0)]] vec4<f32> { return textureSample(myTexture, mySampler, vTexCoord); } 

ডেটা প্রকারের তুলনা

নীচের টেবিলটি GLSL এবং WGSL-এ মৌলিক এবং ম্যাট্রিক্স ডেটা প্রকারের তুলনা দেখায়:

GLSL থেকে WGSL-এ স্থানান্তর করা কঠোর টাইপিং এবং ডেটা আকারের সুস্পষ্ট সংজ্ঞার আকাঙ্ক্ষা প্রদর্শন করে, যা কোড পাঠযোগ্যতা উন্নত করতে পারে এবং ত্রুটির সম্ভাবনা কমাতে পারে।

কাঠামো

কাঠামো ঘোষণার জন্য সিনট্যাক্সও পরিবর্তিত হয়েছে:

GLSL:

 struct Light { vec3 position; vec4 color; float attenuation; vec3 direction; float innerAngle; float angle; float range; };

WGSL:

 struct Light { position: vec3<f32>, color: vec4<f32>, attenuation: f32, direction: vec3<f32>, innerAngle: f32, angle: f32, range: f32, };

WGSL স্ট্রাকচারে ক্ষেত্র ঘোষণা করার জন্য সুস্পষ্ট সিনট্যাক্স প্রবর্তন করা বৃহত্তর স্বচ্ছতার আকাঙ্ক্ষার উপর জোর দেয় এবং শেডার্সে ডেটা স্ট্রাকচার বোঝার সহজতর করে।

ফাংশন ঘোষণা

GLSL :

 float saturate(float x) { return clamp(x, 0.0, 1.0); }

WGSL :

 fn saturate(x: f32) -> f32 { return clamp(x, 0.0, 1.0); }

WGSL-এ ফাংশনগুলির সিনট্যাক্স পরিবর্তন ঘোষণা এবং রিটার্ন মানগুলির পদ্ধতির একীকরণকে প্রতিফলিত করে, কোডটিকে আরও সামঞ্জস্যপূর্ণ এবং অনুমানযোগ্য করে তোলে।

অন্তর্নির্মিত ফাংশন

WGSL-এ, অনেক অন্তর্নির্মিত GLSL ফাংশনের নাম পরিবর্তন করা হয়েছে বা প্রতিস্থাপন করা হয়েছে। উদাহরণ স্বরূপ:

ডাব্লুজিএসএল-এ অন্তর্নির্মিত ফাংশনগুলির নাম পরিবর্তন করা কেবল তাদের নামগুলিকে সহজ করে না, বরং সেগুলিকে আরও স্বজ্ঞাত করে তোলে, যা অন্যান্য গ্রাফিক্স APIগুলির সাথে পরিচিত ডেভেলপারদের জন্য রূপান্তর প্রক্রিয়াটিকে সহজতর করতে পারে৷

Shader রূপান্তর

যারা তাদের প্রকল্পগুলিকে WebGL থেকে WebGPU-তে রূপান্তর করার পরিকল্পনা করছেন, তাদের জন্য এটা জানা গুরুত্বপূর্ণ যে GLSL কে WGSL-এ স্বয়ংক্রিয়ভাবে রূপান্তর করার জন্য টুল রয়েছে, যেমন **[নাগা](//github.com/gfx-rs/naga /)**, যা GLSL কে WGSL এ রূপান্তর করার জন্য একটি মরিচা লাইব্রেরি। এমনকি WebAssembly এর সাহায্যে এটি আপনার ব্রাউজারে কাজ করতে পারে।

এখানে নাগা সমর্থিত শেষ পয়েন্ট রয়েছে:

কনভেনশন পার্থক্য

টেক্সচার

স্থানান্তরের পরে, আপনি ফ্লিপ করা চিত্রগুলির আকারে একটি বিস্ময়ের সম্মুখীন হতে পারেন৷ যারা কখনও OpenGL থেকে Direct3D (অথবা তদ্বিপরীত) অ্যাপ্লিকেশন পোর্ট করেছেন তারা ইতিমধ্যে এই ক্লাসিক সমস্যার সম্মুখীন হয়েছেন।

OpenGL এবং WebGL এর প্রেক্ষাপটে, টেক্সচারগুলি সাধারণত এমনভাবে লোড করা হয় যে শুরুর পিক্সেলটি নীচের বাম কোণে অনুরূপ। যাইহোক, অনুশীলনে, অনেক ডেভেলপার উপরের বাম কোণ থেকে শুরু করে ছবি লোড করে, যা ফ্লিপ করা চিত্র ত্রুটির দিকে নিয়ে যায়। তবুও, এই ত্রুটিটি অন্যান্য কারণগুলির দ্বারা ক্ষতিপূরণ করা যেতে পারে, শেষ পর্যন্ত সমস্যাটি সমতল করে।

ওপেনজিএল-এর বিপরীতে, ডাইরেক্ট3ডি এবং মেটালের মতো সিস্টেমগুলি ঐতিহ্যগতভাবে টেক্সচারের জন্য শুরুর বিন্দু হিসাবে উপরের-বাম কোণ ব্যবহার করে। এই পদ্ধতিটি অনেক বিকাশকারীদের জন্য সবচেয়ে স্বজ্ঞাত বলে মনে করে, WebGPU-এর নির্মাতারা এই অনুশীলনটি অনুসরণ করার সিদ্ধান্ত নিয়েছেন।

ভিউপোর্ট স্পেস

যদি আপনার WebGL কোড ফ্রেম বাফার থেকে পিক্সেল নির্বাচন করে, তাহলে WebGPU একটি ভিন্ন স্থানাঙ্ক সিস্টেম ব্যবহার করে তার জন্য প্রস্তুত থাকুন। স্থানাঙ্ক সংশোধন করার জন্য আপনাকে একটি সাধারণ "y = 1.0 - y" অপারেশন প্রয়োগ করতে হতে পারে।

ক্লিপ স্পেস

যখন একজন বিকাশকারী এমন একটি সমস্যার সম্মুখীন হয় যেখানে বস্তুগুলি প্রত্যাশিত সময়ের আগে ক্লিপ করা হয় বা অদৃশ্য হয়ে যায়, এটি প্রায়শই গভীরতার ডোমেনের পার্থক্যের সাথে সম্পর্কিত। WebGL এবং WebGPU এর মধ্যে পার্থক্য রয়েছে যে তারা কীভাবে ক্লিপ স্পেসের গভীরতা পরিসীমা নির্ধারণ করে। যখন WebGL -1 থেকে 1 পর্যন্ত একটি পরিসর ব্যবহার করে, WebGPU 0 থেকে 1 পর্যন্ত একটি পরিসর ব্যবহার করে, অন্যান্য গ্রাফিক্স API যেমন Direct3D, Metal, এবং Vulkan এর মতো। অন্যান্য গ্রাফিক্স API-এর সাথে কাজ করার সময় শনাক্ত করা 0 থেকে 1 পর্যন্ত পরিসর ব্যবহার করার বিভিন্ন সুবিধার কারণে এই সিদ্ধান্ত নেওয়া হয়েছে।

আপনার মডেলের অবস্থানগুলিকে ক্লিপ স্পেসে রূপান্তরিত করার প্রধান দায়িত্বটি প্রজেকশন ম্যাট্রিক্সের সাথে রয়েছে। আপনার কোড মানিয়ে নেওয়ার সবচেয়ে সহজ উপায় হল আপনার প্রজেকশন ম্যাট্রিক্স আউটপুট 0 থেকে 1 এর রেঞ্জে ফলাফল নিশ্চিত করা। যারা gl-matrix-এর মতো লাইব্রেরি ব্যবহার করেন তাদের জন্য একটি সহজ সমাধান রয়েছে: perspective ফাংশন ব্যবহার করার পরিবর্তে, আপনি ব্যবহার করতে পারেন perspectiveZO ; অনুরূপ ফাংশন অন্যান্য ম্যাট্রিক্স অপারেশন জন্য উপলব্ধ.

 if (webGPU) { // Creates a matrix for a symetric perspective-view frustum // using left-handed coordinates mat4.perspectiveZO(out, Math.PI / 4, ...); } else { // Creates a matrix for a symetric perspective-view frustum // based on the default handedness and default near // and far clip planes definition. mat4.perspective(out, Math.PI / 4, …); }

যাইহোক, কখনও কখনও আপনার কাছে একটি বিদ্যমান প্রজেকশন ম্যাট্রিক্স থাকতে পারে এবং আপনি এর উত্স পরিবর্তন করতে পারবেন না। এই ক্ষেত্রে, এটিকে 0 থেকে 1 পর্যন্ত পরিসরে রূপান্তর করতে, আপনি আপনার প্রজেকশন ম্যাট্রিক্সকে অন্য একটি ম্যাট্রিক্স দ্বারা প্রাক-গুণ করতে পারেন যা গভীরতার পরিসরকে সংশোধন করে।

WebGPU টিপস এবং কৌশল

এখন, WebGPU এর সাথে কাজ করার জন্য কিছু টিপস এবং কৌশল নিয়ে আলোচনা করা যাক।

আপনি যে পাইপলাইন ব্যবহার করেন তার সংখ্যা কমিয়ে দিন।

আপনি যত বেশি পাইপলাইন ব্যবহার করবেন, তত বেশি স্টেট সুইচিং হবে এবং কর্মক্ষমতা তত কম হবে; আপনার সম্পদ কোথা থেকে এসেছে তার উপর নির্ভর করে এটি তুচ্ছ নাও হতে পারে।

অগ্রিম পাইপলাইন তৈরি করুন

একটি পাইপলাইন তৈরি করা এবং অবিলম্বে এটি ব্যবহার করা কাজ করতে পারে, তবে এটি সুপারিশ করা হয় না। পরিবর্তে, ফাংশন তৈরি করুন যা অবিলম্বে ফিরে আসে এবং একটি ভিন্ন থ্রেডে কাজ শুরু করে। আপনি যখন পাইপলাইন ব্যবহার করেন, তখন এক্সিকিউশন সারিটি মুলতুবি থাকা পাইপলাইন তৈরি শেষ হওয়ার জন্য অপেক্ষা করতে হবে। এর ফলে উল্লেখযোগ্য কর্মক্ষমতা সমস্যা হতে পারে। এটি এড়াতে, পাইপলাইন তৈরি করা এবং প্রথমে এটি ব্যবহার করার মধ্যে কিছু সময় রাখা নিশ্চিত করুন।

অথবা, আরও ভাল, create*PipelineAsync ভেরিয়েন্ট ব্যবহার করুন! প্রতিশ্রুতিটি সমাধান করা হয় যখন পাইপলাইনটি ব্যবহার করার জন্য প্রস্তুত হয়, কোনো স্থবিরতা ছাড়াই।

 device.createComputePipelineAsync({ compute: { module: shaderModule, entryPoint: 'computeMain' } }).then((pipeline) => { const commandEncoder = device.createCommandEncoder(); const passEncoder = commandEncoder.beginComputePass(); passEncoder.setPipeline(pipeline); passEncoder.setBindGroup(0, bindGroup); passEncoder.dispatchWorkgroups(128); passEncoder.end(); device.queue.submit([commandEncoder.finish()]); });

RenderBundles ব্যবহার করুন

রেন্ডার বান্ডেলগুলি পূর্ব-রেকর্ড করা, আংশিক, পুনরায় ব্যবহারযোগ্য রেন্ডার পাস। এগুলিতে বেশিরভাগ রেন্ডারিং কমান্ড থাকতে পারে (ভিউপোর্ট সেট করার মতো জিনিসগুলি ব্যতীত) এবং পরে একটি প্রকৃত রেন্ডার পাসের অংশ হিসাবে "পুনরায় প্লে" করা যেতে পারে।

 const renderPass = encoder.beginRenderPass(descriptor); renderPass.setPipeline(renderPipeline); renderPass.draw(3); renderPass.executeBundles([renderBundle]); renderPass.setPipeline(renderPipeline); renderPass.draw(3); renderPass.end();

রেন্ডার বান্ডিলগুলি নিয়মিত রেন্ডার পাস কমান্ডের পাশাপাশি কার্যকর করা যেতে পারে। প্রতি বান্ডেল এক্সিকিউশনের আগে এবং পরে রেন্ডার পাস স্টেট ডিফল্টে রিসেট করা হয়। এটি প্রাথমিকভাবে অঙ্কনের জাভাস্ক্রিপ্ট ওভারহেড কমাতে করা হয়। পদ্ধতি নির্বিশেষে GPU কর্মক্ষমতা একই থাকে।

সারসংক্ষেপ

WebGPU-তে রূপান্তর মানে শুধু গ্রাফিক্স এপিআই স্যুইচ করার চেয়েও বেশি কিছু। এটি বিভিন্ন গ্রাফিক্স এপিআই থেকে সফল বৈশিষ্ট্য এবং অনুশীলনগুলিকে একত্রিত করে ওয়েব গ্রাফিক্সের ভবিষ্যতের দিকেও একটি পদক্ষেপ। এই স্থানান্তরের জন্য প্রযুক্তিগত এবং দার্শনিক পরিবর্তনগুলির একটি পুঙ্খানুপুঙ্খ বোঝার প্রয়োজন, তবে সুবিধাগুলি উল্লেখযোগ্য।

দরকারী সম্পদ এবং লিঙ্ক:

• Alain Galvan দ্বারা
• ব্র্যান্ডন জোন্স দ্বারা
• WebGL + WebGPU মিটআপ - জুলাই 2023