핵심 정리
| 항목 | 의미 |
|---|---|
| Pass | shadow, G-buffer, lighting, post-process 같은 작업 단위 |
| Resource | texture, buffer, depth target 같은 입출력 |
| Dependency | 어떤 pass가 어떤 resource를 읽고 쓰는지 |
| Lifetime | resource가 필요한 프레임 구간 |
| Barrier | 읽기/쓰기 상태 전환과 동기화 |
구조
현대 렌더러는 한 번의 draw로 화면을 만들지 않습니다. shadow, depth prepass, G-buffer, lighting, reflection, post-process, UI 같은 pass가 여러 render target과 buffer를 주고받습니다.
shadow pass -> shadow map
gbuffer pass -> gbuffer textures
lighting pass -> hdr color
post pass -> back bufferrender graph는 이 pass와 resource 관계를 그래프로 표현합니다. 각 pass는 무엇을 읽고 무엇을 쓰는지 선언하고, 시스템은 실행 순서, resource lifetime, barrier, 임시 texture 재사용을 계산합니다.
이 구조가 없으면 pass가 많아질수록 “어떤 texture가 언제 생성되고 언제 읽히는지”를 사람이 직접 추적해야 합니다. render graph는 복잡한 프레임 구성을 명시적으로 관리하게 해 줍니다.
Resource lifetime
temporary render target은 프레임 전체에서 계속 살아 있을 필요가 없습니다. render graph는 마지막 사용 이후 resource를 재사용하거나 해제할 수 있어 메모리 사용량을 줄일 수 있습니다.
설계 기준
| 상황 | render graph에서 볼 것 |
|---|---|
| pass 순서가 복잡함 | dependency 선언 |
| 임시 render target이 많음 | lifetime, aliasing |
| GPU barrier가 많음 | resource state transition |
| 후처리 체인이 김 | pass merge 가능성 |
| 디버깅이 어려움 | pass/resource 이름과 시각화 |
render graph는 성능 최적화 도구이기도 하지만, 먼저 구조화 도구입니다. 렌더링 결과가 어디서 만들어지고 어디서 소비되는지 보이게 만드는 것이 핵심입니다.
주의할 점
render graph가 있다고 자동으로 빠른 렌더러가 되지는 않습니다. pass가 너무 잘게 쪼개지면 barrier, render target 전환, bandwidth 비용이 늘 수 있습니다.
또 외부 resource나 async compute를 섞을 때는 lifetime과 synchronization을 더 명확히 해야 합니다. 그래프 밖에서 resource를 몰래 읽거나 쓰면 의존성 분석이 깨집니다.