워크로드 불균형을 흡수한 공용 코어 풀,
엔진 데이터 모델이 된 PBR 머터리얼,
언리얼엔진의 전제가 바뀌었다.

 지난 글에서 DX10 / SM4 시점의 Unified Shader(공용 셰이더 코어 풀) 전환을 다뤘습니다. 이 변화는 "파이프라인 단계가 사라졌다."가 아니라 Programmable 단계(VS, GS, PS)가 같은 실행 자원을 공유하게 됐다는 의미였습니다.

 

 엔진 관점에서 중요한 건, 이 하드웨어 변화가 단순히 GPU 내부 구조에 그치지 않고 렌더러 설계의 전제를 바꿨다는 점입니다. UE4의 초기 렌더링 설계는 이 전제를 강하게 반영한 사례라고 볼 수 있습니다.

UE3 시대의 한계

 UE3는 DX9(SM3) 중심 세대에서 성장했고, 그 시절 GPU는 VS / PS가 상대적으로 분리된 구조를 갖는 경우가 많았습니다. 그래서 한 프레임에서 픽셀 작업이 과도해지거나(혹은 반대로 정점 / 기하 작업이 과도해지면) 특정 단계가 병목이 되고 다른 단계 자원은 놀게 되는 로드 불균형이 구조적으로 발생하기 쉬웠습니다.

 

 또한 당시에는 "픽셀 단계에서 하고 싶은 일"이 지금만큼 과감하게 커지기 어려웠습니다. 화면 해상도, 셰이딩 복잡도, 포스트 프로세스 규모 자체가 지금보다 작았고, GPU가 이를 감당하기 위한 동적 스케줄링 / 대규모 병렬 실행 기반도 점진적으로 성숙해가는 중이었습니다.

UE4, 화면 품질은 픽셀 작업이 만든다.

DX10(SM4) 이후에는 Programmable 단계가 공용 코어 풀을 공유하면서, 프레임마다 달라지는 부하를 더 유연하게 흡수할 수 있는 기반이 생겼습니다. 엔진 입장에서 이건 간단히 말해

  1. 픽셀 작업을 더 공격적으로 늘려도 하드웨어가 그 부담을 흡수할 여지가 커졌다.
  2. 결과적으로 "화면 품질"을 픽셀 단계 / 화면 공간 패스에서 더 많이 만들 수 있게 됐다.

입니다.

 

 UE4의 초기 렌더링 방향은 이 흐름과 맞물립니다.UE4는 초기부터 Deferred Rendering을 기본 축으로 가져가고, 머티리얼 / 조명 / 후처리를 "여러 패스의 조합"으로 구성하는 쪽으로 무게가 실립니다.

UE4 전기의 핵심

 UE4의 초기 렌더러를 이해할 때 중요한 포인트는 "한 번에 끝내는 파이프라인"이 아니라, 프레임을 여러 단계의 화면 공간 처리로 쪼개는 방식입니다. 대표적인 흐름은 다음처럼 요약할 수 있습니다.

  • GBuffer 생성 (기하 정보 / 머티리얼 속성 저장)
  • 조명 계산 (여러 광원을 누적)
  • 후처리 (톤매핑, 블룸, 컬러 그레이딩 등)

 이 구조는 "픽셀 단계가 프레임 비용의 큰 비중을 차지한다."는 현실과 자연스럽게 연결됩니다. 즉, UE4 전기의 렌더링 설계는 픽셀 작업 비중 증가를 전제로 안정적으로 동작하도록 구성되어 있습니다.

머티리얼 시스템

 UE4는 머티리얼을 단순한 셰이더 코드가 아니라, 엔진 내부에서 관리되는 일관된 모델(그래프 / 파라미터 / 퍼뮤테이션)로 다루는 비중이 커집니다. 이 변화의 의미는 다음입니다.

  • 머티리얼이 복잡해질수록 "코드 몇 개"로 관리하기 어렵다.
  • 렌더링이 여러 패스로 쪼개질수록, 동일한 머티리얼 정보가 여러 단계에서 재사용된다.
  • 결국 엔진은 머티리얼을 데이터 모델로 표준화하고, 필요에 따라 셰이더 코드를 생성 / 변형하는 쪽으로 구조가 이동한다.

 UE4 전기에서 "렌더러의 복잡도"가 증가하는 만큼, 이를 감당하기 위한 엔진 내부 구조(머티리얼 / 셰이더 관리)가 같이 강화됩니다.

Physically Based Rendering (PBR)

Epic Games, 물리 기반 머티리얼에서 발췌

 

 PBR은 머티리얼을 "예쁜 값 몇 개"가 아니라 물리 기반 파라미터 집합으로 강제합니다.

  • Base Color
  • Metallic
  • Roughness
  • Specular / IOR 성격의 값
  • Normal
  • AO 등

 즉, 조명 / 환경이 달라도 일관된 반응을 내기 위해, 엔진은 머티리얼 입력을 표준화하고 그 의미를 고정해야 합니다. 이게 머티리얼 시스템을 "엔진의 핵심 데이터 모델"로 끌어올린 큰 이유 중 하나입니다.

 

 하지만 머티리얼 시스템에는 PBR 말고도 “엔진이 감당해야 하는 운영 요소”가 같이 들어갑니다.

  • 머티리얼 그래프를 셰이더 코드로 변환(코드 생성/컴파일)
  • 다양한 렌더 패스에서의 동일 머티리얼 재사용(GBuffer, Depth, Shadow, Velocity 등)
  • Feature/플랫폼별 퍼뮤테이션 관리(옵션 조합 폭발)
  • 파라미터/인스턴싱(런타임 조정)

그래서 관계는 보통 이렇게 보는 게 안전합니다.

  • PBR은 머티리얼 시스템의 의미 / 표준 입력을 강제한 핵심 원인
  • 머티리얼 시스템은 거기에 더해 엔진 운영(생성/컴파일/퍼뮤테이션/패스 재사용)까지 포함하는 더 큰 구조

맺음말

 정리하면 UE4 전기의 렌더링 전제는 파이프라인 단계가 바뀌어서가 아닌 Unified Shader 이후의 GPU에서 Programmable 단계가 공용 코어 풀을 공유하게 되면서 프레임 워크로드를 더 유연하게 흡수할 수 있게 된 점에서 시작합니다. 그 위에서 UE4는 Deferred + 다중 패스 + 머티리얼 / 셰이더 관리 구조를 엔진레벨로 끌어올렸고, PBR은 그 머티리얼 시스템의 표준 입력과 그 의미를 고정하는핵심 축으로 작동했습니다. 다음 글에서는 DX11 / SM5 그리고 UE4 후기로 넘어가며 이 흐름이 어떤 식으로 확장 및 결합하는지 이어서 보겠습니다.

다음글

 

UE4 후기 : DX11(SM5)과 모던 렌더링의 안정화

GPU의 역사 - 4 : DX11(SM5), Tessellation과 Compute ShaderGPU의 역사 - 3 : DX10/SM4와 Unified Shader 전환GPU의 역사 - 2 : SIMD에서 SIMT로, Branch DivergenceGPU의 역사 - 1 : FFP에서 SIMD까지그래픽카드의 한계 2000년대 초반

chessire.tistory.com

이전글

 

GPU의 역사 - 4 : DX11(SM5), Tessellation과 Compute Shader

GPU의 역사 - 3 : DX10/SM4와 Unified Shader 전환GPU의 역사 - 2 : SIMD에서 SIMT로, Branch DivergenceGPU의 역사 - 1 : FFP에서 SIMD까지그래픽카드의 한계 2000년대 초반의 GPU는 FFP(Fixed Function Pipeline)중심이었고, 지금

chessire.tistory.com

 

UE3 - Forward Rendering을 넘어 Deferred Rendering으로

UE2의 Overlay Shader와 초기 Post Process EffectGPU의 역사 - 1 : FFP에서 SIMD까지그래픽카드의 한계 2000년대 초반의 GPU는 FFP(Fixed Function Pipeline)중심이었고, 지금처럼 복잡한 셰이더 기반 렌더링이 불가능했

chessire.tistory.com