การกระจายงาน WebGL Compute Shader: เจาะลึกการกำหนด Thread ของ GPU

Compute shaders ใน WebGL นำเสนอวิธีที่มีประสิทธิภาพในการใช้ประโยชน์จากความสามารถในการประมวลผลแบบขนานของ GPU สำหรับงานประมวลผลทั่วไป (GPGPU) โดยตรงภายในเว็บเบราว์เซอร์ การทำความเข้าใจวิธีการกระจายงานไปยัง GPU threads แต่ละรายการเป็นสิ่งสำคัญสำหรับการเขียน compute kernels ที่มีประสิทธิภาพและมีประสิทธิภาพสูง บทความนี้ให้การสำรวจที่ครอบคลุมเกี่ยวกับการกระจายงานใน WebGL compute shaders ซึ่งครอบคลุมแนวคิดพื้นฐาน กลยุทธ์การกำหนด thread และเทคนิคการเพิ่มประสิทธิภาพ

ทำความเข้าใจโมเดลการ Execution ของ Compute Shader

ก่อนที่จะเจาะลึกลงไปในการกระจายงาน มาสร้างรากฐานโดยทำความเข้าใจโมเดลการ execution ของ compute shader ใน WebGL โมเดลนี้เป็นแบบลำดับชั้น ประกอบด้วยส่วนประกอบสำคัญหลายประการ:

• Compute Shader: โปรแกรมที่ดำเนินการบน GPU ซึ่งมีตรรกะสำหรับการคำนวณแบบขนาน
• Workgroup: ชุดของ work items ที่ execute ร่วมกันและสามารถแชร์ข้อมูลผ่าน shared local memory คิดว่านี่เป็นทีมงานที่ execute ส่วนหนึ่งของงานโดยรวม
• Work Item: อินสแตนซ์แต่ละรายการของ compute shader ซึ่งแสดงถึง GPU thread เดียว แต่ละ work item execute โค้ด shader เดียวกัน แต่ดำเนินการกับข้อมูลที่อาจแตกต่างกัน นี่คือคนงานแต่ละคนในทีม
• Global Invocation ID: ตัวระบุที่ไม่ซ้ำกันสำหรับแต่ละ work item ทั่วทั้ง compute dispatch
• Local Invocation ID: ตัวระบุที่ไม่ซ้ำกันสำหรับแต่ละ work item ภายใน workgroup ของตัวเอง
• Workgroup ID: ตัวระบุที่ไม่ซ้ำกันสำหรับแต่ละ workgroup ใน compute dispatch

เมื่อคุณ dispatch compute shader คุณจะระบุขนาดของ workgroup grid กริดนี้กำหนดจำนวน workgroups ที่จะถูกสร้างขึ้น และจำนวน work items ที่แต่ละ workgroup จะมี ตัวอย่างเช่น การ dispatch dispatchCompute(16, 8, 4) จะสร้างกริด 3 มิติของ workgroups ที่มีขนาด 16x8x4 จากนั้นแต่ละ workgroup จะถูก populate ด้วยจำนวน work items ที่กำหนดไว้ล่วงหน้า

การกำหนดค่า Workgroup Size

Workgroup size ถูกกำหนดไว้ในซอร์สโค้ด compute shader โดยใช้ qualifier layout:

            layout (local_size_x = 8, local_size_y = 8, local_size_z = 1) in;
            

              
                Copy
              
            
          

การประกาศนี้ระบุว่าแต่ละ workgroup จะมี 8 * 8 * 1 = 64 work items ค่าสำหรับ local_size_x, local_size_y และ local_size_z ต้องเป็น constant expressions และโดยทั่วไปจะเป็นเลขยกกำลังของ 2 Workgroup size สูงสุดขึ้นอยู่กับฮาร์ดแวร์และสามารถ query ได้โดยใช้ gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_INVOCATIONS) นอกจากนี้ ยังมีข้อจำกัดเกี่ยวกับขนาดแต่ละมิติของ workgroup ที่สามารถ query ได้โดยใช้ gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_SIZE) ซึ่งจะส่งกลับอาร์เรย์ของตัวเลขสามตัวที่แสดงถึงขนาดสูงสุดสำหรับมิติ X, Y และ Z ตามลำดับ

ตัวอย่าง: การค้นหา Workgroup Size สูงสุด

            const maxWorkGroupInvocations = gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_INVOCATIONS);
const maxWorkGroupSize = gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_SIZE);

console.log("Maximum workgroup invocations: ", maxWorkGroupInvocations);
console.log("Maximum workgroup size: ", maxWorkGroupSize); // Output: [1024, 1024, 64]

            

              
                Copy
              
            
          

การเลือก workgroup size ที่เหมาะสมเป็นสิ่งสำคัญสำหรับประสิทธิภาพ Workgroups ขนาดเล็กอาจใช้ประโยชน์จาก parallelism ของ GPU ได้ไม่เต็มที่ ในขณะที่ workgroups ขนาดใหญ่อาจเกินข้อจำกัดของฮาร์ดแวร์ หรือนำไปสู่รูปแบบการเข้าถึงหน่วยความจำที่ไม่มีประสิทธิภาพ บ่อยครั้ง ต้องมีการทดลองเพื่อกำหนด workgroup size ที่เหมาะสมที่สุดสำหรับ compute kernel เฉพาะและฮาร์ดแวร์เป้าหมาย จุดเริ่มต้นที่ดีคือการทดลองกับ workgroup sizes ที่เป็นเลขยกกำลังของสอง (เช่น 4, 8, 16, 32, 64) และวิเคราะห์ผลกระทบต่อประสิทธิภาพ

การกำหนด GPU Thread และ Global Invocation ID

เมื่อ compute shader ถูก dispatch การ implementation ของ WebGL มีหน้าที่รับผิดชอบในการกำหนดแต่ละ work item ให้กับ GPU thread ที่เฉพาะเจาะจง แต่ละ work item จะถูกระบุอย่างไม่ซ้ำกันโดย Global Invocation ID ซึ่งเป็นเวกเตอร์ 3 มิติที่แสดงถึงตำแหน่งภายในกริด compute dispatch ทั้งหมด ID นี้สามารถเข้าถึงได้ภายใน compute shader โดยใช้ตัวแปร GLSL ที่สร้างไว้ในตัว gl_GlobalInvocationID

gl_GlobalInvocationID คำนวณจาก gl_WorkGroupID และ gl_LocalInvocationID โดยใช้สูตรต่อไปนี้:

            gl_GlobalInvocationID = gl_WorkGroupID * gl_WorkGroupSize + gl_LocalInvocationID;
            

              
                Copy
              
            
          

โดยที่ gl_WorkGroupSize คือ workgroup size ที่ระบุใน qualifier layout สูตรนี้เน้นความสัมพันธ์ระหว่าง workgroup grid และ work items แต่ละรายการ แต่ละ workgroup จะได้รับการกำหนด ID ที่ไม่ซ้ำกัน (gl_WorkGroupID) และแต่ละ work item ภายใน workgroup นั้นจะได้รับการกำหนด local ID ที่ไม่ซ้ำกัน (gl_LocalInvocationID) จากนั้น global ID จะถูกคำนวณโดยการรวม ID ทั้งสองนี้

ตัวอย่าง: การเข้าถึง Global Invocation ID

            #version 450

layout (local_size_x = 8, local_size_y = 8, local_size_z = 1) in;

layout (binding = 0) buffer DataBuffer {
    float data[];
} outputData;

void main() {
    uint index = gl_GlobalInvocationID.x + gl_GlobalInvocationID.y * gl_NumWorkGroups.x * gl_WorkGroupSize.x;
    outputData.data[index] = float(index);
}
            

              
                Copy
              
            
          

ในตัวอย่างนี้ แต่ละ work item จะคำนวณดัชนีของตัวเองลงในบัฟเฟอร์ outputData โดยใช้ gl_GlobalInvocationID นี่เป็นรูปแบบทั่วไปสำหรับการกระจายงานในชุดข้อมูลขนาดใหญ่ บรรทัด `uint index = gl_GlobalInvocationID.x + gl_GlobalInvocationID.y * gl_NumWorkGroups.x * gl_WorkGroupSize.x;` เป็นสิ่งสำคัญ มาทำลายมันลง: * `gl_GlobalInvocationID.x` ให้พิกัด x ของ work item ใน global grid * `gl_GlobalInvocationID.y` ให้พิกัด y ของ work item ใน global grid * `gl_NumWorkGroups.x` ให้จำนวน workgroups ทั้งหมดในมิติ x * `gl_WorkGroupSize.x` ให้จำนวน work items ในมิติ x ของแต่ละ workgroup ร่วมกัน ค่าเหล่านี้ช่วยให้แต่ละ work item สามารถคำนวณดัชนีที่ไม่ซ้ำกันของตัวเองภายในอาร์เรย์ข้อมูลเอาต์พุตที่ถูกทำให้แบนได้ หากคุณกำลังทำงานกับโครงสร้างข้อมูล 3 มิติ คุณจะต้องรวม `gl_GlobalInvocationID.z`, `gl_NumWorkGroups.y`, `gl_WorkGroupSize.y`, `gl_NumWorkGroups.z` และ `gl_WorkGroupSize.z` เข้าในการคำนวณดัชนีด้วย

Memory Access Patterns และ Coalesced Memory Access

วิธีที่ work items เข้าถึงหน่วยความจำสามารถส่งผลกระทบอย่างมากต่อประสิทธิภาพ ตามหลักการแล้ว work items ภายใน workgroup ควรเข้าถึงตำแหน่งหน่วยความจำที่อยู่ติดกัน สิ่งนี้เรียกว่า coalesced memory access และช่วยให้ GPU สามารถดึงข้อมูลใน chunk ขนาดใหญ่ได้อย่างมีประสิทธิภาพ เมื่อการเข้าถึงหน่วยความจำกระจัดกระจายหรือไม่ต่อเนื่อง GPU อาจต้องทำธุรกรรมหน่วยความจำขนาดเล็กหลายรายการ ซึ่งอาจนำไปสู่คอขวดด้านประสิทธิภาพ

เพื่อให้บรรลุ coalesced memory access สิ่งสำคัญคือต้องพิจารณาอย่างรอบคอบเกี่ยวกับ layout ของข้อมูลในหน่วยความจำ และวิธีที่ work items ถูกกำหนดให้กับองค์ประกอบข้อมูล ตัวอย่างเช่น เมื่อประมวลผลภาพ 2 มิติ การกำหนด work items ให้กับพิกเซลที่อยู่ติดกันในแถวเดียวกันสามารถนำไปสู่ coalesced memory access ได้

ตัวอย่าง: Coalesced Memory Access สำหรับการประมวลผลภาพ

            #version 450

layout (local_size_x = 16, local_size_y = 16, local_size_z = 1) in;

layout (binding = 0) uniform sampler2D inputImage;
layout (binding = 1) writeonly uniform image2D outputImage;

void main() {
    ivec2 pixelCoord = ivec2(gl_GlobalInvocationID.xy);
    vec4 pixelColor = texture(inputImage, vec2(pixelCoord) / textureSize(inputImage, 0));

    // Perform some image processing operation (e.g., grayscale conversion)
    float gray = dot(pixelColor.rgb, vec3(0.299, 0.587, 0.114));
    vec4 outputColor = vec4(gray, gray, gray, pixelColor.a);

    imageStore(outputImage, pixelCoord, outputColor);
}
            

              
                Copy
              
            
          

ในตัวอย่างนี้ แต่ละ work item จะประมวลผลพิกเซลเดียวในภาพ เนื่องจาก workgroup size คือ 16x16 work items ที่อยู่ติดกันใน workgroup เดียวกันจะประมวลผลพิกเซลที่อยู่ติดกันในแถวเดียวกัน สิ่งนี้ส่งเสริม coalesced memory access เมื่ออ่านจาก inputImage และเขียนไปยัง outputImage

อย่างไรก็ตาม ลองพิจารณาว่าจะเกิดอะไรขึ้นหากคุณสลับเปลี่ยนข้อมูลภาพ หรือหากคุณเข้าถึงพิกเซลในลำดับ column-major แทนที่จะเป็นลำดับ row-major คุณอาจเห็นประสิทธิภาพที่ลดลงอย่างมาก เนื่องจาก work items ที่อยู่ติดกันจะเข้าถึงตำแหน่งหน่วยความจำที่ไม่ต่อเนื่องกัน

Shared Local Memory

Shared local memory หรือที่เรียกว่า local shared memory (LSM) เป็น region หน่วยความจำขนาดเล็กและรวดเร็วที่แชร์โดย work items ทั้งหมดภายใน workgroup สามารถใช้เพื่อปรับปรุงประสิทธิภาพโดยการแคชข้อมูลที่เข้าถึงบ่อย หรือโดยการอำนวยความสะดวกในการสื่อสารระหว่าง work items ภายใน workgroup เดียวกัน Shared local memory ถูกประกาศโดยใช้คีย์เวิร์ด shared ใน GLSL

ตัวอย่าง: การใช้ Shared Local Memory สำหรับการ Data Reduction

            #version 450

layout (local_size_x = 64, local_size_y = 1, local_size_z = 1) in;

layout (binding = 0) buffer InputBuffer {
    float inputData[];
} inputBuffer;

layout (binding = 1) buffer OutputBuffer {
    float outputData[];
} outputBuffer;

shared float localSum[gl_WorkGroupSize.x];

void main() {
    uint localId = gl_LocalInvocationID.x;
    uint globalId = gl_GlobalInvocationID.x;

    localSum[localId] = inputBuffer.inputData[globalId];

    barrier(); // Wait for all work items to write to shared memory

    // Perform reduction within the workgroup
    for (uint i = gl_WorkGroupSize.x / 2; i > 0; i /= 2) {
        if (localId < i) {
            localSum[localId] += localSum[localId + i];
        }
        barrier(); // Wait for all work items to complete the reduction step
    }

    // Write the final sum to the output buffer
    if (localId == 0) {
        outputBuffer.outputData[gl_WorkGroupID.x] = localSum[0];
    }
}
            

              
                Copy