illustration of life

GPU Works Graphs(1)

illu_yun — Tue, 19 May 2026 16:22:59 +0900

원문 링크 : https://coburggraphicslab.github.io/files/Kuth25GWG.pdf
AMD link : https://gpuopen.com/learn/gpu-work-graphs/gpu-work-graphs-intro/?fbclid=IwY2xjawMmIAdleHRuA2FlbQIxMQABHvl4MRxkz6uzfhsgcnV6SgLYsQZoHE3HDRoOOCj6KsiYqLPplTJ3GkFz1yWC_aem_0q3oWG-YVfEeWqZ8Q2ZhKw

to 103page

오늘 SIGGRAPH에서 Work Graphs에 대한 강좌를 진행합니다.

코부르크 대학교와 AMD는 2023년 1월부터 바이에른 주의 지원을 받아 Work Graphs의 실질적인 연구에 공동으로 집중해 왔습니다.

지난 2년 반 동안 Work Graphs는 우리의 업무 환경을 지배해 왔으며, 이 새로운 기술을 활용하여 저희와 다른 연구자들이 지금까지 무엇을 했는지 간략하게 말씀드리고자 합니다.

우리가 연구를 진행하는 동안 Work Graphs는 샘플 코드가 포함된 미리보기로 제공되었고, Vulkan 지원이 추가되었으며, AMD는 여러 개의 Work Graphs 샘플을 게시했습니다.

Work Graphs Preview
https://gpuopen.com/learn/gpu-work-graphs/gpu-work-graphs-intro/
▪ Sample Code
https://github.com/GPUOpen-LibrariesAndSDKs/WorkGraphsHelloWorkGraphs
▪ Vulkan Support
https://gpuopen.com/gpu-work-graphs-in-vulkan/
▪ Work Graph Samples
https://gpuopen.com/learn/rgp-work-graphs/
https://gpuopen.com/learn/work_graphs_learning_sample/

게임 개발자 컨퍼런스(GDC) 2024에서 Work Graphs를 활용한 첫 데모를 선보였습니다. 또한, 연구 결과를 고성능 그래픽(HPG) 2024에 발표했습니다.

GDC 2024 - GPU Work Graphs: Welcome to the Future of GPU Programming
https://youtu.be/QQP6-JF64DQ?si=s1CA8AIouDfdZYom
GDC 2024 We reveal incredible Work Graphs perf, AMD FSR 3.1, GI with Brixelizer, and so much more
https://gpuopen.com/events/amd-at-gdc-2024/
GDC 2024 Work graphs and draw calls – a match made in heaven!
https://gpuopen.com/learn/gdc-2024-workgraphs-drawcalls/

Real-Time Procedural Generation with GPU Work Graphs
https://gpuopen.com/download/Real-Time_Procedural_Generation_with_GPU_Work_Graphs-GPUOpen_preprint.pdf

저희 연구는 2024년 3분기에 출시된 메시 노드를 활용합니다. 또한 works graph와 mesh node에 대한 내용을 담은 여러 블로그 게시물을 작성했습니다.^[각주:1]

웍스 그래프의 장점을 강조하는 데모 영상은 여기에서 확인하실 수 있습니다.
https://gpuopen.com/learn/gdc-2024-workgraphs-drawcalls/

GDC 데모와 HPG 논문이 많은 관심을 불러일으켜 2024년 네덜란드 브레다에서 열리는 그래픽 프로그래밍 컨퍼런스 마스터 클래스에 초청받았습니다. 바로 이 자리에서 Work Graph Playground 앱을 처음 출시했습니다. 이 수업에서도 이 앱을 사용할 예정입니다. 노트북을 가져오셨다면 Work Graph Playground 앱을 직접 사용해 보실 수 있습니다.

앱을 바이너리로 설치하려면 다음 단계를 따르세요. 지금 바로 설치하시기 바랍니다. 약 30분 후에 앱을 사용해 보세요.

GPU가 Work Graphs를 지원하지 않는 경우, WARP(소프트웨어 에뮬레이션) 어댑터를 사용하세요. DownloadWarpAdapter.bat 배치 스크립트를 사용하여 해당 DLL을 다운로드하세요.

GitHub 저장소의 지침에 따라 소스 코드에서 빌드할 수도 있습니다.

https://github.com/GPUOpen-LibrariesAndSDKs/WorkGraphPlayground
https://github.com/GPUOpen-LibrariesAndSDKs/WorkGraphPlayground/releases

앱 외에도 GDC 2025를 위해 Work Graphs를 사용하여 GPU에서 직접 식물을 생성하는 데모도 만들었습니다.

저희 데모에는 몇 주 전 HPG 2025에서 공유할 수 있었던 연구 결과가 가득합니다.

HPG에서 Bastian의 강연 영상은 여기에서 시청하실 수 있습니다: https://www.youtube.com/watch?v=SPWDLMc-9h4&t=26050s
전체 논문은 여기에서 확인하실 수 있습니다: https://diglib.eg.org/bitstream/handle/10.2312/hpg20251168/hpg20251168.pdf

6월에는 미리보기 단계를 포함하여 Work Graphs 출시 2주년을 기념했습니다. Work Graphs가 공식 발표된 지 1년 반도 채 되지 않았습니다. 따라서 상당히 새로운 기술입니다.

이 과정의 목표는 여러분께 Work Graphs의 사용법을 알려드리고, 이를 여러분의 애플리케이션에 직접 활용할 수 있도록 돕는 것입니다.

오늘 다룰 주제에 대한 간략한 개요는 다음과 같습니다.

Work Graphs의 강력한 기능을 보여주는 몇 가지 애플리케이션을 살펴보았습니다. 자세한 내용을 살펴보기 전에 먼저 핵심 질문부터 답해 보겠습니다.

왜 Work Graphs를 사용해야 할까요?

이 질문에는 다른 접근 방식과 Work Graphs를 왜 선호해야 하는지에 대한 질문이 뒤따릅니다. 하지만 그 전에 Work Graphs에 중요한 GPU 개념을 간략하게 살펴보겠습니다.

우리는 이러한 개념이 Work Graphs에 중요하다고 믿습니다.

GPU 발전의 간략한 역사를 통해 이러한 개념을 가장 잘 설명할 수 있습니다. 더 큰 유연성에 대한 요구는 지난 수십 년 동안 GPU 프로그래밍 기능의 발전을 주도해 왔습니다. 초기 레지스터 결합기는 초보적인 프래그먼트 처리[Kilgard 1999]를 가능하게 했고, 이후 정점 처리는 프로그래밍이 가능해졌습니다[Lindholm et al. 2001].

2002년 DirectX 9.0 Shader Model 2.0은 최초의 프로그래밍 가능 하드웨어 정점 및 픽셀 셰이더 파이프라인으로 간주됩니다. 2년 후, Shader Model 3.0은 동적 제어 흐름을 추가했습니다[Akenine-Möller 2018].

지오메트리 셰이더[Blythe 2006]는 프로그래밍 가능한 프리미티브별 처리를 선보였습니다. 하드웨어 테셀레이션[Andrews and Barker 2006]은 빠른 온-칩(on-chip) 지오메트리 증폭[Niessner et al. 2016]을 가능하게 했습니다.

컴퓨트 셰이더[Peercy et al., Nvidia 2007]의 도입은 하드웨어 지향 프로그래밍 모델, 즉 GPGPU의 시작을 드러냈습니다. GPU Gems 3 책[Nguyen 2007]에서 볼 수 있듯이, 이를 통해 GPU는 고성능 그래픽 및 비그래픽 애플리케이션을 실행할 수 있게 되었습니다. 또한, 하드웨어에서의 최신 GPU 레이 트레이싱[Haines and Akenine-Möller 2019]은 컴퓨트 셰이더 기반 레이 트레이싱 구현[Parker et al. 2010]에서 유래했습니다.

indirect execution 또는 execute indirect ^[각주:2]를 통해 드로우 콜과 디스패치의 크기를 GPU 메모리에서 가져와 GPU 기반 작업 생성을 가능하게 합니다. 증폭(Amplification)^[각주:3] 및 메시 셰이더[Kubisch 2018]는 컴퓨트 셰이더의 프로그래밍 모델을 따라 래스터화 워크로드를 위한 단일 레벨의 비재귀적 증폭 파이프라인을 제공합니다.

Works Graph[Microsoft 2024]는 컴퓨팅 및 래스터화 워크로드의 다단계 자체 재귀적 증폭을 제공하여 GPU 프로그래밍 가능성을 높입니다.^[각주:4]

우리는 이러한 이정표가 GPU 파이프라인의 기본 개념을 설명하기에 충분하다고 생각합니다.

…그리고 프로그래밍 가능한 정점 및 픽셀 셰이딩을 도입한 Shader Model 2부터 시작합니다.

파이프라인을 간략하게 표현한 버전입니다. 파란색과 노란색 상자는 파이프라인의 각 단계를 나타냅니다.

원으로 표시된 꼭짓점을 가진 삼각형 메시가 주어졌습니다. 검은색 모서리는 꼭짓점을 연결하여 삼각형을 형성합니다. 꼭짓점 좌표는 열 벡터로 표시된 4D 좌표입니다.

이들은 오른쪽에 보여지는 표시된 파이프라인에 입력됩니다

output으로 슬라이드 왼쪽 하단의 픽셀 그리드에 표시된 것처럼 픽셀 그래픽을 얻습니다.

정점(vertex) 좌표는 vertex buffer라 불리는 배열에 저장됩니다.

그리고 vertex index는 index buffer라고 불리는 곳에 저장됩니다.

파이프라인에 정점 버퍼와 인덱스 버퍼를 입력하면 어떤 일이 일어나는지 다시 살펴보겠습니다.

먼저, 인덱스 버퍼의 각 요소가 input assembler에 입력됩니다.

그런 다음 인풋 어셈블러는 정점 버퍼에서 요소(elements, 여기서는 vertex 내의 값들)를 수집하여 outputs에서 사용할 수 있도록 합니다.

인풋 어셈블러는 각 요소를 독립적으로 처리할 수 있습니다. 이를 통해 GPU는 높은 수준의 병렬성을 확보할 수 있습니다.

그런 다음 정점은 다음 단계인 정점 셰이더로 전달됩니다.

정점 셰이더에서는 프로그래머가 왼쪽에 표시된 것처럼 셰이더 코드를 작성할 수 있습니다.

인풋 어셈블러의 출력을 설명하는 구조체를 정의합니다. 동시에 이 구조체는 정점 셰이더의 입력으로 사용됩니다. 인풋 어셈블러가 출력하는 각 정점에 대해 GPU는 하나의 정점 셰이더 스레드를 실행합니다.

첫 번째 정점을 예로 들어 보겠습니다.

노란색 상자 안의 정점은 하나의 정점 셰이더 스레드에 대한 입력 역할을 합니다.

해당 입력을 통해 정점 셰이더 스레드는 프로그래머가 지정한 작업을 수행합니다.

… 그리고 프로그래머가 파란색 상자에 표시된 구조체로 정의한 출력을 작성합니다.

그러면 결과가 정점 셰이더 출력에서 제공됩니다.

다른 모든 정점도 같은 운명을 겪습니다. 즉, 서로 다른 입력을 사용하여 동일한 정점 셰이더 코드를 통과합니다.

이것은 매우 중요한 개념입니다. 동일한 코드가 서로 다른 데이터 항목에 대해 실행됩니다.

즉, 하나의 명령어(Single Instruction)가 여러 데이터에 대해 동작합니다. 따라서 단일 명령어, 다중 데이터…라는 이름이 붙었습니다.

… 또는 줄여서 SIMD라고도 합니다.

SIMD는 GPU의 기본 병렬 컴퓨팅 모델이며, GPU 성능에 매우 중요합니다. 웍스 그래프는 GPU에서 실행되므로 SIMD 모델을 사용합니다.

참고 : GPU와 관련하여, 대규모 병렬 기반 컴퓨팅 모델은 SIMT(Single Instruction, Multiple Threads)라고도 합니다.

추상적인 관점에서 보면, SIMD의 D(데이터)와 같은 정점 속성은 작업 항목(Work Items)입니다.

… 파이프라인을 통해 진행됩니다.

파이프라인에서 한 단계는 생산자 역할을 하고, 그 다음 단계는 소비자 역할을 합니다. 각 단계는 항목을 소비하고 동시에 생산할 수 있습니다.

파이프라인을 통해 흐르는 항목을 작업 항목(work items)이라고 합니다.

이러한 관점에서 볼 때, 그래픽스 파이프라인은 이미 Work Graphs에서도 사용되는 데이터 흐름 지향 모델(data-flow-oriented model)을 제공하고 있지만, 훨씬 더 정교한 방식으로 제공됩니다.

하지만 이미 익숙한 버텍스-픽셀 셰이더 파이프라인으로 돌아가 보겠습니다.

버텍스 셰이더는 방금 버텍스를 변환했습니다.

래스터라이저는 세 개의 정점으로 구성된 튜플을 수집하고 삼각형을 프래그먼트로 이산화(discretizes)^[각주:5]합니다.

이는 작업 증폭(work amplification)으로 볼 수 있습니다. 삼각형을 입력 데이터 항목으로 가정합니다. 이 입력 데이터 항목을 훨씬 더 많은 출력 항목, 즉 프래그먼트로 증폭합니다.

하지만 래스터라이저는 프래그먼트를 생성하지 않는 삼각형을 제거하는 등 작업을 완전히 줄일 수도 있습니다.

픽셀 셰이더는 다시 SIMD 모델을 사용하는 프로그램입니다. 각 프래그먼트는 입력 작업 항목(input work item)입니다.

…그리고 GPU의 한 스레드에 의해 실행(executed)됩니다…

… 어느 색상이 출력될지 계산합니다.

각 프래그먼트 셰이더 스레드는 출력 데이터 항목을 출력 병합기에 전달합니다.

그런 다음 output 병합기는 프래그먼트를 기존에 있던것과 병합하여 최종 이미지를 형성합니다.

이것으로 2002년의 버텍스 및 픽셀 셰이더 파이프라인에 대한 이야기를 마칩니다.

Work Graph에 사용할 일부 개념은 당시에도 이미 존재했다는 것을 살펴보았습니다.

파이프라인에는 두 개의 프로그래밍 가능한 스테이지와 여러 개의 구성 가능한 고정 기능 스테이지가 있습니다.

버텍스 셰이더는 버텍스에 대해 SIMD를 사용하고, 프래그먼트 셰이더는 프래그먼트에 대해 SIMD를 사용합니다. 2006년, D3D10은 또 다른 프로그래밍 가능 단계인 지오메트리 셰이더를 도입했습니다. 이 단계는 삼각형 및 기타 기본 요소에 대해 SIMD를 사용합니다.

하드웨어 설계자들은 모든 프로그래밍 가능 단계가 동일한 기본 SIMD 원리를 사용한다는 것을 발견했습니다.

공통된 추상화를 제공하기 위해 통합 셰이더 모델을 만들었습니다.

각 스레드는 셰이더 코어에 매핑됩니다. 여러 셰이더 코어는 하나의 작업 그룹 프로세서로 그룹화됩니다. 예를 들어, AMD RDNA 3 아키텍처에서는 작업 그룹 프로세서당 128개의 셰이더 코어가 있습니다.

작업 그룹 프로세서의 셰이더 코어는 AMD RDNA 3 GPU에서 128KiB의 공유 메모리를 통해 통신할 수 있습니다.

이러한 여러 개의 작업 그룹 프로세서가 GPU에 탑재되어 있습니다. AMD Radeon RX 7800 XT에는 30개의 작업 그룹 프로세서가 있습니다.

작업 그룹 프로세서는 공통 그래픽 메모리를 공유합니다. 현재 이 메모리는 수 GB에 달합니다.

GPU의 추상 모델이 이렇게 완성되었으니, 새로운 셰이더 유형을 정의하는 것은 당연한 일이었습니다. 이를 통해 컴퓨트 셰이더(Compute Shader)가 탄생했습니다.

컴퓨트 셰이더는 GPU 추상화^[각주:6]를 필요로 합니다.

공통 그룹 공유 메모리에 접근하는 스레드를 포함하는 셰이더입니다. 스레드는 셰이더 코어에 매핑되고, 그룹 공유 메모리는 공유 메모리에 매핑됩니다.

스레드들은 스레드 그룹으로 클러스터링됩니다. GPU 하드웨어에서 스레드 그룹은 작업 그룹 프로세서에서 실행됩니다.

컴퓨트 셰이더 프로그램에서 SV_GroupThreadID 시맨틱은 스레드 그룹 내 최대 1024개 스레드의 그리드에서 3차원 인덱스를 제공합니다.

// 최대 1024개 스레드의 1D, 2D, 3D 그리드
uint3 gtid : SV_GroupThreadID;

// 각 차원마다 최대 65536개 스레드 그룹의
// 1D, 2D, 3D 그리드
uint3 gid : SV_GroupID;

스레드 그룹의 위치를 찾기 위해 SV_GroupID 시맨틱은 프로그래머에게 스레드 그룹 그리드 내의 3차원 인덱스를 제공합니다.

struct Data {
    float3 u;
    float2 v;
};

StructuredBuffer<Data> A : register(t0);
StructuredBuffer<Data> B : register(t1);
RWStructuredBuffer<Data> C : register(u0);

[numthreads(128, 1, 1)]
void main(uint3 gtid : SV_GroupThreadID,
          uint3 gid  : SV_GroupID) {

    const uint t = gtid.x + gid.x * 128;

    C[t].u = A[t].u + B[t].u;
    C[t].v = A[t].v * B[t].v;
}

컴퓨트 셰이더는 SIMD 모델을 따르는 셰이더 프로그램을 사용하여 프로그래밍됩니다.

스레드 그룹 크기(이 예제에서는 128개 스레드)를 알고 있을 때, SV_GroupThreadID 와 SV_GroupID 를 사용하여 각 스레드를 고유하게 식별할 수 있습니다.

이러한 고유 ID를 사용해 메모리(이 예제에서는 StructuredBuffer)를 인덱싱하여 계산을 수행합니다.

Work Graphs를 위한 GPU 개념

✅ SIMD
✅ 작업 항목(Work Item)
✅ 작업 증폭(Work Amplification), 작업 축소(Work Reduction)
✅ 컴퓨트 셰이더(Compute Shaders)
❓ 메시 셰이더(Mesh Shaders)

따라서 우리는 네 번째 개념인 “컴퓨트 셰이더(Compute Shaders)”를 얻게 되었습니다

그렇다면 컴퓨트 셰이더는 그래픽스 파이프라인과 어떻게 상호작용할까요?

// Compute Shader로 지오메트리 처리
commandList->SetPipelineState(...);
commandList->Dispatch(...);
commandList->Barrier(...);

이 예제에서 컴퓨트 셰이더는 CPU로부터 디스패치됩니다. GPU에서는 컴퓨트 셰이더의 스레드들이 그래픽스 메모리로부터 전달된 인스턴스 목록을 처리합니다.

예를 들어, 컴퓨트 셰이더의 작업이 뷰 프러스텀(view frustum) 밖의 인스턴스를 컬링하는 것이라고 가정합니다. 컴퓨트 셰이더는 화면에 보이는 인스턴스만 다시 그래픽스 메모리에 기록합니다.

// Graphics Pipeline로 지오메트리 처리
commandList->SetPipelineState(...);
commandList->DrawIndexedInstanced(...);
commandList->Barrier(...);

다음으로 그래픽스 파이프라인은 화면에 보이는 인스턴스만 렌더링합니다. 그래픽스 메모리에서 해당 데이터를 읽어 2D 이미지를 생성하며, 생성된 이미지는 다시 그래픽스 메모리에 기록됩니다.

// 컴퓨트 셰이더로 Post Process 처리
commandList->SetPipelineState(...);
commandList->Dispatch(...);
commandList->Barrier(...)

그런 다음, 다른 컴퓨트 셰이더를 실행합니다. 예를 들어, 이 셰이더는 이미지에 대한 포스트 프로세싱을 수행할 수 있습니다. 따라서 모든 픽셀을 읽고, 변환한 다음, 그래픽 메모리에 다시 기록합니다.

Compute Shader의 문제점

❌ 배리어(Barriers)

하지만 두 가지 문제가 있습니다. 첫 번째 문제는 배리어(barrier)입니다.
배리어는 파이프라인 간의 읽기/쓰기 충돌(read/write hazard)을 방지하기 위해 필요합니다.

하나의 파이프라인은 다른 파이프라인이 시작되기 전에 전체 연산을 모두 끝마쳐야 합니다. 이러한 동작은 배리어에 의해 보장됩니다.

이로 인해 많은 워크그룹 프로세서가 유휴 상태(idle)로 남을 수 있으며, 특히 파이프라인 연산이 거의 끝나갈 때 이러한 현상이 두드러집니다.

두 번째 문제는 파이프라인 간 통신이 그래픽 메모리를 통해 이루어지는데, 이것이 성능 저하의 원인이 될 수 있다는 점입니다.

CPU <> CPU Memory 약 64GiB/s
GPU <> Graphics Memory 약 1TiB/s(GPU Memory Bandwidth)
CPU Memory <> Graphics Memory 약 59GiB/s(PCIe 5.0x16 - 상호연결 대역폭).^[각주:7]

여기 몇 가지 수치를 보겠습니다. 시스템 내의 다른 메모리 버스와 비교하면, GPU의 워크그룹 프로세서와 그래픽스 메모리 사이의 1 TiB/s 대역폭은 매우 커 보입니다.

하지만 이 그래프에서 볼 수 있듯이, 지난 수년 동안 GPU 연산 성능(GPU Compute Performance)의 증가 속도는 GPU 메모리 대역폭(GPU Memory Bandwidth)의 증가 속도를 앞질렀습니다.

출처:
이미지는 다음 자료를 기반으로 수정됨:
https://github.com/amirgholami/ai_and_memory_wall/blob/main/imgs/pngs/hw_scaling.png

논문 출처:
Gholami A, Yao Z, Kim S, Mahoney MW, Keutzer K.
AI and Memory Wall.
RiseLab Medium Blog Post, University of California Berkeley, 2021년 3월 29일.

따라서 그래픽스 메모리에 대해 1 TiB/s의 대역폭이 있더라도…

코어 내부에는 훨씬 빠른 공유 메모리가 있습니다. 실제로 그래픽 메모리에 비해 지연 시간이 매우 짧습니다.

하지만 메모리 용량은 훨씬 작습니다.

따라서 2009년 당시에도 입출력(I/O)은 이미 문제였습니다. I/O를 줄이기 위해 2009년에 하드웨어 테셀레이션(hardware tessellation)이 도입되었습니다.

이것은 헐 셰이더와 도메인 셰이더라는 두 개의 추가된 프로그래밍 가능한 스테이지와 고정 기능 하드웨어 테셀레이터를 포함하고 있습니다.

하드웨어 테셀레이션은 몇 개의 제어점으로 이루어진 지오메트리 구조를 더 많은 삼각형으로 확장할 수 있게 해줍니다. 하지만 다소 경직된 테셀레이션 패턴은 원하는 만큼의 토폴로지의 자유도를 제공하지 못합니다.

이것이 바로 2018년에 파이프라인에 메시 셰이딩이 추가된 이유입니다. 메시 셰이딩은 워크 그래프에도 중요합니다.

// Process Geometry with Computer Shader
commandList->SetPipelineState(...);
commandList->Dispatch(...);
commandList->Barrier(...);

그렇다면 메시 셰이딩은 어떤 문제를 해결하는 것일까요? 지오메트리를 생성하거나 변환하는 컴퓨트 셰이더를 생각해 봅시다. 그런데 이 컴퓨트 셰이더는 출력을 그래픽 메모리에 저장해야 합니다.

// Process Geometry with Graphics Pipeline
commandList->SetPipelineState(...);
commandList->DrawIndexedInstanced(...);
commandList->Barrier(...);

그러면 그래픽 파이프라인이 그래픽 메모리에서 읽을 수 있습니다. 따라서 메모리 쓰기와 읽기 작업이 각각 한 번씩 발생하므로, 이를 줄일 수 있습니다. 그래픽 메모리 접근은 상당히 비용이 많이 드는 작업이라는 점을 기억하세요.

// Process with Mesh Shader
commandList->SetPipelineState(...);
commandList->DispatchMesh(...);

메시 셰이딩의 핵심 아이디어는 컴퓨트 셰이더에서 래스터라이저로 직접 데이터를 전달하는 것입니다. 이를 통해 그래픽 메모리 접근 횟수를 줄일 수 있습니다.

이로써 우리는 세 번째 파이프라인인 메시 셰이딩 파이프라인을 얻게 됩니다.

[outputtopology("triangle")]
[numthreads(128, 1, 1)]

void main(
uint3 gtid : SV_GroupThreadID,
uint3 gid : SV_GroupID,
out vertices float3 smallVertexBuffer[256],
out indices uint3 smallIndexBuffer[256])
{
}

컴퓨트 셰이더처럼 메시 셰이더 스레드 그룹 그리드를 실행합니다. 따라서 코드에는 SV_GroupThreadID와 SV_GroupID 시맨틱이 있습니다. 각 메시 셰이더 스레드 그룹은 최대 128개의 스레드를 가질 수 있습니다. 삼각형(또는 다른 primitives)을 최대 256개의 정점과 삼각형을 저장할 수 있는 작은 정점 및 인덱스 버퍼에 출력할 수 있습니다. 메시 셰이더의 출력은 작은 메시와 같으므로 일반적으로 메시렛이라고 합니다.

여러 개의 메시 셰이더 스레드 그룹을 사용하면 여러 개의 메시렛을 출력할 수 있습니다.

더 큰 모델을 렌더링하려면 먼저 전처리 단계에서 모델을 여러 개의 메쉬렛으로 분해해야 합니다.

그런 다음 각 메쉬렛에 대해 메쉬 셰이더 스레드 그룹을 실행합니다.

메시 셰이더 스레드 그룹은 이러한 메시렛을 변환한 다음 래스터라이저로 전달합니다.

메시 셰이딩은 워크 그래프의 초경량 버전입니다.
자세한 내용은 다음 블로그 게시물 시리즈를 참조하세요.
https://gpuopen.com/learn/mesh_shaders/mesh_shaders-index

하지만 이제 메쉬 셰이딩이 생겼으니, 워크 그래프에 필요한 모든 개념을 한데 모을 수 있게 되었습니다.

이제 문제는 왜 우리에게 워크 그래프가 필요한 가? 하는 것입니다.

그 질문에 답하기 위해 먼저 파이프라인에 추가된 또 다른 기능이 해결하려는 문제를 살펴보겠습니다. 제가 말하는 것은 "간접 실행 - indirect execute"입니다.

컴퓨팅 파이프라인과 그래픽 파이프라인이 있다고 가정해 봅시다.

그리고 CPU에서 컴퓨트 파이프라인을 시작합니다.

그 다음 GPU는 컴퓨트 파이프라인을 사용하여 계산을 수행합니다. 이를 위해 그래픽스 메모리에서 데이터를 읽고, 결과를 다시 그래픽스 메모리에 기록합니다.

모든 데이터가 그래픽스 메모리에 기록되었는지 보장하기 위해 배리어(barrier)를 포함해야 합니다.^[각주:8]

배리어에 도달한 이후에야 그래픽스 파이프라인을 시작할 수 있습니다. 따라서 반드시 기다려야 합니다. 이후 그래픽스 파이프라인은 메모리에서 데이터를 읽어 픽셀 출력을 생성합니다. 그 다음에는 또 다른 배리어가 필요합니다.

이러한 배리어는 시스템이 적극적으로 대기(active wait)해야 하기 때문에 심각한 성능 문제가 될 수 있습니다.

프로듀서(즉, 컴퓨트 커널)^[각주:9]가 가변적인 수의 데이터 항목을 생성할 때 상황은 더욱 심각해집니다.

예를 들어, 수만 개의 객체가 있는 장면을 상상해 보세요. 프로듀서의 역할은 보이지 않는 객체를 제거하는 것입니다. 프로듀서 커널이 실행된 후, 5000개의 보이는 객체를 데이터에 출력합니다. 그리고 거기에 N = 5000이라고 기록합니다.

컨슈머는 5000개의 객체를 렌더링합니다. 하지만 이를 위해서는 CPU가 드로우 콜을 구성해야 하고, 이때 N이라는 숫자를 알아야 합니다.

즉, CPU는 GPU로부터 N 값을 읽어와야 합니다. 따라서 CPU와 GPU를 동기화하는 펜스(fence)를 포함해야 합니다. 이 펜스를 통과한 후에야 CPU는 N 값을 읽고 드로우 콜을 올바르게 구성할 수 있습니다.

해당 데이터 핸들과 객체 개수를 알면 CPU는 화면에 표시되는 객체에 5000번의 드로우 콜을 실행할 수 있습니다.

단, 프로듀서와 컨슈머는 데이터 핸들(&Data)에 대해 사전에 합의해야 합니다.

"간접 실행-indirect execute"을 사용하면 숫자 N이 저장된 위치에 대한 핸들도 얻을 수 있습니다. 이것이 어떻게 상황을 개선할 수 있는지 살펴보겠습니다.

프로듀서는 &N과 &Data라는 두 개의 핸들을 모두 받습니다. 이전과 마찬가지로, 보이는 객체(Data)와 보이는 객체의 개수(N)를 출력합니다.

이제 CPU는 GPU 핸들의 위치는 알지만 실제 값은 알지 못합니다. 따라서 실제 값을 전송할 필요가 없습니다.

그러므로 펜스(fence)도 필요 없습니다.

CPU가 해야 할 일은 실제 값 대신 핸들을 매개변수로 사용하여 컨슈머를 호출하는 것뿐입니다.

하지만 프로듀서와 컨슈머가 여전히 그래픽 메모리를 통해 통신하기 때문에 펜스는 여전히 필요합니다.

또한, N=0인 경우 CPU가 컨슈머를 디스패치할 이유가 없습니다. 하지만 CPU는 N이 0인지 알 수 없으므로, 어떤 경우에도 드로우 콜을 디스패치해야 합니다.^[각주:10]

이는 위험한 것은 아니지만, 배리어를 포함한 런치 오버헤드가 발생합니다.^[각주:11]

간접 실행(indirect execute)의 또 다른 문제는 데이터에 포함될 수 있는 메모리를 예약해야 한다는 것입니다. 컬링 예제로 돌아가 보면, 모든 객체를 렌더링할 수도 있고, 객체를 하나도 렌더링하지 않을 수도 있습니다. 이를 미리 알 수 없기 때문에 항상 최악의 경우를 대비해야 하며, 따라서 잠재적으로 메모리를 낭비하게 됩니다.

우리는 항상 최악의 시나리오를 고려해야 합니다. 그렇지 않으면 위험한 메모리 오버플로 상황에 직면할 수 있습니다.

그러니까 이것들은 모두 기존의 간접 실행 문제들입니다.

이러한 문제들을 메시 셰이더(mesh shaders)로 해결할 수 있을까요?
아직 메시 셰이딩 파이프라인의 amplification shader 단계에 대해서는 설명하지 않았습니다.^[각주:12]

Amplification Shader는 GPU 상에서 직접 실행할 메시 셰이더 스레드 그룹의 개수를 제어할 수 있습니다. 본질적으로 이것은 작은 규모의 consumer-producer 파이프라인입니다.

따라서 매우 단순한 시나리오에서는 메시 셰이딩이 이러한 문제들 중 일부를 해결할 수 있습니다

하지만 메시 셰이딩은 그래픽 처리 기능만 제공하며, 연산 처리 기능은 지원하지 않습니다.^[각주:13]

예를 들어 재귀적 세분화와 같은 자기 재귀를 원하는 경우 문제가 발생합니다.

메쉬 셰이딩 파이프라인은 프로그래밍 가능한 단계가 하나 또는 두 개뿐입니다. 따라서 긴 체인은 구현할 수 없습니다.

또는 여러 개의 서로 다른 셰이더 체인을 사용할 수도 있습니다.

분류-실행 패턴(이 강좌의 재질 셰이딩 섹션 뒷부분 참조)과 같이 셰이더 체인에서 분기되는 방식 또한 불가능합니다.

여기서 말하는 Mesh node는 Mesh Shader 단계 전체를 Work Graph의 한 노드로 취급한 개념으로 개별 커널 실행 단위(스레드 그룹 하나)가 아니라, “Mesh Shader 파이프라인 호출”을 그래프의 노드 단위 작업으로 캡슐화 한 것을 말한다. 이 Mesh Node는 Work Graph 내 다른 노드(예: Culling Node, LOD Selection Node, Lighting Node)와 연결되어 데이터 플로우를 형성하게 된다.(works graph 상에서 추상화한 노드)

논문에서 말한 “2024년 3분기에 공개된 Mesh Nodes”는 DirectX 12 Work Graphs의 Mesh Nodes 프리뷰를 이야기하며,. 이때부터 그래프의 리프(leaf) 노드에서 메쉬 셰이더 파이프라인을 직접 실행할 수 있게 되어, CPU 드로우콜 없이 그래프 안에서 바로 렌더링이 가능해졌다.(Microsoft가 Agility SDK v1.715.0 프리뷰와 함께 Mesh Nodes를 공개했고, AMD 라데온 공개 드라이버는 Q3 2024에 Mesh Nodes 지원이 탑재된다고 공지)
https://devblogs.microsoft.com/directx/d3d12-mesh-nodes-in-work-graphs/

기존 Work Graph 노드는 전부 “컴퓨트형”이었는데, Mesh Node는 컴퓨트가 아니라 메쉬 셰이더 기반 그래픽스 파이프라인을 dispatch한다. 즉, 노드 자체가 mesh shader + (선택적) pixel shader + 래스터라이저 상태를 포함한 그래픽스 프로그램(PSO 유사체)로 구성되게 된다. 이로 인해 그래프 내부에서 드로우콜이 1급 시민이 되며, PSO 선택/스위칭과 (옵션) 순서 보장 래스터라이즈까지 지원하게된다. 이로인해 완전한 GPU-driven 파이프라인을 구성할 수 있게 된다.

AMD의 가이드 https://gpuopen.com/learn/work_graphs_mesh_nodes/work_graphs_mesh_nodes-tips_tricks_best_practices/ 에서 이야기하는 주요 내용은 아래와 같다.

1) 작게 쪼개진 디스패치를 합쳐라 : 작은 레코드 다발 대신 코얼레싱 노드나 그룹 출력으로 “한 번에 더 큰 메쉬 디스패치”를 날려 오버헤드를 가린다.
2) PSO 스위칭 최소화 : 가능한 공통 그래픽스 상태를 크게 유지해 스위칭 비용을 줄여라.
3).렌더 타깃 배열: 동일 그래프 내에서 다른 패스(G-Buffer/섀도우 등)를 동시에 그리려면 배열 슬라이스를 활용하라.

[본문으로]
Indirect Execution : GPU가 실행할 명령(드로우, 디스패치 등)의 파라미터를 메모리 버퍼에서 읽어와 실행하는 방식.
Execute Indirect : DirectX12에서 제공하는 Indirect Execution을 위한 구체적인 API [본문으로]
Amplification Shader (AS) : Mesh Shader 앞에서 실행되어, 몇 개의 Mesh Shader 그룹을 만들지 증폭(amplify).하는 단계를 의미한다 [본문으로]
Work Graphs에서의 “재귀적 증폭"은 노드가 실행 중에 자기 자신 또는 다른 노드를 새로 디스패치할 수 있다는 의미로 한 노드가 “Amplification 역할”을 하고, 그 결과가 다시 추가적인 Amplification을 발생시킬 수 있다는 이야기이다.

다단계 증폭 (multi-level amplification) : Culling → Binning → LOD → Mesh Node → 또 다른 Mesh Node … 와 같이 계층적으로 증폭 구조를 설계 가능
재귀적 증폭 (self-recursive amplification) : 하나의 노드가 자기 자신을 다시 실행해서 동적 워크로드를 계속 확장 가능 (예: 쿼드트리/옥트리 기반 지형 세분화, 파티클 시뮬레이션, LOD streaming)

그래프 노드가 자기 자신이나 다른 노드를 동적으로 증폭·재귀 호출할 수 있는 일반화된 모델을 이야기 한다 [본문으로]
연속적인 삼각형을 실제 화면의 불연속적인 픽셀 그리드로 변환하는 과정을 이야기 한다 [본문으로]
GPU 하드웨어의 실제 구조를 개발자가 직접 다루지 않아도 되도록, GPU를 논리적인 실행 모델로 표현하는 개념으로 여기서 Compute Shader를 다음처럼 추상화하고 있다.

- GPU 작업을 수많은 스레드(Thread) 로 구성
- 스레드들을그룹 내부에서는 각 스레드는 자신의 위치를 SV_GroupThreadID 로 식별

실제 GPU 내부의 코어, SIMD 구조, 스케줄링 등을 직접 신경 쓰는 대신, “3차원 격자(Grid) 안에 있는 스레드들이 병렬로 실행된다” 라는 형태로 단순화해서 프로그래밍할 수 있게 만든 것을 이야기 한다. [본문으로]
GPU 내부보다 약 20배 느리다 [본문으로]
Barrier가 포함되어야 하는것은 프로듀서가 생성된 데이터를 컨슈머가 먼저 접근하는 것을 막기위해 완료 보장을 하기 위함이다. 이로인해 데이터를 쓰는중에 접근해 데이터가 깨지거나 문제가 생기는걸 막는다 [본문으로]
Compute Shader, Cull pass, Visibility pass등 버퍼등 데이터를 생성하는 쪽. 반대로 사용하는 것을 이 내용에서는 Consumer라고 지칭한다. [본문으로]
기존구조에서는 DrawIndirectInstanced를 호출하므로 실제로 N=0로 그릴게 없다 하더라도 파이프라인 전환 및 draw setup등 CPU/GPU 오버헤드는 존재하지만 ExecuteIndirect에서는 N=0일때는 GPU내부에서 실행할 draw가 없기에 CPU개입없이 GPU에서 그냥 넘어갈 수 있음. 대규모 씬 렌더링에서 빈번하게 발생하는 경우 이러한 구조는 매우 유의미하게 이득일 수 있음 [본문으로]
Producer와 Consumer 사이의 동기화는 여전히 필요하므로Barrier 문제를 완전히 없애지는 못함 [본문으로]
왜 amplfication이냐면 입력 작업을 증폭(amplify)하기 때문이다. 예를 들면 하나의 오브젝트를 받아왔을때 이를 amplification shader stage에서 64개의 Mesh Shader task가 생성하는것도 가능하기 때문이다.(작업생성, 분배 및 수를 조절). 이 스테이지의 역할은 Mesh shader가 수행할 작업을 생성하는 단계라 생각하면 된다. [본문으로]
Mesh shader만 생성가능. 범용 GPU 작업은 불가 [본문으로]

[번역] No Graphics API

illu_yun — Mon, 23 Feb 2026 17:28:24 +0900

원문 : https://www.sebastianaaltonen.com/blog/no-graphics-api?fbclid=IwY2xjawQIzflleHRuA2FlbQIxMQBzcnRjBmFwcF9pZBAyMjIwMzkxNzg4MjAwODkyAAEeYW1J5owAqUG6qDQ6kMcjFTaDESQHiSnX6N4FBO5IvW2YHyoZ4x_KlZQAlfk_aem_ZhEs0Y6LCVm17zbiTGNCWQ

Unity 때 엔진팀 리드였던(DOTS hybrid) 세바스티앙 알토넨의 블로그 글.

No Graphics API

Introduction

그래픽스 API, 셰이더 프레임워크, 드라이버의 복잡성은 지난 수십 년 동안 급격히 증가해왔다. 파이프라인 상태 객체(PSO-Pipeline State Object)의 폭증은 이미 통제 불가능한 수준에 이르렀다. 우리는 어떻게 해서 100GB에 달하는 로컬 셰이더 파이프라인 캐시와 이를 호스팅하기 위한 대규모 클라우드 서버를 사용하게 되었을까? 이제는 GPU와 상호작용하는 방식을 단순화하기 위해 추상화 계층과 API 표면을 어떻게 줄일지 논의할 때다.

이 블로그 글에는 많은 저수준 하드웨어 세부 내용이 포함되어 있다. 이 글을 작성하면서 나는 공개된 Linux 오픈소스 드라이버를 교차 참고하기 위해 “GPT5 Thinking” AI 모델을 사용했으며, NDA(비밀 유지 계약) 정보가 포함되지 않았음을 확인했다. 참고 자료로는 AMD RDNA ISA 문서와 GPUOpen, Nvidia PTX ISA 문서, Intel PRM, Linux 오픈소스 GPU 드라이버(Mesa, Freedreno, Turnip, Asahi), 그리고 각 벤더의 최적화 가이드 및 발표 자료가 있다. 이 블로그 글은 공개 전에 여러 업계 관계자들의 검토를 거쳤다.

Low-level graphics APIs change the industry

10년 전, 새로운 저수준 PC 그래픽스 API가 등장하면서 실시간 컴퓨터 그래픽스 분야에 큰 전환점이 찾아왔다. AMD는 Xbox One(2013)과 PlayStation 4(2013) 계약을 모두 따냈고, 그들의 새로운 Graphics Core Next(GCN) 아키텍처는 AAA 게임 개발의 사실상 기준 플랫폼이 되었다. 당시 PC 그래픽스 API였던 DirectX 11과 OpenGL 4.5는 드라이버 오버헤드가 크고 단일 스레드 렌더링을 전제로 설계되어 있었다. AAA 개발자들은 PC에서 더 높은 성능을 낼 수 있는 API를 요구했다. 이에 DICE는 AMD와 협력해 PC용 저수준 AMD GCN 전용 API인 Mantle을 만들었다. 그에 대한 대응으로 Microsoft, Khronos, Apple이 각자의 저수준 API 개발에 착수했고, 그 결과 DirectX 12, Vulkan, Metal이 탄생했다.

이 새로운 저수준 API에 대한 초기 반응은 엇갈렸다. 합성 벤치마크와 데모에서는 상당한 성능 향상이 나타났지만, Unreal이나 Unity 같은 주요 게임 엔진에서는 뚜렷한 성능 개선이 보이지 않았다. Ubisoft에서는 기존 DirectX 11 렌더러를 DirectX 12로 포팅할 경우 오히려 성능이 떨어지는 경우가 많다는 사실을 확인했다. 뭔가 잘못되어 있었다.

기존의 고수준 API는 지속 상태가 거의 없고, 세분화된 상태 설정 함수와 개별 데이터 입력을 드로우 호출 직전에 셰이더에 바인딩하는 구조였다. 반면 새로운 저수준 API는 드로우 호출을 더 저렴하게 만들기 위해 셰이더 파이프라인 상태와 바인딩을 사전에 묶어 영속 객체로 만드는 방식을 채택했다. 당시 GPU 아키텍처는 매우 이질적이었기 때문에, 데이터 재매핑·검증·업로드를 미리 수행하는 것은 큰 이점이었다. 그러나 기존 게임 엔진의 렌더링 하드웨어 인터페이스(RHI)는 세분화된 즉시 모드 렌더링에 맞춰 설계되어 있었고, 새로운 저수준 API는 데이터를 영속 객체로 묶는 방식을 요구했다.

이러한 비호환성을 해결하기 위해 RHI 아래에 새로운 저수준 그래픽 리매핑 레이어가 생겨났다. 이 레이어는 과거 OpenGL 및 DirectX 11 드라이버가 처리하던 복잡성을 떠안아, 세분화된 동적 사용자 공간 상태와 영속적인 저수준 GPU 상태 사이의 리소스 추적 및 매핑을 관리했다. 그 결과 그래픽스 프로그래머는 두 가지 역할로 분화되기 시작했다. 새로운 저수준 “드라이버” 레이어와 RHI를 다루는 저수준 그래픽스 프로그래머와, RHI 위에서 시각적 그래픽 알고리즘을 구현하는 고수준 그래픽스 프로그래머다. 한편 물리 기반 조명 모델, 컴퓨트 셰이더, 이후의 레이 트레이싱 도입 등으로 시각 프로그래밍 자체도 점점 더 복잡해지고 있었다.

Modern APIs?

DirectX 12, Vulkan, Metal은 흔히 “모던 API”라고 불린다. 하지만 이 API들도 이제 10년이 되었다. 이들은 오늘날 기준으로 13년이나 된 GPU를 지원하기 위해 설계되었는데, GPU 역사에서 13년은 엄청나게 긴 시간이다. 과거의 GPU 아키텍처는 오늘날처럼 범용적이고 연산 집약적인 워크로드보다는 전통적인 버텍스/픽셀 셰이더 작업에 최적화되어 있었다. 또한 벤더마다 서로 다른 바인딩 모델과 데이터 경로를 가지고 있었기 때문에, 이러한 하드웨어 차이를 하나의 공통 API 아래로 감싸야 했다. 이 과정에서 매핑, 업로드, 검증, 바인딩 비용을 사전에 처리하기 위해 미리 생성된 영속 객체(persistent object)가 중요했다.

반면 콘솔 API와 Mantle은 AMD의 GCN 아키텍처만을 대상으로 설계되었으며, 당시로서는 매우 선구적인 구조였다. GCN은 완전한 읽기/쓰기 캐시 계층과 텍스처 및 버퍼 디스크립터를 저장할 수 있는 스칼라 레지스터를 갖추고 있어, 모든 것을 사실상 메모리처럼 취급할 수 있었다. 복잡한 데이터 리매핑 API가 필요하지 않았고, 사전 작업도 훨씬 적었다. 단일하고 현대적인 GPU 아키텍처만을 대상으로 했기 때문에, 콘솔 API와 Mantle은 API 복잡성이 훨씬 낮았다.

그로부터 10년이 흐르는 동안 GPU는 크게 진화했다. 이제 모든 현대 GPU 아키텍처는 일관성을 갖춘 최상위 캐시를 포함한 완전한 캐시 계층을 제공한다. PCIe REBAR나 UMA를 통해 CPU가 GPU 메모리에 직접 쓸 수 있고, 64비트 GPU 포인터도 셰이더에서 직접 지원된다. 텍스처 샘플러는 바인드리스(bindless) 방식으로 동작해 CPU 드라이버가 디스크립터 바인딩을 구성할 필요가 없다. 텍스처 디스크립터는 GPU 메모리 내 배열(흔히 descriptor heap이라 불림)에 직접 저장될 수 있다. 오늘날의 GPU를 기준으로 API를 새롭게 설계한다면, 이러한 영속적인 “retained mode” 객체의 상당수는 더 이상 필요하지 않을 것이다. DirectX 12.0, Metal 1, Vulkan 1.0이 감수해야 했던 타협들은 이제 필요하지 않으며, API를 대폭 단순화할 수 있다.

지난 10년은 이들 모던 API의 약점도 드러냈다. 그중 가장 큰 문제는 PSO(파이프라인 상태 객체) 조합 폭발이다. 벤더(Valve, Nvidia 등)는 아키텍처와 드라이버 조합별로 테라바이트 단위의 PSO를 저장하는 대규모 클라우드 서버를 운영하고 있다. 사용자 로컬 PSO 캐시가 100GB를 넘는 경우도 있다. 게이머들이 로딩 시간이 길고 끊김(stutter)이 발생한다고 불평하는 것도 무리가 아니다.

The history of GPUs and APIs

API 표면을 줄이는 이야기를 하기 전에, 그래픽스 API가 역사적으로 왜 이런 방식으로 설계되었는지를 이해할 필요가 있다. OpenGL이 일부러 느리게 설계된 것도 아니고, Vulkan이 일부러 복잡하게 만들어진 것도 아니다. 10~20년 전의 GPU 하드웨어는 매우 다양했고 빠르게 진화하고 있었다. 이렇게 이질적인 하드웨어 집합을 아우르는 크로스 플랫폼 API를 설계하려면 타협이 불가피했다.

고전적인 사례부터 살펴보자. 3dFX Voodoo 2 12MB(1998)는 세 개의 칩으로 구성된 설계였다. 하나의 래스터라이저 칩이 4MB 프레임버퍼 메모리에 연결되어 있었고, 두 개의 텍스처 샘플링 칩이 각각 4MB 텍스처 메모리에 연결되어 있었다. 지오메트리 파이프라인도 없었고, 프로그래머블 셰이더도 존재하지 않았다. CPU가 변환을 마친 삼각형 정점을 래스터라이저로 직접 전송했다. 래스터라이저에는 정점 색상과 두 텍스처 샘플러 결과를 어떻게 결합할지 제어하는 블렌딩 방정식이 구성 가능하게 마련되어 있었다. 텍스처 샘플러는 서로의 메모리나 프레임버퍼를 읽을 수 없었기 때문에, 다중 렌더 패스를 지원하지 않았다. 또한 하드웨어가 윈도우 합성을 지원하지 못했기 때문에, 별도의 2D 비디오 카드와 연결하기 위한 루프백 케이블이 필요했다. 3D 렌더링은 전용 전체 화면 모드에서만 동작했다.

당시의 3D 그래픽 카드는 오늘날의 대규모 프로그래머블 SIMD 배열을 갖춘 GPU와는 거의 공통점이 없는, 매우 특수화된 하드웨어였다. 이 시대의 하드웨어 특성은 DirectX(1995)와 OpenGL(1992)의 설계에 큰 영향을 미쳤다. 하위 호환성은 매우 중요한 요소였고, API는 점진적으로 개선되어 왔다. 그렇게 30년 전에 설계된 API 구조가 오늘날 우리가 소프트웨어를 작성하는 방식에도 여전히 영향을 미치고 있다.

3dFX Voodoo 2 12MB (1998) : 각 프로세서와 그에 연결된 전용 메모리 칩(프로세서당 1MB 칩 4개) 사이의 개별 배선이 뚜렷하게 보인다. 이미지 © TechPowerUp.

Nvidia의 GeForce 256은 “GPU”라는 용어를 처음 사용했다. 이 칩은 래스터라이저에 더해 지오메트리 프로세서를 포함하고 있었다. 지오메트리 프로세서, 래스터라이저, 텍스처 샘플링 유닛은 모두 하나의 다이에 통합되어 메모리를 공유했다. DirectX 7은 렌더 타깃 텍스처와 유니폼 상수라는 두 가지 새로운 개념을 도입했다. 멀티패스 렌더링이 가능해지면서 텍스처 샘플러가 래스터라이저의 출력을 읽을 수 있게 되었고, 이는 3dFX Voodoo 2의 분리된 메모리 구조를 무력화했다.

지오메트리 프로세서 API는 변환 행렬(float4x4), 광원 위치, 색상(float4) 등을 위한 유니폼 데이터 입력을 제공했다. GPU 구현은 제조사마다 달랐으며, 많은 경우 지오메트리 엔진 내부에 소규모 상수 메모리 블록을 포함하는 방식을 택했다. 하지만 이것만이 유일한 방식은 아니었다. OpenGL API에서는 각 셰이더가 자체적인 영속 유니폼을 가졌다. 이 설계 덕분에 드라이버가 상수를 셰이더 명령 스트림에 직접 삽입할 수 있었는데, 이러한 API 특성은 오늘날 OpenGL 4.6과 ES 3.2에도 여전히 남아 있다.

당시 GPU에는 범용 읽기/쓰기 캐시가 존재하지 않았다. 래스터라이저는 블렌딩과 깊이 버퍼링을 위한 화면 지역 캐시를 갖고 있었고, 텍스처 샘플러는 선형 보간된 정점 UV를 기반으로 데이터 프리패칭을 수행했다. DirectX 8의 셰이더 모델 1.0(SM 1.0)에서 셰이더가 도입되었을 때, 픽셀 셰이더 단계는 텍스처 UV를 계산하는 기능을 지원하지 않았다. UV는 정점 단위에서 계산되어 하드웨어에 의해 보간된 뒤, 텍스처 샘플러로 직접 전달되었다.

DirectX 9는 셰이더 명령 수 제한을 크게 늘렸지만, 셰이더 모델 2.0은 새로운 데이터 경로를 노출하지는 않았다. 버텍스 셰이더와 픽셀 셰이더는 여전히 1:1 입력-출력 구조로 동작했으며, 사용자는 정점 위치와 속성의 변환 수학, 그리고 픽셀 색상만을 커스터마이즈할 수 있었다. 프로그래머블 로드/스토어는 지원되지 않았다. 고정 기능 입력 블록(버텍스 페치, 유니폼/상수 메모리, 텍스처 샘플러)은 계속 유지되었다. 버텍스 셰이더는 별도의 실행 유닛이었으며, 상수 인덱싱(float4 배열로 제한됨) 같은 새로운 기능을 얻었지만 여전히 텍스처 샘플링은 지원하지 않았다.

DirectX 9 셰이더 모델 3.0은 명령 수 제한을 65,536으로 늘려, 사람이 셰이더 어셈블리를 직접 작성하고 유지하기 어렵게 만들었다. 이에 따라 고수준 셰이딩 언어가 등장했다. HLSL(2002)과 GLSL(2002~2004)이다. 이 언어들은 1:1 요소 단위 변환 설계를 계승했다. 각 셰이더 인보케이션은 하나의 데이터 요소(정점 또는 픽셀)에 대해 동작했다. 이러한 프레임워크식 셰이더 설계는 이후 그래픽스 API 설계에 큰 영향을 미쳤다. 당시에는 하드웨어 차이를 추상화하는 좋은 방법이었지만, 오늘날에는 확장성 측면에서 한계를 드러내고 있다.

DirectX 11은 데이터 모델 측면에서 큰 전환점이었다. 컴퓨트 셰이더, 범용 읽기/쓰기 버퍼, 간접 드로우를 지원하기 시작하면서 GPU가 스스로 작업을 생성하고 처리할 수 있게 되었다. 범용 버퍼의 도입으로 셰이더는 프로그래머블 메모리 위치에 접근하고 수정할 수 있게 되었고, 이에 따라 하드웨어 벤더들은 범용 캐시 계층을 구현해야 했다. 셰이더는 더 이상 단순한 1:1 데이터 변환에 머물지 않게 되었고, 특수화된 고정 데이터 경로의 시대가 끝났다. GPU 하드웨어는 점차 범용 SIMD 설계로 이동했다. 이제 SIMD 유닛은 버텍스, 픽셀, 지오메트리, 헐, 도메인, 컴퓨트 등 모든 셰이더 유형을 실행한다. 오늘날 프레임워크에는 16개의 서로 다른 셰이더 엔트리 포인트가 존재한다. 이는 API 표면을 크게 늘리고 조합을 어렵게 만든다. 그 결과 GLSL과 HLSL은 여전히 활발한 라이브러리 생태계를 갖추지 못하고 있다.

DirectX 11에는 하드웨어 데이터 경로의 특수성을 반영한 다양한 버퍼 유형이 존재했다. typed SRV & UAV, byte address SRV & UAV, structured SRV & UAV, append & consume(카운터 포함), constant, vertex, index 버퍼 등 일종의 “버퍼 동물원”이었다. 텍스처와 마찬가지로 DirectX의 버퍼는 불투명 디스크립터를 사용한다. 디스크립터는 하드웨어에 특화된(보통 128~256비트) 데이터 블록으로, 리소스의 크기, 포맷, 속성, GPU 메모리 주소를 인코딩한다. DirectX 11 GPU는 버퍼 로드(gather) 연산에 텍스처 샘플러를 활용했다. 샘플러는 타입 변환 하드웨어와 소형 읽기 전용 캐시를 이미 갖추고 있었기 때문이다. Typed 버퍼는 텍스처와 동일한 포맷을 지원했고, DirectX는 텍스처와 버퍼 모두에 동일한 SRV(Shader Resource View) 추상화를 사용했다.

불투명 디스크립터를 사용한다는 것은 버퍼 포맷이 셰이더 컴파일 시점에 알려지지 않는다는 의미다. 읽기 전용 버퍼에서는 샘플러가 이를 처리했기 때문에 문제가 크지 않았다. 그러나 읽기/쓰기 버퍼(UAV)는 초기에는 32비트 및 128비트(vec4) 타입으로 제한되었다. 이후 API와 하드웨어 개정으로 typed UAV 로드의 제약이 완화되었지만, 근본적인 문제는 남아 있었다. 디스크립터는 간접 참조(포인터 포함)를 요구하고, 데이터 타입이 런타임에만 알려지므로 컴파일러 최적화가 제한되며, 포맷 변환 하드웨어는 지연(latency)을 추가하고, 로드 시 확장(expand at load)은 레지스터 점유 시간을 늘리며, 디스크립터 관리는 CPU 드라이버 복잡성을 증가시키고, API 자체도 지나치게 복잡하다(열 가지 버퍼 유형).

DirectX 11에서 structured buffer는 사용자 정의 struct 타입을 허용한 유일한 버퍼였다. 다른 버퍼 유형은 단순한 스칼라/벡터 요소의 균질 배열이었다. 하지만 structured buffer는 다른 버퍼 유형과 레이아웃 호환이 되지 않았다. structured buffer 뷰를 typed buffer, byte address buffer, vertex/index buffer에 적용할 수 없었다. 그 이유는 structured buffer가 구형 vec4 아키텍처에 최적화된 AoSoA 스위즐 방식을 내부적으로 사용했기 때문이다. 이러한 하드웨어 특화 최적화는 structured buffer의 활용성을 제한했다.

DirectX 12는 모든 버퍼를 선형 메모리 구조로 만들어 서로 호환되도록 했다. SM 6.2는 byte address buffer에 대해 load<T> 문법을 추가해 임의 오프셋에서 구조체를 깔끔하게 로드할 수 있게 했다. 하지만 하위 호환성 때문에 기존 버퍼 유형은 여전히 유지되고 있으며, 모든 버퍼는 여전히 불투명 디스크립터를 사용한다. HLSL은 여전히 64비트 GPU 포인터를 지원하지 않는다. 반면 Nvidia CUDA(2007)는 처음부터 64비트 포인터에 전적으로 의존했지만, 초기에는 학술 분야에 주로 사용되었다. 오늘날 CUDA는 AI 분야의 선도 플랫폼이 되었고, 하드웨어 설계에도 큰 영향을 미치고 있다.

DirectX 12 출시 당시 16비트 레지스터 및 16비트 연산 지원은 혼란스러웠다. Microsoft는 DirectX 12를 Windows 7에 백포트하지 않는 결정을 내렸고, Windows 8용 셰이더 바이너리는 16비트 타입을 지원했지만 대부분의 게이머는 여전히 Windows 7을 사용했다. 개발자들은 두 종류의 셰이더를 배포하고 싶어하지 않았다. OpenGL의 lowp/mediump 명세도 혼란스러웠고, 비트 깊이가 명확히 표준화되지 않았다. mediump는 모바일 게임에서 인기 있는 최적화였지만, 많은 PC 드라이버는 이를 무시했다. PS4 Pro가 2016년에 double-rate fp16을 지원하기 전까지 AAA 게임은 16비트 연산을 거의 사용하지 않았다.

AI, 레이 트레이싱, GPU 기반 렌더링이 부상하면서 GPU 벤더들은 원시 데이터 로드 경로를 최적화하고 더 크고 빠른 범용 캐시를 제공하는 데 집중하기 시작했다. 텍스처 샘플러를 통한 로드는 현대 셰이더에서 흔한 종속적 로드 체인에 과도한 지연을 초래했다. 하드웨어는 8비트, 16비트, 64비트 타입과 포인터를 네이티브로 지원하게 되었다.

대부분의 벤더는 고정 기능 버텍스 페치 하드웨어를 제거하고, 대신 버텍스 셰이더에서 표준 raw load 명령을 사용하도록 했다. 완전한 프로그래머블 버텍스 페치는 클러스터 기반 GPU 주도 렌더링과 같은 새로운 알고리즘을 가능하게 했다. 고정 기능 하드웨어에 쓰이던 트랜지스터 예산은 다른 곳에 활용될 수 있었다.

메시 셰이더는 래스터라이저 진화의 정점이라 할 수 있다. 인덱스 중복 제거 하드웨어와 포스트 트랜스폼 캐시를 제거하고, 모든 입력을 원시 메모리로 취급한다. 사용자는 메시를 내부적으로 정점을 공유하는 독립적인 메시릿(meshlet)으로 나누어야 하며, 이는 보통 오프라인에서 수행된다. GPU는 드로우 호출마다 병렬 인덱스 중복 제거를 수행할 필요가 없어 전력과 트랜지스터를 절약한다. 오늘날 Nvidia 매출의 90%가 AI에서 나오고 게임은 10%에 불과하며, 레이 트레이싱도 성장하고 있다는 점을 고려하면, 고정 기능 지오메트리 하드웨어가 최소 수준으로 축소되고 드라이버가 자동으로 버텍스 셰이더를 메시 셰이더로 변환하는 시점이 머지않았을 가능성이 크다.

모바일 GPU는 타일 기반 렌더러다. 타일러는 삼각형을 작은 타일(보통 16x16~64x64 픽셀)로 분할한다. 메시 셰이더는 이 목적에는 너무 거칠다. 메시릿을 작은 타일로 다시 분할하면 과도한 지오메트리 오버셰이딩이 발생한다. 따라서 명확한 수렴 경로는 없으며, 여전히 버텍스 셰이더 경로를 지원해야 한다.

DirectX 12.0, Vulkan 1.0, Metal 1.0이 등장한 10년 전에는 GPU 하드웨어가 바인드리스 리소스를 널리 지원하지 않았다. API는 하드웨어 차이를 추상화하기 위해 복잡한 바인딩 모델을 도입했다. DirectX는 스테이지당 최대 128개 리소스 인덱싱을 허용했지만, Vulkan과 Metal은 초기에는 디스크립터 인덱싱을 지원하지 않았다. 개발자들은 텍스처 아틀라스 패킹이나 메시 병합 같은 전통적 우회 기법을 계속 사용해야 했다. 지난 10년 동안 GPU 하드웨어는 크게 발전했고, 범용 바인드리스 SIMD 설계로 수렴했다.

이제 현대적인 바인드리스 하드웨어만을 전제로 그래픽 API와 셰이더 언어를 설계한다면 얼마나 단순해질 수 있을지 살펴보자.

Modern GPU memory management

메모리 관리부터 살펴보자. 과거의 그래픽스 API는 GPU 메모리 관리를 완전히 추상화했다. 이는 옛 GPU들이 분리된 메모리 구조를 갖거나, 캐시 일관성 문제가 있는 특수 데이터 경로를 사용했기 때문에 필요한 설계였다. 10년 전 DirectX 12와 Vulkan이 등장했을 무렵에는 GPU 하드웨어가 충분히 성숙해져, 사용자에게 배치 힙(placement heap)을 노출할 수 있게 되었다. 콘솔은 이미 여러 세대 전부터 메모리를 직접 노출해왔고, 개발자들도 PC와 모바일에서 비슷한 유연성을 요구했다. Apple은 Vulkan과 DirectX 12가 나온 지 4년 뒤 Metal 2에서 배치 힙을 도입했다.

현대 API에서는 GPU 드라이버가 제공하는 메모리 유형을 파악하기 위해 사용자가 힙 타입을 열거해야 한다. 큰 덩어리로 메모리를 미리 할당하고 사용자 공간 할당자(suballocator)로 나누어 쓰는 것은 좋은 관행이다. 그러나 Vulkan에는 설계상의 문제가 있다. 먼저 텍스처나 버퍼 객체를 생성한 뒤에야, 해당 리소스와 호환되는 힙 타입을 질의할 수 있다. 이는 사용자를 지연 할당(lazy allocation) 패턴으로 몰아넣으며, 런타임에서 성능 끊김이나 메모리 급증을 유발할 수 있다. 또한 GPU 메모리 할당을 크로스 플랫폼 라이브러리로 감싸기 어렵게 만든다. 예를 들어 AMD VMA는 Vulkan 전용 버퍼/텍스처 객체를 생성하는 동시에 메모리 할당 까지 수행한다. 우리는 이 두 관심사를 완전히 분리하고자 한다.

오늘날 CPU는 GPU 메모리를 완전히 가시적으로 접근할 수 있다. 통합 GPU는 UMA를 사용하고, 최신 외장 GPU는 PCIe Resizable BAR를 지원한다. 전체 GPU 힙을 매핑할 수 있다. Vulkan의 힙 API는 자연스럽게 CPU 매핑 GPU 힙을 지원하며, DirectX 12도 2023년에 HEAP_TYPE_GPU_UPLOAD를 통해 이를 지원하게 되었다.

CUDA는 GPU 메모리 할당에 대해 단순한 설계를 갖는다. GPU malloc API는 크기를 입력받아 CPU에서 매핑된 포인터를 반환하고, GPU free API는 해당 메모리를 해제한다. CUDA는 CPU 매핑 GPU 메모리를 지원하지 않는다. GPU는 PCIe 버스를 통해 CPU 메모리를 읽는다. CUDA는 GPU 메모리 할당도 지원하지만, 이 메모리는 CPU가 직접 쓸 수 없다.

우리는 CUDA의 malloc 설계와 CPU 매핑 GPU 메모리(UMA/ReBAR)를 결합한다. 이는 양쪽의 장점을 취한 방식이다. 데이터는 CPU가 쓰기에도 빠르고 GPU가 읽기에도 빠르며, 동시에 깔끔하고 사용하기 쉬운 설계를 유지할 수 있다.

// Allocate GPU memory for array of 1024 uint32
uint32 * numbers = gpuMalloc(1024 * sizeof(uint32));

// Directly initialize (CPU mapped GPU pointer)
for (int i = 0; i < 1024; i++) numbers[i] = random();

gpuFree(numbers);

기본 gpuMalloc 정렬(alignment)은 16바이트(vec4 정렬)이다. 더 큰 정렬이 필요하면 gpuMalloc(size, alignment) 오버로드를 사용하면 된다. 예제 코드에서는 gpuMalloc<T> 래퍼를 사용해 gpuMalloc(elements * sizeof(T), alignof(T)) 형태로 호출한다.

GPU 메모리에 데이터를 직접 쓰는 방식은 드로우 인자, 유니폼, 디스크립터 같은 작은 데이터에 최적이다. 그러나 큰 영속 데이터의 경우에는 여전히 복사(copy) 연산을 수행하는 것이 바람직하다. GPU는 캐시 지역성을 개선하기 위해 텍스처를 Morton-order와 유사한 스위즐 레이아웃으로 저장한다. DirectX 11.3과 12는 이 스위즐 레이아웃을 표준화하려 했지만, 모든 GPU 제조사를 설득하지는 못했다. 일반적으로 텍스처 스위즐은 드라이버가 제공하는 복사 명령을 통해 수행된다. 이 복사 명령은 CPU 매핑 “업로드” 힙에서 선형 텍스처 데이터를 읽어, 프라이빗 GPU 힙의 스위즐 레이아웃으로 기록한다.

모든 최신 GPU는 무손실 델타 컬러 압축(DCC)도 지원한다. 최신 GPU의 복사 엔진은 DCC 압축과 해제를 처리할 수 있다. DCC와 Morton 스위즐은 텍스처를 프라이빗 GPU 힙으로 복사하려는 주요 이유다. 최근에는 버퍼 데이터에 대해서도 범용 무손실 메모리 압축이 추가되었다. 하지만 메모리 힙이 CPU 매핑 상태라면, CPU가 해당 압축 형식을 이해하지 못하기 때문에 GPU는 벤더별 무손실 압축을 활성화할 수 없다. 따라서 데이터를 압축하려면 복사 명령을 사용해야 한다.

프라이빗 GPU 메모리를 지원하려면 gpuMalloc 함수에 메모리 타입 파라미터가 필요하다. 기본 메모리 타입은 CPU 매핑 GPU 메모리(write-combined CPU 접근)여야 한다. 이는 GPU가 읽기에 빠르고, CPU도 일반 포인터처럼 직접 쓸 수 있다. GPU 전용 메모리는 텍스처와 대형 GPU 전용 버퍼에 사용된다. CPU는 이 GPU 포인터에 직접 쓸 수 없다. 사용자는 먼저 CPU 매핑 GPU 메모리에 데이터를 작성한 뒤, 복사 명령을 발행해 데이터를 최적의 압축 형식으로 변환한다. 최신 텍스처 샘플러와 디스플레이 엔진은 압축된 GPU 데이터를 직접 읽을 수 있으므로, 이후 별도의 데이터 레이아웃 변환은 필요하지 않다(“Modern barriers” 장 참고). 업로드된 데이터는 즉시 사용 가능하다.

GPU 포인터에는 두 가지 유형이 있다. 하나는 CPU 매핑 가상 주소이고, 다른 하나는 GPU 가상 주소다. GPU는 GPU 주소만 역참조할 수 있으므로, GPU 데이터 구조 내의 모든 포인터는 GPU 주소를 사용해야 한다. CPU 매핑 주소는 CPU가 데이터를 쓸 때만 사용된다. CUDA는 CPU 매핑 주소를 GPU 주소로 변환하는 API(cudaHostGetDevicePointer)를 제공한다. Metal 4의 버퍼 객체는 .contents(CPU 매핑 주소)와 .gpuAddress(GPU 주소) 두 가지 접근자를 제공한다. gpuMalloc API는 Metal처럼 관리 객체 핸들을 반환하는 대신 포인터를 반환하므로, 여기서는 CUDA 방식(gpuHostToDevicePointer)을 선택한다. 이 주소 변환 호출은 비용이 없지 않다. 드라이버는 이를 해시 맵으로 구현할 가능성이 높으며(기본 주소 외의 변환이 필요하면 트리 구조가 필요할 수도 있다). 이상적으로는 할당당 한 번만 주소 변환을 수행하고, 사용자 공간 구조체에 (void *cpu, void *gpu) 형태로 캐시하는 것이 좋다. 내가 구현한 사용자 공간 GPUBumpAllocator도 이 방식을 사용한다(전체 구현은 부록 참고).

// Load a mesh using a 3rd party library
auto mesh = createMesh("mesh.obj");
auto upload = uploadBumpAllocator.allocate(mesh.byteSize); // Custom bump allocator (wraps a gpuMalloc ptr)
mesh.load(upload.cpu);

// Allocate GPU-only memory and copy into it
void* meshGpu = gpuMalloc(mesh.byteSize, MEMORY_GPU);
gpuMemCpy(commandBuffer, meshGpu, upload.gpu);

Vulkan에는 최근 VK_EXT_host_image_copy라는 새로운 확장이 추가되었다. 이 확장은 드라이버가 CPU에서 GPU로 직접 이미지 복사를 수행하도록 하며, 이 과정에서 하드웨어 특화 텍스처 스위즐을 CPU에서 처리한다. 현재 이 확장은 UMA 아키텍처에서만 지원되지만, PCIe ReBAR 환경에서도 기술적으로 불가능한 것은 아니다. 다만 이 API는 DCC를 지원하지 않는다. CPU에서 DCC 압축을 수행하는 것은 비용이 너무 크기 때문이다. 이 확장은 주로 블록 압축 텍스처에 유용한데, 블록 압축 텍스처는 DCC가 필요하지 않기 때문이다. 따라서 이 방식은 하드웨어 복사를 통한 GPU 프라이빗 메모리 전송을 완전히 대체할 수는 없다.

또한 리드백(readback)을 위해 세 번째 메모리 타입, 즉 CPU 캐시드 메모리도 필요하다. 이 메모리 타입은 CPU와의 캐시 일관성 때문에 GPU 쓰기 속도가 느리다. 게임에서는 리드백을 자주 사용하지 않으며, 대표적인 용도는 스크린샷이나 가상 텍스처링 리드백이다. 반면 AI 학습 및 추론과 같은 GPGPU 알고리즘은 CPU와 GPU 간의 효율적인 데이터 교환에 크게 의존한다.

CUDA의 malloc 방식의 단순함과 CPU 매핑 GPU 메모리를 결합하면, 최소한의 API 표면으로도 유연하고 빠른 GPU 메모리 할당 시스템을 만들 수 있다. 이는 최소주의적인 현대 그래픽스 API를 설계하기 위한 훌륭한 출발점이 된다.

Modern data

CUDA, Metal, OpenCL은 64비트 포인터 의미론을 지원하는 C/C++ 기반 셰이더 언어를 사용한다. 이러한 언어는 적절히 정렬된 GPU 메모리의 임의 위치로부터 구조체를 로드하고 저장할 수 있다. 넓은 로드(combine), 레지스터 매핑, 비트 추출과 같은 최적화는 컴파일러가 내부적으로 처리한다. 많은 최신 GPU는 레지스터의 8/16비트 부분을 추출하는 무료 명령어 수정자(instruction modifier)를 제공하므로, 컴파일러는 8비트 및 16비트 값을 하나의 레지스터에 패킹할 수 있다. 이는 셰이더 코드를 깔끔하고 효율적으로 유지하는 데 도움이 된다.

예를 들어 32비트 값 8개로 이루어진 구조체를 로드하면, 컴파일러는 대개 128비트 폭의 로드 두 번(각각 4개 레지스터 채움)으로 변환한다. 이는 로드 명령 수를 4배 줄이는 효과가 있다. 특히 구조체에 8비트 또는 16비트 필드가 포함된 경우, 넓은 로드는 훨씬 빠르다. GPU는 ALU 밀도가 높고 레지스터 파일이 크지만, CPU에 비해 메모리 경로는 상대적으로 느리다. CPU는 보통 두 개의 로드 포트를 통해 매 사이클 로드를 수행할 수 있지만, 최신 GPU에서는 4사이클당 하나의 SIMD 로드가 가능하다. 따라서 넓은 로드 후 셰이더에서 언팩(unpack)하는 방식이 데이터 처리에 가장 효율적인 경우가 많다.

DirectX 게임에서는 전통적으로 8~16비트의 압축 데이터가 텍셀 버퍼(Buffer<T>)에 저장되어 왔다. 그러나 현대 GPU는 컴퓨트 워크로드에 최적화되어 있다. 현재 원시(raw) 버퍼 로드 명령은 텍셀 버퍼 대비 최대 2배 높은 처리량과 최대 3배 낮은 지연 시간을 제공한다. 텍셀 버퍼는 더 이상 최적의 선택이 아니다. 텍셀 버퍼는 구조체 데이터를 지원하지 않아, 사용자는 데이터를 여러 텍셀 버퍼에 SoA(Structure of Arrays) 형태로 분리해야 한다. 각 텍셀 버퍼는 자체 디스크립터를 갖고 있으며, 데이터 접근 전에 이를 로드해야 한다. 이는 리소스(SGPR, 디스크립터 캐시 슬롯)를 소모하고, 단일 64비트 원시 포인터를 사용하는 것보다 초기 지연을 증가시킨다. 또한 SoA 레이아웃은 비선형 인덱스 조회(예: 머티리얼, 텍스처, 삼각형, 인스턴스, 본 ID)에서 캐시 미스를 크게 증가시킨다. 텍셀 버퍼는 정규화된([0,1] 및 [-1,1]) 타입을 부동소수점 레지스터로 무료 변환해준다는 장점이 있다. ALU 비용은 없지만, 넓은 로드를 지원하지 못하고(로드 결합 불가), 명령이 느린 텍스처 샘플러 경로를 통과한다. 좁은 텍셀 버퍼 로드는 레지스터 사용량도 증가시킨다. 예를 들어 RGBA8_UNORM을 vec4로 로드하면 즉시 4개의 벡터 레지스터가 할당된다. 샘플러 하드웨어는 결국 이 레지스터에 값을 기록한다. 컴파일러는 로드 지연을 숨기기 위해 로드→사용 간 거리를 최대화하려고 셰이더 초반에 로드 명령을 배치한다. 이렇게 하면 ALU 연산과 겹치게 하여 지연을 숨기고 여러 로드를 중첩시킬 수 있다. 반면 넓은 원시 로드를 사용하면 uint8x4 데이터는 단 하나의 32비트 레지스터만 차지한다. 실제 사용 시점에 8비트 채널을 언팩하면 되므로 레지스터 수명도 훨씬 짧다. 현대 GPU는 언팩 없이도 16비트 레지스터의 상·하위 절반에 직접 접근할 수 있고, 일부는 8비트 접근도 가능하다(예: AMD의 SDWA 수정자). 패킹된 double-rate 연산은 2x16비트 변환 명령을 더 빠르게 수행할 수 있다. 또한 일부 GPU 아키텍처(Nvidia, AMD)는 64비트 포인터 기반 원시 로드를 VRAM에서 직접 그룹 공유 메모리로 수행할 수 있어, 지연 숨김을 위한 레지스터 사용량을 더욱 줄일 수 있다. 64비트 포인터를 사용하면, 게임 엔진은 AI 하드웨어 최적화의 이점을 자연스럽게 활용할 수 있다.

포인터 기반 시스템은 메모리 정렬을 명시적으로 드러낸다. DirectX나 Vulkan에서 버퍼 객체를 할당할 때는 API를 통해 정렬 요구사항을 질의해야 하며, 버퍼 바인딩 오프셋도 올바르게 정렬되어야 한다. Vulkan은 바인딩 오프셋 정렬을 질의하는 API를 제공하고, DirectX는 고정된 정렬 규칙을 갖는다. 이러한 정렬 계약은 저수준 셰이더 컴파일러가 정렬된 4×32바이트 폭 로드와 같은 최적 코드를 생성할 수 있게 해준다. 하지만 DirectX의 ByteAddressBuffer 추상화에는 설계상의 결함이 있다. load2, load3, load4 명령은 4바이트 정렬만 요구한다. SM 6.2의 load<T> 역시 요소 단위 정렬만 요구한다(예: half4 = 2, float4 = 4). 일부 GPU 벤더(예: Nvidia)는 ByteAddressBuffer.load4를 네 개의 개별 로드 명령으로 분할해야 한다. 버퍼 추상화가 항상 잘못된 코드 생성(codegen)을 가려주지는 못하며, 잘못된 코드 생성은 수정하기도 어렵다. CUDA나 Metal과 같은 C/C++ 기반 언어에서는 alignas 속성을 통해 구조체 정렬을 명시할 수 있다. 예제 코드의 루트 구조체에는 모두 alignas(16)을 사용한다.

기본적으로 GPU 쓰기는 동일한 스레드 그룹(= 동일한 컴퓨트 유닛) 내의 스레드에서만 가시적이다. 이는 비일관성(non-coherent) L1 캐시 설계를 가능하게 한다. 그룹 간 가시성은 일반적으로 배리어로 보장한다. 단일 디스패치 내에서 그룹 간 메모리 가시성이 필요하다면, 사용자는 버퍼 바인딩에 [globallycoherent] 속성을 지정한다. 그러면 셰이더 컴파일러는 해당 버퍼 접근에 대해 일관성 있는 로드/스토어 명령을 생성한다. 우리는 버퍼 객체 대신 64비트 포인터를 사용하므로, 명시적인 일관성(coherent) 로드/스토어 명령을 제공한다. 문법은 원자적 로드/스토어와 유사하다. 또한 전체 캐시 계층을 우회하는 비일시적(non-temporal) 로드/스토어 명령도 제공할 수 있다.

Vulkan은 2019년에 도입된 VK_KHR_buffer_device_address extension을 통해 64비트 포인터를 지원한다. 이 확장은 모든 GPU 벤더(모바일 포함)에서 널리 지원되지만, Vulkan 1.4의 코어에는 포함되지 않았다. BDA의 주요 문제는 GLSL과 HLSL 셰이더 언어에서 포인터를 지원하지 않는다는 점이다. 사용자는 대신 원시 64비트 정수를 사용해야 한다. 64비트 정수는 구조체로 캐스팅할 수 있으며, 구조체는 별도의 BDA 전용 문법으로 정의된다. 배열 인덱싱을 위해서는 인덱스 주소 계산을 컴파일러가 생성하도록, 배열을 포함하는 별도의 BDA 구조체 타입을 선언해야 한다. 현재 디버깅 지원도 제한적이다. 사용성은 매우 중요하며, HLSL과 GLSL이 포인터를 네이티브로 지원하기 전까지 BDA는 틈새 기능에 머물 것이다. 이는 포인터 지원이 언어의 핵심인 CUDA, OpenCL, Metal과는 대조적이다. 이들 환경에서는 디버깅도 원활하다.

DirectX 12는 셰이더에서 포인터를 지원하지 않는다. 그 결과 HLSL은 배열을 함수 매개변수로 전달할 수 없다. UBO/SSBO 안에 머티리얼 배열을 두는 것조차 매크로를 동원한 우회가 필요하다. groupshared 메모리 배열을 함수 간에 전달할 수 없기 때문에, prefix sum이나 정렬 같은 재사용 가능한 함수 작성도 사실상 불가능하다. 각 유틸리티 헤더/라이브러리마다 별도의 전역 배열을 선언할 수는 있지만, 컴파일러는 각 배열마다 groupshared 메모리를 따로 할당해 점유율(occupancy)을 낮춘다. groupshared 메모리를 쉽게 별칭(alias) 처리할 방법도 없다. GLSL도 동일한 문제를 가진다. 반면 CUDA나 Metal MSL 같은 포인터 기반 언어에서는 배열과 관련해 이런 제약이 없다. CUDA는 방대한 서드파티 라이브러리 생태계를 갖추고 있으며, 이 생태계는 Nvidia를 세계에서 가장 가치 있는 기업으로 만드는 데 기여했다. 그래픽 셰이딩 언어도 현대적 기준에 맞게 진화해야 한다. 우리에게도 라이브러리 생태계가 필요하다.

이후 예제에서는 CUDA와 Metal MSL에 가까운 C/C++ 스타일 셰이딩 언어를 사용하되, 그래픽스 관련 요소에는 일부 HLSL 스타일의 시스템 값(SV) 시맨틱을 혼합해 설명할 것이다.

Root arguments

운영체제의 스레딩 API는 일반적으로 스레드 함수에 하나의 64비트 void 포인터만 전달한다. 운영체제는 사용자의 데이터 입력 레이아웃에 관여하지 않는다. 이와 같은 철학을 GPU 커널의 데이터 입력에도 적용해보자. 셰이더 커널은 단 하나의 64비트 포인터를 전달받고, 커널 함수 시그니처에서 이를 원하는 구조체로 캐스팅한다. 개발자는 CPU와 GPU 양쪽에서 동일한 C/C++ 공용 헤더를 사용할 수 있다.

// Common header...
struct alignas(16) Data
{
    // Uniform data
    float16x4 color; // 16-bit float vector
    uint16x2 offset; // 16-bit integer vector
    const uint8* lut; // pointer to 8-bit data array

    // Pointers to in/out data arrays
    const uint32* input;
    uint32* output;
};

// CPU code...
gpuSetPipeline(commandBuffer, computePipeline);

auto data = myBumpAllocator.allocate<Data>(); // Custom bump allocator (wraps gpuMalloc ptr, see appendix)
data.cpu->color = {1.0f, 0.0f, 0.0f, 1.0f};
data.cpu->offset = {16, 0};
data.cpu->lut = luts.gpu + 64; // GPU pointers support pointer math (no need for offset API)
data.cpu->input = input.gpu;
data.cpu->output = output.gpu;

gpuDispatch(commandBuffer, data.gpu, uvec3(128, 1, 1));

// GPU kernel...
[groupsize = (64, 1, 1)]
void main(uint32x3 threadId : SV_ThreadID, const Data* data)
{
    uint32 value = data->input[threadId.x];
    // TODO: Code using color, offset, lut, etc...
    data->output[threadId.x] = value;
}

예제 코드에서는 GPU 인자 할당을 위해 단순한 선형 범프 할당자(myBumpAllocator)를 사용한다(구현은 부록 참고). 이 할당자는 { void * cpu, void * gpu } 구조체를 반환한다. CPU 포인터는 영구 매핑된 GPU 메모리에 직접 데이터를 쓰는 데 사용하고, GPU 포인터는 GPU 데이터 구조에 저장하거나 디스패치 명령 인자로 전달할 수 있다.

대부분의 GPU는 웨이브를 실행하기 직전에 루트 유니폼(64비트 포인터 포함)을 상수 또는 스칼라 레지스터로 미리 로드한다. 이러한 최적화는 여전히 유효하다. 드로우/디스패치 명령은 기본 데이터 포인터를 전달하고, 모든 입력 유니폼(다른 데이터에 대한 포인터 포함)은 이 기본 포인터로부터 작은 고정 오프셋에 위치한다. 셰이더는 사전 컴파일되고, PSO 생성 시 장치별 마이크로코드로 추가 최적화되므로, 드라이버는 레지스터 프리로드나 루트 데이터 최적화를 충분히 수행할 수 있다. 일부 아키텍처에서는 루트 데이터 크기가 제한되어 있으므로, 가장 중요한 데이터는 루트 구조체의 앞부분에 배치하는 것이 좋다. 우리의 루트 구조체는 하드한 크기 제한이 없으며, 나머지 필드에 대해서는 셰이더 컴파일러가 일반적인(스칼라/유니폼) 메모리 로드를 생성한다. 셰이더에 전달되는 루트 데이터 포인터는 const다. 이는 명령 프로세서가 새 웨이브를 시작할 때 데이터를 재사용할 수 있기 때문에, 셰이더가 루트 입력 데이터를 수정해서는 안 되기 때문이다. 출력은 const가 아닌 포인터(예: 예제의 Data::output)를 통해 수행한다. 루트 데이터를 const로 강제하면 GPU 드라이버가 특수한 유니폼 데이터 경로 최적화를 적용할 수 있다.

그렇다면 별도의 유니폼 버퍼 타입이 필요할까? 현대 셰이더 컴파일러는 자동 유니폼성 분석(uniformity analysis)을 수행한다. 어떤 명령의 모든 입력이 유니폼이면, 그 출력도 유니폼이 된다. 유니폼성은 셰이더 전체로 전파된다. 모든 최신 아키텍처는 스칼라 레지스터/로드(또는 Intel의 SIMD1과 같은 유사 개념)를 갖고 있다. 유니폼성 분석은 벡터 로드를 스칼라 로드로 변환하는 데 사용되며, 이는 레지스터를 절약하고 지연을 줄인다. 이 분석은 버퍼 타입(UBO vs SSBO)에 의존하지 않는다. 다만 리소스는 읽기 전용이어야 한다(그래서 GLSL에서는 SSBO에 readonly를 붙이고, DirectX 12에서는 UAV 대신 SRV를 사용하는 것이 좋다). 또한 컴파일러는 해당 포인터가 별칭(alias)되지 않는다는 것을 증명할 수 있어야 한다. C/C++의 const는 해당 포인터를 통해 수정할 수 없다는 의미일 뿐, 다른 읽기/쓰기 포인터가 같은 메모리를 참조하지 않는다는 보장은 하지 않는다. 이를 위해 C99는 restrict 키워드를 도입했으며, CUDA 커널에서도 자주 사용된다. Metal의 루트 포인터는 기본적으로 no-alias(restrict)이며, Vulkan과 DirectX 12의 버퍼 객체도 동일하다. 우리는 동일한 관례를 채택해 컴파일러가 더 자유롭게 최적화하도록 해야 한다.

컴파일러가 항상 컴파일 시점에 주소의 유니폼성을 증명할 수 있는 것은 아니다. 현대 GPU는 동적으로 유니폼한 주소 로드를 기회주의적으로 최적화한다. 메모리 컨트롤러가 벡터 로드 명령의 모든 레인이 동일한 주소를 참조한다는 것을 감지하면, SIMD 폭의 gather 대신 단일 레인 로드를 수행하고 그 결과를 모든 레인에 복제한다. 이 최적화는 투명하게 이루어지며, 셰이더 코드 생성이나 레지스터 할당에 영향을 주지 않는다. 동적 유니폼 데이터의 성능 비용은 과거에 비해 훨씬 줄었으며, 특히 최신의 빠른 raw 로드 경로와 결합될 때 그 영향이 작다.

일부 GPU 벤더(ARM Mali, Qualcomm Adreno)는 유니폼성 분석을 한 단계 더 확장한다. 셰이더 컴파일러가 유니폼 로드와 유니폼 연산을 추출해, 셰이더 실행 전에 스칼라 프리앰블을 실행한다. 유니폼 메모리 로드와 연산은 드로우/디스패치당 한 번만 수행되고, 결과는 특수 하드웨어 상수 레지스터(루트 상수에 사용되는 동일한 레지스터)에 저장된다.

이러한 모든 최적화를 종합하면, 전통적인 16KB/64KB 유니폼/상수 버퍼 추상화보다 더 나은 유니폼 데이터 처리 방식이 가능하다. 많은 GPU는 여전히 루트 상수, 시스템 값, 프리앰블 실행을 위한 특수 유니폼 레지스터를 갖고 있다.

Texture bindings

이상적으로는 텍스처 디스크립터도 GPU 메모리의 일반 데이터처럼 동작해, 다른 데이터와 함께 구조체 안에 자유롭게 섞어 쓸 수 있어야 한다. 그러나 이러한 수준의 유연성은 아직 모든 최신 GPU에서 보편적으로 지원되지는 않는다. 다행히 지난 10년간 바인드리스 텍스처 샘플러 설계는 점차 수렴해왔으며, 현재는 크게 두 가지 방식만 남아 있다. 256비트 원시(raw) 디스크립터 방식과 인덱스 기반 디스크립터 힙 방식이다.

AMD의 원시 디스크립터 방식은 256비트 디스크립터를 GPU 메모리에서 직접 로드해 컴퓨트 유닛의 스칼라 레지스터에 저장한다. 32비트 스칼라 레지스터 8개가 하나의 디스크립터를 구성한다. SIMD 텍스처 샘플 명령 실행 시, 셰이더 코어는 256비트 텍스처 디스크립터와 각 레인의 UV를 샘플러 유닛에 전달한다. 이를 통해 샘플러는 추가적인 간접 참조 없이 텍셀을 주소 지정하고 로드할 수 있다. 단점은 256비트 디스크립터가 많은 레지스터 공간을 차지하며, 샘플 명령마다 다시 전달해야 한다는 점이다.

인덱스 기반 디스크립터 힙 방식은 32비트 인덱스(구형 Intel iGPU는 20비트)를 사용한다. 32비트 인덱스는 구조체에 저장하기 쉽고, 표준 SIMD 레지스터에 로드하기도 간단하며, 전달 비용도 적다. SIMD 샘플 명령 시 셰이더 코어는 텍스처 인덱스와 각 레인의 UV를 샘플러에 전달한다. 샘플러는 디스크립터 힙에서 디스크립터를 가져온다: 힙 기본 주소 + 텍스처 인덱스 × 스트라이드(현대 GPU에서는 256비트). 텍스처 힙의 기본 주소는 Vulkan/Metal에서는 드라이버가 추상화하며, DirectX 12에서는 사용자가 SetDescriptorHeaps로 설정한다. 힙 기본 주소 변경은 구형 하드웨어에서 내부 파이프라인 배리어를 유발할 수 있다. 현대 GPU에서는 샘플 명령 데이터에 64비트 힙 기본 주소가 포함되어 여러 힙을 자연스럽게 샘플링할 수 있다(64비트 기본 주소 + 레인당 32비트 오프셋). 샘플러 유닛은 최초 접근 이후 간접 읽기를 피하기 위해 작은 내부 디스크립터 캐시를 갖는다. 디스크립터 힙이 수정되면 캐시를 무효화해야 한다.

몇 년 전까지만 해도 AMD의 스칼라 레지스터 기반 디스크립터 방식이 장기적으로 더 유리해 보였다. 스칼라 레지스터는 디스크립터 힙보다 유연해, 디스크립터를 GPU 데이터 구조 안에 직접 포함할 수 있기 때문이다. 하지만 단점도 있다. 최신 GPU 워크로드(예: 레이 트레이싱, Nanite 기반 지연 텍스처링)는 비균일(non-uniform) 텍스처 인덱스를 많이 사용한다. SIMD 웨이브 내에서 텍스처 힙 인덱스가 균일하지 않다. 32비트 인덱스는 4바이트에 불과해 레인마다 전달할 수 있지만, 256비트 디스크립터는 32바이트이므로 레인마다 전체 디스크립터를 전달하는 것은 비현실적이다. Nvidia, Apple, Qualcomm의 최신 GPU는 샘플 명령에서 레인별 디스크립터 인덱스를 지원해 비균일 경우를 효율적으로 처리한다. 필요 시 샘플러 유닛이 내부 루프를 수행한다. 입력/출력은 힙 인덱스의 균일성과 무관하게 한 번만 전달된다. 반면 AMD의 스칼라 레지스터 기반 방식은 비균일 인덱스 처리 시 셰이더 컴파일러가 스칼라화 루프를 생성해야 한다. 이는 추가 ALU 비용을 발생시키고, 샘플러 데이터 송수신을 여러 번(부분 마스크 포함) 수행해야 한다. Nvidia가 레이 트레이싱에서 AMD보다 빠른 이유 중 하나다. ARM과 Intel도 32비트 힙 인덱스를 사용하지만, 최신 아키텍처에서도 레인별 힙 인덱스 모드를 완전히 지원하지는 않아 AMD와 유사한 스칼라화 루프를 생성한다.

이러한 차이점은 통합된 텍스처 디스크립터 힙 추상화로 감쌀 수 있다. 사실상의 디스크립터 크기는 256비트이며(Apple은 텍스처 디스크립터 192비트 + 샘플러 32비트 분리), 텍스처 힙은 256비트 디스크립터 블롭의 균질 배열로 표현할 수 있다. 인덱싱은 단순하다. DirectX 12 SM 6.6은 이와 유사한 추상화를 제공하지만, 디스크립터 힙 메모리에 대한 CPU 또는 컴퓨트 셰이더의 직접 쓰기를 허용하지 않는다. 디스크립터 생성 및 CPU→GPU 복사를 위한 별도 API를 사용하며, GPU는 디스크립터를 직접 쓸 수 없다. 오늘날에는 이 API 추상화를 제거하고 CPU와 GPU가 디스크립터 힙에 직접 쓸 수 있도록 할 수 있다. 필요한 것은 256비트(uint64[4]) 하드웨어 특화 디스크립터 블롭을 생성하는 간단한 사용자 공간 드라이버 헬퍼 함수뿐이다. 최신 GPU는 UMA 또는 PCIe ReBAR를 지원하므로 CPU가 GPU 메모리에 직접 디스크립터 블롭을 쓸 수 있다. 사용자는 컴퓨트 셰이더로 디스크립터를 복사하거나 생성할 수도 있다. 셰이더 언어에도 디스크립터 생성 내장 함수가 있어, 하드웨어 특화 uint64x4 디스크립터 블롭을 반환하도록 한다(이는 CPU API와 유사하다). 이러한 접근은 API 복잡성을 크게 줄이면서 DirectX 12의 디스크립터 업데이트 모델보다 더 빠르고 유연하다. Vulkan의 VK_EXT_descriptor_buffer 확장(2022)은 이 제안과 유사하게 CPU 및 GPU의 직접 쓰기를 허용하며, 대부분의 벤더가 지원하지만 아직 Vulkan 1.4 코어 사양에는 포함되지 않았다.

// App startup: Allocate a texture descriptor heap (for example 65536 descriptors)
GpuTextureDescriptor *textureHeap = gpuMalloc<GpuTextureDescriptor>(65536);

// Load an image using a 3rd party library
auto pngImage = pngLoad("cat.png");
auto uploadMemory = uploadBumpAllocator.allocate(pngImage.byteSize); // Custom bump allocator (wraps gpuMalloc ptr)
pngImage.load(uploadMemory.cpu);

// Allocate GPU memory for our texture (optimal layout with metadata)
GpuTextureDesc textureDesc { .dimensions = pngImage.dimensions, .format = FORMAT_RGBA8_UNORM, .usage = SAMPLED };
GpuTextureSizeAlign textureSizeAlign = gpuTextureSizeAlign(textureDesc);
void *texturePtr = gpuMalloc(textureSizeAlign.size, textureSizeAlign.align, MEMORY_GPU);
GpuTexture texture = gpuCreateTexture(textureDesc, texturePtr);

// Create a 256-bit texture view descriptor and store it
textureHeap[0] = gpuTextureViewDescriptor(texture, { .format = FORMAT_RGBA8_UNORM });

// Batched upload: begin
GpuCommandBuffer uploadCommandBuffer = gpuStartCommandRecording(queue);

// Copy all textures here!
gpuCopyToTexture(uploadCommandBuffer, texturePtr, uploadMemory.gpu, texture);
// TODO other textures...

// Batched upload: end
gpuBarrier(uploadCommandBuffer, STAGE_TRANSFER, STAGE_ALL, HAZARD_DESCRIPTORS);
gpuSubmit(queue, { uploadCommandBuffer });

// Later during rendering...
gpuSetActiveTextureHeapPtr(commandBuffer, gpuHostToDevicePointer(textureHeap));

이론적으로는 CPU 측 텍스처 객체(GpuTexture)를 거의 완전히 제거하는 것도 가능하다. 그러나 아쉽게도 모든 최신 GPU의 삼각형 래스터라이저 유닛은 아직 바인드리스가 아니다. CPU 드라이버는 렌더 타깃, 깊이-스텐실 버퍼의 바인딩, 클리어 및 리졸브 등을 위해 명령 패킷을 준비해야 한다. 이러한 API는 256비트 GPU 텍스처 디스크립터를 사용하지 않는다. 따라서 드라이버 전용의 추가 CPU 데이터가 필요하며, 이는 GpuTexture 객체에 저장된다.

셰이더에서 텍스처를 참조하는 가장 단순한 방법은 32비트 인덱스를 사용하는 것이다. 하나의 인덱스는 디스크립터 범위의 시작 오프셋을 나타낼 수도 있다. 이는 별도의 API 없이 DirectX 12의 디스크립터 테이블 추상화와 Vulkan의 디스크립터 세트 추상화를 구현할 수 있는 간단한 방법을 제공한다. 또한 빠른 머티리얼 전환(use case)에 대해서도 우아한 해결책을 제시한다. 필요한 것은 머티리얼 데이터 구조체(머티리얼 속성 + 32비트 텍스처 힙 시작 인덱스 포함)를 가리키는 하나의 64비트 GPU 포인터뿐이다. Vulkan의 vkCmdBindDescriptorSets나 DirectX 12의 SetGraphicsRootDescriptorTable은 비교적 빠른 API 호출이지만, 영구 매핑된 GPU 메모리에 단일 64비트 포인터를 쓰는 것만큼 빠르지는 않다. 리소스 바인딩 API 객체를 생성·업데이트·삭제할 필요가 없어지면서 많은 복잡성이 제거된다. 또한 사용자 측에서 디스크립터 세트 해시 맵을 유지할 필요가 없어 CPU 시간도 절약된다. 이는 게임 엔진에서 즉시 모드와 보존 모드 간의 불일치를 해결하기 위해 흔히 사용되던 접근 방식이었다.

// Common header...
struct alignas(16) Data
{
    uint32 srcTextureBase;
    uint32 dstTexture;
    float32x2 invDimensions;
};

// GPU kernel...
const Texture textureHeap[];

[groupsize = (8, 8, 1)]
void main(uint32x3 threadId : SV_ThreadID, const Data* data)
{
    Texture textureColor = textureHeap[data->srcTextureBase + 0];
    Texture textureNormal = textureHeap[data->srcTextureBase + 1];
    Texture texturePBR = textureHeap[data->srcTextureBase + 2];

    Sampler sampler = {.minFilter = LINEAR, .magFilter = LINEAR}; // Embedded sampler (Metal-style)

    float32x2 uv = float32x2(threadId.xy) * data->invDimensions;

    float32x4 color = sample(textureColor, sampler, uv);
    float32x4 normal = sample(textureNormal, sampler, uv);
    float32x4 pbr = sample(texturePBR, sampler, uv);

    float32x4 lit = calculateLighting(color, normal, pbr);

    TextureRW dstTexture = TextureRW(textureHeap[data->dstTexture]);
    dstTexture[threadId.xy] = lit;
}

Metal 4는 텍스처 디스크립터 힙을 자동으로 관리한다. 텍스처 객체에는 .gpuResourceID라는 64비트 힙 인덱스가 있으며(Xcode GPU 디버거에서는 0x3 같은 작은 값으로 보인다), 이를 DirectX SM 6.6이나 Vulkan(디스크립터 버퍼 확장)에서 텍스처 인덱스를 사용하는 것처럼 GPU 구조체에 직접 기록할 수 있다. 하지만 Metal에서는 힙 관리가 자동이기 때문에 사용자가 텍스처 디스크립터를 연속된 범위로 할당할 수 없다. 일반적으로는 첫 번째 텍스처의 32비트 인덱스를 저장하고, 나머지 텍스처의 인덱스를 계산하는 방식을 사용한다(위 코드 예시 참고). Metal은 이를 지원하지 않는다. 사용자는 각 텍스처마다 64비트 핸들을 개별적으로 기록해야 한다. 예를 들어 5개의 텍스처 세트를 참조하려면 Metal에서는 40바이트(5 × 64비트)가 필요하지만, Vulkan과 DirectX 12에서는 4바이트(32비트 인덱스 1개)면 충분하다. Apple GPU 하드웨어는 SM 6.6 스타일의 텍스처 힙을 구현할 수 있지만, 제약은 Metal API(소프트웨어) 쪽에 있다.

텍셀 버퍼는 하위 호환성을 위해 계속 지원할 수 있다. DirectX 12에서는 텍셀 버퍼 디스크립터를 텍스처 디스크립터와 동일한 힙에 저장한다. 텍셀 버퍼는 1D 텍스처(비필터링 tfetch 경로)와 유사하게 동작한다. 주 용도가 하위 호환성이라면, 드라이버 벤더가 이를 내부적으로 raw 메모리 로드 같은 더 빠른 코드 경로로 교체하기 위해 복잡한 우회 구현을 할 필요는 없다. 개인적으로는 드라이버 백그라운드 스레드나 셰이더 교체 방식은 선호하지 않는다.

비균일 텍스처 인덱스(Non-Uniform texture index)는 GLSL과 HLSL의 NonUniformResourceIndex 표기법과 유사한 방식으로 처리해야 한다. 이는 저수준 GPU 셰이더 컴파일러가 레인별 힙 인덱스를 사용하는 특수 텍스처 명령을 생성하거나, 균일 디스크립터만 지원하는 GPU에서는 스칼라화 루프를 생성하도록 지시한다. 버퍼는 디스크립터가 아니므로 NonUniformResourceIndex가 필요 없다. 단순히 레인당 64비트 포인터를 전달하면 된다. 이는 모든 최신 GPU에서 동작하며, 스칼라화 루프도 필요 없고 복잡성도 없다. 또한 언어는 ptr[index] 형태의 메모리 로드를 네이티브로 지원해야 한다. 여기서 index는 32비트이다. 일부 GPU는 32비트 레인 오프셋을 사용하는 raw 메모리 로드 명령을 지원해 레지스터 압박을 줄일 수 있다. GPU 벤더에게 제안하자면, 아직 지원하지 않는 아키텍처라면 64비트 공유 베이스 + 32비트 레인 오프셋을 사용하는 raw 로드 명령과 16비트 UV(W) 텍스처 로드 명령을 추가해주기 바란다.

const Texture textureHeap[];

[groupsize = (8, 8, 1)]
void main(uint32x3 threadId : SV_ThreadID, const Data* data)
{
    // Non-uniform "buffer data" is not an issue with pointer semantics!
    Material* material = data->materialMap[threadId.xy];

    // Non-uniform texture heap index
    uint32 textureBase = NonUniformResourceIndex(material.textureBase);

    Texture textureColor = textureHeap[textureBase + 0];
    Texture textureNormal = textureHeap[textureBase + 1];
    Texture texturePBR = textureHeap[textureBase + 2];

    Sampler sampler = {.minFilter = LINEAR, .magFilter = LINEAR};

    float32x2 uv = float32x2(threadId.xy) * data->invDimensions;

    float32x4 color = sample(textureColor, sampler, uv);
    float32x4 normal = sample(textureNormal, sampler, uv);
    float32x4 pbr = sample(texturePBR, sampler, uv);

    color *= material.color;
    pbr *= material.pbr;

    // Rest of the shader
}

현대적인 바인드리스 텍스처링을 사용하면 모든 텍스처 바인딩 API를 제거할 수 있다. 전역적으로 인덱싱 가능한 텍스처 힙을 두면, 모든 텍스처가 모든 셰이더에서 가시적으로 접근 가능해진다. 물론 텍스처 데이터는 여전히 DCC 및 Morton 스위즐을 활성화하기 위해 복사 명령을 통해 GPU 메모리에 로드되어야 한다. 또한 텍스처 디스크립터 생성에는 얇은(thin) GPU 특화 사용자 공간 API가 필요하다. 그러나 텍스처 힙 자체는 CPU와 GPU 모두에 원시 GPU 메모리 배열로 직접 노출할 수 있으며, 이를 통해 DirectX 12 SM 6.6과 비교해 텍스처 힙 관련 API 복잡성을 대부분 제거할 수 있다.

Shader pipelines

셰이더의 루트 데이터가 단일 64비트 포인터이고, 텍스처가 단순한 32비트 인덱스라면 셰이더 파이프라인 생성은 매우 단순해진다. 텍스처 바인딩, 버퍼 바인딩, 바인드 그룹(디스크립터 세트, 아규먼트 버퍼), 루트 시그니처를 정의할 필요가 없다.

auto shaderIR = loadFile("computeShader.ir");
GpuPipeline computePipeline = gpuCreateComputePipeline(shaderIR);

DirectX 12와 Vulkan은 루트 시그니처, 푸시 디스크립터, 푸시 상수, 디스크립터 세트 등을 바인딩하고 설정하기 위해 복잡한 API를 사용한다. 하지만 현대 GPU 드라이버의 본질적인 동작은 GPU 메모리에 하나의 구조체를 구성하고, 그 포인터를 커맨드 프로세서에 전달하는 것에 가깝다. 우리는 이러한 API 복잡성이 불필요하다는 점을 보였다. 사용자는 루트 구조체를 영구 매핑된 GPU 메모리에 직접 작성하고, 64비트 GPU 포인터를 드로우/디스패치 함수에 그대로 전달하면 된다. 또한 구조체 내부에 64비트 포인터와 32비트 텍스처 힙 인덱스를 포함해 원하는 간접 데이터 레이아웃을 자유롭게 구성할 수 있다. 루트 바인딩 API와 DirectX 12의 복잡한 버퍼 체계는 64비트 포인터로 효율적으로 대체할 수 있다. 이는 셰이더 파이프라인 생성을 획기적으로 단순화하며, 데이터 레이아웃을 별도로 정의할 필요도 없다. 거대한 API 복잡성을 제거하면서 사용자에게 더 많은 유연성을 제공하는 셈이다.

Static constants

Vulkan, Metal, WebGPU에는 셰이더 파이프라인 생성 시 고정되는 정적(특수화, specialization) 상수 개념이 있다. 드라이버의 내부 셰이더 컴파일러는 이 상수를 입력 셰이더 IR에 리터럴로 적용하고, 이후 상수 전파 및 데드 코드 제거를 수행한다. 이를 통해 파이프라인 생성 시 동일한 셰이더의 여러 변형을 만들 수 있으며, 모든 셰이더 조합을 오프라인에서 컴파일하는 데 필요한 시간과 저장 공간을 줄일 수 있다.

Vulkan과 Metal은 특수화 상수와 그 값을 기술하기 위한 별도의 API와 전용 셰이더 문법을 제공한다. 하지만 셰이더 측에서 정의한 상수 구조체와 동일한 C 구조체를 그대로 전달하는 방식이 더 간단하고 바람직하다. 이는 API 표면을 최소화하면서도 중요한 개선을 제공할 수 있다.

Vulkan의 특수화 상수에는 설계상의 한계가 있다. 특수화 상수는 디스크립터 세트 레이아웃을 변경할 수 없다. 입력과 출력 데이터 레이아웃이 고정된다. 사용자는 모든 가능한 입력/출력을 포함하는 ‘우버 레이아웃’을 정의하고 사용하지 않는 디스크립터를 갱신하지 않는 방식으로 우회할 수 있지만, 이는 번거롭고 비효율적이다. 우리가 제안하는 설계에는 이러한 문제가 없다. 상수에 따라 분기하면(반대편 경로는 데드 코드 제거됨) 셰이더 입력 포인터를 다른 구조체로 재해석할 수 있다. C++ 상속 레이아웃을 모방할 수도 있다. 입력 구조체의 앞부분은 공통 레이아웃으로 두고, 특수화된 데이터는 뒤에 배치하는 방식이다. 이를 통해 정적 다형성(static polymorphism)을 깔끔하게 구현할 수 있다. 런타임 성능은 수작업으로 최적화한 셰이더와 동일하다. 특수화 구조체에는 GPU 포인터도 포함할 수 있어, 런타임 메모리 위치를 상수처럼 하드코딩할 수 있다. 이는 간접 참조를 피하게 해주며, 기존 셰이더 언어에서는 불가능했던 방식이다. 과거에는 GPU 벤더가 런타임에 셰이더를 분석해 유사한 교체 최적화를 수행하기 위해 백그라운드 스레드를 사용해야 했고, 이는 CPU 비용과 드라이버 복잡성을 크게 증가시켰다.

// Common header...
struct alignas(16) Constants
{
    int32 qualityLevel;
    uint8* blueNoiseLUT;
};

// CPU code...
Constants constants { .qualityLevel = 2, blueNoiseLUT = blueNoiseLUT.gpu };

auto shaderIR = loadFile("computeShader.ir");
GpuPipeline computePipeline = gpuCreateComputePipeline(shaderIR, &constants);

// GPU kernel...
[groupsize = (8, 8, 1)]
void main(uint32x3 threadId : SV_ThreadID, const Data* data, const Constants constants)
{
    if (constants.qualityLevel == 3)
    {
        // Dead code eliminated
    }
}

셰이더 퍼뮤테이션 지옥은 현대 그래픽스에서 가장 큰 문제 중 하나다. 게이머는 끊김(stutter)을 호소하고, 개발자는 오프라인 셰이더 컴파일에 몇 시간이 걸린다고 불평한다. 이 새로운 설계는 사용자에게 더 큰 유연성을 제공한다. 셰이더 내부에서 정적 동작과 동적 동작을 전환할 수 있어, 범용(fallback) 경로와 필요 시 특수화를 쉽게 함께 구현할 수 있다. 이는 셰이더 퍼뮤테이션 수를 줄이고, 파이프라인 생성으로 인한 런타임 정지를 감소시킨다.

Barriers and fences

현대 그래픽스 API에서 가장 미움받는 기능은 아마도 배리어일 것이다. 배리어는 두 가지 목적을 가진다 : 생산자→소비자 실행 의존성을 보장하는 그리고 텍스처를 서로 다른 레이아웃 간에 전환하는 것.

많은 그래픽스 프로그래머는 GPU 동기화에 대해 잘못된 정신 모델을 가지고 있다. 흔히 GPU 동기화가 개별 텍스처와 버퍼 단위의 세밀한 의존성 추적으로 이루어진다고 믿지만, 실제로 현대 GPU 하드웨어는 개별 리소스 자체에는 크게 관심이 없다. 우리는 사용자 공간에서 각 리소스의 상태와 레이아웃 변화를 정리하느라 많은 CPU 시간을 쓰지만, 현대 GPU 드라이버는 사실상 그 목록을 대부분 무시한다. 추상화와 실제 하드웨어 동작이 일치하지 않는다.

현대의 바인드리스 아키텍처는 GPU에 많은 자유를 준다. 셰이더는 전역 디스크립터 힙의 어떤 텍스처든, 어떤 64비트 포인터든 쓸 수 있다. CPU는 GPU가 어떤 결정을 내릴지 알 수 없다. 그렇다면 CPU는 어떻게 각 리소스에 대해 전환 배리어를 발행할 수 있을까? 이는 바인드리스 아키텍처와 전통적인 CPU 주도 렌더링 API 사이의 명백한 불일치다. 왜 10년 전 API가 이렇게 설계되었는지 살펴보자.

AMD의 GCN 아키텍처는 현대 그래픽 API 설계에 큰 영향을 미쳤다. GCN은 비동기 컴퓨트와 바인드리스 텍스처링(스칼라 레지스터에 디스크립터 저장)에서 시대를 앞서갔지만, 델타 컬러 압축(DCC)과 캐시 설계에는 중요한 제약이 있었다. 이 제약은 오늘날 배리어 모델이 복잡해진 이유를 잘 보여준다. GCN은 일관성 있는 마지막 레벨 캐시가 없었다. ROP(래스터 연산, 즉 픽셀 셰이더 출력)는 VRAM에 직접 연결된 특수 비일관성 캐시를 가지고 있었다. 픽셀 셰이더 출력이 다른 셰이더나 샘플러에서 보이도록 하려면, 드라이버는 먼저 ROP 캐시를 메모리에 플러시하고, 그다음 L2 캐시를 무효화해야 했다. 커맨드 프로세서 또한 L2 캐시의 클라이언트가 아니었다. 컴퓨트 셰이더에서 작성한 간접 인자는 L2 캐시를 전체 무효화하고 더티 라인을 VRAM으로 플러시하지 않으면 커맨드 프로세서에 보이지 않았다. GCN 3는 ROP용 델타 컬러 압축(DCC)을 도입했지만, AMD의 텍스처 샘플러는 DCC 압축 텍스처나 압축 깊이 버퍼를 직접 읽을 수 없었다. 드라이버는 내부적으로 디컴프레스 컴퓨트 셰이더를 실행해 압축을 제거해야 했다. 디스플레이 엔진도 DCC 압축 텍스처를 직접 읽을 수 없었다. 렌더 타깃을 샘플링하는 일반적인 경우에는 두 번의 내부 배리어와 모든 캐시 플러시가 필요했다(ROP 완료 대기 → ROP 캐시 및 L2 플러시 → 디컴프레스 컴퓨트 실행 → 컴퓨트 완료 대기).

AMD의 최신 RDNA 아키텍처는 여러 중요한 개선을 이뤘다. 모든 메모리 연산을 포괄하는 일관성 있는 L2 캐시를 갖추고 있으며, ROP와 커맨드 프로세서도 L2의 클라이언트다. 비일관성 캐시는 컴퓨트 유닛 내부의 작은 L0 캐시와 스칼라 캐시(K$)뿐이다. 이제 배리어는 작은 캐시의 미완료 쓰기를 상위 캐시로 플러시하는 것만으로 충분하다. 드라이버가 L2 캐시를 VRAM으로 플러시할 필요가 없어 배리어가 훨씬 빨라졌다. RDNA의 개선된 디스플레이 엔진은 DCC 압축 텍스처를 직접 읽을 수 있고, L2와 L0 텍스처 캐시 사이에는 (디)컴프레서가 위치한다. 텍스처를 샘플링하기 전에 VRAM에 디컴프레스할 필요가 없어져, 압축/비압축 레이아웃 전환이 필요 없다. 오늘날 데스크톱과 모바일 GPU 벤더들은 비슷한 결론에 도달했다. 병목은 대역폭이다. 리소스를 VRAM에 디코딩하는 데 대역폭을 낭비해서는 안 된다. 레이아웃 전환은 더 이상 필요하지 않다.

AMD RDNA (2019) : RDNA 아키텍처에서는 캐시 계층, DCC, 디스플레이 엔진이 크게 개선되었다. L2 캐시는 DCC 압축 데이터를 저장하며, (디)컴프레서는 L2와 하위 레벨 캐시 사이에 위치한다. L0(텍스처 캐시)는 압축이 해제된 데이터를 사용한다. (이미지 © AMD)

리소스 목록은 DirectX 12와 Vulkan에서 배리어의 가장 성가신 측면이다. 사용자는 각 리소스의 상태를 개별적으로 추적하고, 각 배리어에 대해 이전 상태와 다음 상태를 그래픽스 API에 알려야 한다. 이는 10년 전 GPU에서는 필요했다. 벤더들이 다양한 디컴프레스 명령을 배리어 API 아래에 숨겨두었기 때문이다. 배리어 명령은 디컴프레스 명령의 역할을 했기 때문에, 어떤 리소스가 디컴프레스가 필요한지 알아야 했다. 오늘날 하드웨어는 텍스처 레이아웃이나 디컴프레스 단계를 필요로 하지 않는다. Vulkan은 최근 VK_KHR_unified_image_layouts 확장(https://www.khronos.org/blog/so-long-image-layouts-simplifying-vulkan-synchronisation) (2025)을 도입해 배리어 명령에서 이미지 레이아웃 전환을 제거했다. 그러나 여전히 사용자가 개별 텍스처와 버퍼를 나열하도록 요구한다. 왜 그럴까?

주된 이유는 레거시 API 및 툴링과의 호환성이다. 사람들은 리소스 의존성에 대해 생각하는 방식에 익숙하며, 기존 Vulkan 및 DirectX 12 검증 레이어도 그 방식으로 설계되어 있다. 그러나 GPU가 실행하는 배리어 명령에는 텍스처나 버퍼에 대한 정보가 전혀 없다. 리소스 목록은 오직 드라이버에서만 소비된다.

현대 드라이버는 사용자의 리소스 목록을 순회하며 플래그 집합을 채운다. 드라이버는 더 이상 리소스 레이아웃이나 마지막 레벨 캐시 일관성을 걱정할 필요는 없지만, 여전히 특정 경우에 플러시해야 하는 작은 비일관성 캐시가 존재한다. 현대 GPU는 대부분의 비일관성 캐시를 모든 배리어에서 자동으로 플러시한다. 예를 들어 AMD의 L0$와 K$(스칼라 캐시)는 항상 플러시된다. 모든 패스가 어떤 출력을 쓰며, 이 출력은 이러한 캐시에 존재하기 때문이다. 모든 쓰기 주소를 세밀하게 추적하는 것은 비용이 너무 크다. 작은 비일관성 캐시는 대개 포함(inclusive) 구조다. 수정된 라인은 상위 캐시 레벨로 플러시된다. 이는 빠르며 VRAM 트래픽을 발생시키지 않는다. 일부 아키텍처에는 자동으로 플러시되지 않는 특수 캐시가 있다. 예: 텍스처 샘플러의 디스크립터 캐시(위 장 참고), 래스터라이저 ROP 캐시 및 HiZ 캐시. 커맨드 프로세서는 웨이브 생성 지연을 줄이기 위해 일반적으로 앞서 실행된다. 셰이더에서 간접 인자를 썼다면, 레이스를 피하기 위해 커맨드 프로세서 프리패처를 멈추도록 GPU에 알려야 한다. GPU는 실제로 컴퓨트 셰이더가 간접 인자 버퍼에 썼는지 알지 못한다. DirectX 12에서는 해당 버퍼를 D3D12_RESOURCE_STATE_INDIRECT_ARGUMENT로 전환하고, Vulkan에서는 소비자 의존성에 VK_PIPELINE_STAGE_DRAW_INDIRECT_BIT라는 특별한 단계를 사용한다. 이러한 리소스 전환이나 단계 의존성이 있는 배리어의 경우, 드라이버는 배리어에 커맨드 프로세서 프리패처 정지 플래그를 포함한다.

현대적인 배리어 설계는 리소스 목록을, 이러한 특수 비일관성 캐시에 어떤 일이 일어나는지를 설명하는 단일 비트필드로 대체한다. 특수한 경우에는 다음이 포함된다: 텍스처 디스크립터 무효화, 드로우 인자 무효화, 깊이 캐시 무효화. 이러한 플래그는 드로우 인자를 생성하거나, 디스크립터 힙에 쓰거나, 컴퓨트 셰이더로 깊이 버퍼에 쓸 때 필요하다. 대부분의 배리어는 특별한 캐시 무효화 플래그가 필요하지 않다.

일부 GPU는 여전히 특수한 경우에 데이터를 디컴프레스해야 한다. 예를 들어 복사 또는 클리어 명령 중에(클리어 색상이 변경된 경우 fast clear eliminate). 복사 및 클리어 명령은 영향을 받는 리소스를 매개변수로 받는다. 필요하다면 드라이버가 데이터를 디코딩하는 데 필요한 조치를 취할 수 있다. 이러한 특수 경우를 위해 배리어에 리소스 목록이 필요하지 않다. 모든 포맷과 사용 플래그가 압축을 지원하는 것은 아니다. 이러한 경우 드라이버는 데이터를 압축되지 않은 상태로 유지하며, 대역폭을 낭비하면서 앞뒤로 전환하지 않는다.

표준 UAV 배리어(컴퓨트 → 컴퓨트)는 단순하다.

gpuBarrier(commandBuffer, STAGE_COMPUTE, STAGE_COMPUTE);

텍스처 디스크립터 힙에 쓰기를 하는 경우(드문 경우), 특별한 플래그를 추가해야 한다.

gpuBarrier(commandBuffer, STAGE_COMPUTE, STAGE_COMPUTE, HAZARD_DESCRIPTORS);

래스터라이저 출력과 픽셀 셰이더 사이의 배리어는 오프스크린 렌더 타깃 → 샘플링에서 흔한 경우다. 우리의 예제는 배리어가 버텍스 셰이더를 막지 않도록 의존 단계가 설정되어 있어, 이전 패스와 버텍스 셰이딩(모바일 GPU에서는 타일 비닝)이 겹쳐 실행될 수 있다. 래스터 출력 단계(또는 그 이후)를 프로듀서로 하는 배리어는 GPU 아키텍처가 필요로 하는 경우 비일관성 ROP 캐시를 자동으로 플러시한다. 이에 대해 별도의 명시적 플래그는 필요하지 않다.

gpuBarrier(commandBuffer, STAGE_RASTER_COLOR_OUT | STAGE_RASTER_DEPTH_OUT, STAGE_PIXEL_SHADER);

사용자는 큐 실행 의존성만 기술한다: 프로듀서 및 컨슈머 단계 마스크. 개별 텍스처와 버퍼 리소스 상태를 추적할 필요가 없어, 현재 DirectX 12 및 Vulkan 설계 대비 많은 복잡성을 제거하고 상당한 CPU 시간을 절약할 수 있다. Metal 2는 이미 현대적인 배리어 설계를 갖고 있으며, 리소스 목록을 사용하지 않는다.

많은 GPU는 커스텀 스크래치패드 메모리를 갖고 있다: 각 컴퓨트 유닛 내부의 그룹 공유 메모리, 타일 메모리, Qualcomm GMEM과 같은 대형 공유 스크래치패드 등이 있다. 이러한 메모리는 드라이버가 자동으로 관리한다. 그룹 공유 메모리와 같은 임시 스크래치패드는 절대 메모리에 저장되지 않는다. 타일 메모리는 타일 래스터라이저에 의해 자동으로 저장된다(store op == store). 유니폼 레지스터는 읽기 전용이며 각 드로우 호출 전에 미리 채워진다. 스크래치패드와 유니폼 레지스터는 캐시 일관성 프로토콜을 갖지 않으며, 배리어와 직접적으로 상호작용하지 않는다.

현대 GPU는 특정 셰이더 단계가 끝났을 때 메모리에 값을 쓰는 동기화 명령과, 특정 메모리 위치에 값이 나타날 때까지 다음 셰이더 단계가 시작되지 않도록 기다리는 명령(대기에는 선택적 캐시 플러시 의미론 포함)을 지원한다. 이는 배리어를 두 개로 나눈 것과 같다: 프로듀서와 컨슈머. DirectX 12의 스플릿 배리어와 Vulkan의 event→wait가 이러한 설계의 예다. 배리어를 컨슈머→프로듀서로 분리하면, 그 사이에 독립적인 작업을 배치해 GPU를 비우지 않고도 실행할 수 있다.

Vulkan의 event→wait(DX12 스플릿 배리어 포함)는 거의 사용되지 않는다. 주된 이유는 일반 배리어 자체가 이미 매우 복잡해 개발자들이 추가 복잡성을 피하려 하기 때문이다. 과거에는 스플릿 배리어에 대한 드라이버 지원도 완벽하지 않았다. 리소스 목록을 제거하면 스플릿 배리어는 훨씬 단순해진다. 또한 스플릿 배리어를 타임라인 세마포어와 유사한 의미론으로 만들 수 있다: signal 명령은 단조 증가하는 64비트 값(atomic max)을 메모리에 쓰고, wait 명령은 해당 값이 N 이상(>=)이 될 때까지 기다린다. 이 카운터는 단순한 GPU 메모리 포인터일 뿐, 별도의 영구 API 객체가 필요하지 않다. 이는 훨씬 단순한 event→wait API를 제공한다.

gpuSignalAfter(commandBuffer, STAGE_RASTER_COLOR_OUT, gpuPtr, counter, SIGNAL_ATOMIC_MAX);
// Put independent work here
gpuWaitBefore(commandBuffer, STAGE_PIXEL_SHADER, gpuPtr, counter++, OP_GREATER_EQUAL);

이 API는 기존 VkEvent API보다 훨씬 단순하면서도 더 높은 유연성을 제공한다. 위 예제에서는 타임라인 세마포어 의미론을 구현했지만, 다른 패턴도 구현할 수 있다. 예를 들어 비트마스크를 사용해 여러 프로듀서를 기다리는 방식이다: SIGNAL_ATOMIC_OR로 비트를 설정하고, 특정 마스크의 모든 비트가 설정될 때까지 기다린다(마스크는 gpuWaitBefore 명령의 선택적 매개변수다).

독립적인 작업을 프로듀서→컨슈머 사이에 배치하는 연쇄적인 signal→wait는 GPU 정지를 방지한다. 이미지 © Timothy Lottes.

GPU→CPU 동기화는 초기 Vulkan과 Metal에서 다소 혼란스러웠다. 사용자는 제출마다 별도의 펜스 객체를 생성해야 했다. 객체를 재사용하기 위해 N 버퍼링이 일반적인 기법이었다. 이는 위에서 언급한 VkEvent와 유사한 사용성 문제다. DirectX 12는 타임라인 세마포어를 통해 GPU→CPU 동기화를 깔끔하게 해결한 최초의 API였다. 이후 Vulkan 1.2와 Metal 2도 동일한 설계를 채택했다. 타임라인 세마포어는 단 하나의 64비트 단조 증가 카운터만 필요하다. 이는 많은 엔진이 오늘날까지 사용 중인 이전 Vulkan 및 Metal 펜스 API보다 복잡성을 크게 줄여준다.

#define FRAMES_IN_FLIGHT 2

GpuSemaphore frameSemaphore = gpuCreateSemaphore(0);
uint64 nextFrame = 1;

while (running)
{
    if (nextFrame > FRAMES_IN_FLIGHT)
    {
        gpuWaitSemaphore(frameSemaphore, nextFrame - FRAMES_IN_FLIGHT);
    }

    // Render the frame here

    gpuSubmit(queue, {commandBuffer}, frameSemaphore, nextFrame++);
}

gpuDestroySemaphore(frameSemaphore);

우리가 제안하는 배리어 설계는 DirectX 12와 Vulkan에 비해 큰 개선이다. API 복잡성을 크게 줄인다. 사용자는 더 이상 개별 리소스를 추적할 필요가 없다. 우리의 단순한 해저드 추적은 큐 + 단계(stage) 단위의 세밀도를 가진다. 이는 오늘날 GPU 하드웨어가 실제로 동작하는 방식과 일치한다. 게임 엔진의 그래픽스 백엔드는 단순해질 수 있고, CPU 사이클도 절약된다.

Command buffers

Vulkan과 DirectX 12는 리소스를 사전 생성하고 재사용하도록 장려하는 방식으로 설계되었다. 초기 Vulkan 예제들은 시작 시 하나의 커맨드 버퍼를 기록하고, 이를 매 프레임 재생했다. 그러나 개발자들은 곧 커맨드 버퍼 재사용이 비현실적이라는 것을 깨달았다. 실제 게임 환경은 동적이며 카메라는 끊임없이 움직인다. 가시 객체 집합(visible object set)도 자주 변경된다.

게임 엔진들은 사전 기록된 커맨드 버퍼를 사실상 무시했다. Metal과 WebGPU는 일시적(transient) 커맨드 버퍼를 제공한다. 이들은 기록 직전에 생성되고, GPU가 렌더링을 마치면 사라진다. 이는 커맨드 버퍼 관리의 필요성을 제거하고, 동일한 명령을 여러 번 제출하는 것을 방지한다. Vulkan에서도 GPU 벤더들은 원샷(one-shot) 커맨드 버퍼(프레임별 리셋 가능한 커맨드 풀)를 권장한다. 이는 드라이버 내부 메모리 관리(힙 할당자 대신 범프 할당자 사용)를 단순화하기 때문이다. 이러한 모범 사례는 Metal과 WebGPU의 설계와 일치한다. 영속적인 커맨드 버퍼 객체는 제거해도 된다. 그 API 복잡성은 실질적으로 가치 있는 기능을 제공하지 못했다.

while (running)
`
GpuCommandBuffer commandBuffer = gpuStartCommandRecording(queue);
// Render frame here
}

Graphics shaders

가장 뜨거운 질문부터 시작해보자 : 이제 그래픽스 셰이더가 정말로 필요한가? UE5의 Nanite는 64비트 원자 연산을 사용해 픽셀을 찍는 컴퓨트 셰이더를 사용한다. 상위 비트에는 픽셀 깊이를, 하위 비트에는 페이로드를 담는다. atomic-min은 가장 가까운 표면이 남도록 보장한다. 이 기법은 2015년 SIGGRAPH에서 Media Molecule Dreams(Alex Evans)에 의해 처음 발표되었다. 하드웨어 래스터라이저는 여전히 계층적/조기 깊이-스텐실 테스트와 같은 장점을 갖는다. Nanite는 오직 거친 클러스터 컬링에만 의존해야 하며, 그 결과 키트배시된 콘텐츠에서는 추가적인 오버드로우가 발생한다. Ubisoft(필자와 Ulrich Haar)는 2015년 SIGGRAPH에서 이 2패스 클러스터 컬링 알고리즘을 발표했다. Ubisoft는 클러스터 컬링을 하드웨어 래스터라이저와 결합해 더 세밀한 컬링을 구현했다. 오늘날 GPU는 바인드리스이며, 이러한 GPU 주도 워크로드에 훨씬 더 적합하다. 10년 전 Ubisoft는 바인드리스 텍스처링 대신 가상 텍스처링(모든 텍스처를 하나의 아틀라스에 배치)에 의존해야 했다. 오늘날 Nanite, SDF 구면 추적, DDA 보셀 트레이싱 등 많은 컴퓨트 전용 래스터라이저가 존재하지만, 하드웨어 래스터라이저는 여전히 게임에서 삼각형을 렌더링하는 가장 일반적인 기법이다. 따라서 래스터라이제이션 파이프라인을 더 유연하고 사용하기 쉽게 만드는 방법을 논의할 가치가 충분하다.

현대 셰이더 프레임워크는 16개의 셰이더 엔트리 포인트로 확장되었다. 래스터라이제이션용 8개(픽셀, 버텍스, 지오메트리, 헐, 도메인, 패치 상수, 메시, 앰플리피케이션)와 레이 트레이싱용 6개(레이 생성, 미스, 최근접 히트, 애니 히트, 교차, 호출 가능)가 있다. 이에 비해 CUDA는 단 하나의 엔트리 포인트만 가진다: 커널. 이 구조 덕분에 CUDA는 조합 가능하다. CUDA는 건강한 서드파티 라이브러리 생태계를 갖고 있다. 텐서 코어(AI)와 같은 새로운 GPU 하드웨어 블록은 내장 함수(intrinsic)로 노출된다. 그래픽스에서도 처음에는 이런 방식이었다. 텍스처 샘플링이 첫 번째 내장 함수였다. 오늘날 텍스처 샘플링은 완전한 바인드리스이며 드라이버 설정조차 필요 없다. 이것이 개발자들이 선호하는 설계다. 단순하고, 조합 가능하며, 확장 가능하다.

최근 우리는 더 많은 내장 함수를 얻었다: 인라인 레이 트레이싱과 코어퍼레이티브 매트릭스(DirectX 12의 wave matrix, Metal의 subgroup matrix). 이것이 새로운 방향이 되기를 바란다. 거대한 16개 셰이더 프레임워크를 해체하고, 유연하게 조합 가능한 내장 함수로 대체해야 한다.

셰이더 프레임워크의 복잡성을 해결하는 것은 매우 방대한 주제다. 이 글의 범위를 유지하기 위해, 오늘은 컴퓨트 셰이더와 래스터 파이프라인만 다루겠다. 다음 글에서는 레이 트레이싱, 셰이더 실행 재정렬(SER), 동적 레지스터 할당 확장, 그리고 Apple의 새로운 L1 캐시 기반 레지스터 파일(다이내믹 캐싱)과 같은 현대적 주제를 포함해 셰이더 프레임워크 단순화에 대해 다룰 예정이다.

Raster pipelines

오늘날 관련 있는 래스터 파이프라인은 두 가지다: 버텍스+픽셀과 메시+픽셀이다. 타일 기반 지연 렌더링(TBDR)을 사용하는 모바일 GPU는 삼각형 단위로 타일 비닝을 수행한다. 타일 크기는 일반적으로 16x16에서 64x64 픽셀 사이이며, 이 때문에 메슐릿(meshlet)은 비닝에 사용하기에는 너무 거친 단위의 프리미티브다. 메슐릿은 레인과 버텍스 간에 명확한 1:1 매핑이 없으며, 선택된 삼각형만을 대상으로 부분적인 메시 셰이더 웨이브를 실행할 간단한 방법도 없다. 이것이 모바일 GPU 벤더들이 Nvidia와 AMD가 설계한 데스크톱 중심 메시 셰이더 API를 적극적으로 채택하지 않은 주요 이유다. 모바일에서는 여전히 버텍스 셰이더가 중요하다.

지오메트리, 헐, 도메인, 패치 상수(테셀레이션) 셰이더는 여기서 다루지 않는다. 그래픽스 커뮤니티는 이들 셰이더 타입을 대체로 실패한 실험으로 본다. 설계상 치명적인 성능 문제가 있다. 관련된 모든 사용 사례에서, 인덱스 버퍼를 생성하는 컴퓨트 프리패스를 실행하는 것이 이들 단계를 능가할 수 있다. 또한 메시 셰이더는 온칩 메모리에 압축된 8비트 인덱스 버퍼를 생성할 수 있어, 이러한 레거시 셰이더 단계와의 성능 격차를 더욱 벌린다.

우리의 목표는 베이크된 상태를 최소화한 현대적인 PSO 추상화를 구축하는 것이다. Vulkan과 DirectX 12에 대한 주요 비판 중 하나는 파이프라인 퍼뮤테이션 폭증이다. PSO 내부의 상태가 적을수록 파이프라인 퍼뮤테이션도 줄어든다. 개선해야 할 주요 영역은 두 가지다: 그래픽스 셰이더 데이터 바인딩과 래스터라이저 상태다.

Graphics shader bindings

버텍스+픽셀 셰이더 파이프라인은 컴퓨트 커널에 비해 몇 가지 추가 입력이 필요하다: 버텍스 버퍼, 인덱스 버퍼, 래스터라이저 상태, 렌더 타깃 뷰, 깊이-스텐실 뷰다. 먼저 셰이더에서 보이는 데이터 바인딩에 대해 논의해보자.

버텍스 버퍼 바인딩은 쉽게 해결할 수 있다: 그냥 제거하면 된다. 현대 GPU는 빠른 raw 로드 경로를 갖고 있다. 대부분의 GPU 벤더는 이미 여러 세대에 걸쳐 버텍스 페치 하드웨어를 에뮬레이션해왔다. 그들의 저수준 셰이더 컴파일러는 사용자 정의 버텍스 레이아웃을 읽고, 버텍스 셰이더 시작 부분에 적절한 raw 로드 명령을 생성한다.

버텍스 바인딩 선언은 구조체 메모리 레이아웃을 정의하기 위한 또 하나의 특수한 C/C++ 스타일 API의 예다. 이는 복잡성을 증가시키고, 서로 다른 레이아웃에 대해 여러 PSO 퍼뮤테이션을 컴파일하도록 강제한다. 우리는 버텍스 버퍼를 표준 C/C++ 구조체로 단순히 대체한다. 별도의 API는 필요 없다.

// Common header...
struct Vertex
{
    float32x4 position;
    uint8x4 normal;
    uint8x4 tangent;
    uint16x2 uv;
};

struct alignas(16) Data
{
    float32x4x4 matrixMVP;
    const Vertex *vertices;
};

// CPU code...
gpuSetPipeline(commandBuffer, graphicsPipeline);

auto data = myBumpAllocator.allocate<Data>();
data.cpu->matrixMVP = camera.viewProjection * modelMatrix;
data.cpu->vertices = mesh.vertices;

gpuDrawIndexed(commandBuffer, data.gpu, mesh.indices, mesh.indexCount);

// Vertex shader...
struct VertexOut
{
    float32x4 position : SV_Position;
    float16x4 normal;
    float32x2 uv;
};

VertexOut main(uint32 vertexIndex : SV_VertexID, const Data* data)
{
    Vertex vertex = data->vertices[vertexIndex];
    float32x4 position = data->matrixMVP * vertex.position;
    // TODO: Normal transform here
    return { .position = position, .normal = normal, .uv = vertex.uv };
}

인스턴스별(per-instance) 데이터와 다중 버텍스 스트림도 마찬가지다. 이 역시 raw 메모리 로드로 효율적으로 구현할 수 있다. raw 로드 명령을 사용하면 버텍스 스트라이드를 동적으로 조정하고, 보조 버텍스 버퍼 로드를 조건 분기로 건너뛰며, 클러스터 기반 GPU 드리븐 렌더링, 파티클 쿼드 확장, 고차 곡면, 효율적인 지형 렌더링 등 다양한 알고리즘을 구현하기 위해 커스텀 공식으로 버텍스 인덱스를 계산할 수 있다. 추가적인 셰이더 엔트리 포인트나 바인딩 API는 필요 없다. 새로운 정적 상수 시스템을 사용해 파이프라인 생성 시 사용하지 않는 버텍스 스트림을 데드 코드 제거할 수 있고, 원한다면 정적 버텍스 스트라이드를 제공할 수도 있다. 기존의 모든 최적화 전략은 그대로 유지되지만, 이제는 렌더러의 요구에 맞게 기법들을 자유롭게 조합할 수 있다.

// Common header...
struct VertexPosition
{
    float32x4 position;
};

struct VertexAttributes
{
    uint8x4 normal;
    uint8x4 tangent;
    uint16x2 uv;
};

struct alignas(16) Instance
{
    float32x4x4 matrixModel;
}

struct alignas(16) Data
{
    float32x4x4 matrixViewProjection;
    const VertexPosition *vertexPositions;
    const VertexAttributes *vertexAttribues;
    const Instance *instances;
};

// CPU code...
gpuSetPipeline(commandBuffer, graphicsPipeline);

auto data = myBumpAllocator.allocate<Data>();
data.cpu->matrixViewProjection = camera.viewProjection;
data.cpu->vertexPositions = mesh.positions;
data.cpu->vertexAttributes = mesh.attributes;
data.cpu->instances = batcher.instancePool + instanceOffset; // pointer arithmetic is convenient

gpuDrawIndexedInstanced(commandBuffer, data.gpu, mesh.indices, mesh.indexCount, instanceCount);

// Vertex shader...
struct VertexOut
{
    float32x4 position : SV_Position; // SV values are not real struct fields (doesn't affect the layout)
    float16x4 normal;
    float32x2 uv;
};

VertexOut main(uint32 vertexIndex : SV_VertexID, uint32 instanceIndex : SV_InstanceID, const Data* data)
{
    Instance instance = data->instances[SV_InstanceIndex];

    // NOTE: Splitting positions/attributes benefits TBDR GPUs (vertex shader is split in two parts)
    VertexPosition vertexPosition = data->vertexPositions[SV_VertexIndex];
    VertexAttributes vertexAttributes = data->vertexAttributes[SV_VertexIndex];

    float32x4x4 matrix = data->matrixViewProjection * instance.matrixModel;
    float32x4 position = matrix * vertexPosition.position;

    // TODO: Normal transform here

    return { .position = position, .normal = normal, .uv = vertexAttributes.uv };
}

인덱스 버퍼 바인딩은 여전히 특별한 경우다. GPU에는 인덱스 중복 제거 하드웨어가 있다. 동일한 버텍스에 대해 버텍스 셰이더를 두 번 실행하고 싶지는 않다. 인덱스 중복 제거 하드웨어는 버텍스 웨이브를 재구성해 중복 버텍스를 제거한다. 인덱스 버퍼링은 오늘날에도 여전히 중요한 최적화다. 비인덱스 지오메트리는 삼각형당 3번의 버텍스 셰이더 호출(레인)을 실행한다. 완벽한 그리드는 셀당 두 개의 삼각형을 가지므로, (마지막 행/열을 제외하면) 두 개의 삼각형당 한 번의 버텍스 셰이더 호출만 필요하다. 최신 오프라인 버텍스 캐시 최적화 도구는 삼각형당 약 0.7 버텍스 효율의 메시를 출력한다. 실제 환경에서는 인덱스 버퍼를 통해 버텍스 셰이딩 비용을 약 4~6배 줄일 수 있다.

오늘날 인덱스 버퍼 하드웨어는 다른 GPU 유닛과 동일한 캐시 계층에 연결되어 있다. 인덱스 버퍼는 단순히 drawIndexed 호출에 전달되는 추가 GPU 포인터일 뿐이다. 인덱스 버퍼링에 필요한 API 표면은 이것이 전부다.

메시 셰이더는 오프라인 버텍스 중복 제거에 의존한다. 일반적인 구현은 레인당 하나의 버텍스를 셰이딩하고 이를 온칩 메모리에 출력한다. 8비트 로컬 인덱스 버퍼는 각 삼각형이 어떤 3개의 버텍스를 사용하는지 래스터라이저에 알려준다. 모든 메슐릿 출력은 한 번에 उपलब्ध하고 이미 온칩 저장소에서 변환된 상태이므로, 삼각형 설정 이후에 버텍스를 중복 제거하거나 패킹할 필요가 없다. 이것이 메시 셰이더가 인덱스 중복 제거 하드웨어나 포스트 트랜스폼 캐시를 필요로 하지 않는 이유다. 모든 메시 셰이더 입력은 raw 데이터다. gpuDrawMeshlets 명령 외에는 추가 API 표면이 필요 없다.

내 예제 메시 셰이더는 128레인 스레드 그룹을 사용한다. Nvidia는 출력 메슐릿당 최대 126개 버텍스와 64개 삼각형을 지원한다. AMD는 256개 버텍스와 128개 삼각형을 지원한다. 셰이더는 초과 레인을 마스킹한다. 삼각형 수가 64개를 넘지 않으므로, 최적의 삼각형 레인 활용을 위해 64레인 스레드 그룹을 선택하고 버텍스 셰이딩을 두 번 반복하는 루프를 사용할 수도 있다. 내 삼각형 페치 로직은 단일 메모리 로드 명령이므로, 그 단계에서 절반의 레인을 낭비하는 것은 큰 문제가 아니다. 대신 버텍스 셰이딩에서 추가적인 병렬성을 선택했다. 최적의 선택은 워크로드와 대상 하드웨어에 따라 달라진다.

// Common header...
struct Vertex
{
    float32x4 position;
    uint8x4 normal;
    uint8x4 tangent;
    uint16x2 uv;
};

struct alignas(16) Meshlet
{
    uint32 vertexOffset;
    uint32 triangleOffset;
    uint32 vertexCount;
    uint32 triangleCount;
};

struct alignas(16) Data
{
    float32x4x4 matrixMVP;
    const Meshlet *meshlets;
    const Vertex *vertices;
    const uint8x4 *triangles;
};

// CPU code...
gpuSetPipeline(commandBuffer, graphicsMeshPipeline);

auto data = myBumpAllocator.allocate<Data>();
data.cpu->matrixMVP = camera.viewProjection * modelMatrix;
data.cpu->meshlets = mesh.meshlets;
data.cpu->vertices = mesh.vertices;
data.cpu->triangles = mesh.triangles;

gpuDrawMeshlets(commandBuffer, data.gpu, uvec3(mesh.meshletCount, 1, 1));

// Mesh shader...
struct VertexOut
{
    float32x4 position : SV_Position;
    float16x4 normal;
    float32x2 uv;
};

[groupsize = (128, 1, 1)]
void main(uint32x3 groupThreadId : SV_GroupThreadID, uint32x3 groupId : SV_GroupID, const Data* data)
{
    Meshlet meshlet = data->meshlets[groupId.x];

    // Meshlet output allocation intrinsics
    VertexOut* outVertices = allocateMeshVertices<VertexOut>(meshlet.vertexCount);
    uint8x3* outIndices = allocateMeshIndices(meshlet.triangleCount);

    // Triangle indices (3x 8 bit)
    if (groupThreadId.x < meshlet.triangleCount)
    {
        outIndices[groupThreadId.x] = triangles[meshlet.triangleOffset + groupThreadId.x].xyz;
    }

    // Vertices
    if (groupThreadId.x < meshlet.vertexCount)
    {
        Vertex vertex = data->vertices[meshlet.vertexOffset + groupThreadId.x];
        float32x4 position = data->matrixMVP * vertex.position;
        // TODO: Normal transform here
        outVertices[groupThreadId.x] = { .position = position, .normal = normal, .uv = vertex.uv };
    }
}

버텍스 셰이더와 메시 셰이더 모두 픽셀 셰이더를 사용한다. 래스터라이저는 삼각형의 픽셀 커버리지, HiZ, early depth/스텐실 테스트 결과에 따라 픽셀 셰이더 작업을 생성한다. 하드웨어는 여러 삼각형과 여러 인스턴스를 동일한 픽셀 셰이더 웨이브에 패킹할 수 있다. 픽셀 셰이더 자체는 그다지 특별하지 않다. 오늘날 픽셀 셰이더는 다른 모든 셰이더 타입과 동일한 SIMD 코어에서 실행된다. 다만 몇 가지 특수 입력이 제공된다: 보간된 버텍스 출력, 스크린 위치, 샘플 인덱스와 커버리지 마스크, 삼각형 ID, 삼각형의 앞/뒤 방향 등이다. 이러한 특수 입력은 기존 API와 유사하게 시스템 값(: SV) 시맨틱을 사용해 커널 함수 매개변수로 선언된다.

// Pixel shader...
const Texture textureHeap[];

struct VertexIn // Matching vertex shader output struct layout
{
    float16x4 normal;
    float32x2 uv;
};

struct PixelOut
{
    float16x4 color : SV_Color0;
};

PixelOut main(const VertexIn &vertex, const DataPixel* data)
{
    Texture texture = textureHeap[data->textureIndex];
    Sampler sampler = {.minFilter = LINEAR, .magFilter = LINEAR};

    float32x4 color = sample(texture, sampler, vertex.uv);
    return { .color = color };
}

데이터 바인딩을 제거하면 버텍스와 픽셀 셰이더를 더 단순하게 사용할 수 있다. 복잡한 데이터 바인딩 API는 모두 64비트 GPU 포인터 하나로 대체된다. 사용자는 각 버텍스 레이아웃마다 PSO 퍼뮤테이션을 만들지 않고도, 유연한 버텍스 페치 코드를 작성할 수 있다.

Rasterizer state

레거시 API(OpenGL과 DirectX 9)는 모든 셰이더 입력과 래스터라이저 상태를 설정하기 위한 세밀한 명령을 제공했다. 드라이버는 필요할 때 셰이더 파이프라인을 생성해야 했다. 하드웨어 특화 래스터라이저, 블렌더, 입력 어셈블러 명령 패킷은 개별적인 세밀한 상태를 결합한 섀도우 상태(shadow state)로부터 구성되었다. Vulkan 1.0과 DirectX 12는 정반대의 설계를 선택했다. 모든 상태를 사전에 PSO에 베이크했다. 뷰포트, 시저 사각형, 스텐실 값 등 일부 상태만 동적으로 변경할 수 있다. 그 결과 PSO 퍼뮤테이션이 대폭 증가했다.

PSO 생성은 비용이 크다. GPU 드라이버의 저수준 셰이더 컴파일러를 호출해야 하기 때문이다. PSO 퍼뮤테이션은 상당한 저장 공간과 RAM을 소비한다. PSO 변경은 가장 비용이 큰 상태 변경이다. 일부 벤더가 렌더 상태를 셰이더 마이크로코드에 직접 포함해 얻은 작은 성능 이점은, 파이프라인 생성·바인딩·데이터 관리 비용이 크게 증가하면서 발생한 성능 문제에 의해 상쇄되었다. 진자는 반대쪽으로 너무 많이 흔들렸다.

현대 GPU는 ALU 밀도가 높다. Nvidia와 AMD는 최근 추가 파이프라인을 통해 ALU 처리율을 두 배로 늘렸다. Apple도 M 시리즈 칩에서 fp32 파이프라인을 두 배로 늘렸다. 셰이더 내 상수 치환으로 해결되는 단순 상태는, 추가 ALU 명령 하나가 생기거나 유니폼 레지스터를 하나 더 사용하는 정도의 비용이 들더라도 파이프라인을 복제할 필요가 없다. 오늘날 대부분의 셰이더는 ALU 병목이 아니다. 그 비용은 측정하기 어려울 정도로 작지만, 퍼뮤테이션을 줄이는 이점은 매우 크다. Vulkan 1.3은 올바른 방향으로 나아간 큰 진전이다. 많은 베이크된 PSO 상태를 이제 동적으로 설정할 수 있다.

만약 더 깊이 살펴보면, 모든 GPU가 래스터라이저와 깊이-스텐실 유닛을 구성하기 위해 명령 패킷을 사용한다는 것을 알 수 있다. 이러한 명령 패킷은 셰이더 마이크로코드에 직접적으로 묶여 있지 않다. 래스터라이저 및 깊이-스텐실 상태를 변경하기 위해 셰이더 마이크로코드를 수정할 필요는 없다. Metal은 별도의 깊이-스텐실 상태 객체와 이를 적용하는 별도의 명령을 갖고 있다. 별도의 상태 객체는 PSO 퍼뮤테이션을 줄이고, 비용이 큰 셰이더 바인딩 호출을 줄인다. Vulkan 1.3의 동적 상태 역시 유사하게 PSO 퍼뮤테이션을 줄이지만, 더 세밀한 방식이다. Metal의 설계는 실제 하드웨어 명령 패킷 구조와 더 잘 맞는다. 더 큰 패킷은 API 비대화와 오버헤드를 줄인다. DirectX 12는 안타깝게도 대부분의 깊이-스텐실 상태를 여전히 PSO에 묶어두고 있다(스텐실 레퍼런스와 깊이 바이어스만 동적 상태다). 우리의 설계에서는 깊이-스텐실 상태를 별도의 객체로 둔다.

GpuDepthStencilDesc depthStencilDesc =
{
    .depthMode = DEPTH_READ | DEPTH_WRITE,
    .depthTest = OP_LESS_EQUAL,
    .depthBias = 0.0f,
    .depthBiasSlopeFactor = 0.0f,
    .depthBiasClamp = 0.0f,
    .stencilReadMask = 0xff,
    .stencilWriteMask = 0xff,
    .stencilFront =
    {
        .test = OP_ALWAYS,
        .failOp = OP_KEEP,
        .passOp = OP_KEEP,
        .depthFailOp = OP_KEEP,
        .reference = 0
    },
    .stencilBack =
    {
        .test = COMPARE_ALWAYS,
        .failOp = OP_KEEP,
        .passOp = OP_KEEP,
        .depthFailOp = OP_KEEP,
        .reference = 0
    }
};

// A minimal way to descibe the above (using C++ API struct default values):
GpuDepthStencilDesc depthStencilDesc =
{
    .depthMode = DEPTH_READ | DEPTH_WRITE,
    .depthTest = OP_LESS_EQUAL,
};

GpuDepthStencilState depthStencilState = gpuCreateDepthStencilState(depthStencilDesc);

즉시 모드-Immediate mode(desktop) GPU도 알파 블렌더 유닛을 구성하기 위한 유사한 명령 패킷을 가지고 있다. 만약 우리가 DirectX 13을 설계한다면, 단순히 블렌드 상태 객체를 PSO에서 분리하고 끝낼 것이다. 하지만 우리는 크로스 플랫폼 API를 설계하고 있으며, 모바일 GPU에서 블렌딩은 완전히 다르게 동작한다.

모바일 GPU(TBDR)는 오래전부터 프로그래머블 블렌딩을 지원해왔다. 렌더 타일은 컴퓨트 유닛 근처의 스크래치패드 메모리(groupshared 메모리같은)에 들어가며, 픽셀 셰이더는 이전에 래스터라이즈된 픽셀에 대해 직접적이고 저지연의 읽기+쓰기 접근을 할 수 있다. 대부분의 모바일 GPU에는 고정 기능 블렌딩 하드웨어가 없다. 전통적인 그래픽스 API를 사용할 경우, 드라이버의 저수준 셰이더 컴파일러는 셰이더 끝에 블렌딩 명령을 추가한다. 이는 앞서 설명한 버텍스 페치 코드 생성과 유사하다. 만약 모바일 GPU만을 위한 API를 설계한다면, 버텍스 버퍼를 제거했던 것처럼 블렌드 상태 API도 완전히 제거했을 것이다. 모바일 중심 API는 현재 픽셀의 이전 색상을 효율적으로 얻기 위한 프레임버퍼 페치 intrinsic을 노출한다. 사용자는 원하는 어떤 블렌딩 공식이든 작성할 수 있으며, 순서 독립 투명도 같은 고급 알고리즘을 구현하기 위한 복잡한 공식도 가능하다. 또한 사용자는 PSO 퍼뮤테이션 폭증을 줄이기 위해 일반화된 매개변수화 공식도 작성할 수 있다. 이처럼 데스크톱과 모바일 GPU는 블렌딩과 관련된 파이프라인 퍼뮤테이션을 줄이는 각자의 방법을 가지고 있으며, 제약은 현재의 API에 있다.

Vulkan의 서브패스(subpass)는 프레임버퍼 페치를 크로스 플랫폼 API로 감싸기 위해 설계되었다. 이는 Vulkan 설계에서 또 하나의 잘못된 선택이었다. Vulkan은 Mantle에서 단순한 저수준 설계를 계승했지만, OpenGL의 대체재로 설계되었기 때문에 모든 모바일과 데스크톱 GPU 아키텍처를 대상으로 해야 했다. 완전히 다른 두 아키텍처 유형을 동일한 API 아래에서 추상화하는 것은 쉽지 않다. 서브패스는 저수준 API 안에 들어간 고수준 개념이 되었다. 하나의 서브패스는 전체 렌더 패스 체인을 정의할 수 있었지만, 마치 단일 렌더 패스인 것처럼 취급되었다. 서브패스는 드라이버 복잡성을 증가시키고, 셰이더 및 렌더패스 API를 불필요하게 복잡하게 만들었다. 사용자는 복잡한 영속적 멀티 렌더 패스 객체를 사전에 생성하고 이를 셰이더 파이프라인 생성 시 전달해야 했다. 셰이더 파이프라인은 내부적으로 여러 개의 파이프라인(서브패스당 하나)으로 분리되었다. Vulkan은 단지 프레임버퍼 페치 intrinsic을 셰이더 언어에 직접 노출하지 않기 위해 이 모든 복잡성을 추가했다. 설상가상으로 서브패스는 프로그래머블 블렌딩 문제를 해결하기에도 충분하지 않았다. 픽셀 순서는 패스 경계에서만 보장된다. 서브패스는 제한적인 1:1 멀티패스 사용 사례에서만 유용했다. Vulkan 1.3은 서브패스를 폐기하고 “동적 렌더링(dynamic rendering)”을 도입했다. 이제 사용자는 Metal, DirectX 12, WebGPU처럼 영속적 렌더 패스 객체를 생성할 필요가 없다. 이는 복잡한 프레임워크가 API 설계자에게 매력적으로 보일 수 있지만, 개발자는 단순한 셰이더 intrinsic을 선호한다는 좋은 예다. 게임 엔진은 이미 플랫폼별로 서로 다른 셰이더를 빌드하는 것을 지원한다. Apple의 Metal 예제도 마찬가지다: iOS에서는 프레임버퍼 페치를 사용하고, Mac에서는 전통적인 멀티패스 알고리즘을 사용한다.

블렌딩과 프레임버퍼 페치에 관한 하드웨어 차이를 추상화할 수 없다는 것은 분명하다. Vulkan 1.0은 이를 시도했고 크게 실패했다. 올바른 해결책은 사용자에게 선택권을 제공하는 것이다. 사용자는 블렌드 상태를 PSO에 포함시킬 수 있다. 이는 모든 플랫폼에서 동작하며, 블렌드 상태와 관련된 파이프라인 퍼뮤테이션 문제를 겪지 않는 셰이더에 적합한 접근이다. 모바일 GPU에서는 내부 드라이버 셰이더 컴파일러가 평소처럼 픽셀 셰이더 끝에 블렌딩 명령을 추가한다. 즉시 모드(데스크톱) GPU(및 일부 모바일 GPU)에서는 사용자가 별도의 블렌드 상태 객체를 사용할 수 있다. 이는 PSO 퍼뮤테이션 수를 줄이고, 전체 파이프라인 변경 없이 블렌드 상태 구성 패킷만 전송하면 되므로 런타임에 블렌드 상태를 더 빠르게 변경할 수 있게 해준다.

GpuBlendDesc blendDesc =
{
    .colorOp = OP_ONE,
    .srcColorFactor = FACTOR_SRC_ALPHA,
    .dstColorFactor = FACTOR_ONE_MINUS_SRC_ALPHA,
    .alphaOp = OP_ONE,
    .srcAlphaFactor = FACTOR_SRC_ALPHA,
    .dstAlphaFactor = FACTOR_ONE_MINUS_SRC_ALPHA,
    .colorWriteMask = 0xf
};

// Create blend state object (needs feature flag)
GpuBlendState blendState = gpuCreateBlendState(blendDesc);

// Set dynamic blend state (needs feature flag)
gpuSetBlendState(commandBuffer, blendState);

모바일 GPU에서는 사용자가 기존처럼 블렌드 상태를 PSO에 포함시킬 수도 있고, 프레임버퍼 페치를 사용해 커스텀 블렌딩 공식을 작성할 수도 있다. 모바일 개발자가 서로 다른 알파 블렌딩 모드에 대해 여러 PSO 퍼뮤테이션을 컴파일하는 것을 피하고 싶다면, 동적 드로우 구조체 입력으로 매개변수화된 일반 공식을 작성하면 된다.

// Standard percentage blend formula (added automatically by internal shader compiler)
dst.rgb = src.rgb * src.a + dst.rgb * (1.0 - src.a);
dst.a = src.a * src.a + dst.a * (1.0 - src.a);

// Custom formula supporting all blend modes used by HypeHype
const BlendParameters& p = data->blendParameters;
vec4 fs = src.a * vec4(p.sc_sa.xxx + p.sc_one.xxx, p.sa_sa + p.sa_one) + dst.rgba * vec4(p.sc_dc.xxx, sa_da);
vec4 fd = (1.0 - src.a) * vec4(p.dc_1msa.xxx, p.da_1msa) + vec4(p.dc_one.xxx, p.da_one);
dst.rgb = src.rgb * fs.rgb + dst.rgb * fd.rgb;
dst.a = src.a * fs.a + dst.a * fd.a;

블렌드 상태가 PSO에서 분리되면 일부 자동 데드 코드 최적화를 잃을 가능성이 있다. 사용자가 컬러 출력을 비활성화하고 싶을 때는 전통적으로 블렌드 상태의 colorWriteMask를 사용한다. 블렌드 상태가 PSO에 포함되어 있을 경우, 컴파일러는 이를 기반으로 데드 코드 제거를 수행할 수 있다. 유사한 데드 코드 최적화를 가능하게 하기 위해, 우리는 PSO에 각 컬러 타깃별 writeMask를 둔다.

듀얼 소스 블렌딩은 픽셀 셰이더에서 두 개의 컬러 출력을 요구하는 특수 블렌드 모드다. 듀얼 소스 블렌딩은 단일 렌더 타깃만 지원한다. 우리의 블렌드 상태는 분리될 수 있으므로, PSO 설명자에 supportDualSourceBlending 필드를 두어야 한다. 이 옵션이 활성화되면, 셰이더 컴파일러는 두 번째 출력이 듀얼 소스 블렌딩용임을 알 수 있다. 출력이 존재하지 않으면 검증 레이어가 오류를 발생시킨다. 두 개의 컬러를 출력하는 픽셀 셰이더는 듀얼 소스 블렌딩 없이도 사용할 수 있지만(두 번째 컬러는 무시됨), 두 개의 컬러를 출력하는 데에는 약간의 비용이 있다.

PSO에 남는 렌더링 상태는 최소한이다: 프리미티브 토폴로지, 렌더 타깃 및 깊이-스텐실 타깃 포맷, MSAA 샘플 수, 알파 투 커버리지다. 이러한 상태는 생성되는 셰이더 마이크로코드에 영향을 미치므로 PSO에 남아 있어야 한다. 상태 변경 때문에 셰이더 PSO 마이크로코드를 재빌드하는 일은 절대 원하지 않는다. 블렌드 상태가 PSO에 포함된 경우, 그것 역시 PSO에 베이크된다. 이렇게 하면 PSO 생성을 위한 단순한 래스터 상태 구조체만 남게 된다.

GpuRasterDesc rasterDesc =
{
    .topology = TOPOLOGY_TRIANGLE_LIST,
    .cull = CULL_CCW,
    .alphaToCoverage = false,
    .supportDualSourceBlending = false,
    .sampleCount = 1`
    .depthFormat = FORMAT_D32_FLOAT,
    .stencilFormat = FORMAT_NONE,
    .colorTargets =
    {
        { .format = FORMAT_RG11B10_FLOAT }, // G-buffer with 3 render targets
        { .format = FORMAT_RGB10_A2_UNORM },
        { .format = FORMAT_RGBA8_UNORM }
    },
    .blendstate = GpuBlendDesc { ... } // optional (embedded blend state, otherwise dynamic)
};

// A minimal way to descibe the above (using C++ API struct default values):
GpuRasterDesc rasterDesc =
{
    .depthFormat = FORMAT_D32_FLOAT,
    .colorTargets =
    {
        { .format = FORMAT_RG11B10_FLOAT },
        { .format = FORMAT_RGB10_A2_UNORM },
        { .format = FORMAT_RGBA8_UNORM }
    },
};

// Pixel + vertex shader
auto vertexIR = loadFile("vertexShader.ir");
auto pixelIR = loadFile("pixelShader.ir");
GpuPipeline graphicsPipeline = gpuCreateGraphicsPipeline(vertexIR, pixelIR, rasterDesc);

// Mesh shader
auto meshletIR = loadFile("meshShader.ir");
auto pixelIR = loadFile("pixelShader.ir");
GpuPipeline graphicsMeshletPipeline = gpuCreateGraphicsMeshletPipeline(meshletIR, pixelIR, rasterDesc);

HypeHype의 Vulkan 셰이더 PSO 초기화 백엔드 코드는 400줄이며, 내가 개발해온 다른 엔진들과 비교해도 상당히 간결한 편이다. 여기서는 단 18줄의 코드로 픽셀 + 버텍스 셰이더를 초기화했다. 읽고 이해하기도 쉽다. 그럼에도 성능 저하는 없다.

래스터 파이프라인으로 렌더링하는 방식은 컴퓨트 파이프라인과 유사하다. 하나의 데이터 포인터 대신 두 개를 제공한다는 점만 다르다. 커널 엔트리 포인트가 두 개이기 때문이다: 하나는 버텍스 셰이더용, 다른 하나는 픽셀 셰이더용이다. Metal은 버텍스와 픽셀 셰이더에 대해 별도의 데이터 바인딩 슬롯을 가진다. DirectX, Vulkan, WebGPU는 각 바인딩에 대해 가시성 마스크(버텍스, 픽셀, 컴퓨트 등)를 사용한다. 많은 엔진은 동일한 데이터를 버텍스와 픽셀 셰이더에 모두 바인딩한다. DirectX, Vulkan, WebGPU에서는 마스크 비트를 결합할 수 있어 이는 적절한 방식이지만, Metal에서는 바인딩 호출이 두 배로 늘어난다. 우리가 제안하는 두 개의 데이터 포인터 방식은 양쪽의 장점을 모두 가진다. 버텍스와 픽셀 셰이더에서 동일한 데이터를 사용하고 싶다면 동일한 포인터를 두 번 전달하면 된다. 또는 셰이더 단계 간 완전한 분리를 원한다면 서로 다른 데이터 포인터를 제공할 수도 있다. 셰이더 컴파일러는 픽셀과 버텍스 셰이더에 대해 각각 데드 코드 제거 및 상수/스칼라 프리로드 최적화를 수행한다. 데이터 공유든 데이터 중복이든 성능에 악영향을 주지 않는다. 사용자는 자신의 설계에 맞는 방식을 선택하면 된다.

// Common header...
struct Vertex
{
    float32x4 position;
    uint16x2 uv;
};

struct alignas(16) DataVertex
{
    float32x4x4 matrixMVP;
    const Vertex *vertices;
};

struct alignas(16) DataPixel
{
    float32x4 color;
    uint32 textureIndex;
};

// CPU code...
gpuSetDepthStencilState(commandBuffer, depthStencilState);
gpuSetPipeline(commandBuffer, graphicsPipeline);

auto dataVertex = myBumpAllocator.allocate<DataVertex>();
dataVertex.cpu->matrixMVP = camera.viewProjection * modelMatrix;
dataVertex.cpu->vertices = mesh.vertices;

auto dataPixel = myBumpAllocator.allocate<DataPixel>();
dataPixel.cpu->color = material.color;
dataPixel.cpu->textureIndex = material.textureIndex;

gpuDrawIndexed(commandBuffer, dataVertex.gpu, dataPixel.gpu, mesh.indices, mesh.indexCount);

// Vertex shader...
struct VertexOut
{
    float32x4 position : SV_Position; // SV values are not real struct fields (doesn't affect the layout)
    float32x2 uv;
};

VertexOut main(uint32 vertexIndex : SV_VertexID, const DataVertex* data)
{
    Vertex vertex = data.vertices[vertexIndex];
    float32x4 position = data->matrixMVP * vertex.position;
    return { .position = position, .uv = vertex.uv };
}

// Pixel shader...
const Texture textureHeap[];

struct VertexIn // Matching vertex shader output struct layout
{
    float32x2 uv;
};

PixelOut main(const VertexIn &vertex, const DataPixel* data)
{
    Texture texture = textureHeap[data->textureIndex];
    Sampler sampler = {.minFilter = LINEAR, .magFilter = LINEAR};

    float32x4 color = sample(texture, sampler, vertex.uv);
    return { .color = color };
}

우리의 목표는 PSO 내부에 남아 있는 상태를 최소화하여 PSO 퍼뮤테이션 폭증을 줄이는 것이었다. 깊이-스텐실 상태는 모든 아키텍처에서 분리할 수 있다. 블렌드 상태 분리는 데스크톱 하드웨어에서는 가능하지만, 대부분의 모바일 하드웨어는 블렌드 방정식을 픽셀 셰이더 마이크로코드 끝에 포함시킨다. 프레임버퍼 페치 intrinsic을 사용자에게 직접 노출하는 것은 Vulkan의 실패한 서브패스 접근보다 훨씬 나은 방법이다. 사용자는 새로운 렌더링 알고리즘을 가능하게 하는 자신만의 블렌드 공식을 작성할 수 있고, PSO 수를 줄이기 위해 일반화된 매개변수화 블렌딩 공식을 만들 수도 있다.

Indirect drawing

표준 드로우/디스패치 명령은 C/C++ 함수 매개변수를 사용해 스레드 그룹 차원, 인덱스 개수, 인스턴스 개수 등의 인자를 전달한다. 간접 드로우 호출은 이러한 드로우 인자의 소스로 GPU 버퍼 + 오프셋 쌍을 대신 제공할 수 있게 하며, 이는 GPU 주도 렌더링을 가능하게 하는 중요한 기능이다. 우리의 버전은 일반적인 버퍼 객체 + 오프셋 쌍 대신 단일 GPU 포인터를 사용해 API를 약간 더 단순화한다.

gpuDispatchIndirect(commandBuffer, data.gpu, arguments.gpu);
gpuDrawIndexedInstancedIndirect(commandBuffer, dataVertex.gpu, dataPixel.gpu, arguments.gpu);

우리의 모든 인자는 GPU 포인터다. 데이터와 인자 모두가 간접적이다. 이는 기존 API에 비해 큰 개선이다. DirectX 12, Vulkan, Metal은 간접 루트 인자를 지원하지 않는다. 이를 제공하는 것은 CPU의 몫이다.

간접 멀티드로우(MDI)도 지원되어야 한다. 드로우 개수는 GPU 주소에서 가져온다. MDI 파라미터는 다음과 같다: 루트 데이터 배열(GPU 포인터, 버텍스와 픽셀 각각), 드로우 인자 배열(GPU 포인터), 그리고 루트 데이터 배열의 스트라이드(버텍스와 픽셀 각각). 스트라이드가 0이면 동일한 루트 데이터가 각 드로우에 대해 반복 사용됨을 의미한다.

gpuDrawIndexedInstancedIndirectMulti(
commandBuffer,
dataVertex.gpu, sizeof(DataVertex),
dataPixel.gpu, sizeof(DataPixel),
arguments.gpu,
drawCount.gpu
);

Vulkan의 멀티드로우는 드로우 호출마다 바인딩을 변경할 수 없다. gl_DrawID를 사용해 드로우 데이터 구조체를 담은 버퍼를 인덱싱할 수 있지만, 이는 셰이더에 간접 참조를 추가한다. 텍스처를 가져오기 위해서는 디스크립터 인덱싱이나 새로운 디스크립터 버퍼 확장을 사용해야 한다.

DirectX 12의 ExecuteIndirect는 사용자가 드로우마다 루트 상수를 수동 설정할 수 있는 구성 가능한 커맨드 시그니처를 제공하지만, 모든 GPU 커맨드 프로세서에서 빠른 경로를 타지는 않는다. ExecuteIndirect Tier 1.1(2024)은 D3D12_INDIRECT_ARGUMENT_TYPE_INCREMENTING_CONSTANT라는 새로운 선택적 카운터 증가 기능을 추가했다. 이는 드로우 ID를 구현하는 데 사용할 수 있다. SM 6.8(2024)은 마침내 SV_StartInstanceLocation을 지원해, 사용자가 간접 드로우 인자에 상수를 직접 포함할 수 있게 했다. SV_InstanceID와 달리 SV_StartInstanceLocation은 전체 드로우 호출에 걸쳐 균일하므로, 인덱스 로드에 대해 최적의 코드 생성(유니폼/스칼라 경로)을 제공한다. 그러나 데이터 페치는 여전히 간접 참조가 필요하다. GPU 생성 루트 데이터는 지원되지 않는다.

드로우 인자나 루트 데이터를 GPU에서 생성하는 경우, 커맨드 프로세서가 디스패치 완료를 기다리도록 보장해야 한다. 현대 커맨드 프로세서는 지연을 숨기기 위해 명령과 인자를 미리 가져온다(prefetch). 이를 방지하기 위한 플래그를 우리는 배리어에 포함한다. 가장 좋은 방법은 세밀한 배리어를 피하기 위해 모든 드로우 인자와 루트 데이터를 한 번에 업데이트하는 것이다.

gpuBarrier(commandBuffer, STAGE_COMPUTE, STAGE_COMPUTE, HAZARD_DRAW_ARGUMENTS);

간접 셰이더 선택이 없다는 점은 현재 PC 및 모바일 그래픽스 API의 중요한 한계다. 간접 셰이더 선택은 레이 트레이싱과 유사한 멀티 파이프라인으로 구현할 수 있다. Metal은 간접 커맨드 생성도 지원한다(Nvidia는 유사한 Vulkan 확장을 제공한다). 드로우 호출을 효율적으로 건너뛰는 기능은 유용한 부분집합이다. DirectX의 워크 그래프와 CUDA의 동적 병렬성은 셰이더가 필요에 따라 추가 웨이브를 생성할 수 있게 한다. 그러나 이러한 하드웨어 개선에 접근하기 위한 API는 여전히 플랫폼별로 다르고, 여러 셰이더 엔트리 포인트에 흩어져 있다. 명확한 표준화가 없다. 이에 대해서는 후속 글에서 셰이더 프레임워크를 다루며 자세히 설명할 예정이다.

우리의 제안 설계는 간접 드로잉을 매우 강력하게 만든다. 셰이더 루트 데이터와 드로우 파라미터 모두 GPU에서 간접적으로 제공할 수 있다. 이러한 장점은 멀티드로우를 강화해, 해킹 없이 깔끔하고 효율적인 드로우별 데이터 바인딩을 가능하게 한다. 간접 드로잉과 셰이더 프레임워크의 미래는 후속 글에서 다룰 것이다.

Render passes

래스터라이저 하드웨어는 드로잉을 시작하기 전에 렌더링 준비가 되어야 한다. 일반적인 작업에는 렌더 타깃과 깊이-스텐실 뷰 바인딩, 컬러 및 깊이 클리어가 포함된다. 클리어 색상이 변경되면 fast clear eliminate가 발생할 수 있다. 이는 클리어 명령에서 투명하게 처리된다. 모바일 GPU에서는 렌더링 중에 온칩 저장소의 타일이 VRAM으로 저장된다. Vulkan, Metal, WebGPU는 렌더 타깃의 클리어, 로드, 저장을 위해 렌더 패스 추상화를 사용한다. DirectX 12는 최신 Intel(Gen11) 및 Qualcomm(Adreno 630) GPU에서 렌더링을 최적화하기 위해 2018년 업데이트에서 렌더 패스 지원을 추가했다. 렌더 패스 추상화는 눈에 띄는 API 복잡성을 추가하지 않으므로, 현대적인 크로스 플랫폼 API에서 합리적인 선택이다.

DirectX 12에는 렌더 타깃 뷰와 깊이-스텐실 뷰가 있으며, 이를 저장하기 위한 별도의 디스크립터 힙이 있다. 이는 단지 API 추상화일 뿐이다. 이러한 힙은 드라이버가 할당한 CPU 메모리다. 렌더 타깃과 깊이-스텐실 뷰는 GPU 디스크립터가 아니다. 래스터라이저 API는 바인드리스가 아니다. CPU 드라이버가 명령 패킷을 사용해 래스터라이저를 설정한다. Vulkan과 Metal에서는 기존 텍스처/뷰 객체를 beginRenderPass에 직접 전달한다. 드라이버는 내부적으로 텍스처 객체에서 필요한 정보를 얻는다. 우리가 제안하는 GpuTexture 객체가 이 역할을 수행한다. 래스터라이제이션 출력은 여전히 CPU 측 텍스처 객체가 필요한 주요 이유다. 우리는 텍스처 디스크립터를 GPU 메모리에 직접 작성한다. CPU 측 드라이버는 그것에 접근할 수 없다.

GpuRenderPassDesc renderPassDesc =
{
    .depthTarget = {.texture = deptStencilTexture, .loadOp = CLEAR, .storeOp = DONT_CARE, .clearValue = 1.0f},
    .stencilTarget = {.texture = deptStencilTexture, .loadOp = CLEAR, .storeOp = DONT_CARE, .clearValue = 0},
    .colorTargets =
    {
        {.texture = gBufferColor, .loadOp = LOAD, .storeOp = STORE, .clearColor = {0,0,0,0}},
        {.texture = gBufferNormal, .loadOp = LOAD, .storeOp = STORE, .clearColor = {0,0,0,0}},
        {.texture = gBufferPBR, .loadOp = LOAD, .storeOp = STORE, .clearColor = {0,0,0,0}}
    }
};

gpuBeginRenderPass(commandBuffer, renderPassDesc);
// Add draw calls here!
gpuEndRenderPass(commandBuffer);

바인드리스 렌더 패스, 바인드리스/간접(멀티) 클리어 명령, 간접 시저/뷰포트 사각형(배열) 등이 있으면 좋겠지만, 오늘날 많은 GPU는 여전히 CPU 드라이버가 래스터라이저를 설정해야 한다.

배리어에 대한 참고 사항: 렌더 패스 시작/종료 명령이 자동으로 배리어를 발생시키지는 않는다. 서로 다른 렌더 타깃에 기록한다면, 사용자는 여러 렌더 패스를 동시에 실행할 수 있다. 래스터 출력 단계(또는 그 이후 단계)와 소비자 단계 사이에 배리어를 두면, 해당 GPU 아키텍처에서 필요할 경우 작은 ROP 캐시가 플러시된다. 렌더 패스 사이에 자동 배리어가 없는 것은 효율적인 깊이 프리패스 구현에 매우 중요하다(ROP 캐시가 불필요하게 플러시되지 않는다).

Claybook의 GPU 기반 점토 시뮬레이션과 레이 트레이싱 기술(Sebastian Aaltonen, GDC 2018): 나는 Unreal Engine 4의 콘솔 배리어 구현(Xbox One, PS4)을 최적화해 렌더 타깃 오버랩이 가능하도록 했다. 배리어로 인한 스톨을 피했다.

Prototype API

내 프로토타입 API는 한 화면에 들어간다: 코드 150줄이다. 이 블로그 글의 제목은 “No Graphics API”다. 물론 오늘날 그것은 불가능한 목표지만, 우리는 꽤 근접했다. WebGPU는 더 작은 기능 집합을 가지며, 약 2700줄 규모의 API(Emscripten C 헤더)를 제공한다. Vulkan 헤더는 약 20,000줄에 달하지만, 레이 트레이싱과 우리가 아직 지원하지 않는 많은 기능을 포함한다. 우리는 API 복잡성을 줄이면서도 성능을 희생하지 않았다. 이 기능 범위에서는, 우리의 API가 기존 API보다 더 큰 유연성을 제공한다. 2025년 여름 기준으로 완전히 확장된 Vulkan 1.4도 실제로는 동일한 작업을 수행할 수 있지만, 사용하기 훨씬 복잡하고 API 오버헤드도 더 크다.

// Opaque handles
struct GpuPipeline;
struct GpuTexture;
struct GpuDepthStencilState;
struct GpuBlendState;
struct GpuQueue;
struct GpuCommandBuffer;
struct GpuSemaphore;

// Enums
enum MEMORY { MEMORY_DEFAULT, MEMORY_GPU, MEMORY_READBACK };
enum CULL { CULL_CCW, CULL_CW, CULL_ALL, CULL_NONE };
enum DEPTH_FLAGS { DEPTH_READ = 0x1, DEPTH_WRITE = 0x2 };
enum OP { OP_NEVER, OP_LESS, OP_EQUAL, OP_LESS_EQUAL, OP_GREATER, OP_NOT_EQUAL, OP_GREATER_EQUAL, OP_ALWAYS };
enum BLEND { BLEND_ADD, BLEND_SUBTRACT, BLEND_REV_SUBTRACT, BLEND_MIN, BLEND_MAX };
enum FACTOR { FACTOR_ZERO, FACTOR_ONE, FACTOR_SRC_COLOR, FACTOR_DST_COLOR, FACTOR_SRC_ALPHA, ... };
enum TOPOLOGY { TOPOLOGY_TRIANGLE_LIST, TOPOLOGY_TRIANGLE_STRIP, TOPOLOGY_TRIANGLE_FAN };
enum TEXTURE { TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE, TEXTURE_2D_ARRAY, TEXTURE_CUBE_ARRAY };
enum FORMAT { FORMAT_NONE, FORMAT_RGBA8_UNORM, FORMAT_D32_FLOAT, FORMAT_RG11B10_FLOAT, FORMAT_RGB10_A2_UNORM, ... };
enum USAGE_FLAGS { USAGE_SAMPLED, USAGE_STORAGE, USAGE_COLOR_ATTACHMENT, USAGE_DEPTH_STENCIL_ATTACHMENT, ... };
enum STAGE { STAGE_TRANSFER, STAGE_COMPUTE, STAGE_RASTER_COLOR_OUT, STAGE_PIXEL_SHADER, STAGE_VERTEX_SHADER, ... };
enum HAZARD_FLAGS { HAZARD_DRAW_ARGUMENTS = 0x1, HAZARD_DESCRIPTORS = 0x2, , HAZARD_DEPTH_STENCIL = 0x4 };
enum SIGNAL { SIGNAL_ATOMIC_SET, SIGNAL_ATOMIC_MAX, SIGNAL_ATOMIC_OR, ... };

// Structs
struct Stencil
{
    OP test = OP_ALWAYS,
    OP failOp = OP_KEEP;
    OP passOp = OP_KEEP;
    OP depthFailOp = OP_KEEP;
    uint8 reference = 0;
};

struct GpuDepthStencilDesc
{
    DEPTH_FLAGS depthMode = 0;
    OP depthTest = OP_ALWAYS;
    float depthBias = 0.0f;
    float depthBiasSlopeFactor = 0.0f;
    float depthBiasClamp = 0.0f;
    uint8 stencilReadMask = 0xff;
    uint8 stencilWriteMask = 0xff;
    Stencil stencilFront;
    Stencil stencilBack;
};

struct GpuBlendDesc
{
    BLEND colorOp = BLEND_ADD,
    FACTOR srcColorFactor = FACTOR_ONE;
    FACTOR dstColorFactor = FACTOR_ZERO;
    BLEND alphaOp = BLEND_ADD;
    FACTOR srcAlphaFactor = FACTOR_ONE;
    FACTOR dstAlphaFactor = FACTOR_ZERO;
    uint8 colorWriteMask = 0xf;
};

struct ColorTarget {
    FORMAT format = FORMAT_NONE;
    uint8 writeMask = 0xf;
};

struct GpuRasterDesc
{
    TOPOLOGY topology = TOPOLOGY_TRIANGLE_LIST;
    CULL cull = CULL_NONE;
    bool alphaToCoverage = false;
    bool supportDualSourceBlending = false;
    uint8 sampleCount = 1;
    FORMAT depthFormat = FORMAT_NONE;
    FORMAT stencilFormat = FORMAT_NONE;
    Span<ColorTarget> colorTargets = {};
    GpuBlendDesc* blendstate = nullptr; // optional embedded blend state
};

struct GpuTextureDesc
{
    TEXTURE type = TEXTURE_2D;
    uint32x3 dimensions;
    uint32 mipCount = 1;
    uint32 layerCount = 1;
    uint32 sampleCount = 1;
    FORMAT format = FORMAT_NONE;
    USAGE_FLAGS usage = 0;
};

struct GpuViewDesc
{
    FORMAT format = FORMAT_NONE;
    uint8 baseMip = 0;
    uint8 mipCount = ALL_MIPS;
    uint16 baseLayer = 0;
    uint16 layerCount = ALL_LAYERS;
};

struct GpuTextureSizeAlign { size_t size; size_t align; };
struct GpuTextureDescriptor { uint64[4] data; };

// Memory
void* gpuMalloc(size_t bytes, MEMORY memory = MEMORY_DEFAULT);
void* gpuMalloc(size_t bytes, size_t align, MEMORY memory = MEMORY_DEFAULT);
void gpuFree(void *ptr);
void* gpuHostToDevicePointer(void *ptr);

// Textures
GpuTextureSizeAlign gpuTextureSizeAlign(GpuTextureDesc desc);
GpuTexture gpuCreateTexture(GpuTextureDesc desc, void* ptrGpu);
GpuTextureDescriptor gpuTextureViewDescriptor(GpuTexture texture, GpuViewDesc desc);
GpuTextureDescriptor gpuRWTextureViewDescriptor(GpuTexture texture, GpuViewDesc desc);

// Pipelines
GpuPipeline gpuCreateComputePipeline(ByteSpan computeIR);
GpuPipeline gpuCreateGraphicsPipeline(ByteSpan vertexIR, ByteSpan pixelIR, GpuRasterDesc desc);
GpuPipeline gpuCreateGraphicsMeshletPipeline(ByteSpan meshletIR, ByteSpan pixelIR, GpuRasterDesc desc);
void gpuFreePipeline(GpuPipeline pipeline);

// State objects
GpuDepthStencilState gpuCreateDepthStencilState(GpuDepthStencilDesc desc);
GpuBlendState gpuCreateBlendState(GpuBlendDesc desc);
void gpuFreeDepthStencilState(GpuDepthStencilState state);
void gpuFreeBlendState(GpuBlendState state);

// Queue
GpuQueue gpuCreateQueue(/* DEVICE & QUEUE CREATION DETAILS OMITTED */);
GpuCommandBuffer gpuStartCommandRecording(GpuQueue queue);
void gpuSubmit(GpuQueue queue, Span<GpuCommandBuffer> commandBuffers);

// Semaphores
GpuSemaphore gpuCreateSemaphore(uint64 initValue);
void gpuWaitSemaphore(GpuSemaphore sema, uint64 value);
void gpuDestroySemaphore(GpuSemaphore sema);

// Commands
void gpuMemCpy(GpuCommandBuffer cb, void* destGpu, void* srcGpu,);
void gpuCopyToTexture(GpuCommandBuffer cb, void* destGpu, void* srcGpu, GpuTexture texture);
void gpuCopyFromTexture(GpuCommandBuffer cb, void* destGpu, void* srcGpu, GpuTexture texture);

void gpuSetActiveTextureHeapPtr(GpuCommandBuffer cb, void *ptrGpu);

void gpuBarrier(GpuCommandBuffer cb, STAGE before, STAGE after, HAZARD_FLAGS hazards = 0);
void gpuSignalAfter(GpuCommandBuffer cb, STAGE before, void *ptrGpu, uint64 value, SIGNAL signal);
void gpuWaitBefore(GpuCommandBuffer cb, STAGE after, void *ptrGpu, uint64 value, OP op, HAZARD_FLAGS hazards = 0, uint64 mask = ~0);

void gpuSetPipeline(GpuCommandBuffer cb, GpuPipeline pipeline);
void gpuSetDepthStencilState(GpuCommandBuffer cb, GpuDepthStencilState state);
void gpuSetBlendState(GpuCommandBuffer cb, GpuBlendState state);

void gpuDispatch(GpuCommandBuffer cb, void* dataGpu, uvec3 gridDimensions);
void gpuDispatchIndirect(GpuCommandBuffer cb, void* dataGpu, void* gridDimensionsGpu);

void gpuBeginRenderPass(GpuCommandBuffer cb, GpuRenderPassDesc desc);
void gpuEndRenderPass(GpuCommandBuffer cb);

void gpuDrawIndexedInstanced(GpuCommandBuffer cb, void* vertexDataGpu, void* pixelDataGpu, void* indicesGpu, uint32 indexCount, uint32 instanceCount);
void gpuDrawIndexedInstancedIndirect(GpuCommandBuffer cb, void* vertexDataGpu, void* pixelDataGpu, void* indicesGpu, void* argsGpu);
void gpuDrawIndexedInstancedIndirectMulti(GpuCommandBuffer cb, void* dataVxGpu, uint32 vxStride, void* dataPxGpu, uint32 pxStride, void* argsGpu, void* drawCountGpu);

void gpuDrawMeshlets(GpuCommandBuffer cb, void* meshletDataGpu, void* pixelDataGpu, uvec3 dim);
void gpuDrawMeshletsIndirect(GpuCommandBuffer cb, void* meshletDataGpu, void* pixelDataGpu, void *dimGpu);

Tooling

버퍼와 텍스처 객체를 바인딩하지도 않고, 메모리 레이아웃을 명시적으로 설명하는 API도 호출하지 않는 코드를 어떻게 디버그할 수 있을까? C/C++ 디버거는 수십 년 동안 그런 일을 해왔다. 소프트웨어의 메모리 레이아웃을 설명하기 위한 특별한 운영체제 API는 없다. 디버거는 64비트 포인터 체인을 따라갈 수 있고, 컴파일러가 제공하는 디버그 심볼 데이터를 사용할 수 있다. 여기에는 구조체와 클래스의 메모리 레이아웃도 포함된다. CUDA와 Metal은 완전한 64비트 포인터 시맨틱을 갖는 C/C++ 기반 셰이딩 언어를 사용한다. 둘 다 포인터 체인을 문제없이 따라가는 견고한 디버거를 갖고 있다. 텍스처 디스크립터 힙은 그저 GPU 메모리다. 디버거는 이를 인덱싱해 텍스처 디스크립터를 로드하고, 디스크립터 데이터를 보여주며, 텍셀을 시각화할 수 있다. 이런 것들은 Xcode Metal 디버거에서 이미 동작한다. 어떤 GPU 주소의 어떤 구조체 안에 있는 텍스처나 샘플러 핸들을 클릭해도, 디버거가 그것을 시각화해준다.

현대 GPU는 메모리를 가상화한다. 각 프로세스는 자신의 페이지 테이블을 가진다. GPU 캡처에는 자체 가상 주소 공간을 가진 별도의 리플레이어 프로세스가 있다. 리플레이어가 모든 할당을 단순히 다시 재생(replay)한다면, 각 메모리 할당은 서로 다른 GPU 가상 주소를 받게 된다. 레거시 API에서는 GPU 주소를 데이터 구조체에 직접 저장할 수 없었기 때문에 이것이 문제가 되지 않았다. 하지만 현대 API에서는 리플레이어가 정확히 동일한 GPU 가상 메모리 레이아웃을 미러링하도록 강제하는 특수한 리플레이 메모리 할당 API가 필요하다. DX12와 Vulkan BDA에는 이를 위한 공개 API가 있다: RecreateAt과 VkMemoryOpaqueCaptureAddressAllocateInfo. Metal과 CUDA 디버거도 내부의 문서화되지 않은 API를 사용해 같은 일을 한다. RenderDoc 같은 오픈 소스 도구가 동작하려면 공개 API가 더 바람직하다.

원시 포인터는 보안 문제를 가져오지 않을까? 다른 앱의 메모리를 읽고/쓸 수 있지 않을까? 가상 메모리 때문에 이는 불가능하다. 접근할 수 있는 것은 자기 자신의 메모리 페이지뿐이다. 실수로 오래된 포인터를 쓰거나 오버플로가 발생하면 페이지 폴트가 발생한다. 페이지 폴트는 기존의 버퍼 기반 API에서도 가능하다. DirectX 12와 Vulkan은 스토리지(바이트어드레스/스트럭처드) 버퍼 주소를 클램프하지 않는다. OOB(범위 밖 접근)는 페이지 폴트를 일으킨다. 사용자가 메모리 힙을 해제한 뒤에도 오래된 버퍼/텍스처 디스크립터를 계속 사용해 페이지 폴트를 일으킬 수도 있다. 본질적으로 달라지는 것은 없다. 매핑되지 않은 영역에 접근하면 페이지 폴트가 발생하고 애플리케이션은 크래시한다. 이는 C/C++ 프로그래머에게 익숙한 동작이다. 견고함(robustness)이 필요하다면 ptr + size 쌍을 사용할 수 있다. WebGPU가 정확히 이런 방식으로 구현되어 있다. WebGPU 셰이더 컴파일러(Tint 또는 Naga)는 정점 접근(인덱스 버퍼 값 범위 밖)까지 포함해 각 버퍼 접근마다 추가 클램프 명령을 생성한다. WebGL은 인덱스 버퍼 데이터를 다른 데이터와 함께 셰이딩하는 것을 허용하지 않았다. WebGL은 CPU에서 인덱스를 훑어 검사했는데(그 결과 인덱스 버퍼 업데이트가 매우 느려졌다). 그 당시에는 커스텀 버텍스 페치가 불가능했다. 셰이더가 실행되기도 전에 하드웨어가 페이지 폴트를 내버렸기 때문이다.

Translation layers

기존 소프트웨어를 실행할 수 있는 능력은 매우 중요하다. ANGLE, Proton, MoltenVK 같은 번역 레이어는 레거시 API의 이식성과 폐기(deprecation) 과정에서 핵심적인 역할을 한다. 이제 DirectX 12, Vulkan, Metal을 우리의 새로운 API로 번역하는 방법을 살펴보자.

MoltenVK(Vulkan → Metal 번역 레이어)는 Vulkan의 버퍼 중심 API가 Metal의 64비트 포인터 기반 생태계로 번역될 수 있음을 증명한다. MoltenVK는 Vulkan의 디스크립터 세트를 Metal의 argument buffer로 변환한다. 생성된 argument buffer는 각 버퍼 바인딩당 64비트 GPU 포인터 하나, 각 텍스처 바인딩당 64비트 텍스처 ID 하나를 포함하는 표준 GPU 구조체다. 우리는 더 나은 방식을 사용할 수 있다. 각 디스크립터 세트에 대해 텍스처 힙에 연속된 범위의 텍스처 디스크립터를 할당하고, 각 텍스처 바인딩마다 64비트 텍스처 ID 대신 단일 32비트 베이스 인덱스를 저장하는 것이다. 이는 우리의 API가 Metal과 달리 사용자 관리 텍스처 힙을 가지기 때문에 가능하다.

MoltenVK는 디스크립터 세트를 Metal API 루트 바인딩 슬롯에 매핑한다. 우리는 최대 8개의 64비트 포인터 필드를 가진 루트 구조체를 생성하고, 각 필드는 디스크립터 세트 구조체를 가리킨다. 루트 상수는 값 필드로 변환되고, 루트 디스크립터(루트 버퍼)는 64비트 포인터로 변환된다. GPU 드라이버가 루트 구조체 필드를 유니폼/스칼라 레지스터에 프리로드한다고 가정하면, 효율성은 동일해야 한다.

우리 API는 Metal과 같은 64비트 포인터 시맨틱을 사용한다. 셰이더에서의 버퍼 로드/스토어 명령을 번역할 때 MoltenVK가 사용하는 기법을 그대로 적용할 수 있다. MoltenVK는 Vulkan의 buffer device address 확장도 번역 지원한다.

Proton(DX12 → Vulkan 번역 레이어)은 DirectX 12 SM 6.6 디스크립터 힙이 Vulkan의 descriptor buffer 확장으로 번역될 수 있음을 증명한다. Proton은 다른 DirectX 12 기능도 Vulkan으로 변환한다. MoltenVK를 통해 Vulkan → Metal 번역이 가능하다는 점을 이미 보였으므로, 간접적으로 DirectX 12 → Metal 번역도 가능함이 증명된다. MoltenVK에서 가장 부족한 기능은 SM 6.6 스타일 디스크립터 힙(Vulkan descriptor buffer 확장)이다. Metal은 디스크립터 힙을 사용자에게 직접 노출하지 않는다. 우리가 제안하는 새로운 API는 이러한 제한이 없다. 우리의 디스크립터 힙 시맨틱은 SM 6.6 디스크립터 힙의 상위 집합이며, Vulkan descriptor buffer 확장과도 매우 유사하다. 번역은 직관적이다. Vulkan 확장은 디스크립터 무효화 플래그도 추가하는데, 이는 우리의 HAZARD_DESCRIPTORS와 일치한다. DirectX 12 디스크립터 힙 API 역시 GPU 메모리의 원시 디스크립터 배열 위에 얇은 래퍼일 뿐이므로 번역이 쉽다.

Metal 4.0을 지원하려면 Metal의 드라이버 관리 텍스처 디스크립터 힙을 구현해야 한다. 이는 우리의 텍스처 힙 위에 단순한 프리리스트를 구현함으로써 가능하다. Metal은 64비트 텍스처 핸들을 사용하는데, 이는 최신 Apple Silicon에서 직접 힙 인덱스로 구현된다. Metal은 셰이더에서 텍스처 핸들을 텍스처처럼 직접 사용할 수 있게 한다. 이는 textureHeap[uint64(handle)]에 대한 문법적 설탕에 불과하다. Metal 텍스처 핸들은 셰이더 번역기를 통해 uint64로 변환되어 동일한 GPU 메모리 레이아웃을 유지한다.

우리 API는 버텍스 버퍼를 지원하지 않는다. WebGPU 역시 하드웨어 버텍스 버퍼를 사용하지 않지만, 고전적인 버텍스 버퍼 추상화를 구현한다. WGSL 셰이더 번역기(Tint 또는 Naga)는 각 버텍스 스트림에 대해 하나의 스토리지 버퍼 바인딩을 추가하고, 버텍스 셰이더 시작 부분에 버텍스 로드 명령을 생성한다. 커스텀 버텍스 페치는 OOB 동작을 방지하기 위한 클램프 명령을 삽입할 수 있다. 악의적인 웹사이트가 브라우저를 크래시시키는 일은 없다. 우리의 셰이더 번역기 역시 각 버텍스 스트림에 대해 루트 구조체에 64비트 포인터를 추가하고, 해당 레이아웃에 맞는 구조체를 생성하며, 버텍스 셰이더 시작 부분에 버텍스 구조체 로드 명령을 생성한다.

이로써 DirectX 12, Vulkan, Metal 애플리케이션을 우리의 새로운 API 위에서 실행하기 위한 번역 레이어를 작성하는 것이 가능함을 보였다. WebGPU는 브라우저에서 이러한 API 위에 구현되어 있으므로, WebGPU 애플리케이션도 실행할 수 있다.

Min spec hardware

Nvidia Turing(RTX 2000 시리즈, 2018)은 레이 트레이싱, 텐서 코어, 메시 셰이더, 저지연 raw 메모리 경로, 더 크고 빠른 캐시, 스칼라 유닛, 보조 정수 파이프라인 등 미래 지향적인 여러 기능을 도입했다. 공식적인 PCIe ReBAR 지원은 RTX 3000 시리즈와 함께 시작되었지만, 이를 지원하는 비공식 Turing 드라이버도 존재해 하드웨어 자체는 이를 지원할 수 있음을 보여준다. 이 7년 된 GPU는 우리가 필요로 하는 모든 기능을 지원한다. Nvidia는 2025년 가을에 GTX 1000 시리즈 드라이버 지원을 종료했다. 현재 지원 중인 모든 Nvidia GPU는 우리의 새로운 API를 지원할 수 있다.

AMD RDNA2(RX 6000 시리즈, 2020)는 레이 트레이싱과 메시 셰이더를 통해 Nvidia의 기능 세트에 맞섰다. 그보다 1년 앞서 RDNA 1은 코히어런트 L2$, 새로운 L1$ 레벨, 빠른 L0$, 범용 DCC 읽기/쓰기 경로, fastpath 비필터 로드, 최신 SIMD32 아키텍처를 도입했다. PCIe ReBAR는 “Smart Access Memory”라는 브랜드명으로 공식 지원된다. 이 5년 된 GPU는 우리가 필요로 하는 모든 기능을 지원한다. AMD는 이미 2021년에 GCN 드라이버 지원을 종료했다. 현재 RDNA 1과 RDNA 2는 버그 수정과 보안 업데이트만 받고 있으며, RDNA 3가 게임 최적화를 받는 가장 오래된 GPU다. 현재 지원되는 모든 AMD GPU는 우리의 API를 지원할 수 있다.

Intel Alchemist / Xe1(2022)은 SM 6.6 글로벌 인덱서블 힙을 지원한 최초의 Intel 칩이다. 이 칩들은 레이 트레이싱, 메시 셰이더, PCIe ReBAR(외장형), UMA(내장형)도 지원한다. 이 3년 된 Intel GPU들은 우리가 필요로 하는 모든 기능을 지원한다.

Apple M1 / A14(MacBook M1, iPhone 12, 2020)은 Metal 4.0을 지원한다. Metal 4.0은 CPU에 대한 GPU 메모리 가시성을 보장하며(폰과 컴퓨터 모두 UMA), 사용자가 64비트 포인터와 64비트 텍스처 핸들을 GPU 메모리에 직접 기록할 수 있게 한다. Metal 4.0에는 새로운 residency set API가 추가되어, 기존 useResource/useHeap API의 바인드리스 리소스 관리에서의 중요한 사용성 문제를 해결했다. iOS 26은 여전히 iPhone 11을 지원한다. 현재로서는 개발자가 Metal 4.0을 요구하는 앱을 출시할 수 없다. iOS 27에서는 아마도 내년에 iPhone 11 지원이 종료될 가능성이 크다. Mac에서는 Intel Mac 지원을 중단하면 Metal 4.0이 보장된다. M1부터 M5까지 5세대, 5년에 해당한다.

ARM Mali-G710(2021)은 ARM의 첫 번째 현대적 아키텍처다. 새로운 커맨드 스트림 프런트엔드(CSF)를 도입해 드로우 콜 빌딩에 대한 CPU 의존성을 줄이고, 멀티 드로우 간접과 컴퓨트 큐 같은 중요한 기능을 추가했다. 비균일 인덱스 텍스처 샘플링 성능이 크게 향상되었고, AFBC 무손실 압축기는 이제 16비트 부동소수점 타깃을 지원한다. G710은 Vulkan BDA와 descriptor buffer 확장을 지원하며, 향후 드라이버에서 2025년 unified image layout 확장도 지원할 수 있다. Mali-G715(2022)는 레이 트레이싱 지원을 도입했다.

Qualcomm Adreno 650(2019)은 Vulkan BDA, descriptor buffer, unified image layout 확장을 지원하며, 최신 Turnip 오픈소스 드라이버와 함께 16비트 저장/연산, dynamic rendering, 확장 동적 상태를 지원한다. Adreno 740(2022)는 레이 트레이싱을 도입했다.

PowerVR DXT(Pixel 10, 2025)는 PowerVR의 첫 번째 Vulkan descriptor buffer 및 buffer device address 확장 지원 아키텍처다. 또한 64비트 원자 연산, 8비트 및 16비트 저장/연산, dynamic rendering, 확장 동적 상태 및 우리가 요구하는 모든 기능을 지원한다.

Conclusion

현대 그래픽스 API는 지난 10년간 점진적으로 개선되어 왔다. DirectX 12 출시 6년 후, SM 6.6(2021)는 현대적인 글로벌 텍스처 힙을 도입해 완전한 바인드리스 렌더러 설계를 가능하게 했다. Metal 4.0(2025)과 CUDA는 최소한의 바인딩 API 표면을 갖춘 깔끔한 64비트 포인터 기반 셰이더 아키텍처를 제공한다. Vulkan은 가장 제한적인 표준을 갖고 있지만, buffer device address(2020), descriptor buffer(2022), unified image layouts(2025) 같은 확장을 통해 현대적인 바인드리스 인프라를 지원하게 되었다. 그러나 툴링은 여전히 뒤처져 있다. 현재로서는 우리의 모든 요구를 충족하는 단일 API는 없지만, 각 API의 장점을 결합하면 현대 하드웨어에 최적화된 이상적인 API를 만들 수 있다.

10년 전, 현대 API는 CPU 주도 바인딩 모델을 기준으로 설계되었다. 새로운 바인드리스 기능은 선택적 기능이나 확장으로 제시되었다. 과감한 단절(clean break)은 사용성을 개선하고 API 비대화와 드라이버 복잡성을 크게 줄일 수 있다. 업계 전체를 새로운 API로 이끄는 것은 매우 어렵다. 하지만 벤더들이 새로운 메이저 API 버전(Vulkan 2.0, DirectX 13)에서 하위 호환성을 과감히 포기하고, 오늘날의 완전한 바인드리스 GPU 아키텍처를 수용하길 기대한다. 새로운 바인드리스 API 설계는 API와 게임 엔진 RHI 사이의 불일치를 해결해 해시 맵과 세밀한 리소스 추적을 제거할 수 있게 한다. Metal 4.0은 이 목표에 근접했지만, 글로벌 인덱서블 텍스처 힙이 아직 없다. 64비트 텍스처 핸들 하나로는 텍스처 범위를 표현할 수 없다.

HLSL과 GLSL 셰이딩 언어는 20년 이상 전에 1:1 요소 단위 변환 함수(버텍스, 픽셀, 지오메트리, 헐, 도메인 등) 프레임워크로 설계되었다. 메모리 접근은 추상화되어 있고, 포인터를 지원하지 않기 때문에 배열 처리도 번거롭다. 20년이 지났지만 HLSL과 GLSL은 라이브러리 생태계를 구축하는 데 실패했다. 반면 CUDA는 메모리를 직접 노출하고, 새로운 기능(예: AI 텐서 코어)을 intrinsic으로 제공하는 조합 가능한 언어다. CUDA는 폭넓은 라이브러리 생태계를 갖추었고, 이는 Nvidia를 4조 달러 가치 기업으로 끌어올렸다. 우리는 여기서 배워야 한다.

WebGPU 참고 : WebGPU 설계는 10년 된 Vulkan 1.0 코어를 기반으로 하며 추가적인 제한을 둔다. WebGPU는 바인드리스 리소스, 64비트 GPU 포인터, 영구 매핑 GPU 메모리를 지원하지 않는다. DirectX 11과 Vulkan 1.0의 혼합처럼 보인다. 웹 그래픽스에는 큰 진전이지만, 현대적인 바인드리스 API 기준에는 미치지 못한다. WebGPU에 대해서는 별도의 블로그 글에서 다룰 예정이다.

내 프로토타입 API는 최신 API들의 장점을 결합했을 때 오늘날 현대 GPU 아키텍처로 무엇이 가능한지를 보여준다. DirectX 11과 Metal 1.0보다 사용하기 쉽고, 동시에 DirectX 12와 Vulkan보다 더 나은 성능과 유연성을 제공하는 API를 만드는 것이 가능하다. 우리는 현대 바인드리스 하드웨어를 받아들여야 한다.

Appendix

모든 예제 코드에서 사용된 간단한 사용자 공간 GPU 범프 할당기다. 임시 할당기 생성자에서 gpuHostToDevicePointer를 한 번 호출한다. GPU 포인터에 대해 표준 포인터 연산(예: 오프셋)을 수행할 수 있다. 기존 Vulkan/DX12 버퍼 API는 별도의 오프셋을 요구한다. 이는 API와 사용자 코드를 단순화한다(포인터 vs 핸들+오프셋 쌍). 실제 제품 수준의 임시 할당기는 오버플로 처리(확장, 플러시 등)를 구현해야 한다.

template<typename T>
struct GPUTempAllocation<T>
{
    T* cpu;
    T* gpu;
}

struct GPUBumpAllocator
{
    uint8 *cpu;
    uint8 *gpu;
    uint32 offset = 0;
    uint32 size;

    TempBumpAllocator(uint32 size) : size(size)
    {
        cpu = gpuMalloc(size);
        gpu = gpuHostToDevicePointer(cpu);
    }

    TempAllocation<uint8> alloc(int bytes, int align = 16)
    {
        offset = alignRoundUp(offset, align);
        if (offset + bytes > size) offset = 0; // Simple ring wrap (no overflow detection)
        TempAllocation<uint8> alloc = { .cpu = cpu + offset, . gpu = gpu + offset };
        offset += bytes;
        return alloc;
    }

    template<typename T>
    T* alloc(int count = 1)
    {
        TempAllocation<uint8> mem = alloc(sizeof(T) * count, alignof(T));
        return TempAllocation<T> { .cpu = (T*)mem.cpu, . gpu = (T*)mem.gpu };
    }
};

[번역] State of HLSL : 2026.2

illu_yun — Sat, 14 Feb 2026 19:56:59 +0900

원문 : https://www.abolishcrlf.org/2026/02/10/HLSLState.html?fbclid=IwZXh0bgNhZW0CMTEAc3J0YwZhcHBfaWQQMjIyMDM5MTc4ODIwMDg5MgABHgl8W9EXMPw9HJ_v2remHvETZ9yj4FOV7sHOUYPX0RQujg9XxwI-cdM8eExH_aem_UDUl1x35x8I2rKGu0ksVmA

HLSL의 현황: 2026년 2월

아마도 나는 2025년을, GPU 프로그래밍의 미래 방향에 대해 이야기하다가 누군가가 슬그머니 “neural(신경망)”이라는 단어를 끼워 넣지 않고는 대화를 이어갈 수 없게 된 해로 기억하게 될 것이다. 개인적으로 나는 신경망의 많은 활용 사례에 대해 회의적인 편이지만, 2025년은 특히 실시간 그래픽스 분야에서 꽤 흥미로운 사용 사례들이 주목받기 시작한 해이기도 하다.

내가 썩 좋아하지는 않는 표현이지만, 이른바 “뉴럴 렌더링(neural rendering)”의 부상은 2025년을 규정했고, 올해 HLSL을 둘러싼 논의를 지배했다. 하지만 HLSL 세계에서 일어나고 있는 일이 그것뿐만은 아니다. 그러니 먼저 다른 이야기들부터 살펴본 뒤, 다시 이 주제로 돌아오도록 하자.

Clang에서의 HLSL 현황

Microsoft와 Google의 HLSL 팀은 Clang 기반 HLSL 구현을 꾸준히 발전시켜 왔다. 현재 Clang은 [RW]Buffer와 [RW]StructuredBuffer 리소스 타입을 지원하며, 곧 [RW]ByteAddressBuffer도 지원할 예정이다. 또한 HLSL 내장 함수(intrinsic functions)에 대한 지원도 계속 확장하고 있다. 이제 막 그래픽스 셰이더 작업을 시작했으며, 여기에는 셰이더 입력/출력, 행렬 데이터 타입, 텍스처 리소스 등 다양한 기능 지원이 포함될 예정이다.

현재 우리가 추진 중인 작업의 대부분은 DXC와의 기능 동등성(feature parity)을 맞추기 위한 것이다. 하지만 DXC를 넘어 의미 있는 개선을 이루기 위해 투자하고 있는 몇 가지 영역을 강조하고 싶다.^[각주:1]

더 나은 루트 시그니처 진단 기능

올해 Clang에 새롭게 구현된 매우 인상적인 기능 중 하나는 새로운 루트 시그니처 파서이다(이 작업을 진행한 Finn Plummer에게 감사의 인사를 전한다). 루트 시그니처에 대해서는 여러 이유로 많은 불만이 제기되어 왔는데, 그중 하나가 바로 기묘한 문법 파싱 방식이다. 장기적인 루트 시그니처 개선 방안은 아직 로드맵에 포함되어 있지 않지만, Clang의 새로운 파서는 상당히 훌륭하며, 우리 팀이 얼마나 품질에 중점을 두고 있는지를 잘 보여준다.

이번 작업의 핵심 목표 중 하나는 루트 시그니처 파서에서 나오는 진단 메시지를 최대한 정확한 소스 위치 정보와 함께 제공하는 것이었다. 즉, 루트 시그니처에 오류가 있을 경우, 파서가 가능한 한 많은 정보를 제공하여 오류를 쉽게 찾을 수 있도록 하는 것이다. 이를 위해 새로운 루트 시그니처 파서는 Clang의 파싱 유틸리티, 소스 위치 추적, 진단 시스템을 활용하게된다. 그 결과, DXC에서는 제공할 수 없었던 정확한 소스 위치 기반 진단을 Clang에서는 제공할 수 있게 되었다.

예를 들어, 다음과 같이 루트 시그니처가 지정된 경우 :

#define BasicValidation \
  "StaticSampler(s0, maxAnisotropy = 13)," \
  "StaticSampler(s1, maxAnisotropy = 17)," \
  "StaticSampler(s2, maxAnisotropy = 13)," \
  "StaticSampler(s3, maxAnisotropy = 13)," \
  "StaticSampler(s4, maxAnisotropy = 23)," \
  "StaticSampler(s5, maxAnisotropy = 13)"

DXC는 다음과 같은 진단을 제공하며, 이때 소스 위치는 실제 오류가 있는 지점이 아니라 전처리기 지시문이 시작된 줄을 가리킨다.

<source>:40:9: error: root signature error - Static sampler: MaxAnisotropy must be in the range [0 to 16]. 17 specified.

Clang의 새로운 파서는 매크로 정의 내부의 구체적인 위치를 포함해 훨씬 더 많은 문맥 정보를 제공한다.

<source>:42:4: error: value must be in the range [0, 16]
   42 |   "StaticSampler(s1, maxAnisotropy = 17)," \
|    ^
<source>:45:4: error: value must be in the range [0, 16]
   45 |   "StaticSampler(s4, maxAnisotropy = 23)," \
|    ^
2 errors generated.

Clang이 하나가 아니라 두 개의 오류를 출력한 것을 알 수 있을 것이다. 이것은 DXC의 파서와 Clang의 파서 사이의 또 다른 중요한 차이점이다. DXC 파서는 처음 발견한 오류에서 즉시 중단한다. 따라서 루트 시그니처에 여러 오류가 있는 경우, 하나를 수정한 뒤 셰이더를 다시 컴파일해 다음 오류를 확인하는 과정을 반복해야 한다. 반면 Clang의 새로운 파서는 가능한 한 파싱 오류로부터 복구하고, 한 번의 처리로 더 포괄적인 진단 정보를 제공하기 위해 파싱을 계속 시도한다.

Clang 파서의 견고함과 오류 복구 능력을 보여주기 위해, 때로는 같은 절 안에 여러 오류가 포함된 다음과 같은 루트 시그니처를 살펴보자.

#define Recovery \
  "CBV(b0, reported_diag, flags = skipped_diag)," \
  "DescriptorTable( " \
  "  UAV(u0, reported_diag), " \
  "  SRV(t0, skipped_diag), " \
  ")," \
  "StaticSampler(s0, reported_diag, SRV(t0, reported_diag)"

이 루트 시그니처에 대해 DXC의 파서는 다음과 같은 진단을 제공한다.

<source>:63:9: error: root signature error - Unexpected token 'reported_diag'
#define Recovery \
^

반면 Clang의 새로운 파서는 한 번의 처리로 여러 오류를 식별한다.

<source>:64:12: error: invalid parameter of CBV
   64 |   "CBV(b0, reported_diag, flags = skipped_diag)," \
|            ^
<source>:66:14: error: invalid parameter of UAV
   66 |   "  UAV(u0, reported_diag), " \
|              ^
<source>:69:22: error: invalid parameter of StaticSampler
   69 |   "StaticSampler(s0, reported_diag, SRV(t0, reported_diag)"
|                      ^
<source>:69:45: error: invalid parameter of SRV
   69 |   "StaticSampler(s0, reported_diag, SRV(t0, reported_diag)"
|                                             ^
4 errors generated.

Clang의 파서는 파싱 문맥이 불완전할 수 있기 때문에 항상 모든 오류를 감지할 수 있는 것은 아니지만, DXC의 파서보다 훨씬 더 나은 성능을 보인다.

우리는 이러한 삶의 질 향상이 Clang을 사용자들에게 훨씬 더 나은 도구로 만들어줄 것이라고 믿으며, 이러한 품질 중심의 개선이 실제로 구현되고 있다는 점에 매우 기대하고 있다. 위의 두 예시는 Finn이 만든 Compiler Explorer 데모에서 가져온 것으로, Clang과 DXC의 진단 차이를 매우 잘 보여준다. 더 많은 예시는 해당 데모를 직접 살펴보고 계속 실험해보길 바란다.

오프로드 테스트 스위트

또 다른 큰 투자 영역은 테스트 인프라이다. DXC의 셰이더 실행 테스트 인프라는 Windows에서의 DirectX만 지원하는데, 이는 HLSL을 점점 크로스 플랫폼 언어로 바라보고 있는 상황에서 상당히 큰 제약으로 작용한다. 또한 이 인프라는 DXC에 매우 밀접하게 결합되어 있어 Clang과 함께 사용하기가 쉽지 않다.^[각주:2]

이러한 제약을 해결하기 위해 우리는 LLVM에 Offload Test Suite라는 새로운 테스트 인프라를 구축했다. 이 새로운 인프라는 일부 유틸리티에서 LLVM에 의존하지만, 테스트 실행 자체는 컴파일러와 소스 언어로부터 분리되어 있어 동일한 테스트를 DXC와 Clang 모두에서 실행할 수 있다. 또한 이 인프라는 DirectX, Vulkan, Metal을 지원하여 폭넓은 테스트 커버리지를 제공한다.

우리는 이 새로운 인프라를 활용해 Clang 컴파일러 구현에 대한 테스트를 확장하는 동시에, Clang으로 컴파일한 셰이더가 DXC로 컴파일했을 때와 동일하게 동작하는지 확인하고 있다. 이를 통해 사용자들이 보다 원활하게 전환할 수 있기를 기대한다.

이 인프라에 대해 더 알고 싶다면, 나는 지난가을 LLVM Developer Meeting에서 이에 관한 발표를 진행했으며, HLSL 팀이 이를 어떻게 워크플로에 통합했는지도 소개했다.

HLSL 표준화!

참고: 나는 HLSL 표준화에 대해 DirectX 블로그에 글을 썼다. 좀 더 “공식적인”(유머도 개성도 밈도 없는) 버전을 읽고 싶다면 그쪽을 참고하라. 그렇지 않다면 마음 단단히 먹고 따라오라!

2026년을 맞으며 HLSL에서 가장 기대하고 있는 변화는 HLSL을 표준화하기 위한 위원회 구성 절차를 시작했다는 점이다. 나는 오픈소스 소프트웨어를 중심으로 커리어를 쌓아왔고, 어떤 종류의 소프트웨어는 결코 독점적이어서는 안 된다고 깊이 믿고 있다. HLSL이 계속 발전하고 번영하기 위해서는 표준화로 나아가는 길이 유일한 해법이라고 생각한다. 여러 번 말해왔지만, 여기서 다시 강조하겠다. HLSL의 미래는 크로스 플랫폼이며 오픈이다.

이는 개인적으로도 매우 큰 노력의 과정이었다. Microsoft 내부에서 공감대를 얻는 한편, 업계 전반에 걸쳐 파트너십을 강화하기 위해 힘써왔다. Microsoft가 가진 몇 가지 평판을 극복하기 위해 노력하고 있으며, 우리가 이 일에 진지하다는 신호를 보내기 위해 나 자신의 평판도 상당 부분 걸었다.

왜 이런 일을 하는가?

내 경험상, 컴파일러와 프로그래밍 언어는 지나치게 복잡한 데 비해 기업이 충분한 인력을 투입해 오픈소스 대안과 경쟁할 수 있을 만큼의 품질과 규모로 독자적인 컴파일러를 개발·유지할 만큼의 차별화 가치를 제공하지 못한다. 이러한 점은 C++처럼 복잡한 언어에서 특히 두드러지며, HLSL 역시 그 방향으로 점점 나아가고 있다.

컴파일러 그까이꺼 얼마나 해? 10불??

HLSL에 대한 인력 부족은 우리 팀에 매우 큰 문제였다. 우리는 새로운 셰이더 모델 기능을 지속적으로 공개해야 한다는 막대한 압박을 받아왔지만, 새로운 하드웨어 기능을 노출하는 동시에 사용자의 생산성을 높이기 위해 HLSL 자체를 발전시킬 만큼 충분히 큰 팀을 가져본 적이 없다. 그 결과 여러 단기적인 결정들이 이어졌다. 우리는 지름길을 택했고 막대한 기술 부채를 떠안게 되었는데, 그중 가장 대표적인 사례는 DXC가 10년도 더 지난 LLVM 3.7에 묶여 있다는 점이다.

LLVM 3.7 : C++ 14 초기 수준, 옛 패스 매니저(legacy pass manager), 벡터화/루프 최적화/인라이닝 등의 알고리즘이 구식, 최신 GPU/CPU 아키텍처에 대한 고려 부족. 10년 넘음... .

냉정한 진실은, 훌륭한 프로그래밍 언어와 컴파일러는 어떤 플랫폼이 갖춰야 할 기본 요건일 뿐, 그것만으로 더 많은 하드웨어나 소프트웨어 라이선스를 판매하게 만들지는 않는다는 점이다. 그렇다고 해서 품질이 나쁜 언어와 컴파일러가 문제가 되지 않는 것은 아니다. 오히려 그것들은 개발자들에게 과도한 부담을 주어 양질의 소프트웨어를 출시하는 능력을 저해하고, 이는 결국 매출에 부정적인 영향을 미친다.

나는 아직 HLSL 컴파일러가 심각한 부담이 될 만큼 낡고 “나쁜” 상태라고 보지는 않지만, 그런 방향으로 가고 있는 것은 분명하다. 따라서 이를 반드시 바로잡아야 하며, 그 과정에서 HLSL의 개발 모델을 보다 지속 가능하고 합리적인 자원 투자 구조로 전환해야 한다.

이 모든 비즈니스식 표현을 한마디로 정리하면 이렇다. 오픈소스를 수용하고, 폭넓은 파트너십을 구축하며, 건강한 커뮤니티를 만들자는 것이다.

표준이 사용자에게 어떤 이점을 제공하는가?

HLSL 자체의 발전과 고품질 툴체인 기능에 충분히 투자하지 못했던 점은 업계에 오래 지속된, 때로는 해결 불가능해 보였던 여러 문제를 낳았다. 그 대표적인 사례가 셰이더 빌드 파이프라인의 복잡성이다.

크로스 플랫폼 애플리케이션의 CPU 코드를 빌드할 때는 일반적으로 애플리케이션 로직의 대부분을 동일한 언어(그리고 종종 동일한 컴파일러)로 처리할 수 있다. 예를 들어 Windows, Linux, macOS, Xbox, PlayStation, Nintendo용 게임을 개발한다면 CPU 코드는 C나 C++로 작성하고 Clang을 컴파일러로 사용할 수 있다. 물론 일부 플랫폼 특화 코드는 존재하겠지만, 대부분의 코드는 쉽게 공유 가능하다. 그러나 GPU 프로그래밍에서는 반드시 그렇지 않다.

Khronos Group은 구성원과 커뮤니티를 통해 GPU 프로그램을 위한 크로스 플랫폼 파이프라인을 구축하는 데 놀라운 성과를 이루어냈지만, 그 구조는 매우 복잡하다. Khronos의 SPIR-V 생태계 다이어그램을 내가 약간 수정해 DirectX를 추가한 그림을 생각해보라.

왼쪽에는 선택할 수 있는 소스 언어가 매우 다양하고, 오른쪽에는 실행할 수 있는 대상 런타임이 매우 많다는 점은 인상적이다. 문제는 그 사이에 존재하는 (정보 손실이 발생하는) 번역 단계가 너무 많다는 것이다. 특히 SPIRV-Cross는 많은 셰이더 빌드 파이프라인에서 핵심적인 역할을 하고 있지만, 디버그 정보(최종 실행 코드와 원본 소스 라인의 매핑)를 파괴해 버린다. 그 결과 셰이더 디버깅과 프로파일링이 극도로 어려워진다.

이러한 생태계 구조는 통합된 툴링의 부재에서 비롯된 것이며, 그로 인해 크로스 플랫폼 게임 엔진들은 각자 복잡한 셰이더 빌드 파이프라인을 구축하게 되었다. 나는 이 분야에서 오랫동안 일해왔지만, 개발자들이 실제로 자사 타이틀의 셰이더를 어떻게 빌드하는지 들을 때마다 여전히 경악하게 된다.

AAA급 엔진의 셰이더 빌드 파이프라인은 생산성을 유지한다는 명목 아래 모두가 감수해온 복잡한 루브 골드버그 장치^[각주:3]와 같다. 이 문제를 해결한다고 해서 Microsoft가 Xbox나 Windows 라이선스를 더 많이 판매하게 되는 것은 아니기 때문에, 그동안은 이 문제가 방치되어 왔다. 하지만 이제는 다르다.

현재 우리는 DXC와 Clang을 사용해 DirectX와 Vulkan용 셰이더를 빌드하는 HLSL 네이티브 빌드 파이프라인을 이미 보유하고 있다. 또한 Metal에 대해서도 비교적 네이티브에 가까운 경로를 갖추고 있는데, 이는 IR에서 IR로 변환하는 Metal Shader Converter를 통해 가능하다. 이 도구는 정확한 디버그 정보를 유지하며, Apple의 네이티브 셰이더 디버깅 및 프로파일링 도구와 함께 HLSL을 사용할 수 있게 해준다(정말 인상적인 성과다!).

내 진심 어린 바람은 HLSL을 Clang에 통합하는 작업과 병행해 표준화를 추진함으로써, 크로스 플랫폼 지원, 고품질 툴링, 언어 진화를 우선시하는 폭넓은 커뮤니티를 HLSL 중심으로 구축하는 것이다. 우리의 궁극적인 목표는 업계 전반의 파트너십을 형성해 모든 HLSL 사용자가 최고의 툴링을 누릴 수 있도록 하는 것이다.

애플, 소니, 닌텐도 여러분, 함께하자!

표준 위원회가 있으면 일이 느려지지 않나?

대화를 나눌 때 나는 HLSL이 앞으로 어떻게 발전하길 바라는지를 설명하기 위해 종종 “신중한(deliberate)”이라는 표현을 사용한다. 돌이켜보면, 우리는 새로운 기능의 단기적·장기적 영향을 충분히 숙고하도록 요구하는 틀 없이, 언어를 다소 즉흥적으로 발전시켜온 측면이 있다. 어떤 때는 지나치게 느리게 움직였고, 또 어떤 때는 너무 빠르게 움직였다. 그 결과 유용한 기능 측면에서는 뒤처지면서도, 품질 또한 충분히 확보하지 못하는 상황이 발생했다. 대표적인 사례로, HLSL 2021은 기능 추가보다 버그를 더 많이 만들어냈고, 우리는 그 문제들을 해결하는 데 몇 년을 보내야 했다.

나는 표준 절차를 도입하면 HLSL에 추가(또는 제거)되는 기능에 대해 보다 신중하고 숙고된 접근을 하도록 만드는 구조 안에서 언어를 발전시킬 수 있다고 믿는다. 이 과정은 때로는 그 절차가 없을 때보다 느릴 수 있고, 다른 경쟁 언어들보다 느릴 수도 있다. 하지만 그 대신 더 높은 품질의 결과를 만들어낼 것이며, 그것이 모두에게 최선이라고 생각한다. 또한 국제 표준화 기구 아래에서 이를 추진함으로써, 우리 스스로를 객관적으로 점검하고 성급하고 결함 있는 결정을 내리려는 본능을 억제할 수 있는 틀을 갖게 될 것이라고 본다.

나는 프로그래밍 언어나 컴파일러에서 “빠른 혁신(rapid innovation)”이라는 말을 들으면 불편함을 느낀다. 물론 빠른 혁신이 사용자에게 도움이 되는 소프트웨어 분야도 있다. 그러나 사람들이 의존하는 인프라 소프트웨어는 “빠르게 움직이고 문제는 나중에 고친다(move fast and break things)”는 모델과는 맞지 않는 수준의 안정성과 신뢰성을 요구한다.

누구도 실험적인 도구를 핵심적인 역할로 프로덕션 코드베이스에 통합하고 싶어하지는 않을 것이다. 이와 같은 맥락에서, HLSL 사용자들 역시 오늘 작성한 코드가 미래에도 예상대로 동작하길 바랄 것이라고 생각한다. 우리가 할 수 있는 최악의 일은 사용자와 그 영향에 대한 고려 없이 HLSL의 의미론에 근본적인 변화를 가하는 것이다. 표준 절차는 사용자들이 목소리를 낼 수 있는 장을 제공하고, 우리가 미래를 향해 HLSL을 발전시키는 과정에서 스스로를 점검할 수 있는 틀을 제공할 것이다.

그렇다면 실제로 어떻게 진행되는가?

Ecma International 산하에 새롭게 구성된 기술 위원회 57(Technical Committee 57)은 HLSL 핵심 언어의 명세화와 표준화를 담당하게 된다. 초기에는 핵심 동작(문법, 기본 데이터 타입, 변환 규칙, 오버로드 해석 등)과 모든 API 대상에 공통적으로 적용되는 제한된 범위의 기능에 초점을 맞출 예정이다.

위원회가 발전해 나감에 따라, HLSL을 더 나은 언어로 진화시키는 동력을 제공하는 동시에 Microsoft 플랫폼에 종속되지 않는 크로스 플랫폼 표준으로 확립하는 역할을 하게 되기를 기대하고 있다.

위원회는 거의 전적으로 공개적으로, 그리고 GitHub 상에서 운영될 예정이지만, 회의 자체는 Ecma 회원과 초청된 전문가에게만 공개된다. 우리는 모든 분들이 우리의 공개 작업을 지켜보고 표준화 과정에 기여해주기를 바란다.

뉴럴 렌더링

이제 “뉴럴 렌더링” 이야기를 더는 미루기 어렵겠으니 그냥 꺼내보겠다. 개인적으로 나는 이 용어를 싫어한다. 컴파일러와 언어 관점에서 보면 “뉴럴 렌더링”은 다른 신경망 연산과 본질적으로 다르지 않으며, 결국은 거대한 다차원 행렬에 대한 선형대수 연산에 불과하다는 점을 계속 설명해야 하기 때문이다. 하지만 뭐 어쩌겠는가, 나는 그저 고함치는 늙은이일 뿐이다.

지난해부터, 그리고 현재까지도 신경망 연산과 관련해 상당히 큰 작업을 진행해왔다. 작년에는 렌더링 및 컴퓨트 워크로드에서 소규모 신경망 평가를 가능하게 하는 D3D12 Cooperative Vector 기능의 프리뷰를 공개했다. 하지만 가을에 많은 고민 끝에 이 기능이 아직 정식 도입을 하기에 충분히 성숙하지 않았다고 판단했다. 이후 우리는 Cooperative Vector의 기능은 물론, 2023년에 프리뷰했지만 SM 6.8에 포함되지는 않았던 Wave Matrix의 보다 발전된 대체 기능을 개발하는 데 적극적으로 힘써왔다.

새로운 기능은 다소 밋밋하게도 Linear Algebra(줄여서 LinAlg)라고 이름 붙였으며, Cooperative Vector와 Wave Matrix의 기능을 모두 포함한다. 또한 이 기능을 다른 API(즉, Vulkan)와 보다 긴밀히 정렬되도록 설계해, 장차 HLSL을 통해 Vulkan과 DirectX 양쪽에서 사용할 수 있도록 했다(Apple이 보조를 맞춘다면 Metal에서도 가능할 수 있다). 이는 Windows 환경의 브라우저에서 WebGPU가 제안한 Subgroup Matrix 기능을 구현하는 데에도 활용될 수 있을 것이다.

GenAI나 LLM에 대해 어떻게 생각하든지(나는 회의적인 편이다), 신경망이 그래픽스 프로그래밍에서 점점 더 많은 유용한 응용을 갖고 있다는 점은 분명하다. 텍스처 압축, 라디언스 캐싱, 패스 트레이싱, 디노이징, 업스케일링 등 신경망을 활용하려는 움직임이 활발하다. 이러한 모든 응용 분야에서 중요한 것은 HLSL이 이러한 알고리즘을 효율적으로 하위 수준으로 변환(lowering)할 수 있어야 한다는 점이며, 그래야 셰이더 작성자가 최신 GPU 하드웨어의 성능을 최대한 활용할 수 있다.

내가 특히 기대하는 부분은 신경망이 복잡한 함수를 근사할 수 있는 능력이다. 몇 년 안에 행렬 곱셈 및 누적 연산 전용 하드웨어가 저가형 GPU까지 확산되고, 설치 기반 전반에 보급된다면, 함수 근사는 낮은 사양의 하드웨어에서도 허용 가능한 프레임 속도로 더 높은 수준의 렌더링 품질을 구현하는 데 유용한 기법이 될 수 있다.

맺으며

여기까지 읽었다면 축하한다. 꽤 장황하게 이야기했으니 여기서는 길게 붙잡지 않겠다. 위에서 길게 설명한 내용에 이미 담겨 있지만, 2026년에 내가 HLSL에서 특히 밀고자 하는 몇 가지 핵심 주제를 분명히 정리해보겠다.

크로스 플랫폼과 오픈

HLSL의 미래는 크로스 플랫폼이며 오픈이다. 이는 오픈소스를 의미하고, 로열티 프리 특허 및 지식재산 정책을 갖춘 공개 명세를 의미한다. 그리고 전 세계 누구로부터든 기여를 환영한다는 뜻이다.

품질, 품질, 그리고 품질

우리는 속도나 화려함을 위해 품질을 희생해서는 안 된다. 지름길을 택하거나 느슨한 품질 기준을 적용했다가 여러 차례 대가를 치러왔고, 그 피해는 결국 사용자에게까지 이어졌다. 컴파일러 구현이든, 새로운 기능 설계든, 초안 단계의 언어 명세든, HLSL과 관련된 모든 영역에서 더 높은 품질 기준을 확립하기 위해 우리는 많은 노력을 기울여왔다. 앞으로도 이러한 품질에 대한 투자를 지속할 것이며, 그 과정에서 우리를 객관적으로 점검해줄 커뮤니티와 함께해 나갈 것이다.

HLSL은 사용자를 위해 존재한다

HLSL이 가치 있는 기술인 이유는 그것이 널리 사용되고 있기 때문이다. 우리는 사용자와 적극적으로 소통하고, 그들의 피드백에 응답하며, 그들의 우려 사항을 우선순위에 둘 것이다. 물론 모든 개별 사용자의 요구를 그대로 수용할 수는 없다. 전체 사용자 기반을 아우르는 보다 종합적인 관점이 필요하기 때문이다. 그러나 우리의 중심 동기는 언제나 사용자들이 생산적으로 일할 수 있도록 돕고, 우리의 도구를 활용해 그들의 애플리케이션을 최상의 수준으로 만들 수 있도록 지원하는 데 있어야 한다.

여기서 이야기하는 Clang은 LLVM 프로젝트의 C/C++ 계열 컴파일러 프론트엔드를 이야기 하는 것으로
- LLVM : 다양한 언어를 위한 컴파일러 인프라(백엔드 + 최적화 프레임워크)
- Clang : LLVM을 사용하는 C, C++, Objective-C 등의 프론트 엔드 컴파일러
- DXC : Microsoft의 기존 HLSL 컴파일러(DirectX Shader Compiler)

최근 Microsoft와 Google은 HLSL을 Clang 기반으로 구현하고 있으며, 기존 DXC처럼 별도의 전용 컴파일러가 아니라:Clang의 파서, 진단 시스템, 타입 시스템 등을 활용해 HLSL을 하나의 정식 언어 프론트엔드처럼 통합하려는 시도를 진행중이다. 이런 형태로 진행이된다면 Clang의 진단 시스템을 그대로 활용할 수 있는 장점이 있다.(HLSL을 차세대 컴파일러 인프라(LLVM/Clang)에 통합하려는 프로젝트) [본문으로]
여기서 말하는 Test Suite는 일종의 테스트 묶음으로 이해하면 된다 [본문으로]
Rube Goldberg는 20세기 초 미국의 만화가. 아주 단순한 일을 하기위해 지나치게 복잡한 프로세스를 가진 장치나 절차를 풍자함 [본문으로]

2025 TA Campus 수업 문서 링크

illu_yun — Tue, 20 Jan 2026 15:40:43 +0900

과제수행해주신 내용들도 좋은데 그거까지 넣음 넘 링크가 많아질듯해서 여기까지만......

GV70 26년식 짧은 후기

illu_yun — Sun, 30 Nov 2025 23:46:31 +0900

차 받고 대략 3주정도 지난 시점에서 800km 정도 타고 다녔는데 몇가지 느끼는 점들을 써본다.

제일 기분좋은건 차 올때까지 기다리는거.... 제네시스 따로 할인이 없어서 카드 캐쉬백 조금 받는걸로 하고 일시불로 결재....

홍대에서 차를 인도 받고 집까지 몰고 왔는데, 도로주행 시험칠때 말곤 도로에서 운전을 안해봐서 걱정이 많았다. 그런데 집까지 운전해서 가지고 와보니 할만했다.(20대때 바이크 몇년 몰아본게 시험칠때도 그렇고 꽤나 도움이 됐던..... 도로주행 연수를 받을까 계속 고민했는데 시간도 안맞고 출퇴근 해보니 할만해서 요샌 그냥 몰고 다닌다. 주차는 여전히 어렵다만.... 회사 주차장은 할만하고 집이 문제)

26년식이 되면서 후면 배기구가 뒤로 안 뚫리고 아래로 향하는 구조로 바뀌고 차량 모델명, 2WD-AWD 표기 자체가 없어졌다. 깔끔해보여서 이건 나름 만족중. 색상은 우유니화이트로 했는데 26년식에 추가된 베링블루도 괜찮겠다 싶다.

인터넷에 도는 사진 퍼왔는데 요런 느낌. 좀 유니크한 색상이라 맘에 든다.

옵션은 외장은 하나도 안하고 기본에 휠도 18인치 기본휠(이게 연비가 젤 좋단다). AWD를 할지 고민좀 했는데 그냥 이것도 2륜으로.(참고로 GV70은 FR). 파노라마 선루프^[각주:1]만 추가 했다.

내장옵션은 시그니처 디자인 셀렉션 I 프로즌 그레이(이거때문에 이차 샀다. I이 170만원 추가고 II가 300만원 추가인데 나파가죽이 좋긴한데 오염이나 관리가 힘들어 보여 야외 주차를 해야하는 상황이라 안했다). 파퓰러 패키지1(26년식에서 옵션이 변경되었다. 2열 컴포트가 빠지고 드라이빙 어시스트 I + HUD였나?) +2열 컴포트 패키지 + 빌트인 캠. HUD(Head Up Display)를 할지 말지 고민을 좀 했는데 모두가 다 하라고 해서 넣었는데 대만족 중이다. 하고나서 아쉬운건 컨비니언스 패키지가 좋아보이긴 하는데.... 가끔 동승하는 부서원들이나 지인들 보면 2열 컴포트 넣긴 잘했나 싶기도 하고....

시트 커버는 청바지, 블랙진 주로 입는 내입장에서 밝은 가죽은 이염은 무조건 생긴다고 생각하고 바로 주문했다. 아임반 방석+콘솔커버, 시트 후면커버 3가지. 시트 뒷면이 원래 브라운으로 되어있는데 그레이로 통일 하는게 훨씬 이쁜듯. 겸사겸사 더러워지는거 신경안써도 되고...

그외 소소하게 알리에서 악세사리 주문해서 몇개 넣어줬다(컵홀더 받침대)

개인적으로 가격대비 꽤 만족스러운 보조 손잡이 커버

지현님이 선물해준 방향제

드레, 정미니 선물 방향제. 이렇게 총3개

샤오미 마그네틱 거치대. 이거 생각보다 잘 잡아준다. 근데 힘을 좀만 세게 주니 부러질거 같은...

센터페시아 조작패널 마감은 하이그로시라고 하는데 저 기어패널쪽 부분이 손떼가 금방 탄다. 자주 조작하는 부위이기도 하고. 좀 써보다가 이대로는 안되겠다 싶어서 인터넷에서 필름 주문해서 붙였다(카본 패턴). 이거 붙여주니 훨씬 관리하기도 손에 촉감도 좋다.

그리고 연비..... 출퇴근 평균 50km내외인데 약 6~8km/l 정도 나온다... 연비는 정말 기대하면 안되는 차인듯... 고속 주행조금 하면 10km 가깝게 나오는데 강변북로 주로 타는 아침 저녁 출퇴근때는 답이 안나온다.

눈, 비올때는 조심 또 조심...

승차감은 꽤나 편하다. 2열에 타본 지인들도 승차감은 만족하는중. 제일 큰건 2열 시트가 뒤로 좀 넘어가는게 큰 듯하다(나도 사기전에 센터장님꺼 타보고 생각보다 뒷자리 괜찮은데? 싶어서 샀던것도 있다) 지하철과 자차 출근시 몸이 느끼는 피로도는 확실히 차가 몸이 좀 더 편하다.

운전은 어라운드뷰, 차선 유지장치, 자세제어장치, HUD, auto hold, 사이드미러 카메라가 들어있어 꽤나 운전하기 편하다. 특히, 순정 네비도 꽤 쓸만하고 HUD에 보여주는 정보량이 차이가 나서 그냥 순정 네비 사용중.(Android Auto 연동해서 다른거 써보니 순정네비보다 자세하게 안나온다)

HDA(Hyundai Driving Assist) 아침 저녁으로 잘 써먹고 있다

저녁에 키를 가지고 접근하면 웰컴 라이트 띄워주는것도 꽤맘에 드는 부분.(내리고 탈때 시트 포지션 움직이는것도 좋다)

역시 차량 인테리어는 밝은톤이 내취향인듯.

앰비언트 라이트는 바이올렛은 기본톤으로 설정하고 경고할때 붉은색으로 바뀐다. 요게 눈도 편하고 퍼스널 컬러랑도 맞아서 좋은듯

아직까지는 주차하다가 사이드 미러 살짝 긁은거 말곤 긁지 않고 잘 버티고 있다.

회사 주차장은 주차하기 편하다. 정말...

덧 : 제네시스 혜택은 5년간 소모품 교환 쿠폰, 그리고 프리빌리지 선택(워커힐 숙박권 받을예정), 제네시스 멤버쉽 이정도다(가죽 키 케이스랑 담요 줌)

꽤 넓게 열린다. 2열에선 이게 꽤나 맘에 드는 모양 [본문으로]

Shader interpolation modifier

illu_yun — Fri, 29 Aug 2025 13:53:02 +0900

Unity Live 25년 8월꺼 보다가 재밌어 보여서 정리
링크 : https://www.youtube.com/live/ZOlOnXWYQvk?si=yxGyJsz5zDklL-cl

Shader Graph Custom Interpolators라는 항목이 새로 들어왔는데 이는 보간기(interpolator)의 보정 설정을 지정할 수 있는 명령이다.
https://docs.unity3d.com/Packages/com.unity.shadergraph@13.1/manual/Custom-Interpolators.html

이렇게 Shader Graph Block에서 VS 끝에 노드를 생성하는 방식으로 설정

이렇게 Custom interpolator에서 우클릭을 통해 설정할 수 있다. 6.3부터 지원

그럼 HLSL에서는 어떻게 컨트롤 하느냐...
MSDN 문서 : https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-struct?utm_source=chatgpt.com

총 5가지의 보간기 키워드를 지원한다.

linear (기본값) : 원근 보정된 선형 보간 (perspective-correct interpolation)
noperspective : 원근 보정 없는 선형 보간
centroid : 삼각형의 내부에서만 샘플링 보장
nointerpolation : 보간 없이, 가장 가까운 정점 값을 픽셀 셰이더로 전달
sample : 멀티샘플링(MSAA) 시 샘플 지점 기준으로 보간. Shader model 4.1 이상에서만 사용 가능. 픽셀 중심이 아닌 샘플 위치에서 보간.

* int/uint 타입을 사용할 때 유일하게 유효한 키워드는 "nointerpolation" 만 가능

struct v2f
            {
                float4 pos : SV_POSITION;

                //일반 보간 (기본값, perspective-correct)
                float3 normal : NORMAL;

                // 원근 보정 없는 보간
                noperspective float3 normal : TEXCOORD0;

                //보간 없이 가장 가까운 정점 값 사용
                nointerpolation float3 normal : TEXCOORD1;
            };

저런 엣지가 두드러지는 스타일의 아트를 만들때 고려해봄직한 방식.

MSAA를 사용할때 centorid와 sample 보간 방식이 유용할 수 있다고 하는데 이는 픽셀 커버리지와 샘플링 위치간의 미묘한 차이 때문이다.

하나의 픽셀 안에 MSAA 샘플이 여러 개 있음
하지만 보간된 데이터는 기본적으로 픽셀 중심에서 계산됨 → 샘플 위치와 보간 위치가 다름

이로 인해 픽셀 가장자리(에지) 근처에서 아티팩트가 생길 수 있고 이를 보간 키워드를 통해 완화할 수 있다.

Modifier	동작방식	언제 유용한가?	특징
centroid	픽셀 내부에서 커버되는(coverage) 유효한 샘플들의 평균 위치를 기준으로 보간	픽셀 경계에 보간 문제가 생길 때 (특히 알파 테스트, 마스크 등 사용 시)	클리핑 오류 방지
sample	MSAA 샘플 위치마다 각각 보간된 값을 사용	MSAA가 활성화되어 있고, sample shading이 필요한 고급 효과에서	더 높은 정확도, 성능 부담 증가

Cutout/AlphaTest 셰이더에서 경계가 깨질 때
Deferred Rendering + MSAA 조합 시 (G-buffer 에러 방지)
MSAA 환경에서 셰이딩 위치에 민감한 값(normal, UV, tangent 등)을 사용할 때

그외 위 같은 상황에 유용할 수 있다.(하지만 애시당초 고해상도에서 MSAA 사용하는것 자체가 비용이.......)

sample 키워드의 경우 SV_SampleIndex와 함께 쓰면, 각 MSAA 샘플마다 다른 보간 값을 받아 정확한 결과를 얻을 수 있지만, 성능이 크게 떨어져서 대부분의 경우 centroid로 충분.

ChinaJoy 2025

illu_yun — Wed, 20 Aug 2025 01:15:44 +0900

매우 급하게 결정된 출장. facebook에는 매일 대략의 경험을 공유했지만 한번 몰아서 정리.
업무상 진행된 내용은 공유하지 못하겠지만 그외에 9년만의 상하이는 꽤나 신선했다. 사우나조이라 불렸던 차이나조이도 요새는 많이 좋아졌다고 해서 중국쪽 개발동향도 궁금했었고...

아래는 링크 기사에 나온 내용중에 상해 날씨에 대한 이야기...

■ ‘사우나조이’, 악명 높은 상하이의 날씨는?
상하이가 얼마나 덥냐고 물어보는 사람들에게 하는 대답이 있다. “눈을 감고, 네가 지금까지 살면서 가장 더웠을 때를 떠올려봐. 거기에다가 습기를 10배 더하고, 온도를 10도 가량 높여. 그게 바로 상하이야”고 말이다.

https://www.gametoc.co.kr/news/articleView.html?idxno=20586
https://www.inven.co.kr/webzine/news/?news=161071

여튼 기대반 두려움반을 안고 상하이로 이동....(그전에 급하게 출장준비에 TA Campus 마무리에 굉장히 정신없었어서 어떻게 갔는지 기억도 안난다...ㅎ)

모닝캄 라운지 바우처가 이번달 마감이라 3장 남은거중에 두장을 이번에 쓰고 한장은 결국 날리게 됐다. 뭐 sky sky priority pass도 있고 법인카드도 일년에 두번은 라운지 쓸 수 있어서 딱히 라운지 이용 못해서 불편한건 없을듯..

뭔가 마계의 도시 같은 느낌의 하늘

가까워질수록 왠지 LA 갈때랑 비슷한 인상을 받았다. 생각해보니 상해로 중국 들어가는건 또 처음이네...까오티엔으로 상해로 와서 나간적은 있어도..

상하이 도시 사이즈는 한국 6배 정도라는데 수도권 전체랑 비교하면 또 그정도 차이는 아니라 하지만 최소 2~3배 정도는 큰 것 같았다.

한국도 역대급으로 더웠기에 상해도 덥겠구나 했지만 상상 그 이상을 맛보게 된다.(갈때는 그저 오랜만에 출국하는게 좋기만 했던...) 마침 작년부터 중국 단기 체류는 비자 면제가 되기도 했어서 여행갈까 했었기에 차라리 잘 되었다 싶었다.

중국 지하철은 난징이나 항저우, 상해 모두 비교적 오래되지 않아 매우 좋다.

마침 퇴근시간이고 상하이 도로 상태는 몇번 겪어본 바 지하철로 이동하기로 했다. 가격은 공항 >> 숙소까지 1인당 7위안인가 그쯤 했다(1RMB = 193원. 대략 1인당 1400원이 안된다). 근거리 이동 기본요금은 3위안으로 매우 저렴하다. 4위안 넘기기 쉽지 않음

googlemap 교통정보가 제공되지 않기 때문에(2015. 16년까지는 됐던거 같은데 여튼 안된다 !!) 고덕지도를 깔아봤는데 이거 생각보다 쓸만했다.

그리고 고덕지도, 알리페이, didi 앱도 설치하고 갔다(이제 이거3개 없이는 중국에서 움직이는게 거의 불가능하다고 보면 된다)

숙소는 SNIEC(Shanghai New International Expo Convention)에서 좀 떨어진 곳. 4성 맞나 싶긴 했지만 그래도 청결한 편이긴 한데 부대시설이 살짝 아쉬운 정도(가격 생각하면....). 보통 차이나조이에선 케리나 히말라야를 잡는데 방이 없었는지 여길 잡아줬다..... 그리고.. 20분을 걸어 다니는 사태가..

뭣보다 중국 최대 매력은 맛있는 먹거리들 ~

같이 출장온 차석님하고 간단히 저녁. 물가는 많이 올랐지만 서울이 그 사이 미친듯이 올라서 서울 물가의 아직 반도 안되는 느낌이다. (이렇게 우육면 + 양꼬치 + 사이드 해도두사람이 2만원 넘기기 쉽지 않다)

이틀차 일정은 업체 기술 미팅

일정이후에 오늘아니면 돌아다니기 어려울거 같아서 와이탄과 예원 일대를 돌아다녔다. 9년만인데 여전히 화려한데다 금요일 저녁이라 그런지 관광객이 미친듯이 많아서 움직이기도 힘들었다.

사람한테 치여서 걷는것 자체가 힘들었다.

그리고 3일차 ChinaJoy 참관. 이미 BTC 티켓은 매진이라 하루는 BTB, 하루는 BTC 둘러보기로 했다. (BTB가 한국이랑 비교해서 엄청 저렴해서 동향 파악겸 둘러보기로 했음)

입장은 따로 패스를 발급받는게 아닌 등록한 정보를 확인하고 여권 스캔후 안면촬영후에 입장이 진행된다. 지스타때 입장 대기열 생각하면 상당히 간소화된 느낌. 중국이 이런부분에서 디지털화가 상당히 잘 되어있다는걸 새삼 실감....

Unity China도 Jerry도 퇴사했었고 Ricahrd 정도 남아있을듯한데 Grow 부스만 있어 아는 얼굴이 안보였다. 아쉽지만 경품만 하나 챙겨서 이동.

공주 컨셉의 독특한 러시아 부스. 모바일 광고 플랫폼인거 같은데 소녀소녀, 공주공주했던 부스

지하철 역에서 나오면 이렇게 행사장 분위기가 느껴진다. 저기 무지막지하게 크다. 코엑스 전체 면적은 한 3~4배를 다 전시장으로 쓰는 느낌

BTB 전체 인상은 AI 관련해서 내용이 있음 좋겠다 싶었는데 그쪽보다는 비지니스 수익화, 광고쪽이 대부분이고 그외 신규 게임 퍼블리싱을 찾기위해 전시하거나 퍼블리싱 사업관련해 게임쪽은 거의 보이지 않았다..... 아쉽

저녁엔 텐센트 담당자 초대로 선상파티 참여. 실제로 배가 출항할줄 몰랐는데 두시간정도 황푸강을 따라 이동했다. 크루즈 위에서 보는 상하이 야경은 멋져서 여행온다면 타보는걸 추천~

바이주중 최고로 친다는 귀주모태주(마오타이) 한병에 82,999RMB 대충 1,600만원짜리. 1ml 32,000원..... 이걸 대형마트 진열장에서 판다... ㅎ...

4일차는 BTC를 둘러보게 되었다. 여긴 VIP패스를 끊어서(일반패스 2배 가격. 약 7만원)

BTB에 비해 사람이 엄청 많았는데 공간도 엄청 크니까 막상 들어가니 그래도 다닐만 했다. 오히려 지스타 한창 사람 몰릴때보다는 좀 여유가 있는 느낌....

명말 : 공허의 깃털 코스프레

일요일이라 그런지 걸그룹 행사가 많았다. 예전 걸스타 보는 느낌 ㅎㅎㅎ. 인플루언서도 많았고

카잔부스의 이 코스프레하시는분은 꽤 유명한 사람이였는지 사람이 엄청 몰렸었다.

검은신화 오공 이후로 중국 콘솔시장이 본격적으로 태동하는 느낌.

Phantom Blade Zero : https://youtu.be/ZX1k0z2pPY0?si=WIdyk9-bW08eSLaE
중국 무협 스타일 게임. 중국식 무협을 잘 구현했다는 느낌이다. 중국 영화에서 보던 연출같은데 액션에 잘 녹아있는 느낌. 요거 은근히 재미있을거 같단 느낌을 받았다.

Lost Soul Aside : https://youtu.be/0EKvNt4bijE?si=y4ceh8i1U6nKIqGk 몇년전에 언리얼4 인디로 꽤 유명했던 영상인데 투자를 받아서 본격적으로 개발을 진행했던 게임이다. 곧 출시를 앞두고 있는듯..... 파판 캐릭터 오마쥬라서 그런지 파판 캐릭터 인상이 강하다.

원피스 앰비션. 3:3 모바일에서 캐릭터 대전을 현장에서 진행했는데 나중에 봤던 킹오파 XV보다 이쪽이 더 재밌어 보였다. 모바일 대전 액션과 유명 IP 게임 연출이 꽤 인상적이였다. 중국에서만 출시한거 같은데 찾아보니 한국에서도 apk 파일구해서 꽤 하고 있나봄

한국게임은 붉은사막, 카잔, 데이브더 다이브 정도 출시

요런 보드게임 전시랑 행사도 있었고...

스냅드래곤 부스는 엄청 큰데 저게 왕자영요인가...?

한화로 약 5,000만원 정도인 스포티한 전기차. 타볼수 있었는데 한번 완충으로 720km 정도 주행가능하다고

샤오미랑 BYD 전기차 전시 부스도 있었다(속으로 게임쇼에 참 별게 다 있네 생각을...)
이거랑 별개로 금번에 중국에서 didi로 중국 전기차를 타보고 다들 중국 전기차에 대한 인상이 바뀌었다 하는데 나도 이부분에는 동감이다. 퀄이 너무 좋다.... 개인적으로 솔직히 많이 놀람... (샤오미, 화웨이, BYD )

그리고 부스 한쪽에서 전시중이였던 중국 인디 스팀게임들중에 눈에 띄던 것

Abyss Rebel : UE4. 이날 만났던 인디 업체중 유일하게 커뮤니케이션이 가능했다(영어가 조금 통함). 개인적으로 비쥬얼적인 부분은 가장 좋아 보였던 프로젝트. 인게임 전투는 전략 턴제고 톤만 실사지 캐릭터 등신 비율이나 연출이 좀 정적인게 아쉽다. 로비씬은 묵직한 메카닉느낌이 좋아서 프로젝트 퀄이 엄청 좋아보였던 플젝
https://store.steampowered.com/app/3855320/ABYSS_REBEL/?curator_clanid=4777282

Wretch : Divine Ascent : 덱 조합 전투 액션 게임
Ogopogo 개발. SapStaR Games가 퍼블리셔로 확인
https://store.steampowered.com/app/3081280/Wretch_Divine_Ascent/

Antro : inside와 같은 횡스크롤 퍼즐 플랫포머 게임. 스팀 페이지에서 찾아본것보다 현장에서 플레이하면서 봤던 비주얼과 스팀 페이지 영상이랑 비주얼 퀄 차이가 좀 있다. 전시전에 보강을 좀 한것 같음. inside 느낌이 많이 들긴 하는데 카툰 스타일에 톤을 다양한게 쓴게 좀 독특해 보이긴 했다.
https://store.steampowered.com/app/1861250/Antro/

바깥은 더운데다 내부에 따로 쉴곳이 없다보니 이렇게 바닥에 앉아 쉬는 사람이 많았다. 개인적으로 이런건 좀 아쉬운 부분...

다시 걸어 나오면서 한장. 날씨가 너무 덥다보니 중간중간 외부로 나올때 체력이 빠르게 방전되는 상황..... 이번에 정말 체력의 한계를 많이 느꼈던게...

너무 습하고 죽을거 같어... !!!

이번에 정말 체력적으로 힘들었다........ 여름 아닐때 하면 다시 오고 싶긴 하지만....

zaijien Shanghai~

[번역중]Microflake theory

illu_yun — Mon, 14 Jul 2025 15:19:17 +0900

고급 위상 함수 처리와 볼륨에 대한 밉맵핑 기법 소개

Rayleigh scattering : 작은 입자 → 빛을 고르게 산란
Mie scattering (소/대 입자) : 입자가 클수록 전방향으로 강하게 산란됨 (Forward scattering)

→ 이 차이가 수식의 위상 함수 ρ(ω,ω′) 에 반영됨

오른쪽 아래 : 위상 함수 또는 산란 분포의 방향성을 시각화

원형 → 등방성 (Isotropic)
앞쪽 타원 → 전방 산란
뒤쪽 타원 → 후방 산란

ρ(ω,ω′)

Phase Function은 광학 매질 내에서 빛이 어떤 방향으로 산란될지를 결정
Rayleigh, Henyey-Greenstein, Schlick 등의 다양한 모델이 존재
볼륨 내부에서의 라이언스 전달을 설명하며, 위상함수 p는 산란의 방향성과 강도를 결정하는 핵심요소이다.
밉맵핑은 이러한 계산을 효율적으로 하기 위한 렌더링 최적화 기법으로 함께 소개될 예정

A Radiative Transfer Framework for Rendering Materials with Anisotropic Structure
(by Wenzel Jakob et al., Cornell University)

비등방성 미세 구조(microflakes)를 갖는 재질 (예: 섬유, 머리카락, 카펫) 렌더링 프레임워크
입사광이 재질의 방향성 구조에 따라 비대칭 산란되도록 모델링
전통적인 등방성(Isotropic) 모델보다 현실적인 표현 가능

(a) 일반적인 확산형태 / (b) 섬유 방향성에 따라 달라진 하이라이트

미세구조에 따른 광 반응 차이 시각화

The SGGX Microflake Distribution
(by Eric Heitz, Jonathan Dupuy, Cyril Crassin, Carsten Dachsbacher)

SGGX (Spherical Gaussian-GGX) 모델은 미세 구조(마이크로플레이크)가 임의 방향으로 분포한 볼륨 기반 재질의 광산란을 정확하게 표현
미세한 입자의 방향 분포를 통해 헤어, 잎사귀, 구름 등의 렌더링 개선
GGX 기반의 구조적 확장을 통해 볼륨 안에서의 조밀한 방향성 정보까지 반영 가능

“복잡한 현상을 표현하기 위해 볼륨(volume) 기반 모델을 사용하자”
→ 단순한 위상 함수(phase function)는 세부 묘사 능력이 떨어진다.

기존의 간단한 phase function은

입사광의 산란을 대칭적이고 단순하게 모델링
예: Isotropic scattering (등방성 산란)
결과적으로 디테일 부족, 현실감 낮음

"A Radiative Transfer Framework for Rendering Materials with Anisotropic Structure"
저자: Wenzel Jakob, Adam Arbree, Jonathan T. Moon, Kavita Bala, Steve Marschner (Cornell University)

복잡한 비등방성(anisotropic) 구조를 가진 재질을 위해
볼륨 내 마이크로 구조(micro-flakes)를 고려한 방사 전달 모델(radiative transfer framework)을 사용
비등방성 재질에 적합한 위상 함수 설계
섬유, 카펫, 헤어 등에서 현실적인 광 표현을 가능하게 함

임의의 함수를 위상 함수 ρ에 사용할 수 있는가?

기존 모델 (예: Henyey-Greenstein, Rayleigh 등) 은 특정 물리적 특성을 근사
그러나 복잡한 재질(예: 섬유, 안개, 피부 등)에서는 단순 위상 함수로 디테일이 손실됨
따라서 연구자들은 ρ를 보다 복잡하고 표현력 높은 함수로 바꾸고자 함

물리적 제약 조건 (Physical properties of ρ) : 임의의 함수를 넣을 수 있는 것처럼 보이지만, 다음 세 가지 물리적 조건을 만족해야만 실제 세계에 기반한 위상 함수가 된다.

positivity (비음수성) : 위상함수는 음수일 수 없으며, 음의 산란량은 물리적으로 의미 없음
reciprocity(상호성) : 광학적 역대칭성 보장. 빛이 ′ → 방향으로 산란되든, → ′ 방향으로 산란되든 확률은 동일
energy conservation(에너지 보존) : 하나의 입사광이 여러 방향으로 퍼질수는 있어도, 총 에너지는 1(입사량 이상)을 넘을수 없다. 일부는 흡수되거나 전달되지 않음

^[각주:1]

기존에는 σₛ가 고정된 스칼라 값이었음 → 이제는 방향에 따른 함수 σₛ(ω) 로 바뀜
이는 매질이 방향에 따라 다르게 산란시키는 것을 반영함 (예: 나무 섬유, 머리카락, 패브릭)

Reciprocity (상호성)

→ 방향별 산란 계수를 고려한 상호성(산란 정도가 다르더라도 상호적 성질 유지해야 함)

기존 σₛ 모든 방향에 대해 일정한 산란 정도
개선된 σₛ(ω) 방향 ω에 따라 산란 정도가 달라짐
용도 섬유, 헤어, 브러시 등 방향성 구조가 있는 매질 표현에 필수
장점 더 정밀한 anisotropic volume rendering 구현 가능

방사선 전달 이론(Radiative Transfer Theory)에서 비구형 입자(non-spherical particles) , 특히 microflakes 의 물리적 의미를 설명

Physical interpretation: non-spherical particles (microflakes)
→ 비구형 입자(편평한 형태의 마이크로 입자)의 산란 특성을 직관적으로 설명

microflake 입자 : 얇고 납작한 형태 (flake = 조각)
σₜ (Sigma_t) : Extinction Coefficient (소광 계수)
- σₜ는 광선이 입자와 충돌하거나 흡수될 확률을 의미.
- σₜ가 클수록 빛이 더 빨리 사라진다 (산란되거나 흡수되기 때문에).
입자 배열 방향 σₜ의 방향성에 결정적 영향
렌더링 영향 방향에 따라 빛의 감쇠가 달라짐 → Anisotropic Volume Rendering 구현 가능

좌측 그림: high σₜ

입자들이 수평 방향으로 놓여 있음
좌측에서 입사하는 광선은 많은 입자 표면과 충돌하게 됨
즉, 빛의 경로가 입자에 의해 자주 방해받음 → σₜ가 높음

우측 그림: low σₜ

입자들이 수직 방향으로 정렬되어 있음
위에서 수직으로 입사하는 광선은 입자 면을 거의 통과하게 됨
따라서 적은 충돌 → σₜ가 낮음

목표 : 입자 분포 및 특성으로부터 σₐ(ω), σₛ(ω), ρ(ω, ω′)를 도출한다. 미세면 이론과 유사 : NDF 및 미세면 구성으로부터 BSDF 도출

즉, 입자 분포로부터:

흡수 계수 (σₐ) : 특정 방향에서 얼마나 빛을 흡수하는지
산란 계수 (σₛ) : 얼마나 빛을 산란시키는지
위상 함수 (ρ) : 입사 방향 ω′에서 방향 ω로 얼마나 산란되는지
이 세 가지 물리량을 유도하는 것이 목표.

마이크로플레이크 이론 : 입자 분포 및 특성으로부터 σₐ(Ω), σₛ(Ω) 및 ρ(Ω, Ω′) 도출

미세 입자(microflake)의 분포 및 속성을 이용해 다음의 방사 전파 특성을 계산한다:

σₐ(ω) : 방향 ω에 대한 흡수 계수
σₛ(ω) : 방향 ω에 대한 산란 계수
ρ(ω, ω′) : 입사 방향 ω′에서 산란되어 방향 ω로 가는 위상 함수

입력 요소 (input)

Particle density(입자밀도) σp
- 단위 부피당 microflake 입자의 수
- 방향에 따라 변하지 않음 (isotropic)
albedo(알베도) α
- 입자가 반사하는 비율 (0~1 사이)
- 방향에 따라 변하지 않음
법선 분포 함수 (NDF) D(m)
- microflake의 법선이 방향 m에 분포하는 정도
- 마이크로페이스 이론과 유사한 개념
- 이 함수는 각 입자의 방향성 구조를 정의함

출력 요소 (output)

위 3가지 입력으로부터 다음을 도출:

흡수 계수 σa(ω)
산란 계수 σs(ω)
위상 함수 ρ(ω,ω′)

“Note: I present a less general version here for simplicity”
해당 설명은 단순화를 위해 방향성 변화를 고려하지 않는 모델로 제한하고 있음을 알립니다. 실제 일반화된 이론은 방향에 따라 변하는 σ, α 등을 포함합니다.

각 마이크로플레이크는 양면 거울 BRDF를 가진 평평한 이중면(two-sided surface)으로 간주된다.

planar

입자는 얇고 납작한 평면형 입자로 모델링됨.
3D 공간에서 정해진 법선 방향을 가진 "플레이크"로 존재.

two-sided mirror

입자는 거울처럼 빛을 반사하는 성질을 가짐.
방향 ω에서 입사된 광선은 플레이크의 법선 m을 기준으로 ω′ 방향으로 반사됨.
중요한 점: 양면 거울이므로, m과 -m 양쪽 모두 반사에 영향을 미침.

즉, 단일 면만 반응하는 것이 아니라, 두 방향 모두에서 입사된 빛이 반사될 수 있는 구조.

BRDF 관점에서

각 마이크로플레이크는 BRDF(양방향 반사 분포 함수)를 가짐.
이 BRDF는 mirror-like, 즉 반사만을 고려하는 델타 함수 기반.
산란의 방향성은 플레이크의 법선 분포 D(m) 에 따라 통계적으로 결정됨.

Particle 분포와 속성으로 부터 입자밀도, 흡수계수 σa ( ω ), 산란계수 σs(ω), 위상합수를 도출한다

assuming the particles are planar(입자는 평면이라고 가정)

총 상호작용 계수 σt(ω)

빛이 입자와 만날 가능성:

D(m) : 법선 분포 함수
m⋅ω : 방향 ω에서의 입자의 투영면적 (교차 확률)
직관 : 광선이 입자 면에 수직으로 갈수록 만날 확률 ↑

왼쪽 : 입사 방향이 입자 방향과 수평
→ 입자 면에 거의 수직하게 들어옴
→ 입자 투영 면적이 작음
→ 입자와의 교차 확률이 낮음
→ → 긴 free path (자유 평균 경로)

오른쪽: 입사 방향이 입자 방향과 수직
→ 입자 면에 수평하게 들어감
→ 입자 투영 면적이 큼
→ 입자와의 교차 확률이 큼
→ → 짧은 free path

즉, 입사 방향 ω에 따라 입자들과의 충돌 확률이 다르며, 이는 곧 free path에 영향을 준다는 걸 보여준다.

산란은 전체 충돌 중 α\alpha만큼
흡수는 나머지 (1−α)(1 - \alpha)

→ σt(ω)=σs(ω)+σa(ω) 성립

위상 함수 ρ(ω,ω′)

방향으로 입사한 빛이 ω′\omega' 방향으로 산란될 확률 밀도
핵심 아이디어 : 거울 반사 조건을 만족하는 법선 벡터 m 를 찾기 위한 조건 :

따라서, 이 방향을 갖는 마이크로플레이크(입자)가 있을 확률이 D(⋅)D(\cdot), 그리고 입사 반사 양면 모두 고려해야 하므로 두 개의 D 항이 곱해짐
마지막으로 정규화를 위해 σs(ω)로 나누어 줌 → reciprocity (상호성) 보장을 위해

상호성 보장 조건 (Reciprocity Condition)

위상 함수는 입출 방향을 바꾸어도 물리적으로 같은 값을 가져야 함
이 수식을 만족하도록 ρ 정의가 설계됨

각 미세한 정사각형은 입자들이 분포한 지역 부피를 보여주며
파란 막대기(입자)에 빛이 입사된 뒤 ω′\omega' 방향으로 산란되는 것을 시각화
이 모든 확률은 D(m)D(m), ω\omega, ω′\omega'의 상호작용으로 결정됨

그림 4는 입사 방향 ωi\omega_iωi 에 대해 두 가지 입자 법선 분포 와 그에 따른 반사 거동 을 보여준다

NDF는 마이크로플레이크 볼륨의 동작을 결정한다!

(a) NDF : D(ω) = cos⁡^20(v, ω)+

법선 분포가 vv 방향으로 매우 집중되어 있음
→ 입자들이 모두 수직 방향으로 정렬된 상태
→ 반사 특성이 거칠게 rough한 표면처럼 동작
→ ωi\omega_i 방향에서 들어온 빛이 NDF 중심 방향 vv에 대해 대칭 반사됨

오른쪽의 fp는 위상 함수(phase function)에 해당하는 분포.

(b) NDF: D(ω) = sin^⁡20(v, ω)+

법선 분포가 vv 방향에서 수직 방향으로 퍼짐
→ 입자들이 vv를 **섬유 방향(tangent)**으로 가지며 평면에 눕는 형태
→ 이는 섬유(fiber) 또는 긴 기공을 가진 재료 같은 형태의 반사를 유도함→ 측면으로 넓게 산란됨

NDF D(m)는 입자들의 배향 분포를 수학적으로 표현한 것으로,
그 분포가 달라지면, 결과적으로 빛이 마이크로플레이크 볼륨 내에서 어떻게 산란되는지 (즉, ρ(ω,ω′))도 완전히 달라짐
실제 재질(예: 머리카락, 흙먼지, 우유, 거친 금속 등)은 이 NDF에 따라 광학적 특성이 달라짐

어떻게 법선 분포 함수(NDF)를 선택할 것인가?

we want the projected area

to have closed-form

위 적분식(법선 분포를 따라 투영된 면적)이 닫힌 형태(closed-form), 즉 수학적으로 명확하게 계산 가능한 형태이기를 원한다.
이 적분은 산란/흡수 계수인 σs(ω), σa(ω) 등의 계산에 핵심적으로 사용되기 때문. 이게 해석적으로 간단하면 렌더링 성능이 향상.

we want D to be “filterable” like a normal map[LEAN, LEADR]

우리는 NDF가 필터링 가능하기를 원한다. 즉, 해상도를 낮추거나 mipmap을 만들 때 부드럽게 평균화할 수 있어야 한다.
참고 논문 : LEAN, LEADR은 NDF를 필터링 가능한 방식으로 사용하는 논문 이름.
보통 normal map을 사용해 디테일을 표현하는데, 이를 확대/축소해도 물리적으로 자연스러워야 하듯이, NDF도 비슷한 성질을 갖춰야 한다는 의미.

SGGX : 표현력, 필터링 가능성, 효율성이 뛰어난 NDF

250627 크래프톤 웨이

illu_yun — Sat, 28 Jun 2025 01:34:21 +0900

1권이 나왔을때는 회사의 민감한 내용까지 이렇게 책으로 낸다고...? 라는 주위와 인터넷의 호들갑에 서점에서 서서 대충 훓어보고는 '그냥 게임회사에서 쉬이 보던 이야기인데?' 하고 잊고 있다가 2권이 올초에 나온걸 보고 한번은 읽어야지 하고 동시에 주문했다.(생각해보면 다른업계에서는 게임쪽 이야기가 신선했을수는 있겠다 싶지만...)

출퇴근 지하철에서 틈틈히 읽은 소감은 1권은 잘 읽히긴 하는데 뭔가 생각할 만한 화두는 딱히 없었고(아마 테라가 내취향이 아니였던 탓도 있으리...배틀그라운드 이야기의 비중이 그리 크지 않았던것도..)

2권이 초반부터 펍지 성공이후 인센티브 책정과 관련된 블루홀 경영진과의 갈등, 성공한 IP를 장기 로드맵을 어떻게 만들어 유지하는지, 어떤 생각으로 드라이브 했는지에 대한 부분은 무척이나 흥미로웠다. 때마침 그즈음에 영문씨가 펍지로 가서 건너 들은 이야기도 생각났고.

특히 게임업계에서의 리더십, 조직운영, 조직문화를 만들어갈때 고민해야하는 부분은 나도 우리부서 꾸리면서 또 임원도 되고나니 고민이 많은 부분이라 여기에 대한 이야기는 엄청 흡입력 있게 다가왔다. 그러다보니 슬슬 조직리더 역할을 하는 지인이나 시니어들에게는 한번쯤 읽어보라 권하는중.

기억에 남는 문장이 몇개 있었는데 1권에서는 이부분

그라고 마지막은 김창한 대표님 맺음말을 첨부해본다.

GPU Specification compare PS5/XBOX Series X/Adreno/PC

illu_yun — Sat, 24 May 2025 23:27:41 +0900

	RTX 3070(2020)	PS5(2020)	SnapDragon865 (2020)	GTX650(2012)	XBOX SeriesX (2020)
GPU Name	GA104(8nm) Ampere	Oberon(7nm) RDNA 2.0	Adreno 650(7nm)	GK106(26nm) Kepler	Scarlett(7nm) RDNA 2.0
Base Clock	1500MHz 1725MHz (Boost Clock)	2233MHz	250MHz 587MHz (Boost Clock)	1058MHz	1825MHz
Memory Clock Memory Size Memory Type Memory Bus Bandwidth	1750MHz 14 Gbps effective 8GB GDDR6 256bit 448.0 GB/s	1750MHz 14 Gbps effective 16GB GDDR6 256bit 448.0 GB/s	2750MHz / LPDDR4X(or LPDDR5) 64bit 44 GB/s	1250MHz 1GB GDDR5 128bit 80.00 GB/s	1750MHz 14 Gbps effective 10GB GDDR6 320bit 560.0 GB/s
Shading Units TMUs ROPs	5888 184 96	2304 144 64	512 24*2 7	384 32 16	3328 208 64
Pixel Rate Texture Rate FP16(half) FP32(float) FP64(double)	165.6 GPixel/s 317.4 GTexel/s 20.31 TFLOPS(1:1) 20.31 TFLOPS 317.4 GFLOPS(1:64)	142.9 GPixel/s 321.6 GTexel/s 20.58 TFLOPS(2:1) 10.29 TFLOPS 643.1 GFLOPS(1:16)	14.1 GPixel/s 28.1 GPixel/s / 1.3 TFLOPS /	8.464 GPixel/s 33.86 GTexel/s / 812.5 GFLOPS 33.86 GFLOPS(1:24)	116.8 GPixel/s 379.6 GTexel/s 24.29 TFLOPS(2:1) 12.15 TFLOPS 759.2 GFLOPS(1:16)

Adreno 830 specifications : https://en.wikipedia.org/wiki/Adreno#Adreno_800_series

	PS5(2020)	PS5 Pro(2024)	Snap Dragon Gen Elite(2024)	RTX 5070(2025)
GPU Name	Oberon(7nm) RDNA 2.0	Viola(4nm) RDNA 2.0	Adreno 830(3nm) Oryon Gen 2	GB205(5nm) Blackwell 2.0
Base Clock	2233MHz	2170MHz 2350MHz(Boost)	1100MHz 1200MHz(for Galaxy)	2325MHz 2515MHz(Boost)
Memory Clock Memory Size Memory Type Memory Bus Bandwidth	1750MHz 14 Gbps effective 16GB GDDR6 256bit 448.0 GB/s	2250MHz 18 Gbps effective 16GB GDDR6 256bit 576.0 GB/s	5300MHz / 12MB(on chip) Shared Meomry LPDDR5X 64bit 84.8 GB/s	1750HMz 28 Gbps effective 12GB GDDR7 192bit 672.0 GB/s
Shading Units TMUs ROPs	2304 144 64	3840 240 64	1536 / /	6144 192 80
Pixel Rate Texture Rate FP16(half) FP32(float) FP64(double)	142.9 GPixel/s 321.6 GTexel/s 20.58 TFLOPS(2:1) 10.29 TFLOPS 643.1 GFLOPS(1:16)	150.4 GPixel/s 564.0 GTexel/s 36.10 TFLOPS(2:1) 18.05 TFLOPS 1128 GFLOPS(1:16)	/ / 6.7584 TFLOPS(2:1) 3.3792 TFLOPS 844.8 GFLOPS	201.0 GPixel/s 482.3 GTexel/s 30.87 TFLPOPS)1:1 30.87 TFLPOPS 482.3 GFLPOPS (1:64)

PS5의 Compute Unit (CU)는 AMD GPU에서 셰이더 연산, 텍스처 처리, 벡터 연산 등을 담당하는 병렬 처리 블록으NVIDIA의 Streaming Multiprocessor(SM)에 해당하는 구조를 말한다. 셰이딩 연산량, 텍스처 처리량등 병렬처리 성능에 영향을 주는 요소이다. PS5에서는 36개에서 Pro에서 60개로 그 수가 늘어났다

Nvidia는 tile based rendering으로 전환하고 xclipse랑 이번 adreno 830은 IMR(IMR (Immediate Mode Rendering) 으로 다시 돌아왔다. xclipse야 RDNA 아키텍처 때문인가 싶은데, 애플 A18 바이오닉보다 벤치 성능이 잘 나오는걸보면 이유가 있지 싶은데...(완전 전통방식 그대로는 아닌듯하고 특히 캐쉬 사이즈 변경등 몇몇 이유를 짐작할 부분이 보인다. 이 추세면 5년뒤 10년뒤 포터블 디바이스 시장은 지금과도 꽤 다를듯)

https://www.reddit.com/r/hardware/comments/1gqubjv/why_does_the_snapdragon_8_elites_gpu_have_so_much/?rdt=59896

Bandwidth : GPU와 VRAM(그래픽 메모리) 간의 초당 데이터 전송량(Byte/s)
→ GPU가 처리할 데이터를 메모리에서 얼마나 빠르게 가져올 수 있느냐에 따라 전체 처리 속도가 달라짐.

Bandwidth = Memory Bus Width × Memory Clock Speed × 2 (DDR) ÷ 8

* Snapdragon 865의 경우 계산으로는 88GB/s이 나오지만 실제 LPDDR4X5의 효율을 반영해 44GB/s으로 표기

GDDR3/GDDR4/GDDR5 칩 하나당 32bit interface가 있는데, 2개를 병렬로 연결하면 64bit GDDR5 bus, 4개면 128 bit, 6개면 192 bit, 8개면 256 bit, 12개면 384 bit, 16개면 512 bit. 메모리칩을 하나의 GPU에 연결하기 위해서 PCB설계가 더욱 더 복잡해지고, 메모리 클럭도 떨어지게 된다. 더 높은 메모리 버스 일수록 파워를 더 많이 먹게되고, 발열, 그리고 GPU자체도 메모리 컨트롤러 때문에 커지게 됨. 256과 512비트의 경우 PCB 기판 가격도 고가가 된다.

GDDR 방식은 메모리 버스를 늘려 대역폭을 확보하는 반면, HBM은 버스폭을 크게 하고 클럭은 낮추는 방식으로 더 높은 대역폭을 달성함. HBM/HBM2 경우 1스택당 1024 bit bus를 제공하여, 적은 클럭으로도 Bandwidth는 크다.

Shading Units : GPU의 계산 유닛 또는 코어에 해당하며 물리, 조명, 그림자등 각종 비주얼 계산에 사용된다. FP32 연산(부동소수점 계산) 단위를 기준으로 GPU FLOPS(연산능력) 계산. Cuda core(Nvidia) / Stream Processor(AMD)
AMD와 Nvidia의 연산방식 차이에 따라 유닛 숫자는 차이날 수 있다.

TMU(Texture Mapping Units) : 텍스처(이미지)를 픽셀에 힙히는 작업을 담당하는 유닛

텍스처 좌표 변환, 필터링(Bilinear, Trilinear, Anisotropic)
Mipmapping 처리 (화질 및 성능 최적화용 텍스처 축소 기술)
텍셀(Texel) → 픽셀(Pixel) 매핑

Texture Fillrate (텍스처 필레이트) = TMU 수 × GPU 클럭으로 계산되며 이는 초당 몇 개의 텍스처를 처리할 수 있는지를 의미(단위: GTexel/s)

ROPs (Render Output Units / Raster Operations Pipelines) : 렌더링 파이프라인의 최종 출력 처리를 담당하는 유닛. 픽셀을 최종 이미지로 출력하기 직전의 "마무리 작업" 수행.

블렌딩(반투명 처리), Z-buffer(깊이 정보 처리), 스텐실 처리, 안티앨리어싱
프레임버퍼로의 출력, 최종 해상도에 맞는 픽셀화

Pixel Fillrate (픽셀 필레이트) = ROP 수 × GPU 클럭. 초당 출력 가능한 픽셀 수 (단위: GPixel/s)

렌더링 과정은 [Shading Units : 계산] → [TMUs : 텍스처] → [ROPs : 출력] 순으로 이루어진다.

부동소수점 연산 성능(Floating Point Operations Per Second) : 초당 부동 소수점 연산 수행 능력을 나태는 지표로 1 GFLOPS는 초당 10억, 1 TFLOPS 1조번 연산능력을 이야기 한다

FLOPS = 연산 유닛 수 × 클럭 속도 × IPC( Instructions Per Cycle)^[각주:1]

이론상 최대값이므로 실제 성능은 이보다 낮을 수 있음. 보통 FP16연산이 FP32보다 빠르게 처리됨. FP64의 경우 게임용 GPU에서는 매우 느리게 작동한다.

GPU 아키텍처마다 정밀도별 유닛 지원 비율이 다르기 때문에 FP16, FP32, FP64의 비율이 다르게 나타난다.

연산포맷	설명	bit 수	용도
FP16 (Half)	Half Precision Floating Point	16bit	모바일, AI 추론
FP32 (Float)	Single Precision	32bit	일반 게임, 그래픽 처리
FP64 (Double)	Double Precision	64bit	과학, 공학, 물리 시뮬레이션 등

FP16 : AI연산 가속 목적으로만 지원하는 경우가 많음. 전통적인 셰이더 코어(SM, CU)와 별개로 존재. 특정 조건에서만 높은 성능 발휘

GPU	FP32	FP16	비율
RTX 3070	20.31 TFLOPS	20.31 TFLOPS	1:1 (FP16 연산은 SM에서 처리)
RTX 3090	35.58 TFLOPS	71 TFLOPS (Tensor Core)	1:2 이상
Adreno 650	1.3 TFLOPS (FP32)	미지원 / 미기재	AI용 NPU에서 처리

플랫폼	설계 목적	정밀도 지원
모바일 SoC	전력효율, 중간 정밀도	FP16/INT8 위주, FP64 없음
콘솔 GPU	게임 그래픽	FP32 중점, FP16 일부
서버/과학용 GPU	시뮬레이션, AI	FP64/FP16 병렬성 극대화

Reference :

RTX 3070 : https://www.techpowerup.com/gpu-specs/geforce-rtx-3070.c3674
GTX 650 : https://www.techpowerup.com/gpu-specs/geforce-gtx-650.c894
PS5 : https://www.techpowerup.com/gpu-specs/playstation-5-gpu.c3480
XBOX Series X : https://www.techpowerup.com/gpu-specs/xbox-series-x-gpu.c3482

한번의 클럭 주기당 몇개의 명령어(instruction)을 실행할 수 있는지를 나타내는 성능지표. 주요 게임용 Nvidia/AMD GPU의 IPC 는 2.0으로 추정되나 Snapdragon 865의 경우 4.3정도로 추산됨(이는 AI unit 가속을 포함한 수치로 추정됨. 단순 비교하기 어려움) [본문으로]

위상함수	상호성	에너지보존	특징
Isotropic	✅	✅	균일 산란
Rayleigh	✅	✅	미세 입자 산란 (파장 영향)
Henyey-Greenstein	✅	✅	편향 산란 (anisotropy 표현)
Schlick	✅	✅	HG의 근사, 계산 단순함