Разпределение на работата в WebGL Compute Shader: Задълбочен поглед върху присвояването на нишки на GPU

Compute shaders в WebGL предлагат мощен начин да се използват възможностите за паралелна обработка на GPU за изчисления с общо предназначение (GPGPU) директно в уеб браузър. Разбирането на това как работата се разпределя към отделните GPU нишки е от решаващо значение за писането на ефективни и високопроизводителни compute kernels. Тази статия предоставя изчерпателно изследване на разпределението на работата в WebGL compute shaders, обхващайки основните концепции, стратегии за присвояване на нишки и техники за оптимизация.

Разбиране на модела на изпълнение на Compute Shader

Преди да се потопим в разпределението на работата, нека да установим основа, като разберем модела на изпълнение на compute shader в WebGL. Този модел е йерархичен, състоящ се от няколко ключови компонента:

• Compute Shader: Програмата, изпълнявана на GPU, съдържаща логиката за паралелни изчисления.
• Workgroup: Колекция от работни елементи, които се изпълняват заедно и могат да споделят данни чрез споделена локална памет. Мислете за това като за екип от работници, изпълняващи част от цялостната задача.
• Work Item: Отделен екземпляр на compute shader, представляващ единична GPU нишка. Всеки работен елемент изпълнява един и същ код на шейдъра, но оперира с потенциално различни данни. Това е отделният работник в екипа.
• Global Invocation ID: Уникален идентификатор за всеки работен елемент в цялото compute dispatch.
• Local Invocation ID: Уникален идентификатор за всеки работен елемент в рамките на неговата работна група.
• Workgroup ID: Уникален идентификатор за всяка работна група в compute dispatch.

Когато изпратите compute shader, вие посочвате размерите на workgroup grid. Тази мрежа определя колко работни групи ще бъдат създадени и колко работни елементи ще съдържа всяка работна група. Например, dispatch на dispatchCompute(16, 8, 4) ще създаде 3D мрежа от работни групи с размери 16x8x4. Всяка от тези работни групи след това се попълва с предварително определен брой работни елементи.

Конфигуриране на размера на работната група

Размерът на работната група се определя в изходния код на compute shader, като се използва квалификаторът layout:

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

              
                Copy
              
            
          

Тази декларация посочва, че всяка работна група ще съдържа 8 * 8 * 1 = 64 работни елемента. Стойностите за local_size_x, local_size_y и local_size_z трябва да бъдат константни изрази и обикновено са степени на 2. Максималният размер на работната група зависи от хардуера и може да бъде заявен с помощта на gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_INVOCATIONS). Освен това, има ограничения върху индивидуалните размери на работна група, които могат да бъдат заявени с помощта на gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_SIZE), който връща масив от три числа, представляващи максималния размер за X, Y и Z размерите съответно.

Пример: Намиране на максимален размер на работна група

            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
              
            
          

Изборът на подходящ размер на работната група е от решаващо значение за производителността. По-малките работни групи може да не използват напълно паралелизма на GPU, докато по-големите работни групи могат да надвишат хардуерните ограничения или да доведат до неефективни модели на достъп до паметта. Често е необходим експеримент, за да се определи оптималният размер на работната група за конкретно compute kernel и целевия хардуер. Добра отправна точка е да експериментирате с размери на работната група, които са степени на две (напр. 4, 8, 16, 32, 64) и да анализирате тяхното въздействие върху производителността.

Присвояване на нишки на GPU и Global Invocation ID

Когато се изпрати compute shader, WebGL имплементацията е отговорна за присвояването на всеки работен елемент към определена GPU нишка. Всеки работен елемент е уникално идентифициран от своя Global Invocation ID, който е 3D вектор, който представлява неговата позиция в цялата compute dispatch grid. До този ID може да се получи достъп в рамките на compute shader, като се използва вградената GLSL променлива gl_GlobalInvocationID.

gl_GlobalInvocationID се изчислява от gl_WorkGroupID и gl_LocalInvocationID, като се използва следната формула:

            gl_GlobalInvocationID = gl_WorkGroupID * gl_WorkGroupSize + gl_LocalInvocationID;
            

              
                Copy
              
            
          

Където gl_WorkGroupSize е размерът на работната група, посочен в квалификатора layout. Тази формула подчертава връзката между workgroup grid и отделните работни елементи. На всяка работна група се присвоява уникален ID (gl_WorkGroupID), а на всеки работен елемент в рамките на тази работна група се присвоява уникален локален ID (gl_LocalInvocationID). Глобалният 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
              
            
          

В този пример всеки работен елемент изчислява своя индекс в буфера outputData, като използва gl_GlobalInvocationID. Това е често срещан модел за разпределяне на работа в голям набор от данни. Редът `uint index = gl_GlobalInvocationID.x + gl_GlobalInvocationID.y * gl_NumWorkGroups.x * gl_WorkGroupSize.x;` е от решаващо значение. Нека го разбием: * `gl_GlobalInvocationID.x` предоставя x-координатата на работния елемент в глобалната мрежа. * `gl_GlobalInvocationID.y` предоставя y-координатата на работния елемент в глобалната мрежа. * `gl_NumWorkGroups.x` предоставя общия брой работни групи в x-измерението. * `gl_WorkGroupSize.x` предоставя броя на работните елементи в x-измерението на всяка работна група. Заедно тези стойности позволяват на всеки работен елемент да изчисли своя уникален индекс в рамките на сплескания масив от изходни данни. Ако работите с 3D структура от данни, ще трябва да включите `gl_GlobalInvocationID.z`, `gl_NumWorkGroups.y`, `gl_WorkGroupSize.y`, `gl_NumWorkGroups.z` и `gl_WorkGroupSize.z` в изчислението на индекса.

Модели на достъп до паметта и обединен достъп до паметта

Начинът, по който работните елементи имат достъп до паметта, може значително да повлияе на производителността. В идеалния случай работните елементи в рамките на работна група трябва да имат достъп до съседни местоположения в паметта. Това е известно като обединен достъп до паметта и позволява на GPU ефективно да извлича данни на големи парчета. Когато достъпът до паметта е разпръснат или не е съседен, GPU може да се наложи да извърши множество по-малки транзакции с паметта, което може да доведе до затруднения в производителността.

За да се постигне обединен достъп до паметта, е важно внимателно да се обмисли оформлението на данните в паметта и начина, по който работните елементи се присвояват на елементи от данни. Например, при обработка на 2D изображение, присвояването на работни елементи на съседни пиксели в един и същ ред може да доведе до обединен достъп до паметта.

Пример: Обединен достъп до паметта за обработка на изображения

            #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
              
            
          

В този пример всеки работен елемент обработва един пиксел в изображението. Тъй като размерът на работната група е 16x16, съседните работни елементи в една и съща работна група ще обработват съседни пиксели в един и същ ред. Това насърчава обединения достъп до паметта при четене от inputImage и записване в outputImage.

Обаче помислете какво би се случило, ако транспонирате данните за изображението или ако имате достъп до пикселите в ред по колони, вместо ред по редове. Вероятно ще видите значително намалена производителност, тъй като съседните работни елементи ще имат достъп до несвързани местоположения в паметта.

Споделена локална памет

Споделената локална памет, известна още като локална споделена памет (LSM), е малък, бърз регион от паметта, който се споделя от всички работни елементи в рамките на работна група. Може да се използва за подобряване на производителността чрез кеширане на често достъпни данни или чрез улесняване на комуникацията между работните елементи в рамките на една и съща работна група. Споделената локална памет се декларира с помощта на ключовата дума shared в GLSL.

Пример: Използване на споделена локална памет за намаляване на данни

            #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