Raph Levien, RP2350에서 JIT로 비트맵 텍스트 렌더링 속도 한계 돌파
JIT bitmap text rendering for microcontrollers
Raph Levien이 RP2350 마이크로컨트롤러에서 비트맵 텍스트를 초고속으로 렌더링하는 기법을 공개했다. 문자열을 즉석에서 최적화된 ARM 어셈블리 코드로 컴파일하는 JIT를 활용해, 스캔라인마다 비디오 버퍼를 채우는 '레이스 더 빔' 방식에서 픽셀당 약 6사이클 예산을 효율적으로 지킨다. 폰트 비트맵을 32비트 워드에 겹쳐 압축해 1140바이트를 960바이트로 줄였고, 명령어 재배치로 지연 슬롯까지 메꿨다.
Rust는 성능 요구 사항을 충족할 수 없어서 ARM 어셈블리 언어로 작성하기 시작했다.
HN 토론
22- drfuchs
관련 선행 연구로는 1996년에 출원된 특허 US-6377261-B1 "Compiling glyphs into instructions for imaging for execution on a general purpose computer"를 참고해 보세요. 기본 아이디어는 각 문자를 "Load Immediate" / "Shift" / "OR to Memory" 명령어의 연속으로 바꾸는 것으로, 픽셀이 생성된 기계어의 Immediate 데이터에 암묵적으로 들어 있기 때문에 더 이상 폰트의 저장된 비트맵에서 가져올 필요가 없습니다. 게다가 문자의 한 행이 이전 행과 같을 때는 Load Immediate조차 할 필요가 없도록 더 나아갈 수도 있죠. 등등. 이 기법은 예전에 Macintosh용 FrameMaker에서 Gus Fernandez가 구현해서 사용했는데(그는 추가 최적화에 미쳐 날뛰었습니다).
- karmakaze
정말 대단한 프로젝트입니다. 요즘 레트로 컴퓨터는 성능이 넘쳐나서 큰 프레임 버퍼를 쓸 수 있고, 그걸 프로그래밍하는 것이 예전처럼 하드웨어에 밀착된 느낌, 그 더 친밀했던 감각을 주지 않죠.
이 구현은 제 초기 경험 두 가지를 떠올리게 합니다. Atari 8-bit에서 디스플레이 리스트를 프로그래밍하던 것과 HP PCL 5e 인터프리터(짧은 래스터 밴드 버퍼 포함)를 다루던 것이죠. VCS/2600의 128바이트 빔 레이싱까지는 깊이 들어가지 않았지만, 직접 만든 게임과 데모를 위해 디스플레이 리스트 인터럽트를 실시간으로 코딩하는 일은 꽤 했습니다. Atari Antic 디스플레이 리스트 시스템은 정말 훌륭하다고 생각했는데(Amiga도 만든 Jay Miner에게 감사합니다), 그 비슷한 것을 다시 보기까지는 OS/2 Presentation Manager나 Java FX 때까지 기다려야 했습니다.
PCL 인터프리터가 아마 가장 비슷한 형태였는데, 수백 줄짜리 순환 버퍼를 사용했죠. y 기준으로 정렬된 객체들로 '렌더링'되고, 이 객체들은 나중에 렌더링/래스터화되어야 했습니다. 각 객체는 최대 255픽셀(0.85인치) 높이로 잘렸고, 빔이 아직 Y - buffer_height를 렌더링 중인 랩어라운드 스캔 라인을 지나기 전에는 그릴 수 없었기 때문에 역방향 max-y 순서를 사용했습니다.
- codazoda
저는 마이크로컨트롤러용 레트로 BASIC 인터프리터인 BASIC32를 만들고 있습니다. 한 번만 플래시하면 새로운 프로젝트를 쉽게 많이 만들 수 있도록 하려는 거죠.
저자의 접근 방식에서 포기하게 되는 것은 '읽기'입니다. 화면이 쓰기 전용이 되는 거죠. 읽기가 필요한 함수는 몇 개뿐입니다. 픽셀의 현재 색을 가져오거나, 플러드 필이나 페인트 같은 연산을 하는 경우입니다.
저는 BASIC의 레트로 느낌을 노렸기 때문에 이런 것들을 지원하고 싶어서 프레임 버퍼를 선택했습니다. 기술적으로 그렇게 멋지지는 않죠. RP2350에서는 RAM이 종종 KB 단위로 제한되기 때문에 낮은 해상도와 낮은 비트 레이트가 필요합니다.
RAM이 4MB나 8MB인 ESP32-S3 변형으로 넘어가면 프레임 버퍼가 훨씬 쉬워집니다.