WebGL 컴퓨트 셰이더 디스패치 최적화: 워크그룹 크기 튜닝

WebGL의 강력한 기능인 컴퓨트 셰이더는 개발자가 웹 브라우저 내에서 직접 GPU의 막대한 병렬성을 범용 컴퓨팅(GPGPU)에 활용할 수 있게 해줍니다. 이는 이미지 처리와 물리 시뮬레이션부터 데이터 분석, 머신 러닝에 이르기까지 광범위한 작업의 속도를 높일 기회를 열어줍니다. 하지만 컴퓨트 셰이더로 최적의 성능을 달성하는 것은 계산이 GPU에서 어떻게 분할되고 실행되는지를 결정하는 핵심 매개변수인 워크그룹 크기를 이해하고 신중하게 튜닝하는 데 달려 있습니다.

컴퓨트 셰이더와 워크그룹 이해하기

최적화 기법을 살펴보기 전에, 기본 개념을 명확히 이해해 봅시다:

• 컴퓨트 셰이더(Compute Shaders): GLSL(OpenGL Shading Language)로 작성되어 GPU에서 직접 실행되는 프로그램입니다. 기존의 버텍스나 프래그먼트 셰이더와 달리, 컴퓨트 셰이더는 렌더링 파이프라인에 묶여 있지 않으며 임의의 계산을 수행할 수 있습니다.
• 디스패치(Dispatch): 컴퓨트 셰이더를 실행하는 행위를 디스패칭이라고 합니다. gl.dispatchCompute(x, y, z) 함수는 셰이더를 실행할 워크그룹의 총 개수를 지정합니다. 이 세 인수는 디스패치 그리드의 차원을 정의합니다.
• 워크그룹(Workgroup): GPU 내의 단일 처리 장치에서 동시에 실행되는 작업 항목(스레드라고도 함)의 모음입니다. 워크그룹은 그룹 내에서 데이터를 공유하고 연산을 동기화하는 메커니즘을 제공합니다.
• 작업 항목(Work Item): 워크그룹 내에서 컴퓨트 셰이더의 단일 실행 인스턴스입니다. 각 작업 항목은 내장 GLSL 변수 gl_LocalInvocationID를 통해 접근할 수 있는 워크그룹 내 고유 ID를 가집니다.
• 전역 호출 ID(Global Invocation ID): 전체 디스패치에 걸쳐 각 작업 항목에 대한 고유 식별자입니다. 이는 gl_GlobalInvocationID(전체 ID)와 gl_LocalInvocationID(워크그룹 내 ID)의 조합입니다.

이러한 개념들의 관계는 다음과 같이 요약할 수 있습니다: 디스패치는 워크그룹 그리드를 실행하고, 각 워크그룹은 여러 작업 항목으로 구성됩니다. 컴퓨트 셰이더 코드는 각 작업 항목이 수행할 연산을 정의하며, GPU는 여러 처리 코어의 힘을 활용하여 이러한 연산을 병렬로 실행합니다.

예시: 필터를 적용하기 위해 컴퓨트 셰이더를 사용하여 큰 이미지를 처리한다고 상상해 보세요. 이미지를 타일로 나눌 수 있으며, 각 타일은 하나의 워크그룹에 해당합니다. 각 워크그룹 내에서 개별 작업 항목은 타일 내의 개별 픽셀을 처리할 수 있습니다. 이때 gl_LocalInvocationID는 타일 내 픽셀의 위치를 나타내고, 디스패치 크기는 처리될 타일(워크그룹)의 수를 결정합니다.

워크그룹 크기 튜닝의 중요성

워크그룹 크기의 선택은 컴퓨트 셰이더의 성능에 지대한 영향을 미칩니다. 부적절하게 구성된 워크그룹 크기는 다음과 같은 문제를 초래할 수 있습니다:

• 최적이 아닌 GPU 활용도: 워크그룹 크기가 너무 작으면 GPU의 처리 장치가 충분히 활용되지 않아 전반적인 성능이 저하될 수 있습니다.
• 오버헤드 증가: 매우 큰 워크그룹은 리소스 경합 및 동기화 비용 증가로 인해 오버헤드를 유발할 수 있습니다.
• 메모리 접근 병목 현상: 워크그룹 내의 비효율적인 메모리 접근 패턴은 메모리 접근 병목 현상을 일으켜 계산 속도를 늦출 수 있습니다.
• 성능 변동성: 워크그룹 크기를 신중하게 선택하지 않으면 다른 GPU 및 드라이버에 따라 성능이 크게 달라질 수 있습니다.

따라서 WebGL 컴퓨트 셰이더의 성능을 극대화하려면 최적의 워크그룹 크기를 찾는 것이 중요합니다. 이 최적의 크기는 하드웨어와 워크로드에 따라 다르므로 실험이 필요합니다.

워크그룹 크기에 영향을 미치는 요인

주어진 컴퓨트 셰이더에 대한 최적의 워크그룹 크기에는 여러 요인이 영향을 미칩니다:

• GPU 아키텍처: GPU마다 처리 장치 수, 메모리 대역폭, 캐시 크기 등 다른 아키텍처를 가지고 있습니다. 최적의 워크그룹 크기는 종종 다른 GPU 공급업체(예: AMD, NVIDIA, Intel) 및 모델에 따라 다릅니다.
• 셰이더 복잡성: 컴퓨트 셰이더 코드 자체의 복잡성이 최적의 워크그룹 크기에 영향을 줄 수 있습니다. 더 복잡한 셰이더는 메모리 지연 시간을 더 잘 숨기기 위해 더 큰 워크그룹의 이점을 볼 수 있습니다.
• 메모리 접근 패턴: 컴퓨트 셰이더가 메모리에 접근하는 방식이 중요한 역할을 합니다. 워크그룹 내의 작업 항목들이 연속적인 메모리 위치에 접근하는 병합 메모리 접근 패턴은 일반적으로 더 나은 성능을 가져옵니다.
• 데이터 의존성: 워크그룹 내의 작업 항목들이 데이터를 공유하거나 연산을 동기화해야 하는 경우, 이는 최적의 워크그룹 크기에 영향을 미치는 오버헤드를 유발할 수 있습니다. 과도한 동기화는 더 작은 워크그룹이 더 잘 수행되게 할 수 있습니다.
• WebGL 제한: WebGL은 최대 워크그룹 크기에 제한을 둡니다. 이 제한은 gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_SIZE), gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_INVOCATIONS), gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_COUNT)를 사용하여 쿼리할 수 있습니다.

워크그룹 크기 튜닝 전략

이러한 요인들의 복잡성을 감안할 때, 워크그룹 크기 튜닝에 대한 체계적인 접근이 필수적입니다. 다음은 사용할 수 있는 몇 가지 전략입니다:

1. 벤치마킹으로 시작하기

모든 최적화 노력의 초석은 벤치마킹입니다. 다양한 워크그룹 크기로 컴퓨트 셰이더의 성능을 측정할 수 있는 신뢰할 수 있는 방법이 필요합니다. 이를 위해서는 컴퓨트 셰이더를 다른 워크그룹 크기로 반복 실행하고 실행 시간을 측정할 수 있는 테스트 환경을 만들어야 합니다. 간단한 접근 방식은 performance.now()를 사용하여 gl.dispatchCompute() 호출 전후의 시간을 측정하는 것입니다.

예시:

const workgroupSizeX = 8;
const workgroupSizeY = 8;
const workgroupSizeZ = 1;

gl.useProgram(computeProgram);
// 유니폼 및 텍스처 설정

gl.dispatchCompute(width / workgroupSizeX, height / workgroupSizeY, 1);
gl.memoryBarrier(gl.SHADER_STORAGE_BARRIER_BIT);
gl.finish(); // 타이밍 측정 전 완료 보장

const startTime = performance.now();

for (let i = 0; i < numIterations; ++i) {
    gl.dispatchCompute(width / workgroupSizeX, height / workgroupSizeY, 1);
    gl.memoryBarrier(gl.SHADER_STORAGE_BARRIER_BIT); // 쓰기 작업이 보이도록 보장
    gl.finish();
}

const endTime = performance.now();
const elapsedTime = (endTime - startTime) / numIterations;
console.log(`워크그룹 크기 (${workgroupSizeX}, ${workgroupSizeY}, ${workgroupSizeZ}): ${elapsedTime.toFixed(2)} ms`);

벤치마킹 시 주요 고려 사항:

• 워밍업: 측정을 시작하기 전에 컴퓨트 셰이더를 몇 번 실행하여 GPU가 워밍업되고 초기 성능 변동을 피하도록 합니다.
• 여러 번 반복: 컴퓨트 셰이더를 여러 번 실행하고 실행 시간을 평균내어 노이즈와 측정 오류의 영향을 줄입니다.
• 동기화: gl.memoryBarrier()와 gl.finish()를 사용하여 실행 시간을 측정하기 전에 컴퓨트 셰이더 실행이 완료되고 모든 메모리 쓰기가 표시되도록 합니다. 이것들이 없으면 보고된 시간은 실제 계산 시간을 정확하게 반영하지 않을 수 있습니다.
• 재현성: 결과의 변동성을 최소화하기 위해 벤치마크 환경이 다른 실행에서도 일관되도록 보장합니다.

2. 체계적인 워크그룹 크기 탐색

벤치마킹 설정이 완료되면, 다양한 워크그룹 크기를 탐색하기 시작할 수 있습니다. 좋은 출발점은 워크그룹의 각 차원에 대해 2의 거듭제곱(예: 1, 2, 4, 8, 16, 32, 64, ...)을 시도하는 것입니다. 또한 WebGL에 의해 부과된 제한을 고려하는 것도 중요합니다.

예시:

const maxWidthgroupSize = gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_SIZE)[0];
const maxHeightgroupSize = gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_SIZE)[1];
const maxZWorkgroupSize = gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_SIZE)[2];

for (let x = 1; x <= maxWidthgroupSize; x *= 2) {
    for (let y = 1; y <= maxHeightgroupSize; y *= 2) {
        for (let z = 1; z <= maxZWorkgroupSize; z *= 2) {
            if (x * y * z <= gl.getParameter(gl.MAX_COMPUTE_WORK_GROUP_INVOCATIONS)) {
              // x, y, z를 워크그룹 크기로 설정하고 벤치마크합니다.
            }
        }
    }
}

다음 사항을 고려하세요:

• 로컬 메모리 사용량: 컴퓨트 셰이더가 상당한 양의 로컬 메모리(워크그룹 내 공유 메모리)를 사용하는 경우, 사용 가능한 로컬 메모리를 초과하지 않도록 워크그룹 크기를 줄여야 할 수 있습니다.
• 워크로드 특성: 워크로드의 성격 또한 최적의 워크그룹 크기에 영향을 줄 수 있습니다. 예를 들어, 워크로드에 분기나 조건부 실행이 많은 경우 더 작은 워크그룹이 더 효율적일 수 있습니다.
• 총 작업 항목 수: 총 작업 항목 수(gl.dispatchCompute(x, y, z) * workgroupSizeX * workgroupSizeY * workgroupSizeZ)가 GPU를 완전히 활용하기에 충분한지 확인합니다. 너무 적은 작업 항목을 디스패치하면 활용도가 낮아질 수 있습니다.

3. 메모리 접근 패턴 분석

앞서 언급했듯이 메모리 접근 패턴은 성능에 중요한 역할을 합니다. 이상적으로는 워크그룹 내의 작업 항목들이 메모리 대역폭을 최대화하기 위해 연속적인 메모리 위치에 접근해야 합니다. 이를 병합 메모리 접근(coalesced memory access)이라고 합니다.

예시:

2D 이미지를 처리하는 시나리오를 생각해 봅시다. 각 작업 항목이 단일 픽셀을 처리하는 경우, 2D 그리드(예: 8x8)로 배열된 워크그룹이 행 우선 순서로 픽셀에 접근하면 병합 메모리 접근을 보입니다. 반대로, 열 우선 순서로 픽셀에 접근하면 비효율적인 스트라이드 메모리 접근이 발생합니다.

메모리 접근 개선 기법:

• 데이터 구조 재배열: 병합 메모리 접근을 촉진하도록 데이터 구조를 재구성합니다.
• 로컬 메모리 사용: 데이터를 로컬 메모리(워크그룹 내 공유 메모리)로 복사하고 로컬 복사본에서 계산을 수행합니다. 이는 전역 메모리 접근 횟수를 크게 줄일 수 있습니다.
• 스트라이드 최적화: 스트라이드 메모리 접근이 불가피한 경우 스트라이드를 최소화하도록 노력합니다.

4. 동기화 오버헤드 최소화

barrier() 및 원자적 연산과 같은 동기화 메커니즘은 워크그룹 내 작업 항목의 동작을 조정하는 데 필요합니다. 그러나 과도한 동기화는 상당한 오버헤드를 유발하고 성능을 저하시킬 수 있습니다.

동기화 오버헤드 감소 기법:

• 의존성 줄이기: 작업 항목 간의 데이터 의존성을 최소화하도록 컴퓨트 셰이더 코드를 재구성합니다.
• 웨이브 수준 연산 사용: 일부 GPU는 웨이브 수준 연산(서브그룹 연산이라고도 함)을 지원하여, 웨이브(하드웨어에서 정의한 작업 항목 그룹) 내의 작업 항목이 명시적인 동기화 없이 데이터를 공유할 수 있게 합니다.
• 원자적 연산의 신중한 사용: 원자적 연산은 공유 메모리에 대한 원자적 업데이트를 수행하는 방법을 제공합니다. 그러나 특히 동일한 메모리 위치에 대한 경합이 있을 때 비용이 많이 들 수 있습니다. 결과를 누적하기 위해 로컬 메모리를 사용한 다음 워크그룹 끝에서 단일 원자적 업데이트를 수행하는 것과 같은 대안적인 접근 방식을 고려하세요.

5. 적응형 워크그룹 크기 튜닝

최적의 워크그룹 크기는 입력 데이터와 현재 GPU 부하에 따라 달라질 수 있습니다. 어떤 경우에는 이러한 요인에 따라 동적으로 워크그룹 크기를 조정하는 것이 유리할 수 있습니다. 이를 적응형 워크그룹 크기 튜닝이라고 합니다.

예시:

크기가 다른 이미지를 처리하는 경우, 디스패치되는 워크그룹 수가 이미지 크기에 비례하도록 워크그룹 크기를 조정할 수 있습니다. 또는 GPU 부하를 모니터링하고 GPU가 이미 과부하 상태이면 워크그룹 크기를 줄일 수 있습니다.

구현 시 고려 사항:

• 오버헤드: 적응형 워크그룹 크기 튜닝은 성능을 측정하고 동적으로 워크그룹 크기를 조정해야 하므로 오버헤드가 발생합니다. 이 오버헤드는 잠재적인 성능 향상과 비교하여 평가해야 합니다.
• 휴리스틱: 워크그룹 크기를 조정하기 위한 휴리스틱의 선택은 성능에 상당한 영향을 미칠 수 있습니다. 특정 워크로드에 가장 적합한 휴리스틱을 찾으려면 신중한 실험이 필요합니다.

실용적인 예제 및 사례 연구

워크그룹 크기 튜닝이 실제 시나리오에서 성능에 어떻게 영향을 미칠 수 있는지 몇 가지 실용적인 예제를 살펴보겠습니다:

예제 1: 이미지 필터링

이미지에 블러 필터를 적용하는 컴퓨트 셰이더를 생각해 봅시다. 순진한 접근 방식은 작은 워크그룹 크기(예: 1x1)를 사용하고 각 작업 항목이 단일 픽셀을 처리하도록 하는 것일 수 있습니다. 그러나 이 접근 방식은 병합 메모리 접근이 부족하여 매우 비효율적입니다.

워크그룹 크기를 8x8 또는 16x16으로 늘리고 이미지 픽셀과 정렬되는 2D 그리드로 워크그룹을 배열함으로써 병합 메모리 접근을 달성하고 성능을 크게 향상시킬 수 있습니다. 또한 관련 이웃 픽셀을 공유 로컬 메모리에 복사하면 중복되는 전역 메모리 접근을 줄여 필터링 작업 속도를 높일 수 있습니다.

예제 2: 입자 시뮬레이션

입자 시뮬레이션에서는 종종 컴퓨트 셰이더를 사용하여 각 입자의 위치와 속도를 업데이트합니다. 최적의 워크그룹 크기는 입자 수와 업데이트 로직의 복잡성에 따라 달라집니다. 업데이트 로직이 비교적 간단하면 더 많은 입자를 병렬로 처리하기 위해 더 큰 워크그룹 크기를 사용할 수 있습니다. 그러나 업데이트 로직에 분기나 조건부 실행이 많은 경우 더 작은 워크그룹이 더 효율적일 수 있습니다.

또한 입자들이 서로 상호 작용하는 경우(예: 충돌 감지 또는 힘 필드를 통해), 입자 업데이트가 올바르게 수행되도록 동기화 메커니즘이 필요할 수 있습니다. 워크그룹 크기를 선택할 때 이러한 동기화 메커니즘의 오버헤드를 고려해야 합니다.

사례 연구: WebGL 레이 트레이서 최적화

베를린에서 WebGL 기반 레이 트레이서를 개발하던 한 프로젝트 팀은 초기에 낮은 성능을 보였습니다. 렌더링 파이프라인의 핵심은 광선 교차에 기반하여 각 픽셀의 색상을 계산하는 컴퓨트 셰이더에 크게 의존했습니다. 프로파일링 후, 그들은 워크그룹 크기가 상당한 병목 현상임을 발견했습니다. 그들은 (4, 4, 1)의 워크그룹 크기로 시작했는데, 이는 많은 작은 워크그룹을 생성하고 GPU 리소스를 충분히 활용하지 못했습니다.

그 후 그들은 체계적으로 다양한 워크그룹 크기를 실험했습니다. 그들은 (8, 8, 1)의 워크그룹 크기가 NVIDIA GPU에서 성능을 크게 향상시키지만 일부 AMD GPU에서는 로컬 메모리 제한을 초과하여 문제를 일으킨다는 것을 발견했습니다. 이를 해결하기 위해 그들은 감지된 GPU 공급업체에 따라 워크그룹 크기를 선택하는 기능을 구현했습니다. 최종 구현에서는 NVIDIA용으로 (8, 8, 1)을, AMD용으로 (4, 4, 1)을 사용했습니다. 또한 그들은 광선-객체 교차 테스트와 워크그룹 내 공유 메모리 사용을 최적화하여 브라우저에서 레이 트레이서를 사용할 수 있게 만들었습니다. 이는 렌더링 시간을 극적으로 향상시켰고 다른 GPU 모델에서도 일관된 성능을 보이게 했습니다.

모범 사례 및 권장 사항

WebGL 컴퓨트 셰이더에서 워크그룹 크기 튜닝을 위한 몇 가지 모범 사례와 권장 사항은 다음과 같습니다:

• 벤치마킹으로 시작하기: 항상 다양한 워크그룹 크기로 컴퓨트 셰이더의 성능을 측정하기 위한 벤치마킹 설정을 만드는 것으로 시작하세요.
• WebGL 제한 이해하기: WebGL이 부과하는 최대 워크그룹 크기 및 디스패치할 수 있는 총 작업 항목 수에 대한 제한을 인지하고 있어야 합니다.
• GPU 아키텍처 고려하기: 워크그룹 크기를 선택할 때 대상 GPU의 아키텍처를 고려하세요.
• 메모리 접근 패턴 분석하기: 메모리 대역폭을 최대화하기 위해 병합 메모리 접근 패턴을 추구하세요.
• 동기화 오버헤드 최소화하기: 동기화 필요성을 최소화하기 위해 작업 항목 간의 데이터 의존성을 줄이세요.
• 로컬 메모리 현명하게 사용하기: 전역 메모리 접근 횟수를 줄이기 위해 로컬 메모리를 사용하세요.
• 체계적으로 실험하기: 다양한 워크그룹 크기를 체계적으로 탐색하고 성능에 미치는 영향을 측정하세요.
• 코드 프로파일링하기: 프로파일링 도구를 사용하여 성능 병목 현상을 식별하고 컴퓨트 셰이더 코드를 최적화하세요.
• 여러 장치에서 테스트하기: 다양한 장치에서 컴퓨트 셰이더를 테스트하여 다른 GPU 및 드라이버에서도 잘 작동하는지 확인하세요.
• 적응형 튜닝 고려하기: 입력 데이터 및 GPU 부하에 따라 동적으로 워크그룹 크기를 조정할 가능성을 탐색하세요.
• 결과 문서화하기: 테스트한 워크그룹 크기와 얻은 성능 결과를 문서화하세요. 이는 향후 워크그룹 크기 튜닝에 대해 정보에 입각한 결정을 내리는 데 도움이 될 것입니다.

결론

워크그룹 크기 튜닝은 WebGL 컴퓨트 셰이더의 성능 최적화에 있어 중요한 측면입니다. 최적의 워크그룹 크기에 영향을 미치는 요인을 이해하고 튜닝에 체계적인 접근 방식을 사용함으로써 GPU의 잠재력을 최대한 발휘하고 컴퓨팅 집약적인 웹 애플리케이션에서 상당한 성능 향상을 달성할 수 있습니다.

최적의 워크그룹 크기는 특정 워크로드, 대상 GPU 아키텍처 및 컴퓨트 셰이더의 메모리 접근 패턴에 따라 크게 달라진다는 점을 기억하세요. 따라서 애플리케이션에 가장 적합한 워크그룹 크기를 찾기 위해서는 신중한 실험과 프로파일링이 필수적입니다. 이 글에서 설명한 모범 사례와 권장 사항을 따르면 WebGL 컴퓨트 셰이더의 성능을 극대화하고 더 부드럽고 반응성이 뛰어난 사용자 경험을 제공할 수 있습니다.

WebGL 컴퓨트 셰이더의 세계를 계속 탐험하면서 여기서 논의된 기술이 단지 이론적인 개념이 아니라는 것을 기억하세요. 이것들은 실제 문제를 해결하고 혁신적인 웹 애플리케이션을 만드는 데 사용할 수 있는 실용적인 도구입니다. 그러니 뛰어들어 실험하고, 최적화된 컴퓨트 셰이더의 힘을 발견하세요!