CPU-bound vs GPU-bound과 렌더링 비용

기본 패턴

text

Profiler로 CPU 프레임 비용 확인
Frame Debugger로 draw call 흐름 확인

프레임이 느리다고 해서 곧바로 "렌더링이 무겁다"거나 "스크립트가 느리다"고 단정하면 안 됩니다. 먼저 CPU-bound인지 GPU-bound인지 구분해야 해결 방향이 달라집니다.
profiler에서 메인 스레드와 렌더 스레드가 두드러지면 CPU 쪽 병목을 의심할 수 있고, 스크립트/physics/UI rebuild를 먼저 봐야 합니다. 반대로 해상도나 post-processing, 그림자, 복잡한 material 효과를 낮췄을 때 프레임이 크게 좋아지면 GPU 부담일 가능성이 큽니다.
draw call 수만 보는 습관은 초보 단계에서는 도움이 되지만, 실제로는 SetPass, material 변경, batching 여부, 오버드로우, pass 수를 함께 봐야 합니다. Frame Debugger는 이 흐름을 눈으로 확인하게 도와줍니다.
SRP Batcher와 GPU Instancing은 같은 재질/셰이더를 더 효율적으로 처리하게 만드는 대표 기법이지만, 모든 프로젝트에서 자동으로 큰 이득이 나는 것은 아닙니다. 구조와 material 사용 방식이 맞아야 효과가 납니다.
좋은 진단 흐름은 "프레임이 느리다 -> CPU/GPU 가설을 세운다 -> profiler와 frame debugger로 증거를 모은다 -> batching, material, 그림자, 해상도, UI rebuild 중 무엇이 실제 원인인지 좁힌다"입니다.

점검 대상	무엇을 보나
Profiler	CPU 프레임 시간, 메인 스레드, 렌더 스레드, 스크립트/UI/physics 비용
Frame Debugger	draw call 순서, material 변경, pass 수, overdraw 단서
SRP Batcher	같은 셰이더 구조의 드로우 효율 개선 여부
GPU Instancing	동일 mesh/material 반복 렌더링 최적화 가능성
핵심 질문	병목이 CPU인지 GPU인지 먼저 구분했는가

draw call 숫자 하나만 보고 최적화 방향을 정하면 엉뚱한 곳을 손댈 수 있습니다. GPU 비용, shader complexity, UI rebuild, physics, script cost가 서로 다른 문제라는 점을 먼저 분리해서 보세요.

4 sources