Apple GPU 간 컴퓨팅 워크로드 확장

안녕하세요, 환영합니다 저는 Apple의 GPU 소프트웨어 엔지니어링 팀의 Marco Giordano입니다 이 세션에서는 Apple M1 GPU에서 워크로드를 확장하는 방법에 대해 말씀드리겠습니다 Apple Silicon 하드웨어를 최대한 활용해 뛰어난 확장성을 달성하고 복잡한 컴퓨팅 워크로드에서 작업하는 방법을 알고 싶으신 여러분들을 위한 내용입니다 먼저 컴퓨팅 확장성 개념과 응용 프로그램이 M1 GPU 제품군에서 자연스럽게 성능을 확장할 수 있는 방법을 논의해봅시다 그런 다음 차근차근 '사용 방법'을 이야기하고 워크로드에 대한 컴퓨팅 확장성을 극대화하기 위해 사용 가능한 도구들을 다뤄보겠습니다 확장성이 무엇인지와 워크로드에서 그것이 중요한 이유에 대해 이해하는 것부터 시작하겠습니다

Apple M1 GPU는 8코어 iPad에서 64코어 MacStudio까지 전체 SOC 제품군 중 Metal3 기능을 지원하는 모든 동일한 GPU에서 워크로드가 우수한 성능을 달성할 수 있도록 처음부터 확장 가능하도록 설계되었습니다

높은 수준의 확장성을 활용하기 위해 M1에 최적화된 앱을 사용하는 것이 좋습니다 유명한 많은 프로 앱이 이미 Apple M1에 최적화되어 있으며 모두 모든 장치에서 뛰어난 확장성을 경험했습니다

예를 들어 사진과 비디오 후편집 프로그램인 Affinity Photo와 DaVinci Resolve가 있습니다 이러한 앱은 뛰어난 확장성을 달성하고 있습니다 확장성의 진정한 의미와 '이상적' 확장성을 얻는 방법을 보죠 GPU 워크로드 확장성은 GPU 코어 수 증가에 따라 성능을 향상시킬 수 있는 능력입니다 오른쪽 차트는 GPU 코어 수 증가에 따른 응용 프로그램의 속도 향상을 보여줍니다 선형 증가가 이상적인 것으로 여겨집니다

하지만 실제로 작업하다보면 이러한 GPU증가에 속도향상이 GPU 타임라인의 간격으로 인해 GPU가 증가해도 정체기가 오거나 아예 증가하지 않기도 합니다 혹은 성능이 향상되는 다른 유형의 확장도 있는데 이렇게 스택에 균일하지 않게 상승하며 일부 구간에서 워크로드가 GPU 제한에 걸리기도 합니다 여기 24코어에서 32코어 구간 48코어에서 64코어 구간과 같이요

여러분의 목표는 가능한 한 선형 확장에 가까워지는 것으로 병목 현상을 식별하고 원하는 결과를 얻을 수 있게하는 방법과 기술을 여러분들께 보여드리겠습니다

다음 섹션에서는 GPU 확장을 최대화하는 방법에 대해 설명하죠 먼저 모든 워크로드에 대해 병목 현상이 있는 곳을 찾아야 하죠 워크로드는 연산이나 대역폭에 의해 제한될 수 있습니다 최적화 과정에서 결국 둘 사이에서 왔다갔다 하게 될 수 있습니다 연산에 의해 병목이 생긴 경우에는 메모리를 활용해 연산량을 줄일 수 있고 반대의 경우도 마찬가지입니다 확장을 하게되면 병목이 옮겨질 수 있습니다 한 가지 좋은 방법은 MPS 또는 MPSGraph와 같은 Apple 프레임워크를 사용하는 것입니다 이 프레임워크는 기본 요소를 잘 활용하면 모든 컴퓨팅 커널이 모든 하드웨어에서 잘 실행되도록 되어있습니다 하지만 MPS로 모든 것을 바꿀 수는 없기때문에 워크로드를 분석하고 이해하는 것이 중요합니다

먼저 GPU 간격을 최소화하는 데 도움이 될 세 가지를 다루겠습니다

작업 분배를 개선하기 GPU 타임라인 간격을 제거하기 그리고 원자적 작업 고려하기입니다 그 다음 컴퓨팅 그리드 모양과 워크로드 메모리 레이아웃의 영향을 조사하고 마지막으로 Blender Cycles의 예시를 살펴보며 GPU 리미터를 최적화하는 법을 설명드리겠습니다 먼저 GPU 간격을 최소화하는 것부터 살펴보겠습니다 이러한 종류의 확장은 GPU가 완전히 활용되지 않고 하드웨어가 유휴 상태인 GPU 타임라인에 간격이 있어 발생할 수 있습니다

작업 분배를 조사하여 확장성을 개선할 수 있는지 보겠습니다

작은 워크로드는 일반적으로 전체 GPU를 사용하지 않으며 커널 동기화에는 추가적인 연산이 필요합니다 따라서 둘 다 적절한 확장을 방해할 수 있습니다 워크로드가 하드웨어에 매핑되는 방식을 이해하기 위해 먼저 살펴보겠습니다 워크로드가 스레드그룹의 3D 그리드 형태로 디스패치됩니다 스레드그룹은 GPU 코어에 균일하게 분산되고 크기는 제한되지만 GPU 코어에 국한되어 매우 빠른 스레드그룹 메모리에 액세스할 수 있습니다 단일 스레드그룹은 SIMD 그룹으로 더 세분화되는데 웨이브 또는 워프라고도 알려져있습니다 컴퓨팅 파이프라인 상태 객체에서 'threadExecutionWidth'를 확인하면 simd-width를 반환하는데 모든 Apple GPU에서 이 값은 32입니다

스레드그룹은 하나당 최대 1024개의 스레드를 가질 수 있으며 스레드는 최대 32KB의 스레드그룹 메모리를 공유할 수 있습니다

GPU를 계속 사용되게 하려면 모든 GPU 코어에서수행할 작업이 충분해야 합니다

다음은 디스패치할 그리드의 예입니다 스레드그룹은 GPU 클러스터로 디스패치되고 GPU 코어 간에 분산됩니다

스레드그룹이 너무 적은 경우 워크로드가 시스템을 완전히 포화시키지 않습니다 이 문제를 해결하는 방법은 다음과 같습니다

먼저 워크로드가 생성하는 스레드 수를 계산하고 디스패치가 전체 GPU를 포화시키는지 대략적으로 확인합니다 상대적으로 복잡한 커널의 경우 셰이더 코어당 1000에서 2000의 동시 스레드가 매우 좋은 점유로 간주되므로 GPU 코어당 1000에서 2000의 스레드를 사용하는 것으로 계산합니다 이제 작업량이 하드웨어를 포화시킬 수 있는지 계산할 수 있습니다 이 표는 여러 SoC를 포화시키기 위한 최저 권장 스레드 수를 보여줍니다

또 피해야할 점은 불필요하게 큰 크기의 스레드그룹을사용하는 것 입니다 스레드그룹이 작을수록 부하가 하드웨어에 더 균일하게 매핑되죠 더 큰 스레드그룹을 사용하면 GPU 코어의 균형에 중요한 균일한 분포를 막습니다

워크로드에 잘 매핑하기 위해 SIMD 너비의 가장 작은 배수를 사용하는 것이 가장 좋습니다 더 작은 스레드그룹을 사용하면 GPU에 워크로드가 더 균형있게 분배될 수 있습니다

Xcode 또는 Instruments GPU로 항상 커널 런타임 성능을 확인하세요

예를 들어 이 GPU 캡처에는 일부 연산을 수행하는 커널이 있는데 예상외로 점유율이 너무 낮습니다 컴파일러 통계에서 Xcode 14의 새로운 기능인 Max Theoretical Occupancy를 보면 100%입니다 이것은 스레드가 충분하지 않을 수 있음을 나타내며 실제로 알고리즘이 점점 적은 수의 스레드를 발송하기 시작해 GPU를 포화시키지 않게 됩니다

낮은 점유율에는 몇 가지 다른 원인이 있을 수 있습니다 자세한 내용은 MacBook Pro Tech 발표의 Metal Compute를 확인하세요 이제 워크로드가 올바르게 분산되었으므로 GPU가 항상 사용 중인지 확인해야 합니다

GPU를 적게 활용하면 이상적인 확장이 될 수 없으며 최악의 경우에는 유휴상태로 남게됩니다 GPU 타임라인 간격으로 인해 GPU가 유휴 상태일 수 있습니다

다음의 예시를 보겠습니다 이 예시에서는 CPU와 GPU 간의 직렬화로 인해 워크로드가 GPU의 50%만 사용합니다 이 경우 전체 작업 시간은 CPU와 GPU 작업시간의 합이며 이 둘은 동시에 진행되지 않습니다

GPU 코어를 두 배로 늘리면 GPU 작업이 더 빨리 완료되지만 CPU 작업은 영향을 받지 않습니다 전체 성능은 33% 증가로 이상적인 확장과는 거리가 멉니다

GPU 코어를 다시 두 배로 늘리면 GPU에서 워크로드가 더 빨라지지만 하지만 전체 지연 시간은 원래 시간에 비해 60%만 감소하죠 즉 이 경우 GPU 코어 확장의 이득이 감소됩니다 이상적인 것과는 거리가 멀죠 수정해 봅시다!

M1 pro에서 Instruments를 보면 큰 GPU 타임라인 간격을 보이는데 이는 적절한 확장의 방해요소죠

M1Ultra에서는 동일한 워크로드가 조금 더 빠르지만 GPU 유휴 시간이 더 길어지고 워크로드가 잘 확장되지 않습니다 이 큰 간격은 명령 버퍼에서 waitUntilCompleted를 사용하는 CPU동기화로 인해 발생합니다 대기 로직을 변경하고 직렬화를 제거하면 멋지게도 GPU가 완전히 활용됩니다

이 변경 전과 후의 워크로드 확장을 비교해보면 확장이 이전보다 이상적인 모습에 가까워졌습니다

이 예제에서는 CPU/GPU 동기화를 없애는 것이 가능했지만 응용 프로그램의 특성상 항상 이것이 가능하지는 않습니다 유휴 시간 감소를 위해 다른 방식으로 접근할 수도 있죠 MTLSSharedEvents를 사용하여 CPU에 신호를 보내거나 더 많은 작업을 파이프라이닝하거나 GPU 기반 인코딩 사용 고려하거나 동시에 디스패치하는 방법 등입니다 GPU 타임라인 간격을 줄이기 위한 여러 방법들을 논의해 보겠습니다 그들 중 일부는 여러분의 워크플로에 적합할 수 있습니다

GPU 완료를 위해 CPU를 기다리면 이상적인 확장을 만들 수 없습니다 응용 프로그램이 WaitUntilCompleted를 사용하는 대신 MTLSSharedEvents를 사용해볼 수 있습니다

MTL 공유 이벤트는 오버헤드가 낮고 타임라인 간격을 줄이는 데 도움이 될 수 있습니다 다음으로 고려해야 할 사항은 워크로드를 파이프라이닝하는 것입니다

알고리즘에 다음 배치작업을 위해 필요한 데이터가 있는 경우 MTL 공유 이벤트를 기다리기 전에 하나 이상의 배치를 미리 인코딩할 수 있습니다 이렇게 하면 GPU가 소모되지 않고 항상 처리해야 할 작업이 생깁니다

작업을 동일한 대기열에서 미리 인코딩할 수 없는 경우 두 번째 대기열을 사용하여 작업을 겹치는 것을 고려해보세요 여러 대기열을 사용하면 독립적인 작업을 제출할 수 있으며 이벤트를 기다릴 때 다른 제출 스레드를 지연시키지 않습니다 이렇게 GPU가 작업을 계속적으로 수신하고 처리할 수 있습니다

어떤 경우에는 알고리즘이 GPU에서 작업을 바로 인코딩할 수 있습니다

간접 명령 버퍼를 사용해서 동기화를 하지 않으며 다음 배치를 GPU에서 바로 인코딩할 수 있습니다 간접 명령 버퍼의 상세 내용은 'Metal을 사용한 현대적 렌더링'을 참고해주시기 바랍니다 워크로드는 이제 CPU와 GPU 사이의 복잡한 동기화를 없애거나 최소화합니다 그러나 작업이 많은 GPU 타임라인에서도 확장 문제가 여전히 있습니다 한번 살펴봅시다 이 그래프는 이미지 처리 워크로드에서 가져온 것입니다 여기서 이미지는 한 번에 1프레임씩 처리됩니다 연속 연산 직렬 디스패치가 많아도 확장을 제한할 수 있습니다 GPU가 사용 중이지만 커널 동기화에는 비용이 따르는데다가 분산됐지만 코어를 포화시키지 않은 스레드그룹에서 모든 디스패치가 조금씩 램프업됩니다 마찬가지로 스레드그룹이 종료되고 사라질 때 코어를 완전히 포화시키기 위해 필요한 작업이 부족할 수 있습니다 이런 상황에서는 가능한 독립적인 작업을 겹치면 좋습니다 그림으로 보겠습니다 두 이미지를 차례로 처리하는 워크로드가 있습니다 일반적으로 커널은 서로 동기화돼야 합니다 그러나 작업 일정을 다르게 만들어도 됩니다 두 이미지에 대한 작업을 동시에 디스패치해 인터리브 할 수 있습니다 동시 디스패치를 통해 드라이버가 다른 두 작업을 인터리브 처리할 수 있습니다 그림을 보시면 연속적으로있던 두개의 커널이 독립적인 작업들로 분리되었음이 보입니다 그러나 MTLDispatchTypeConcurrent를 사용할 때 경계는 수동으로 설정해야 합니다 동시 디스패치는 드라이버가 작업을 더 촘촘하게 묶게 하며 종속 커널의 동기화 비용의 대부분을 없앨 뿐만 아니라 다양한 커널의 램프업과 테일 엔드를 채웁니다 이 최적화를 통해 M1 Max에서 M1 Ultra로 이동할 때 확장성과 워크로드 성능이 크게 향상됩니다 2개의 이미지가 인터리브로 워크로드가 30% 더 빨라지며 3개 이미지를 병렬로 사용할 때는 이전 확장에 비해 70% 더 빠릅니다

커널이 수행하는 원자적 작업을 신중하게 고려해야 합니다 가장 효율적인 방법으로 만들어보겠습니다 원자적 작업은 여러 스레드에서 안전하게 데이터를 읽고 쓸 수 있게 해줍니다 전역 원자성은 전체 GPU에서 일관됩니다 많은 쓰레드가 동일한 전역 값을 읽고 쓰려고 할 때 이것은 경합으로 이어집니다 GPU 코어 수를 늘리면 오히려 더 많은 경합으로 이어집니다 예제의 알고리즘을 통해 원자성 동작을 개선할 수 있는 방법을 알아보겠습니다

예제는 버퍼의 모든 값이 더해지는 감소 알고리즘입니다 가장 간단한 방법은 주 메모리의 스레드 별 원자적 합산 작업을 수행하는 것입니다 그러나 이는 각각의 메모리 쓰기를 효과적으로 직렬화하며 주 메모리의 단일 값에 상당한 압력을 가해 좋은 방법이 아닙니다

원자 메모리 경합에 대해 하드웨어가 제공할 수 있는 도움은 두 가지입니다 Simd 그룹 명령어와 스레드그룹 원자성입니다

prefix_exlusive sum simd_min 등의 SIMD 명령어는 메모리를 거치지 않고 레지스터 간에 작업을 수행하거나 메모리를 교환할 수 있습니다 스레드그룹 원자성은 스레드그룹 메모리에 의해 수행되죠 각 GPU 코어에는 GPU 코어 수에 따라 확장할 수 있는 자체 스레드그룹 메모리가 있습니다 이 두 가지 기능이 워크로드를 어떻게 개선시키는지 보겠습니다

여기에도 똑같은 감소 문제가 있는데 이번에는 simd-group 명령을 사용해서 메모리합계를 구해봅시다 이러한 작업은 마지막 스레드의 simd 그룹에 있는 모든 숫자의 합계를 구합니다 각 SIMD-group의 마지막 스레드는 스레드그룹 메모리에서 단일 원자성 합계를 수행해 모든 SIMD-group을 스레드 그룹 메모리의 단일 값으로 줄일 수 있습니다 이렇게 하면 SIMD 그룹 명령어와 스레드그룹 메모리를 사용해 주 메모리를 건드리지 않고도 전체 스레드그룹을 줄입니다 각 그룹은 독립적인 동시에 병렬로 줄일 수 있습니다

이제 각 스레드그룹이 단일 값으로 축소되었으므로 스레드그룹당 하나의 스레드가 주 메모리에서 단일 원자성으로 작동하게 됩니다 이는 스레드그룹당 하나의 원자만 요구될 뿐 아니라 스레드그룹들이 다른 시간에 완료되므로 시간이 지남에 따라 원자를 분산시켜서 메모리 경합을 더욱 줄여줍니다 요약하자면 원자의 효율성을 극대화기 위해서는 국부 메모리와 SIMD-group 작업을 사용하며 뿐만 아니라 스레드그룹 메모리 원자를 활용해야합니다 이 모든 것들이 원자적 작업 압력을 줄여 확장을 쉬워지게합니다

이제 GPU 간격이 수정됐으니 확장이 잘 됐는지 보겠습니다 Xcode 및 Metal System Trace의 GPU 제한기는 GPU 코어들이 파이프라인을 실행할때 발생하는 모든 병목과 비효율을 최적화에 도움이 됩니다 예를 들어 비효율적인 메모리 액세스 패턴은 항상 높은 최종 레벨 캐시와 메모리 관리 장치 또는 MMU 리미터와 낮은 활용율을 유발합니다 먼저 봐야할 것은 스레드그룹과 메모리 레이아웃 조정입니다 메모리 스팬과 분산을를 줄이는 열쇠는 워크로드 메모리 액세스 패턴을 시공간적으로 명확하게 이해하는 것입니다 그것이 이해되면 두 가지 조정이 가능합니다 데이터 레이아웃을 재구성해 데이터 지역성을 개선하거나 액세스 패턴을 조정해 데이터 레이아웃과 더 잘 일치하게하고 메모리와 캐시 지역성을 개선합니다 예를 들어 보겠습니다

데이터가 한 행씩 수평으로 배치되는 메모리 버퍼가 있습니다 그러나 컴퓨팅 커널이 디스패치되면 사각형 스레드그룹이 배포되며 상당히 공간적으로 국한된 2D 같은 패턴을 갖는 것이 일반적입니다 이 액세스 패턴과 데이터 레이아웃은 데이터 지역성에 부적합합니다

예를 들어 첫 번째 SIMD-group이 데이터에 액세스할 때 요청은 캐시 라인에 압축됩니다 대부분의 캐시 라인은 사용되지 않지만 여전히 캐시에서 공간을 차지합니다! 액세스 패턴에 더 잘 맞도록 데이터를 재정렬해보겠습니다 예를 들어 전체 행에 걸쳐 있는 대신 줄무늬로 국한시킵니다

이 새로운 메모리 레이아웃으로 스레드그룹은 캐시 라인에서 요청되는 데이터의 대부분을 활용해 분산을 줄이고 캐시 효율성을 향상시킬 수 있습니다

다른 방법은 3D 그리드가 현재 데이터 레이아웃에 더 잘 맞도록 디스패치 방식을 변경하는 것입니다 예를 들면 직사각형 모양과 같이 스레드그룹의 크기를 사용해 메모리 레이아웃에 더 잘 맞는 그룹을 만들어보세요 이 경우에는 액세스 패턴은 메모리 레이아웃에 맞춰 정렬되어 훨씬 더 높은 캐시 효율성을 제공합니다 워크로드에 가장 적합한 것을 찾기 위해 실험해야 할 수도 있죠 때로는 메모리 지역성을 위해 스레드 발산을 희생하거나 그 반대와 같이 절충을 해야 할 수도 있습니다 데이터 레이아웃이나 그리드 디스패치 또는 이들의 조합을 변경해보세요 워크로드와 액세스 패턴은 모두 다릅니다

이제 메모리 지역성을 개선하는 방법을 알았으므로 Blender Cycles에서 더 구체적인 예를 살펴보겠습니다

Cycles는 프로덕션 렌더링을 위한 Blender의 물리적 패스 트레이서로 프로덕션에서 필요한 예술적 제어와 유연한 셰이딩 노드를 사용한 물리적 결과를 즉시 제공하도록 설계되었습니다

이 Instruments 추적은 낮은 읽기 대역폭 높은 Top GPU 리미터 높은 캐시 리미터 및 낮은 최종 레벨 캐시 활용 등을 잘 보여줍니다

대역폭 및 MMU 리미터를 잘 컨트롤하는 것은 확장의 중요한 요소입니다 상한 리미터가 최종 레벨 캐시 또는 MMU인 경우 메모리 범위를 줄이고 데이터 지역성을 최대화해야 해요 예를 들어 보겠습니다

Cycles는는 데이터 정렬을 사용해 분산을 줄이려 합니다 이는 재료 별로 광선을 정렬해 수행됩니다 이것은 스레드 분산을 줄이는 데 좋지만 공간적 메모리 분산을 증가시켜 결과적으로 높은 MMU 리미터가 발생합니다 이 문제를 해결하기 위해 정렬 전 데이터 지역성을 높이기 위한 메모리 범위 분할을 실험했습니다 시각화해보겠습니다 빛의 이동을 시뮬레이션하기 위해 장면에 광선을 쏘면 광선은 물체에 부딪히고 데이터는 버퍼에 수집됩니다 교차점에서 유리, 금속 등과 같이 부딪힌 재료 유형이나 교차 위치, 광선 등에 대해 많은 것을 알 수 있습니다 단순함을 위해 여기서는 재료 유형에만 초점을 맞추죠 다음은 메모리의 버퍼에 있는 자료입니다

광선이 부딪힐 때마다 많은 데이터가 수집되지만 메모리 버퍼가 상당히 커질 수 있습니다 많은 메모리를 이리저리 옮기지 않으려면 인덱스 목록을 채우고 이를 정렬해야 합니다 정렬 된 뒤에는 동일한 재료 유형에 대한 인덱스들이 함께 묶이게 됩니다 SIMD-group은 인덱스를 로드해 재료들에 대해 처리할 수 있습니다 SIMD-group은 인덱스를 사용해 원본 버퍼에 해당하는 데이터를 로드합니다

그러나 SIMD-group은 전체 메모리 스팬에서 읽으며 MMU에 압력을 가하게됩니다 새로운 방법을 조사해 보겠습니다 메모리 범위는 다른 파티션의 인덱스가 혼합되지 않도록 이상적인 파티션으로 분할됩니다 정렬할 때 액세스되는 데이터 범위가 이전처럼 전체 메모리 범위에 걸쳐 있지 않고 파티션 내부에 포함됩니다 스레드 분산과 메모리 분산 사이의 균형과 절충입니다 이상적인 파티션 수와 크기는 워크로드에 크게 의존합니다 어떤 것이 가장 잘 작동하는지 실험해야 할 수도 있습니다 다른 금속 시스템을 추적해 작업 부하가 개선됐는지 보죠 여기에서 최적화된 버전의 리미터와 활용도를 볼 수 있습니다 TOP 성능 리미터와 최종 레벨 캐시 리미터가 내려갔고 그 결과 대역폭과 셰이더 런타임이 크게 향상되었습니다 그 정도를 확인해보면 상위 리미터와 LLC 리미터가 약 20% 감소했는데 이는 데이터 흐름이 더 효율적임을 의미합니다 GPU 읽기 대역폭이 크게 증가해서 GPU 코어에 더 많은 데이터를 넣을 수 있습니다

전반적으로 이 실험을 통해 메모리 지역성이 증가했고 장면에 따라 10~30% 성능 향상이 보입니다 이는 메모리 액세스 패턴 개선차 해봄직한 방법 중 하나입니다 Top Performance 리미터를 위해 계속 실험하고 최적화하세요 GPU 도구에는 조정에 필요한 더 유용한 카운터들이 있습니다

Xcode 컴파일러 통계 창에서 새로운 Max Theoretical Occupancy를 확인할 수 있습니다 Xcode와 Instruments에는 이제 새로운 MMU 리미터, MMU 활용 카운터 및 MMU TLB Miss Rate 카운터와 같은 여러 MMU 관련 리미터와 카운터가 있습니다

오늘 많은 내용을 말씀드렸습니다 GPU 확장성과 확장 시 병목 현상의 이동에 대해 다뤘고 확장성 문제를 찾고 수정하는 데 도구를 응용하는 법을 소개했죠 그리고 여러분의 응용 프로그램이 최상의 결과를 얻기 위한 실험과 절충을 하는 방법에 대해서도 논의했습니다 여러분들의 훌륭한 앱들이 Apple Silicon에서 엄청난 확장성을 보이길 기대합니다 시청해주셔서 감사합니다