WebGL Compute Shader Arbetsfördelning: En Djupdykning i GPU-Trådtilldelning

Compute shaders i WebGL erbjuder ett kraftfullt sätt att utnyttja GPU:ns parallella bearbetningsförmåga för allmänna beräkningsuppgifter (GPGPU) direkt i en webbläsare. Att förstå hur arbete fördelas till enskilda GPU-trådar är avgörande för att skriva effektiva och högpresterande compute kernels. Den här artikeln ger en omfattande undersökning av arbetsfördelning i WebGL compute shaders, som täcker de underliggande koncepten, trådtilldelningsstrategier och optimeringstekniker.

Förstå Compute Shader Exekveringsmodell

Innan vi dyker ner i arbetsfördelning, låt oss etablera en grund genom att förstå compute shader exekveringsmodellen i WebGL. Den här modellen är hierarkisk och består av flera nyckelkomponenter:

• Compute Shader: Programmet som körs på GPU:n, som innehåller logiken för parallell beräkning.
• Arbetsgrupp: En samling av arbetsobjekt som körs tillsammans och kan dela data via delat lokalt minne. Tänk på detta som ett team av arbetare som utför en del av den övergripande uppgiften.
• Arbetsobjekt: En individuell instans av compute shader, som representerar en enda GPU-tråd. Varje arbetsobjekt kör samma shaderkod men arbetar med potentiellt olika data. Detta är den enskilda arbetaren i teamet.
• Globalt Anrops-ID: En unik identifierare för varje arbetsobjekt över hela compute dispatch.
• Lokalt Anrops-ID: En unik identifierare för varje arbetsobjekt inom sin arbetsgrupp.
• Arbetsgrupps-ID: En unik identifierare för varje arbetsgrupp i compute dispatch.

När du skickar en compute shader anger du dimensionerna för arbetsgruppsnätet. Det här nätet definierar hur många arbetsgrupper som kommer att skapas och hur många arbetsobjekt varje arbetsgrupp kommer att innehålla. Till exempel kommer en dispatch av dispatchCompute(16, 8, 4) att skapa ett 3D-nät av arbetsgrupper med dimensionerna 16x8x4. Var och en av dessa arbetsgrupper fylls sedan med ett fördefinierat antal arbetsobjekt.

Konfigurera Arbetsgruppsstorlek

Arbetsgruppsstorleken definieras i compute shader källkoden med hjälp av layout qualifier:

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

              
                Copy
              
            
          

Den här deklarationen anger att varje arbetsgrupp kommer att innehålla 8 * 8 * 1 = 64 arbetsobjekt. Värdena för local_size_x, local_size_y och local_size_z måste vara konstanta uttryck och är vanligtvis potenser av 2. Den maximala arbetsgruppsstorleken är hårdvaruberoende och kan frågas med gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_INVOCATIONS). Dessutom finns det gränser för de enskilda dimensionerna av en arbetsgrupp som kan frågas med gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_SIZE) vilket returnerar en array med tre tal som representerar den maximala storleken för X-, Y- och Z-dimensionerna respektive.

Exempel: Hitta Maximal Arbetsgruppsstorlek

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

console.log("Maximalt antal arbetsgruppsanrop: ", maxWorkGroupInvocations);
console.log("Maximal arbetsgruppsstorlek: ", maxWorkGroupSize); // Output: [1024, 1024, 64]

            

              
                Copy
              
            
          

Att välja en lämplig arbetsgruppsstorlek är avgörande för prestanda. Mindre arbetsgrupper kanske inte fullt utnyttjar GPU:ns parallellism, medan större arbetsgrupper kan överskrida hårdvarubegränsningar eller leda till ineffektiva minnesåtkomstmönster. Ofta krävs experiment för att bestämma den optimala arbetsgruppsstorleken för en specifik compute kernel och målhårdvara. En bra utgångspunkt är att experimentera med arbetsgruppsstorlekar som är potenser av två (t.ex. 4, 8, 16, 32, 64) och analysera deras inverkan på prestanda.

GPU-Trådtilldelning och Globalt Anrops-ID

När en compute shader skickas är WebGL-implementationen ansvarig för att tilldela varje arbetsobjekt till en specifik GPU-tråd. Varje arbetsobjekt identifieras unikt av sitt Globala Anrops-ID, vilket är en 3D-vektor som representerar dess position inom hela compute dispatch-nätet. Detta ID kan nås inom compute shader med hjälp av den inbyggda GLSL-variabeln gl_GlobalInvocationID.

gl_GlobalInvocationID beräknas från gl_WorkGroupID och gl_LocalInvocationID med hjälp av följande formel:

            gl_GlobalInvocationID = gl_WorkGroupID * gl_WorkGroupSize + gl_LocalInvocationID;
            

              
                Copy
              
            
          

Där gl_WorkGroupSize är arbetsgruppsstorleken som specificeras i layout qualifier. Den här formeln belyser förhållandet mellan arbetsgruppsnätet och de individuella arbetsobjekten. Varje arbetsgrupp tilldelas ett unikt ID (gl_WorkGroupID), och varje arbetsobjekt inom den arbetsgruppen tilldelas ett unikt lokalt ID (gl_LocalInvocationID). Det globala ID:t beräknas sedan genom att kombinera dessa två ID:n.

Exempel: Åtkomst till Globalt Anrops-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
              
            
          

I det här exemplet beräknar varje arbetsobjekt sitt index i outputData bufferten med hjälp av gl_GlobalInvocationID. Detta är ett vanligt mönster för att fördela arbete över en stor datamängd. Raden `uint index = gl_GlobalInvocationID.x + gl_GlobalInvocationID.y * gl_NumWorkGroups.x * gl_WorkGroupSize.x;` är avgörande. Låt oss bryta ner den: * `gl_GlobalInvocationID.x` ger x-koordinaten för arbetsobjektet i det globala nätet. * `gl_GlobalInvocationID.y` ger y-koordinaten för arbetsobjektet i det globala nätet. * `gl_NumWorkGroups.x` ger det totala antalet arbetsgrupper i x-dimensionen. * `gl_WorkGroupSize.x` ger antalet arbetsobjekt i x-dimensionen för varje arbetsgrupp. Tillsammans tillåter dessa värden varje arbetsobjekt att beräkna sitt unika index inom den plattade output data arrayen. Om du arbetade med en 3D-datastruktur skulle du behöva inkludera `gl_GlobalInvocationID.z`, `gl_NumWorkGroups.y`, `gl_WorkGroupSize.y`, `gl_NumWorkGroups.z` och `gl_WorkGroupSize.z` i indexberäkningen också.

Minnesåtkomstmönster och Sammanfogad Minnesåtkomst

Sättet som arbetsobjekt kommer åt minnet kan påverka prestandan avsevärt. Helst bör arbetsobjekt inom en arbetsgrupp komma åt sammanhängande minnesplatser. Detta kallas sammanfogad minnesåtkomst, och det tillåter GPU:n att effektivt hämta data i stora bitar. När minnesåtkomst är utspridd eller icke-sammanhängande kan GPU:n behöva utföra flera mindre minnestransaktioner, vilket kan leda till prestandaflaskhalsar.

För att uppnå sammanfogad minnesåtkomst är det viktigt att noggrant överväga layouten av data i minnet och hur arbetsobjekt tilldelas till dataelement. Till exempel, när man bearbetar en 2D-bild, kan tilldelning av arbetsobjekt till intilliggande pixlar i samma rad leda till sammanfogad minnesåtkomst.

Exempel: Sammanfogad Minnesåtkomst för Bildbehandling

            #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));

    // Utför någon bildbehandlingsoperation (t.ex. gråskaleomvandling)
    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
              
            
          

I det här exemplet bearbetar varje arbetsobjekt en enda pixel i bilden. Eftersom arbetsgruppsstorleken är 16x16 kommer intilliggande arbetsobjekt i samma arbetsgrupp att bearbeta intilliggande pixlar i samma rad. Detta främjar sammanfogad minnesåtkomst vid läsning från inputImage och skrivning till outputImage.

Men tänk på vad som skulle hända om du transponerade bilddatan, eller om du kom åt pixlar i en kolumn-major ordning istället för en rad-major ordning. Du skulle sannolikt se avsevärt minskad prestanda eftersom intilliggande arbetsobjekt skulle komma åt icke-sammanhängande minnesplatser.

Delat Lokalt Minne

Delat lokalt minne, även känt som lokalt delat minne (LSM), är en liten, snabb minnesregion som delas av alla arbetsobjekt inom en arbetsgrupp. Det kan användas för att förbättra prestandan genom att cachelagra frekvent åtkomstd data eller genom att underlätta kommunikation mellan arbetsobjekt inom samma arbetsgrupp. Delat lokalt minne deklareras med hjälp av nyckelordet shared i GLSL.

Exempel: Använda Delat Lokalt Minne för Datareduktion

            #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(); // Vänta tills alla arbetsobjekt har skrivit till delat minne

    // Utför reduktion inom arbetsgruppen
    for (uint i = gl_WorkGroupSize.x / 2; i > 0; i /= 2) {
        if (localId < i) {
            localSum[localId] += localSum[localId + i];
        }
        barrier(); // Vänta tills alla arbetsobjekt har slutfört reduktionssteget
    }

    // Skriv den slutliga summan till output bufferten
    if (localId == 0) {
        outputBuffer.outputData[gl_WorkGroupID.x] = localSum[0];
    }
}
            

              
                Copy