본문으로 건너뛰기
피드

CPU로 3D 래스터라이저를 밑바닥부터 만들어보는 튜토리얼 시리즈

frontend 약 4분
vote
0
댓글
북마크

대학 OpenGL 강사가 GPU 래스터라이제이션을 CPU로 직접 구현하는 튜토리얼 시리즈를 시작함. 첫 파트에서는 SDL2 윈도우 생성, 드로우 버퍼 설계, 화면 클리어, 자체 그래픽스 API 설계까지 다룸.

  • 1

    SDL2 기반 CPU 래스터라이저 엔진을 밑바닥부터 구현하는 튜토리얼

  • 2

    기존 OpenGL/Vulkan 대신 자체 API를 설계하는 방향 선택

  • 3

    1920x1080에서 clear 0.3ms, 전체 프레임 3.7ms로 약 270 FPS

  • 4

    GPU가 해주는 일을 직접 구현하면서 그래픽스 프로그래밍을 깊이 이해하는 것이 목적

  • 대학에서 OpenGL 강의하는 개발자가 "GPU가 해주는 래스터라이제이션, 직접 CPU로 구현하면 어떨까?" 하는 가려움을 참지 못하고 시작한 프로젝트임. 삼각형 하나 그리는 데 성공했더니 "이거 풀 렌더링 엔진으로 키워볼까?" 하는 두 번째 가려움이 왔고, 결국 튜토리얼 시리즈로 문서화하기로 함

  • CPU 래스터라이저가 실용적이냐고? 당연히 아님. 하지만 정당한 이유는 있음:

    • GPU가 내부적으로 뭘 하는지 진짜 이해하게 됨
    • Nanite 같은 컴퓨트 셰이더 기반 소프트웨어 렌더링의 사전 학습으로 좋음
    • FPGA로 자작 GPU 만들기 전 스테핑 스톤
    • 그리고 뭐니 뭐니 해도 재밌음
  • 첫 번째 파트는 "화면 지우기"부터 시작함. SDL2로 윈도우 만들고, 드로우 버퍼(서피스) 생성하고, 고정 색상으로 채우는 것까지가 목표임. 아주 겸손한 시작

드로우 버퍼 설계

  • SDL2 윈도우 서피스에 직접 쓰는 대신 자체 RGBA8 서피스를 만들어서 복사하는 방식을 선택함. 이유는 윈도우 서피스의 포맷을 컨트롤할 수 없기 때문 (시스템마다 다름)
  • SDL_SetSurfaceBlendMode으로 자동 블렌딩도 꺼버림. 렌더링 엔진을 직접 만드는 마당에 블렌딩까지 SDL한테 맡길 순 없다는 철학

API 설계 철학

  • OpenGL이나 Vulkan을 그대로 구현할 수도 있었지만, 기존 API들은 두 부류로 나뉨:

    • 오래돼서 수십 년 된 설계 결정의 기이함을 80% 시간 써서 처리해야 하거나
    • 지나치게 장황해서 스펙 맞추는 글루 코드가 80%이거나
  • 그래서 제3의 길을 선택: 자체 API 설계. 기존 그래픽스 API를 참고하되 더 심플하고 깔끔하게 만드는 방향

  • 기본 타입부터 정의함. color4ub (RGBA 각 1바이트), vector4f (부동소수점 4D 벡터), image_view (픽셀 배열 + 가로세로 크기) 같은 구조체를 만들고, clear() 함수 하나로 시작

성능 측정

  • 1920x1080 해상도 기준, clear 호출은 약 0.3ms, SDL 블리팅은 약 3.3ms, 전체 프레임은 약 3.7ms로 약 270 FPS가 나옴
  • clear는 꽤 빠르지만 블리팅이 느린 편. 플랫폼 동기화 오버헤드가 있을 듯
  • 물론 이게 CPU 래스터라이저니까 640x480 정도에서 간단한 씬이 아니면 60 FPS 유지가 힘들 거라는 경고도 미리 해둠. GPU한테 감사해야 하는 이유를 체감하게 될 거라는 거임

그래픽스 프로그래밍의 기초를 이해하는 가장 좋은 방법은 직접 만들어보는 것이라는 걸 잘 보여주는 시리즈. Nanite 같은 소프트웨어 렌더링을 이해하고 싶다면 좋은 시작점.

댓글

댓글

댓글을 불러오는 중...

frontend

요즘 픽셀 폰트가 그냥 복고 감성이 아닌 이유

1990년대 기기 화면 느낌을 현대 폰트 시스템으로 재해석한 픽셀 폰트 몇 가지를 소개한 글이다. 핵심은 예쁜 복고풍 글자 모양만이 아니라, 실제 제품에서 쓸 수 있게 기준선, 자간, 메타데이터, 세로 메트릭까지 챙기는지가 중요하다는 점이다.

frontend

HTML의 `<dl>`이 생각보다 쓸모 많은 이유

이 글은 HTML의 description list, 즉 `<dl>`, `<dt>`, `<dd>`가 단순 용어 사전용 태그가 아니라 이름-값 쌍 UI를 표현하는 꽤 강력한 시맨틱 도구라고 설명한다. 숙소 편의시설, 요금 내역, 기술 용어 설명, 게임 능력치표처럼 흔한 패턴을 중첩 `<div>` 대신 의미 있는 HTML로 만들 수 있다는 얘기다.

frontend

HTML을 캔버스 안에 넣는 데모 모음이 등장함

구글 크롬 랩스 저장소에 HTML-in-Canvas 관련 데모와 프레임워크 지원 목록이 정리됐다. Duck Hunt 스타일 폼, 흔들리는 버튼, 셰이더 기반 페이지 전환, 천처럼 매달린 폼 같은 실험적 예제가 포함돼 있고 Three.js와 PlayCanvas 쪽 샘플도 연결돼 있다.

frontend

싱글 페이지 앱이 웹을 너무 비싸게 만들었다는 불평

이 글은 싱글 페이지 앱(SPA)이 사용자 경험을 좋게 만든다는 명분 아래 웹의 초기 로딩 비용, 도구 복잡도, 개발 진입 장벽을 키웠다고 비판한다. 페이스북 로그인 페이지의 CSS 3.8MB, 레딧 몇 개 클릭 후 33MB 다운로드 같은 숫자를 들며, 지금의 프론트엔드 생태계가 사람보다 대기업의 요구에 맞춰져 있다고 주장한다.

frontend

네이티브로 끝까지 가려다 텍스트에서 막힌 macOS 개발자의 고백

20년 가까이 macOS와 iOS 네이티브 개발을 해온 작성자가 SwiftUI, AppKit, TextKit 2로 마크다운 채팅 UI를 만들다 결국 WebKit과 Electron 쪽이 훨씬 낫다는 결론에 도달한 글이다. 문제는 성능 하나가 아니라 선택, 스트리밍, 스크롤, 접근성, 텍스트 상호작용 같은 ‘사용자가 당연히 기대하는 기본기’가 네이티브 조합에서 계속 깨진다는 점이다.