Quick Comparison

draw call 수는 단서일 뿐 목표가 아닙니다. Unity에서 어떤 최적화가 실제로 적용되는지는 render pipeline, shader variant, mesh·material·lightmap·vertex attribute, static flag, instance data에 따라 달라집니다. CPU submission이 느린지, GPU fragment가 느린지 먼저 측정합니다.

측정 순서
1. target device에서 CPU/GPU frame time을 분리한다.
2. Frame Debugger로 실제 draw sequence와 batch break를 확인한다.
3. Profiler/Rendering overlay에서 SRP Batcher·instancing 적용 여부를 본다.
4. GPU 병목이면 transparent·shader·resolution·overdraw를, CPU 병목이면 setup·culling·batch 조건을 바꾼다.

batching과 instancing의 실제 조건

SRP Batcher는 Scriptable Render Pipeline에서 compatible shader material의 GPU setup 비용을 줄이는 경로입니다. static batching은 static GameObject의 mesh data를 미리 묶지만 memory·storage overhead가 있고, Unity는 여전히 mesh를 개별 cull할 수 있습니다. GPU instancing은 같은 mesh의 여러 instance를 그리는 데 맞지만 shader와 instance data 조건을 충족해야 합니다. dynamic batching은 일부 작은 mesh에서 CPU가 vertex를 변환해 묶는 방식이라 항상 이득이 아닙니다.

Unity는 한 renderer에 여러 방식이 표시돼도 모두 동시에 적용하지 않을 수 있습니다. 예를 들어 static batching이 성공하면 그 GameObject의 GPU instancing은 사용되지 않을 수 있고, instancing이 적용되면 dynamic batching은 적용되지 않을 수 있습니다. “같은 material이니 draw call 하나”처럼 추정하지 말고 Frame Debugger에서 draw sequence와 batch break 이유를 봅니다.

overdraw와 GPU 병목

overdraw는 같은 screen pixel에 여러 fragment가 겹쳐 실행되는 현상입니다. transparent particle, full-screen UI, foliage, post process가 화면을 많이 덮으면 draw call이 적어도 fill rate와 fragment shader 비용이 클 수 있습니다. opaque object를 적절히 먼저 그려 depth rejection이 가능한 경우와, alpha blend 때문에 뒤의 결과를 알아야 하는 transparent object는 최적화 방향이 다릅니다.

overdraw를 줄일 때는 particle 수·크기·lifetime, UI hierarchy와 alpha layer, shader sampling, render order, camera resolution을 target device에서 비교합니다. visual quality를 유지할 수 있다면 screen coverage를 줄이는 것이 material을 무조건 합치는 것보다 직접적인 개선일 수 있습니다.

수치를 결과로 읽기

rendering statistics와 draw call count는 서로 다른 pipeline·platform에서 직접 비교하기 어렵습니다. scene 하나의 숫자를 줄이는 대신 memory가 늘거나 culling이 나빠질 수 있으므로, 변경 전후의 CPU/GPU ms, memory, Frame Debugger capture, target resolution을 함께 기록합니다. mobile·XR·desktop은 병목과 supported batching path가 다를 수 있습니다.