Hacker News 의견

• 논문에서 정의한 struct Strip 구조체가 64 비트(8바이트) 크기처럼 보이는데, 본문에서는 한 스트립이 64 바이트라고 되어 있음
  계산해보면 실제로는 259×8 + 7296 ≈ 9KB 정도로 보임. 뭔가 단위가 잘못된 것 같음

  • 작성자임. 맞음, 비트와 바이트를 혼동한 실수였음. 지적해줘서 고맙게 생각함
  • 코드 전체를 살펴볼 시간은 없지만, 논문을 보면 멀티스레딩 관련 섹션이 있음
    단순한 오타일 수도 있지만, 각 스트립을 캐시 라인(64바이트) 단위로 할당했을 가능성도 있음.
    이렇게 하면 false sharing을 피할 수 있어서, 렌더러가 일부러 그렇게 했을 수도 있음
  • 나도 같은 생각임. 해당 문단에서 메모리 사용량이 과대평가된 것 같음.
    논문에서는 주로 실행 시간 비교에 초점을 맞췄고, 저장 공간 비교는 다루지 않았음

• Blaze: Parallel Rasterization on CPU도 함께 보면 좋음

  • 좋은 정보 고마움. 이 프로젝트는 몰랐는데, 벤치마크 수치가 꽤 인상적임
  • 데모가 정말 놀라울 정도로 빠름

• 프로젝트가 흥미로움. 3.9절을 보면 출력이 비트맵 형태라서, 결국 GPU로 이미지를 복사해야 할 것 같음
  Skia가 WebGPU로 이동하고 있고, WebGPU가 compute shader를 지원하니 2D 그래픽은 점점 이식성과 성능 면에서 해결된 문제로 보임
  다만 CPU 렌더러가 여전히 유용한 경우도 있음 — 예를 들어 웹 환경에서는 페이지 로드 시 셰이더를 런타임에 컴파일해야 하므로
  이론적으로는 JS JIT처럼 CPU 렌더러로 시작하고 GPU 셰이더가 준비되면 전환하는 구조도 가능할 듯함
  또 하나의 장점은 바이너리 크기가 작다는 점임. WebGPU(dawn 기반)는 꽤 큼
  참고 링크

  • 맞음, 출력은 비트맵이라 GPU로 업로드해야 함.
    더 큰 프로젝트에서는 Vello Hybrid라는 버전도 있는데, CPU에서 기하 연산을 하고 GPU에서 픽셀 페인팅을 처리함
    CPU 렌더러를 셰이더 컴파일 중에 사용하는 아이디어도 고려했지만 아직 구현하진 않았음
  • CPU 렌더러가 특히 유용한 곳은 테스트 러너임. 출력이 이미지나 스크린샷일 때 GPU로 복사할 필요가 없음
    오히려 GPU에서 렌더링하면 다시 이미지를 복사해야 하므로 비효율적임
  • 통합 메모리 아키텍처(예: Apple Silicon)에서는 GPU로 복사할 필요가 없음. 같은 메모리를 공유하므로 비용이 거의 없음

• 최근 수백만 개의 정점을 가진 고정밀 N-body 궤적을 렌더링하는 코드를 작성했는데,
  이 논문에서 제안한 RLE 표현을 GPU에서 구현하면 단순함을 유지하면서도 잘 작동할지 궁금함
  데모 영상

• 흥미로움. 비교된 렌더러들의 단일 코어 성능을 보고 싶음.
  그게 코드 효율성을 보여줄 것 같음. 인기 있는 렌더러들은 속도는 느리지만 CPU 사용량은 적을 수도 있음

  • 논문에 단일 코어 성능 비교 섹션이 있음
    또 Blend2D 공식 벤치마크나
    내가 추가 렌더러를 포함해 만든 vello_chart에서도 결과를 볼 수 있음

• 혹시 지도교수 중 한 명인 Raph Levien이 예전 Libart 라이브러리의 저자임?

• 약간 주제에서 벗어나지만, GitHub의 PDF 미리보기가 언제부터 일부 페이지만 로드하게 된 건지 궁금함
  예전처럼 전체 PDF를 한 번에 불러와서 브라우저가 렌더링하게 하는 게 더 좋을 것 같음

• 렌더러의 정확성(correctness) 을 검증할 수 있는 벤치마크가 있는지 궁금함

  • 원래 이런 목적을 위해 Cornell box가 만들어졌음
    실제 장면의 라디오시티를 측정해 시뮬레이션 결과와 비교하는 방식임
    실시간 렌더링에서는 Arnold나 Octane 같은 오프라인 렌더러를 기준으로 비교하기도 함
    Cornell box 위키
  • “정확성”이 무엇을 의미하는지에 따라 다름
    현실을 완벽히 재현하는 렌더러는 없고, 모두 어느 정도 트레이드오프를 감수함