ISP·DSP·코덱: 전용 하드웨어

한 가지 일만 하는 회로가 이기는 이유

CPU가 덧셈 하나를 할 때 실제 덧셈기의 에너지는 전체의 몇 %에 불과하다는 것을 1장에서 보았다. 나머지는 명령어를 가져오고, 해독하고, 레지스터 파일을 읽고 쓰고, 파이프라인을 제어하는 데 쓰인다. 2010년 스탠퍼드의 Hameed 등은 H.264 인코더를 범용 프로세서에서 돌린 것과 전용 회로(ASIC)로 만든 것을 비교했는데, 에너지 차이가 약 500배였다. 범용 프로세서에 SIMD 확장과 몇 가지 맞춤 명령을 더해도 차이를 수십 배까지밖에 줄이지 못했다.

전용 회로가 이기는 이유는 세 가지다. ① 명령어가 없다. 무엇을 할지가 배선으로 정해져 있다. ② 데이터가 흐르는 길이 짧다. 한 단계의 출력이 바로 옆 단계의 입력 레지스터로 간다. 캐시도, 레지스터 파일도 거치지 않는다. ③ 필요한 만큼의 비트만 쓴다. 화소가 10비트면 10비트 덧셈기를, 계수가 상수면 곱셈기 대신 시프트와 덧셈을 쓴다. 아래에서 작업을 골라 블록마다 같은 일을 하는 데 드는 전력을 비교해 보자.

대가는 유연성이다. 전용 회로는 설계할 때 정한 일만 한다. H.264 디코더는 AV1을 풀지 못한다. 그래서 전용 블록은 "자주, 오래, 많이" 하는 일, 그리고 표준이 정해져 오래 쓰이는 일에만 만든다. 카메라, 영상 압축, 화면 표시, 오디오가 대표적이다. 그 사이의 중간 지대를 프로그램 가능한 DSP가 메운다.

카메라 ISP: 빛이 사진이 되기까지

이미지 센서의 화소는 색을 모른다. 들어온 빛의 양만 잴 뿐이다. 그래서 화소마다 빨강·초록·파랑 중 하나만 통과시키는 작은 색 필터를 올린다. 가장 흔한 배열은 2×2 칸에 R, G, G, B를 놓는 베이어 패턴(Bayer pattern)(Bryce Bayer, 1976)이다. 초록이 두 개인 이유는 사람 눈이 밝기를 주로 초록 파장으로 느끼기 때문이다. 결국 센서가 보내는 원시 데이터(RAW)는 화소마다 10~14비트 숫자 하나씩이고, 각 화소에서 빠진 두 색은 이웃에게서 추측해야 한다.

ISP는 이 원시 데이터를 받아 다음과 같은 단계를 고정 회로로 차례로 처리한다. 아래 시뮬레이터는 가상의 장면을 만든 뒤, 실제 센서처럼 따뜻한 조명(약 3,500 K), 색 필터의 겹침, 렌즈 주변부 어두워짐, 광자 잡음과 읽기 잡음, 결함 화소까지 넣어 원시 데이터를 만든다. 이제 ISP 단계를 하나씩 켜고 끄며 사진이 완성되는 과정을 보자. 그림 위를 누르거나 끌면 오른쪽 돋보기가 따라온다.

몇 가지 실험을 해 보자. 블랙 레벨 보정을 끄면 검은색이 회색으로 뜬다. 센서는 0 근처의 잡음을 표현하려고 일부러 바닥값(여기서는 1023 중 64)을 더해 보내기 때문이다. 화이트 밸런스를 끄거나 색온도를 틀리게 맞추면 회색 견본이 노랗거나 파랗게 물든다. 사람 눈은 조명에 저절로 적응하지만 센서는 그렇지 않다. 디모자이크를 "안 함"으로 두면 원시 격자가 그대로 보이고, "최근접"이면 동심원 무늬 주변에 계단과 가짜 색이 생긴다. 색 보정 행렬(CCM)을 끄면 색 필터끼리 파장이 겹친 탓에 색이 바랜다. 톤 매핑을 끄면 선형 데이터를 그대로 화면에 보내 사진이 어둡고 해가 하얗게 날아간다.

단계마다 화소 하나에 드는 연산은 수~수십 번이지만, 12 MP 센서를 초당 30장 처리하면 화소가 초당 3억 6천만 개다. 단계 전부를 합치면 초당 수천억 번의 연산이 된다. ISP는 단계마다 화소를 클럭당 1~4개씩 처리하는 전용 파이프라인을 깔아 이를 수백 MHz 클럭과 수백 mW로 해낸다.

프레임이 아니라 줄 단위로: 라인 버퍼

ISP의 단계 대부분은 화소 하나를 계산하는 데 주변 \(K\times K\) 이웃만 본다(디모자이크 5×5, 노이즈 제거 5×5~9×9 등). 센서는 화소를 왼쪽 위부터 한 줄씩 보낸다(래스터 순서). 그렇다면 프레임 전체를 저장할 필요가 없다. 지금 들어오는 줄과 바로 위 \(K-1\)줄만 칩 안 SRAM에 갖고 있으면, 창(window)이 미끄러지며 계산할 수 있다. 이 SRAM을 라인 버퍼(Line buffer)라 부른다.

라인 버퍼 덕분에 ISP는 프레임을 DRAM에 내렸다 올리지 않고 센서 → ISP → (필요하면) NPU·코덱으로 줄 단위로 흘려 보낼 수 있다. DRAM 왕복 한 번에 12 MP 프레임이면 수십 MB, 초당 30장이면 1 GB/s가 넘는다(7장). 이것을 아끼는 것이 카메라 전력의 핵심이다. 대신 이 구조는 "위에서 아래로 한 번" 처리하는 연산에만 맞는다. 여러 장을 합치는 HDR이나 큰 영역을 보는 처리는 결국 DRAM의 프레임 버퍼가 필요하다.

비디오 코덱 ①: 움직임을 찾아라

4K 영상(3840×2160, 4:2:0, 8비트)을 압축 없이 저장하면 초당 30장에 약 3 Gb/s다. 스트리밍 영상은 이것을 10~20 Mb/s, 즉 1/150~1/300로 줄인다. 비결의 첫째는 이웃한 프레임이 거의 같다는 것이다. 현재 프레임을 작은 블록으로 나누고, 각 블록이 이전 프레임의 어디에서 왔는지 찾아 그 움직임 벡터(Motion vector)와 작은 차이(잔차)만 보낸다. 찾는 일을 움직임 추정(Motion estimation)이라 한다.

가장 단순한 방법은 탐색 범위 안의 모든 위치에서 블록을 겹쳐 보고 화소 차이의 절댓값 합, SAD(Sum of Absolute Differences)가 가장 작은 곳을 고르는 것이다.

블록당 연산은 \((2R+1)^2 \times B^2\)번의 뺄셈·절댓값·덧셈이다. ±16 범위, 16×16 블록이면 블록 하나에 약 28만 번, 4K60이면 초당 수백조 번이다. 그래서 실제 인코더는 전역 탐색 대신 다이아몬드 탐색 같은 빠른 탐색, 축소 영상에서 먼저 찾는 계층 탐색, 이웃 블록의 벡터에서 출발하는 예측을 쓴다. 하드웨어는 SAD 계산기 수백 개를 배열로 깔고, 이전 프레임의 탐색 창을 칩 안 SRAM에 올려 이웃 블록끼리 재사용한다. NPU의 시스톨릭 배열과 닮은 구조다(10장).

비디오 코덱 ②: 변환과 양자화

움직임으로 예측하고 남은 잔차(또는 예측 없이 압축하는 I 프레임의 블록)는 이산 코사인 변환(DCT, Discrete Cosine Transform)으로 주파수 성분으로 바꾼다. 자연 영상의 에너지는 대부분 낮은 주파수(왼쪽 위 계수)에 몰려 있다. 그다음 양자화(Quantization)로 계수를 큰 간격으로 나눠 반올림하면, 높은 주파수 계수 대부분이 0이 된다. 0이 길게 이어지면 엔트로피 부호화로 아주 적은 비트로 표현할 수 있다. 정보를 버리는 단계는 양자화 하나뿐이고, 압축률과 화질은 양자화 간격, 즉 QP(Quantization Parameter)로 조절한다. H.264·HEVC에서 QP가 6 오를 때마다 양자화 간격이 두 배가 된다.

실제 코덱은 프레임을 세 종류로 섞는다. I 프레임은 다른 프레임을 참조하지 않고 혼자 압축한다(가장 크다). P 프레임은 이전 프레임에서 움직임을 예측한다. B 프레임은 앞뒤 프레임을 모두 참조해 가장 작다. I 프레임 사이의 묶음을 GOP(Group of Pictures)라 한다. GOP를 길게 하면 비트레이트가 줄지만, 중간부터 재생하거나 전송 오류에서 회복하기가 어려워진다.

DSP: 곱셈-누산을 위한 프로세서

DSP(Digital Signal Processor)는 전용 회로와 CPU 사이에 있다. 프로그램을 돌리지만, 그 명령어와 구조가 신호 처리의 단골 연산, 즉 곱셈-누산(MAC)에 맞춰져 있다. 오디오 필터, 음성 호출어 감지, 센서 융합, 모뎀의 일부 처리가 DSP에서 돈다. 신호 처리의 기본 연산은 FIR 필터(Finite Impulse Response)다. 출력은 최근 입력 \(N\)개에 계수를 곱해 더한 것이다.

탭 수 \(N\)이 곧 샘플당 MAC 수다. 아래에서 저역 통과 필터의 탭 수와 차단 주파수를 바꿔, 낮은 음(220 Hz, 440 Hz)은 남기고 높은 잡음(7 kHz 음과 쉬익 소리)을 지워 보자.

DSP는 이런 루프를 빠르게 돌리도록 특별한 장치를 갖는다. 한 클럭에 MAC 여러 개와 메모리 읽기 두 개, 주소 갱신을 동시에 하는 VLIW(Very Long Instruction Word) 명령어(컴파일러가 병렬로 실행할 명령을 미리 한 묶음으로 짠다), 오버헤드 없는 하드웨어 반복문, 원형 버퍼 주소 지정, 넘치면 최댓값에 멈추는 포화 연산이다. CPU의 비순차 실행 엔진이 실행 중에 하는 일을 컴파일러가 미리 해 두니, 하드웨어가 단순하고 전력이 낮다. 대신 분기가 많고 예측하기 어려운 코드에는 맞지 않는다. 휴대폰의 저전력 DSP는 화면이 꺼진 동안에도 수 mW로 마이크 신호를 듣고 있다가, 호출어가 들리면 그때 CPU를 깨운다(1장).

디스플레이 파이프라인: 초당 120번의 합성

화면에 보이는 것은 그림 한 장이 아니라 여러 층(Layer)이다. 배경화면, 앱 화면, 동영상, 상태 표시줄, 알림이 각자 따로 그려진다. 이 층들을 겹쳐 한 장으로 만드는 일을 합성(Composition)이라 한다. GPU로 합성할 수도 있지만, SoC의 디스플레이 엔진(Display processing unit)은 층들을 DRAM에서 읽으며 화소 단위로 바로 섞어 패널로 내보낼 수 있다(하드웨어 오버레이). 합성한 결과를 DRAM에 다시 쓰지 않으니 대역폭이 준다.

패널은 정해진 박자로 화면을 갱신한다. 그 박자 신호가 VSync(Vertical sync)다. 120 Hz 화면이면 8.33 ms마다 새 프레임이 준비되어 있어야 하고, 앱이 늦으면 이전 프레임이 한 번 더 표시된다. 이것이 화면이 "버벅이는" 끊김(Jank)이다.

주사율을 120 Hz로 올리면 부드러워지지만 앱이 프레임을 8.3 ms 안에 만들어야 하고, 합성 대역폭과 패널 구동 전력도 두 배가 된다. 그래서 최근 패널(LTPO OLED)은 화면이 멈춰 있을 때 1~10 Hz까지 주사율을 낮추고, 스크롤할 때만 120 Hz로 올린다. 디스플레이 엔진은 이 밖에도 색 공간 변환, HDR 톤 매핑, 화면 크기 변환, 패널 압축(DSC)을 고정 회로로 한다. 사진 한 장이 화면에 나타나기까지 ISP → NPU → 코덱 → 디스플레이 엔진을 거치는 긴 여행은 1장에서 따라가 보았다.