체셔's blog

Tessellation은 기하를 '런타임 생성 데이터'로 바꿨고,
Compute Shader는 연산을 '정식 워크로드'로 분리했다.

 지난 시간에는 DX10/SM4로 넘어가며 Unified Shader라는 공용 셰이더 코어 풀에 대해서 다뤘습니다. 이번 시간에는 DX11(SM5)에 새롭게 추가된 Tessellation과 Compute Shader에 대해 알아보겠습니다.

Tessellation의 등장

 그래픽이 발전함에 따라 거리에 따른 최적화인 Level Of Detail(LOD)가 많이 발전하게 되었습니다. 거리에 따라 폴리곤 수를 줄임으로써 깜빡임도 완화시키며 기하 aliasing 문제도 어느정도 해결하고 렌더링을 진행할 폴리곤 수도 줄어드니 1석 2조의 해결책이었죠. GPU Level에서도 기하 디테일을 정적인 폴리곤(Asset Level)로 들고가는 방식의 비용을 줄이고, 런타임에서 연속적으로 LOD와 실루엣을 개선하려는 니즈가 촉발했습니다.

 DX11(SM5) 탄생 직전에 와서는 Programmable Pipeline 자체도 성숙해졌고, 단계 추가를 감당할 수 있는 설계 및 검증 역량도 증가하였습니다. 그리고 GPU 또한 메모리와 대역폭의 압박이 완화되어 초고폴리 저장 대신 필요시 생성이 더 유리해졌죠. 그리하여 고정기능으로 Tessellator + Hull Shader / Domain Shader를 결합하여 표준 파이프라인에 추가할 수 있었습니다.

Compute Shader의 등장

 DX11/SM5에서 또 하나의 큰 축은 Compute Shader(DirectCompute)입니다. 이 시점부터 GPU의 병렬 연산을 그래픽 파이프라인(픽셀 셰이더 등)에 억지로 끼워 넣는 방식이 아니라, 별도의 “계산 워크로드”로 분리해 다룰 수 있는 표준 경로가 강화됩니다.

 Compute Shader가 보급되기 전에는 VS / PS로 GPGPU(General-Purpose computing on Graphics Processing Units)를 진행하여 알고리즘을 돌린 사례가 많았습니다. 데이터를 텍스처나 렌더 타겟으로 포장하고 VS/PS를 커널처럼 사용해 여러 패스로 핑퐁하는 방식이 흔했습니다. 게임에서는 블룸, 톤매핑, 가우시안 블러, SSAO 같은 화면 공간 처리들은 ‘그래픽 파이프라인 기반의 데이터 병렬 계산’ 패턴으로 구현되어 왔고, 산업 영역에서도 영상/신호 처리, 과학 계산, 금융 등에서 GPU 병렬 연산 수요가 점점 커지고 있었습니다.

 이런 니즈가 커지는 상황에서, GPU의 대량 병렬 실행을 안정적으로 수행하는 기반이 성숙하고(스케줄링/실행 모델), 리소스·버퍼 접근 모델(쓰기/구조화 데이터 등)도 강화되면서, 그래픽 셰이더에 억지로 넣던 작업을 Compute 워크로드로 분리할 수 있게 됩니다. 결과적으로 이후의 GPGPU/머신러닝 같은 데이터 병렬 분야가 GPU를 더 직접적으로 활용할 수 있는 토대가 마련됩니다.

데이터 모델의 변화

 DX11/SM5 이전에는 Asset(Mesh, Texture, ...)처럼 "미리 만든 데이터"를 가져와 렌더링하는 비중이 컸습니다. 하지만 DX11/SM5 세대에 들어서며 테셀레이션, 시뮬레이션, 후처리 등으로 인해 GPU가 프레임 안에서 새 데이터를 생성 및 갱신하는 비중이 커졌습니다. 즉, 데이터는 더 이상 입력만이 아니라 "중간 산출물"이 되었습니다.

 데이터 구조가 단순했던 텍스처나 상수에서 "구조화 데이터"로 확장됐습니다. 조명 리스트, 파티클 상태, 타일 / 클러스터 정보, 누적 결과 등. "그림"이 아니라 "테이블 혹은 레코드"에 가까워졌습니다. SM5 세대는 이런 데이터를 GPU에서 다루기 위한 구조가 더 자연스러워지고, 결과적으로 GPU 워크로드는 점점 그래픽 + 데이터 처리의 혼합이 되게 됩니다.

워크로드 모델의 변화

 그렇게 프레임은 [기하 처리] => [래스터라이즈] => [픽셀 셰이딩] => [출력]이라는 단일 파이프라인이 아닌 여러 작업(기하 세밀화, 조명 누적, 후처리, 시뮬레이션, 누적/정리 연산 등)으로 쪼개지는 "작업들의 그래프"가 되었습니다. 그 작업들이 서로의 결과를 다시 입력받습니다. 그렇게 프레임은 점점 데이터 의존성을 가진 패스들의 연결 구조가 됩니다. Compute Shader 또한 계산 워크로드로 분리되면서 렌더링 단계의 제약(출력 형태, 파이프라인 규칙)에 덜 묶인 방식으로 설계할 수 있게 됩니다.

 거기에 읽기 전용 리소스 중심에서 "쓰기 / 갱신 가능한 리소스" 비중 또한 커지면서 GPU는 단순 출력 장치가 아니라 중간 결과를 저장하고 재사용하는 계산 공간이 됩니다. 그것은 단순히 그리기(Draw) 단위가 아니라 Dispatch와 Pass 단위로 사고해야 한다는 것입니다. 화면 결과는 더 이상 "몇 번 그렸나"만으로 설명되지 않습니다. 어떤 작업을 그래픽으로 수행했고, 어떤 작업을 컴퓨트로 수행했으며, 그 사이에 어떤 데이터가 오갔는지가 핵심이 됩니다. 엔진 관점에서는 프레임을 Pass의 집합으로 보고, 각 Pass의 입력과 출력 리소스를 명시적으로 관리하게 됩니다.

 병렬성의 핵심은 "연산량"에서 "데이터의 이동, 합치기"로 이동합니다. 단순히 많이 돌리는 것에서 끝나는 것이 아닙니다. 여러 스레드가 만든 결과를 합치거나 동일 자원에 동시에 접근할 때 규칙이 필요한데 SM5 세대 이후로는 "무엇을 계산하냐"만큼 "결과를 어떻게 축적하고 정리하는지"가 워크로드 설계의 중심으로 올라옵니다.

 화면 품질의 무게중심 또한 "픽셀 셰이딩" 단일 단계에서 "프레임 전체 구성"으로 이동합니다. DX10(SM4)에서 이미 픽셀 작업과 화면 공간 패스 비중이 커졌다면, DX11(SM5)에서는 그 흐름이 더 강화되어 품질은 특정 셰이더 한 방이 아니라 여러 패스의 조합과 데이터 재사용에서 만들어집니다. 조명, 후처리, 시뮬레이션이 서로 데이터를 주고받는 구조가 자연스러워졌습니다.

렌더링 엔진의 책임

 결국 렌더링 엔진의 책임이 단순히 "셰이더 작성"에서 그치지 않고 "파이프라인과 리소스 오케스트레이션"으로 확장되게 됩니다. 이젠 셰이더 한 개를 잘 짜는 것만으로는 부족해집니다. 어떤 리소스가 언제 생성되고, 어떤 단계에서 읽히고, 어떤 단계에서 갱신되는지, 그리고 그 순서가 맞는지(의존성)가 엔진 구조의 핵심이 됩니다. 즉, 엔진은 점점 워크로드 스케줄러 + 리소스 매니저의 성격을 띄게 됩니다.

끝으로

 테셀레이션은 기하를 런타임 데이터 생성 대상으로 만들었고, 컴퓨트는 비그래픽 연산을 정식 워크로드로 분리했습니다. 이 둘이 합쳐지면서, 프레임은 데이터 흐름을 가진 작업 그래프로 재정의되고, 이후의 렌더링 / 시뮬레이션 / 머신러닝 같은 데이터 병렬 워크로드가 GPU로 더 자연스럽게 이동할 수 있는 기반이 형성될 수 있었습니다.

다음글

이전글