Foundations — ROCm - OpenCL alternatives

6.2.15 · D1 · Hardware › GPU Architecture › ROCm - OpenCL alternatives

Parent note ROCm / OpenCL alternatives padhne se pehle, tumhe usmein aane wala har word aur symbol bilkul zero se samajhna hoga. Yahi is page ka kaam hai. Hum shuru karte hain "GPU aakhir kar kya raha hai" se aur khatam karte hain exact formula global_id = group_id × local_size + local_id par.

1. GPU asal mein kya karta hai (picture ke saath)

Figure dekho. Left side mein ek bada square = ek CPU core, ek to-do list par ek step at a time kaam karta hua. Right side mein chhote squares ka grid = GPU cores, har square ek hi waqt "apne do numbers add karo" kar raha hai. Yeh picture hi wajah hai ki baaki sab kuch exist karta hai: us grid ko control karne ke liye humein ek language chahiye.

Is topic ko yeh word kyun chahiye? Kyunki ROCm, OpenCL aur CUDA sab bas alag-alag spelling hain "yeh mera kernel hai, please ise million workers par chalao" ke liye.

2. Host aur Device — do alag computers

Figure mein ek patli pipe se jude do boxes hain. Host box mein tumhara data h_A mein hai (h = host). Device box mein uski copy d_A mein hai (d = device). Pipe unke beech ki slow cable hai — yahi wajah hai ki parent note baar baar cudaMemcpy / hipMemcpy / clEnqueueWriteBuffer call karta hai: GPU ke kuch karne se pehle data ko us pipe se physically ship karna padta hai, aur baad mein jawab wapas ship karna padta hai.

3. Million workers ko naam dena — IDs

Agar har worker ek hi kernel chalata hai, toh worker #504 ko kaise pata chalega ki woh 504th pair add kare aur 1st nahin? Har worker ko ek unique number diya jaata hai.

(0) aur .x dono ka matlab "x-direction" hai. Grid 1-D, 2-D ya 3-D ho sakta hai (jaise workers ki ek line, sheet, ya cube), isliye hum har direction ko alag index karte hain.

4. Workers ko group karna — Work-Groups aur NDRange

Ek million workers ki flat list kyun nahin? Kyunki hardware physically unhe fixed-size bundles mein chalata hai: NVIDIA mein warps of 32, AMD mein wavefronts of 64. Machine se match karne ke liye, hum grid ko equal work-groups mein kaatte hain.

Figure parent note ke "Work-Item Execution Model" formula ki poori kahani hai. Left se right padho:

• Poori amber strip = NDRange (jise Global Work Size bhi kehte hain), total workers $G_x$.
• Yeh equal size ke cyan blocks mein kata hua hai = work-groups, har ek mein $L_x$ workers hain (Local Work Size).
• Ek highlighted worker dikhata hai ki uske teen IDs kaise related hain.

Yeh last formula kyun? Yeh plain chunk-numbering hai. Agar groups mein $L_x=64$ workers hain, toh worker global number $=(\text{kaun sa group})\times 64+(\text{group ke andar position})$. Figure mein highlighted worker dekho: woh group 1 mein hai, local position 2 par, toh uska global number hai $1\times 64+2=66$.

5. Data kahan rehta hai — memory hierarchy

Ek worker har byte tak equally fast nahin pahunch sakta. Topic ke __global / __local / __private keywords batate hain ki memory kitni door hai.

Yahi wajah hai ki parent note baar baar batata hai ki AMD mein 64 KB LDS per compute unit hai jabki NVIDIA mein 48–128 KB shared memory per SM hai: abstraction (__local) ek hi word hai, lekin uske peeche ka size vendor se vendor alag hai — aur tumhare portable code ko koi ek number assume nahin karna chahiye.

6. Translation layers exist kyun hain — IR aur JIT

Har vendor ka GPU apni private machine language mein baat karta hai (NVIDIA: PTX, AMD: GCN/RDNA ISA). Tum apna kernel har ek ke liye dobara nahin likhna chahte.

Parent jo pipeline dikhata hai — $\text{Source}\to \text{LLVM IR}\to \text{Device ISA}\to \text{Execution}$ — bilkul yahi hai: shared vocabulary mein ek baar likho, IR + JIT ko jo bhi hardware tumhare paas hai uske liye fit karne do. Woh ek sentence hi poori wajah hai ki ROCm aur OpenCL vendor lock-in se bahar nikal sakte hain.

7. Yeh pieces topic ko kaise feed karte hain

Equipment checklist

Right side cover karo aur parent note par jaane se pehle har ek ka jawab do.