핵심 정리
| 항목 | 역할 |
|---|---|
| Pipeline state | shader, input layout, raster/depth/blend, render target format 묶음 |
| Dynamic state | viewport, scissor, blend factor처럼 draw 중 바뀌는 상태 |
| Resource binding | texture, buffer, sampler, constant를 shader에 연결 |
| Descriptor / view | resource를 shader가 읽을 수 있는 형태로 설명 |
| Pipeline layout / root signature | shader가 binding slot을 해석하는 약속 |
pipeline state
-> 어떤 shader와 고정 기능 상태로 그릴지
resource binding
-> 그 shader가 어떤 texture/buffer/sampler를 읽을지구조
Pipeline state는 GPU가 geometry를 어떻게 해석하고 화면에 합성할지를 결정하는 큰 상태 묶음입니다. Direct3D 12 기준으로 PSO에는 shader bytecode, input vertex format, primitive topology type, blend state, rasterizer state, depth stencil state, render target format, multisampling 정보, root signature 같은 값이 들어갑니다. 이런 값은 서로 의존성이 크기 때문에 런타임 draw마다 조립하기보다 초기화 시점에 만들어 두고 빠르게 전환하는 구조가 일반적입니다.
Resource binding은 별도 축입니다. shader가 읽을 texture, constant buffer, storage buffer, sampler를 descriptor, descriptor table, descriptor heap, root signature 같은 구조를 통해 연결합니다. 즉 같은 pipeline state라도 다른 material texture와 per-object constant를 바인딩하면 다른 물체를 그릴 수 있습니다.
같은 PSO:
- same vertex shader
- same pixel shader
- same blend/depth/raster state
draw마다 변경:
- vertex/index buffer
- material texture descriptor
- per-object constant
- render target 또는 viewport자주 바뀌는 상태와 비싼 상태를 분리한다
PSO 전환은 shader와 고정 기능 상태를 함께 바꾸는 큰 전환입니다. 반면 descriptor나 small constant 변경은 draw마다 자주 일어나는 쪽입니다. 렌더러는 보통 material, shader, render target 기준으로 draw를 정렬해 PSO와 큰 binding 전환을 줄이고, object transform이나 색상 같은 작은 값만 자주 바꿉니다.
선택 기준
| 상황 | 먼저 볼 것 |
|---|---|
| draw마다 shader가 바뀜 | material 정렬, PSO 캐시 |
| 같은 shader인데 texture만 바뀜 | descriptor/bind group 재사용 |
| viewport나 scissor만 바뀜 | dynamic state로 처리 가능한지 확인 |
| material variant가 많음 | shader permutation과 PSO 수 제한 |
| per-object 값이 작음 | constant/root constant/주기적 buffer upload |
| binding 비용이 큼 | descriptor table, bind group, material batching |
좋은 렌더러는 "무엇을 그릴지"와 "어떤 상태로 그릴지"를 분리합니다. mesh와 material 데이터가 바뀌더라도 pipeline state가 계속 바뀌지 않도록 batch 기준을 잡는 것이 핵심입니다.
주의할 점
Pipeline state와 resource binding을 같은 비용으로 보면 최적화 방향이 흐려집니다. PSO를 draw 중 계속 만들거나, material마다 shader variant를 과도하게 늘리면 CPU submission과 driver validation 비용이 커집니다.
실패 예시
- object마다 작은 색상 값만 다른데 material을 전부 별도 pipeline으로 만듦
- 결과: PSO 전환과 shader variant가 늘어 draw 정렬이 어려워짐
- 대응: pipeline은 공유하고 per-object constant나 instance data로 차이를 넘긴다참고 링크
2 sources