02. SRP 프레임 루프와 데이터 흐름(CPU↔GPU)

이 챕터는 “SRP는 결국 프레임마다 어떤 데이터를 만들고, 어떤 명령을 GPU로 보내는가”를 정리합니다. 이후 RenderGraph/CommandBuffer/Shader 상호작용을 이해하기 위한 기반입니다.

2.1 프레임의 두 층: 논리(렌더 패스 구성) vs 실행(GPU 명령)

URP에서는 이 분리가 특히 RenderGraph에서 선명합니다. RecordRenderGraph()가 논리를 기록하고, 이후 URP가 실행을 담당합니다.

ScriptableRenderContext는 결국 CommandBuffer에 쌓인 명령을 적절한 타이밍에 GPU로 제출합니다.

SRP/URP는 보통 카메라 단위로 렌더링을 수행합니다. 카메라마다:

같은 데이터가 바뀌기 때문입니다.

URP RenderGraph 경로에서는 ContextContainer frameData를 통해 여러 서브시스템이 공유하는 “이번 프레임의 데이터”가 전달됩니다. (구체 예시는 04. RenderGraph의 RecordRenderGraph 예제 참고)

무엇을 만들 때마다 다음을 점검하세요.

렌더링은 결국 “드로우 콜을 얼마나/무엇을/어떤 순서로” 내느냐의 문제입니다. 그 출발점이 컬링입니다.

SRP에서 컬링은 대체로 다음 흐름을 가집니다.

URP는 이 단계를 내부에서 수행하지만, Render Feature/Pass를 작성할 때도 “이 패스가 어떤 오브젝트를 대상으로 하는가”를 설계하려면 컬링과 필터링 개념을 알아야 합니다.

“무엇을 어떤 셰이더 패스로 그릴지”는 보통 다음으로 결정됩니다.

Render Feature로 “특정 레이어만” 오프스크린 RT에 그리거나, “특정 LightMode만” 강제 선택해 마스크를 만들고 싶다면 이 3종이 핵심 도구입니다.

Unity의 렌더링/컬링/잡 시스템에서는 NativeArray<T>가 자주 등장합니다.

핵심 이유:

“NativeArray는 뭔 역할이냐?”를 한 문장으로 요약하면:

렌더링에서 자주 다루는 “큰 배열 데이터(인스턴스/라이트/컬링 결과 등)”를
할당/GC/스레드 문제 없이 다루기 위한 컨테이너입니다.

주의: NativeArray는 수명 관리(Dispose)가 중요합니다.
이 책에서는 URP 내부 구현까지 파고들 때 핵심 개념만 소개하고, 실제 API 사용법/Job 패턴은 별도 자료로 확장하는 것을 권장합니다.

렌더링 디버깅에서 흔히 나오는 질문:

이 대부분은 CPU 명령 기록과 GPU 실행이 분리되어 있기 때문입니다.

따라서:

이 경계를 이해하면 RenderGraph의 “리소스 수명/의존성”이 왜 중요한지도 더 명확해집니다.