RK3588 GPU 펌웨어를 뜯어본 이야기 — ARM Mali CSF의 내부 구조 탐험기

GPU 펌웨어, 그 미지의 영역

우리가 코드를 짜서 GPU를 쓸 때, 보통은 OpenGL이나 Vulkan 같은 API를 통해 접근하잖아요. 그 아래에서 실제로 GPU 하드웨어를 제어하는 건 드라이버이고, 드라이버보다 더 아래에는 펌웨어가 있어요. 펌웨어는 GPU 칩 안에서 직접 돌아가는 소프트웨어로, 하드웨어와 가장 가까운 층에서 작업 스케줄링, 전력 관리, 메모리 관리 같은 일을 담당해요.

그런데 이 펌웨어의 내부 구조는 보통 공개되지 않아요. GPU 제조사의 영업 비밀이거든요. 그래서 오픈소스 GPU 드라이버를 만드는 사람들에게는 항상 큰 장벽이었어요. 최근 한 개발자가 RK3588 SoC에 탑재된 ARM Mali GPU의 CSF 펌웨어를 분석한 글을 공개했는데, GPU 펌웨어의 내부 동작을 이해하고 싶은 분들에게 정말 흥미로운 내용이에요.

CSF가 뭔가요?

CSF는 Command Stream Frontend의 약자예요. 이게 뭐냐면, GPU가 해야 할 일(렌더링 명령, 컴퓨트 작업 등)을 받아서 처리하는 "입구" 역할을 하는 컴포넌트예요.

좀 더 쉽게 설명하면 이래요. 여러분이 카페에 가서 주문을 하면, 카운터 직원이 주문을 받아서 정리하고, 바리스타에게 전달하잖아요. CSF는 이 카운터 직원과 비슷해요. CPU에서 "이 삼각형들을 그려줘", "이 셰이더를 실행해줘" 같은 명령을 보내면, CSF 펌웨어가 이걸 받아서 GPU의 실제 실행 유닛에 적절히 분배하는 거예요.

이전 세대 Mali GPU에서는 이런 작업 분배를 CPU 쪽 드라이버가 직접 했어요. 그런데 CSF가 도입되면서 이 역할이 GPU 내부의 펌웨어로 넘어갔어요. 이렇게 하면 CPU와 GPU 사이의 통신 횟수가 줄어들고, GPU가 더 자율적으로 작업을 스케줄링할 수 있어서 효율이 올라가요.

RK3588과 이 분석이 의미하는 것

RK3588은 Rockchip이 만든 ARM 기반 SoC(System on Chip)로, 싱글보드 컴퓨터(SBC) 세계에서 꽤 인기 있는 칩이에요. Orange Pi 5, Rock 5B 같은 보드에 들어가고, 라즈베리 파이 대안으로 많이 쓰여요. 이 칩 안에 Mali-G610 GPU가 들어있는데, 바로 이 GPU가 CSF 방식을 사용해요.

이 분석 글에서 개발자는 CSF 펌웨어의 바이너리를 리버스 엔지니어링해서 내부 구조를 파악했어요. 구체적으로 살펴본 내용으로는 펌웨어가 GPU 하드웨어 레지스터와 어떻게 상호작용하는지, 작업 큐(queue)를 어떤 방식으로 관리하는지, 그리고 에러 핸들링이 어떻게 이루어지는지 등이 있어요.

특히 흥미로운 부분은 펌웨어 내부의 상태 머신(state machine) 구조예요. GPU가 idle 상태에서 작업을 받으면 어떤 단계를 거쳐 실행 상태로 전환되는지, 작업이 끝나면 어떻게 CPU에 완료를 알리는지, 에러가 발생하면 어떻게 복구하는지 — 이런 것들이 상태 머신으로 정의되어 있다는 거예요. 마치 게임의 캐릭터 AI가 상태에 따라 다른 행동을 하듯이, GPU 펌웨어도 상태에 따라 다른 처리를 하는 거죠.

왜 오픈소스 커뮤니티에서 이게 중요한가

리눅스 커널에는 Panfrost라는 오픈소스 Mali GPU 드라이버가 있어요. 이 드라이버는 ARM Mali GPU를 리눅스에서 쓸 수 있게 해주는 건데, 문제는 CSF 기반 최신 GPU를 제대로 지원하려면 펌웨어와의 인터페이스를 정확히 이해해야 한다는 거예요.

ARM이 공식적으로 CSF 관련 문서를 일부 공개하긴 했지만, 실제 펌웨어 동작의 세부 사항까지는 다루지 않거든요. 그래서 이런 리버스 엔지니어링 분석이 오픈소스 드라이버 개발에 직접적으로 도움이 돼요. 펌웨어가 기대하는 입력 형식이나 에러 코드의 의미 같은 걸 알아야 드라이버가 올바르게 동작하니까요.

비슷한 맥락에서 Nouveau(NVIDIA용 오픈소스 드라이버)나 Freedreno(Qualcomm Adreno용)도 비슷한 리버스 엔지니어링 과정을 거쳐서 만들어졌어요. GPU 오픈소스 드라이버의 역사는 곧 이런 분석과 역공학의 역사이기도 해요.

한국 개발자에게 주는 시사점

이 내용은 솔직히 대부분의 앱 개발자에게는 직접적으로 필요한 지식은 아니에요. 하지만 몇 가지 맥락에서 관련이 있어요.

임베디드/IoT 개발자라면, RK3588 기반 보드를 프로젝트에 쓸 때 GPU 가속이 제대로 되는지, 리눅스 드라이버 상태가 어떤지 알아두는 게 좋아요. 이런 펌웨어 분석이 쌓이면서 오픈소스 드라이버의 완성도가 올라가면, RK3588에서 OpenGL ES나 Vulkan을 활용한 그래픽/컴퓨트 작업이 더 안정적으로 돌아가게 될 거예요.

시스템 프로그래밍에 관심 있는 분이라면, 이 글은 "저수준 시스템이 실제로 어떻게 돌아가는가"를 보여주는 훌륭한 사례 연구예요. 상태 머신 설계, 하드웨어-소프트웨어 인터페이스, 바이너리 분석 기법 등을 실전 맥락에서 배울 수 있거든요.

마무리

GPU 펌웨어는 보통 블랙박스로 취급되는 영역인데, 이런 분석 글이 공개되면서 그 내부가 조금씩 투명해지고 있어요. 하드웨어와 소프트웨어의 경계에서 벌어지는 이런 작업들이 결국 우리가 쓰는 오픈소스 드라이버의 품질을 결정짓는다는 점에서, 보이지 않는 곳에서 묵묵히 이런 분석을 하는 개발자들에게 박수를 보내고 싶네요.

여러분은 이런 저수준(low-level) 하드웨어 분석에 관심이 있으신가요? 혹시 RK3588이나 다른 ARM SBC를 실제로 쓰고 계신 분이 있다면 경험을 나눠주세요!