앞으로의 Arm GPU 아키텍처

Arm은 지난주에 새로운 IP를 발표했습니다. 이번에 공개된 것은 메인스트림 전용 GPU 코어 Mali-G52, 보급형 GPU 코어 Mali-G31입니다. Arm의 GPU 코어는 Mali-G7 시스템이 고성능 모바일, Mali-G5 시스템이 메인스트림, Mali-G3x이 보급형/고효율입니다. 하이엔드는 그대로 유지하고 그 아래 2가지를 발표했는데, Mali-G52는 GPU 아키텍처의 개혁이 이루어졌습니다.

 

 

3가지 Arm GPU 코어 중 2가지를 새로 출시

 

Arm의 최신 GPU 아키텍처는 Bifrost입니다. Mali-G52는 비프로스트의 2세대 확장 버전을 사용합니다. 이전까지는 메인스트림 전용 GPU에서만 구현된 비프로스트의 확장판이지만, Arm의 고성능 GPU 코어 IP도 새 아키텍처로 바뀌는 건 분명합니다. 단순히 개발 주기의 차이가 있을 뿐이며 차세대 Arm의 고성능 GPU(Mali-G7x 계)도 G52와 같은 아키텍처가 될 것으로 보입니다.

 

 

고성능 코어 Mali-G7x 계열은 최대 32개의 쉐이더 코어가 있는 GPU를 탑재

 

 

Mali-G52는 최대 4개의 쉐이더 코어가 있는 GPU 코어

 

Mali-G52의 아키텍처 혁신은 Arm GPU 아키텍쳐의 방향성을 제시한다는 점에서 중요합니다. GPU의 SIMT(Single Instruction, Multiple Thread)의 실행 레인을 기존의 4개에서 8개로 확장했습니다. GPU 면적 당 연산 성능을 높여 쉐이더가 더욱 풍부한 그래픽을 지원합니다.

 

또 Arm은 머신 러닝의 추론 단계를 위해 8비트 정수(Int8)의 특수 연산을 더했습니다. Mali-G52의 최대 구성에서 Int8의 추론 성능은 652GOPS 수준, 아이폰 X의 A11 바이오닉에 내장된 뉴런 프로세서의 성능과 비슷하거나 그 이상입니다.

 

즉, 저렴한 뉴런 전용 코어를 탑재할 여지가 많지 않은 메인스트림 전용 모바일 SoC에서도, Arm Mali를 쓰면 고정밀 머신 러닝 인식 처리가 가능해집니다. 소비 전력 당 성능은 전용 코어만큼은 나오지 않겠지만, 다이 크기(제조 비용)으로 따지면 Arm의 솔루션이 유리합니다.

 

Arm Mali-G52의 Int8 개념도

 

8레인으로 연산 코어의 실행 레인을 두배로

Arm은 Mali-G52에서 SIMT의 연산 파이프를 8레인으로 확장했습니다. 따라서 Execution Engines의 연산 능력은 단순히 따져보면 2배가 됩니다. 기존의 비프로스트는 4레인으로 SIMT 구성 자체가 이례적으로 좁았기에, 이번 확장을 통해 신형 GPU와 같은 구성이 됐다고 할 수 있습니다. 하지만 아키텍처에는 아직도 여러 의문이 남습니다. 

 

Arm은 2011년에 발표한 Mali-T600 패밀리에 Midgard라는 GPU 아키텍처를 사용했습니다. 미드가르드의 연산 코어는 SIMD(Single Instruction, Multiple Data) 기반이었는데, 2016년의 비프로스트 아키텍처에서 SIMT로 바꿨습니다.

 

GPU의 실행 모델은 크게 두가지 종류가 있습니다. 하나는 Array of Structures(AOS), Packed, SIMD(Single Instruction, Multiple Data)라고 부르는 방식. 다른 하나는 Structure of Arrays(SOA) Scalar, SIMT(Single Instruction, Multiple Thread)라고 부르는 방식입니다. SIMD는 데이터를 일정 크기로 압축한 형태로 처리합니다. 반면 SIMT는 시리얼 스칼라 처리를 함께 묶은 형태로 처리합니다.

 

NVIDIA와 AMD 모두 SIMD 아키텍처를 사용했었지만, PC용 GPU는 보다 범용성이 높은 SIMT로 전환하면서 GPU 컴퓨팅 시대가 열리게 됐습니다. 그러한 가운데 모바일 GPU를 다루는 Arm은 SIM를 유지하다 비프로스트에서 SIMT로 전환했습니다.

 

SOA / 스칼라 / SIMT 형으로 전환하여 GPU 컴퓨팅 시대가되었다. 그러한 가운데, 모바일 GPU 전업의 Arm은 AOS / 팍 크드 / SIMD를 계속 왔지만, Bifrost에서 SOA / 스칼라 / SIMT 형으로 전환했다.

 

 

16개의 연산 유닛이 AOS와 SOA 모델로 동작했을 경우를 비교

 

이 두가지는 각각 장단점이 있습니다. 데이터가 정해진 수로 나온다면 SIMD의 효율이 좋습니다. 그러나 데이터 종류가 다양하다면 SIMT가 대응하기 쉽습니다. 또 SIMT가 컴파일러 최적화가 쉽고 실행 효율을 높이기도 좋습니다.

 

 

다양한 프로그램을 지원해 실행 효율을 높이는 SIMT

Arm은 vec3(3-way 벡터)를 예로 듭니다. 여기에선 공간 좌표 x, y, z의 3가지 벡터를 연산합니다. SIMD 모델에선 1개의 버텍스(x, y, z)씩 처리합니다. 이 경우 4요소를 연산할 수 있는 4-way의 SIMD 유닛이 3개의 버텍스만 처리하며 나머지 1유닛은 일을 하지 않고 놀게 됩니다. 이 때 연산 유닛의 실행 효율은 75%가 됩니다.

 

그러나 SIMT 모델은 각 버텍스의 x 값을 함께 실행하고 다음 사이클에서 y를 함께 실행하는 식으로 SIMD를 분해해 실행합니다. 첫 사이클에선 4개의 x를 연산하고 다음 사이클에서는 4개의 y를 처리하는 식입니다. 따라서 4-way라면 모든 연산 유닛을 최대한 사용할 수 있습니다. 프로그램 쪽에서 보면 스칼라 실행처럼 보입니다.

 

 

4-way SIMD에서 3-way vec3를 처리하면 1개의 연산 레인이 빕니다. 

 

 

4-way SIMT에서 3-way의 vec3를 처리하면 3사이클만에 처리가 끝나고 비는 레인은 없습니다.

 

 

픽셀을 구성하는 RGBA의 4가지 요소를 SIMD와 SIMT에서 각각 실행했을 경우의 비교

 

 

버텍스의 위치를 정하는 xyz 3가지 요소를 SIMD와 SIMT에서 각각 실행하을 경우의 비교

 

3개의 요소로 구성된 버텍스 연산에선 SIMT가 유용하며, 범용 컴퓨팅에선 더욱 유리합니다. 일반적인 컴퓨팅 작업에서는 4개의 요소를 모두 갖추지 않은 작업이 매우 많습니다. SIMT에선 이런 다양한 워크로드에서도 꾸준히 성능을 발휘할 수 있습니다. 

 

SIMT는 연산 유닛을 잘 활용하나 단점도 있습니다. SIMD에선 하나의 버텍스(x, y, z)와 하나의 픽셀(R, G, B, A)에 대해 같은 명령을 실행합니다. 버텍스와 픽셀의 각 요소(x, y, z / R, G, B, A)는 분리되지 않기에 SIMD에서 같은 명령을 실행해도 문제가 생기진 않습니다. 그런데 SIMT라면 버텍스 A의 x와 버텍스 B의 x를 동시에 수행합니다. 따라서 반드시 같은 명령이라고는 하지 못합니다. 버텍스와 픽셀에 따라 명령의 조건 분기에선 문제가 생길 수 있습니다.

 

그래서 SIMT는 마스크 레지스터를 사용한 프레디케이션이 일반적입니다. 프레디케이션에서는 각 레인의 스레드마다 명령을 실행할지를(또는 연산 결과를 레지스터에 기록하거나 그렇지 않거나)를 마스크 레지스터에 의해 선택할 수 있습니다. 프레디케이션을 사용하면 레인의 스레드에 조건 분기가 발생해도 마치 분기 예측이 된것처럼 보여집니다. 스칼라 실행이라 부르는 건 이 때문이며, arm의 비프로스트도 비슷한 접근 방식을 사용합니다.

 

 

SIMT는 조건 분기에서 일반적인 프레디케이션을 사용

 

작은 4개 유닛을 제어하는 arm의 비프로스트 아키텍처

 

이처럼 Arm는 비프로스트 아키텍처에서 SIMT 모델로 전환했습니다. 버텍스와 픽셀을 따로 분해해 스칼라 실행하는 것 자체는 NVIDIA, AMD, Imagination Technologies도 사용하는 것이니 드물진 않습니다. 그러나 Arm의 비프로스트만 갖고 있는 특징도 있습니다.

 

많은 업체들은 연산 유닛을 16~32웨이 와이드로 구성합니다. 하드웨어로는 16~32웨이의 와이드 벡터 유닛을 갖추고, 16~64웨이 논리 벡터를 실행하는 스타일이 많습니다. NVIDIA의 Warp(32 스레드)나 AMD의 Wavefront(64 스레드)가 여기에 해당합니다. 대부분은 논리 벡터마다 프로그램 카운터를 1개 넣어 컨트롤 오버헤드를 줄일 수 있습니다. 즉 NVIDIA라면 32스레드에 1 프로그램 카운터(볼타에서 바뀜), AMD라면 64스레드 1프로그램 카운터가 됩니다.

 

반면 ARM의 비프로스트는 하드웨어나 논리적으로 모두 4웨이의 좁은 벡터 구성을 씁니다. 비프로스트에서 4개의 버텍스와 4개의 픽셀을 묶은 Quad를 만듭니다. 이를 실행 단위로 삼아 4-way의 SIMT에 할당했습니다. 즉 4스레드가 프로그램 카운터를 공유하도록 구성합니다. 다른 회사의 GPU와 비교하면 이론적으로 벡터 크기가 작고, 그만큼 컨트롤 오버헤드가 커집니다.

 

Arm은 이것이 저해상도에서도 효율을 높이기 위해서라고 말합니다. 원래 Arm 같은 모바일 GPU는 버텍스와 픽셀 유닛에 프로그램 카운터가 있어, 버텍스와 픽셀 유닛의 조건 분기 같은 플로우 컨트롤이 가능했었습니다. 이에 비해 NVIDIA나 AMD는 SIMT에서 설명한대로 프레디케이션에 의해 플로우 컨트롤을 수행합니다.

 

하지만 분기가 복잡해지면 넓은 SIMT의 프레디케이션에서는 효율이 떨어지는 경우가 있습니다.저해상도와 작은 화면에선 픽셀과 버텍스의 조건 분기가 많아집니다. 따라서 분기 크기가 작은 쪽이 효율은 높습니다. Arm의 4스레드 컨트롤 플로우는 지금까지의 방식과 PC용 GPU의 사이에 위치했다 보입니다.

 

 

왼쪽은 기존의 모바일 GPU, 오른쪽은 PC GPU의 컨트롤 플로우. 저해상도에선 처리 단위가 작은 쪽의 효율이 더 높습니다.

 

 

8레인으로 확장해도 쿼드 유닛 컨트롤은 유지

 

이런 설계 사상을 갖고 Arm은 비프로스트를 4-way벡터를 하나의 실행 유닛으로 삼는 Quad 컨트롤을 수행합니다. 따라서 실행 유닛 자체도 4-way입니다. 그런데 Mali-G52의 확장 버전인 비프로스트는 실행 유닛의 벡터 폭이 8-way가 됐습니다. 물리적인 벡터가 2배로 늘어나 1사이클 연산 성능도 2배가 됐습니다.

 

 

8-way 실행 레인을 갖춘 Mali-G52의 Execution Engines

8-way 연산 유닛에 맞춰 처리하는 스레드의 구성도 8-way가 됐느냐가 중요한데, 만약 8-way가 되면 스레드 번들 디스패치도 여기에 맞춰 8스레드가 되야 합니다. 그러나 Arm이 공개한 Mali-G52의 블럭 다이어그램에는 여전히 Quad Creator와 Quad Manager가 있습니다. arm에서 Mali-G52를 담당하는 Anand Patel(Director of Product Management, Client Business Line, Arm)도 계속해서 Quad 단위의 크기로 처리한다고 설명합니다. 

 

Mali-G52 코어 설계

 

 

Mali-G52 쉐이더 코어의 블럭 다이어그램 

 

 

Mali-G71의 쉐이더 코어

 

 

Arm에서 Mali-G52를 담당하는 Anand Patel(Director of Product Management, Client Business Line, Arm)

 

 

Arm GPU의 ALU 변화. 맨 위가 기존 미드가르드의 128-bit SIMD. 가운데는 현재 비프로스트의 4x32-bit의 SIMT. 아래는 새로 나온 Mali-T604의 8x32-bit SIMT 

 

Mali-G71의 실행 레인 아키텍처

비프로스트의 쉐이더 코어는 프런트 엔드인 Quad Creator가 버텍스, 픽셀, 컴퓨팅까지 스레드를 4개씩 묶어 Quad를 만듭니다. 버텍스와 컴퓨팅 시스템의 프론트 엔드와 픽셀의 프론트 엔드는 분리됐지만, 이건 픽셀 파이프가 버텍스에서 라스터라이저로 픽셀을 만들고 불필요한 픽셀을 제거하는 조작이 더해지기 때문입니다.

 

Quad Creator에서 생성한 Quad는 Quad Manager에서 모아 Execution Engines에 보냅니다. 스레드는 모두 Quad를 단위로 삼아 취급합니다. 이것은 NVIDIA가 Warp 단위로, AMD가 Wavefront 단위로 컨트롤하는 것과 같습니다.

 

그렇게되면 Mali-G52의 8-way 실행 레인에 지정된 Quad를 어떻게 처리할지가 문제입니다. 8-way 레인을 분할해 두 개의 4-way마다 따로 Quad를 할당하면, 이 2개의 Quad는 프로그램 카운터를 공유할까요? 같은 명령을 8-way에서 모두 실행할까요? 사실 같은 명령을 실행하지 않으면 8-way로 확장하는 장점이 줄어듭니다.

 

여기에 대해선 arm이 구조를 아직 밝히지 않았습니다. 2개의 Quad를 연결시키는 경우 실질적으로 8 스레드의 묶음으로 취급합니다. Quad Manager는 실질적으로 2개의 Quad 묶음을 관리하게 됩니다.

 

 

2개의 연산 파이프로 구성된 실행 레인

Arm의 GPU의 연산 코어는 실제로 두 종류의 연산 파이프로 구성됩니다. FMA(Fused Multiply-Add) 유닛과 ADD/SF(Special Function) 유닛의 두가지입니다. FMA 쪽에선 정수 연산, 곱셈과 나눗셈을 실행합니다. ADD/SF에선 덧셈, 나눗셈, 초월 함수 등의 실행이 가능합니다. 두 장치에서 병렬로 실행 가능한 명령어 조합도 있으나, 동일한 스레드의 연속적인 명령으로 자원이 충돌하지 않도록 제한됩니다. 정수와 SF의 2개 파이프는 기존의 GPU에서는 일반적인 구성입니다.

 

G52의 쉐이더 Execution Engines 중 ALU 아키텍처 

 

 

Mali-G71에 표시된 ALU 아키텍처
　

연산 유닛의 실행 레인은 기존의 비프로스트가 4레인, Mali-G52가 8레인이니 2배가 됐습니다. 여기에 맞춰 범용 레지스터 파일도 강화했으나 아직 공개하진 않았습니다. 비프로스트 아키텍처의 레지스터는 64x32-bit라 발표한 바 있습니다. 이것은 1레인 당 레지스터로 추측되며, 레니스터 파일의 총량도 Mali-G52는 두배가 된 것으로 추측됩니다.

 

GPU의 경우 레지스터 파일의 용량과, 내부 실행 스레드 수와, 프로그램이 쓸 수 잇는 레지스터 수가 밀접하게 연결돼 있습니다. 이것은 스레드 당 레지스터 수가 고정되지 않기 때문입니다. 특정한 수의 레지스터를 정하면, 스레드 수를 늘렸을 때 하나의 스레드가 쓸 수 있는 레지스터의 수는 줄어들게 됩니다. 반대로 레지스터 할당을 늘리면 실행할 수 있는 스레드 수가 줄어듭니다. 스레드 수가 줄어들면 메모리 액세스와 텍스처 필터링의 지연 시간을이 그대로 드러나게 됩니다.

 

Arm은 이번의 Mali-G52에서도 스레드 수는 유지한다고 설명합니다. 따라서 레지스터 파일은 2배가 됐으리라 추측됩니다. 또 비프로스트 아키텍처는 연산 결과를 패스하는 미니 레지스터 Temp Registers가 있는데 이것도 2배가 됐을 겁니다.

 

 

Arm 비프로스트의 Clause execution

 

비프로스트의 Temp Registers는 백 투 백 액세스를위한 범용 레지스터 우회에 사용합니다. 기존에 연산했던 결과를 다음 연산의 소스에 사용하는 경우, Temp Registers를 써서 대용량 레지스터 파일에 액세스하는 전력을 절감합니다.

 

 

기존 연산 결과가 다음 연산에 사용될 경우 범용 레지스터에 일단 저장함

 

 

비프로스트는 범용 레지스터를 무시하고 ALU와 함께  Temp Registers에 전달

 

위 슬라이드에 나온 Clause execution은 비프로스트에 도입된 스케줄링 방법입니다. 프로그램 명령 스트림을 Clause로 분할해 스케줄링합니다. 명령 실행 지연 시간이 일정 이하로 줄어들면 백 투 백을 연속적으로 숫행할 수 있는 명령을 블럭 단위로 구분합니다. 그 블럭의 명령은 GPU가 그대로 연속적으로 수행할 수 있는 구조입니다. 기존 명령의 처리 결과를 레지스터에 저장하고 다시 읽어올 필요가 없도록 레지스터를 무시합니다.

 

비프로스트의 Clause execution

거기에 텍스처 액세스처럼 대기 시간이 매우 긴 명령이 왔을 경우, 블럭을 관리하고 텍스처 필터링을 기다리는 Quad의 실행을 중지합니다. 그 사이에 다른 Quad의 실행을 끼워 넣어 멀티 스레딩을 통해 지연 시간을 줄여줍니다.

 

 

대기 시간이 긴 명령이 왔을 경우

 

 

다른 Quad로 실행을 전환

 

Clause 단위로 관리하면서 대기 시간이 긴 명령의 대기를 줄여주고, 레지스터 액세스를 줄여 전력 사용량을 줄입니다. 또 레이턴시 청산을 최적화해 명령을 조합하고, 2가지 실행 파이프에서 병령 실행도 가능합니다. 명령 스케줄링을 자동화해 대기 시간이 긴 명령만 관리하는 방식은 NVIDIA 같은 다른 GPU 회사도 채용한 방법입니다.

 

Clause execution와 temp Register의 최적화 사례