No Graphics API

Sebastian Aaltonen - No Graphics API를 번역한 글입니다

Yongsik Im

December 25, 2025 · 29 min read

이 포스트는 해당 글을 번역해 옮겼습니다. 번역 과정에서 일부 의역을 포함했습니다.
번역 과정에서 ‘Modern’을 문맥에 따라 ‘최신’, ‘현대’, ‘모던’(그래픽스 API를 지칭할 때 한정) 으로 혼용합니다.

No Graphics API #

소개 #

그래픽스 API, 셰이더 프레임워크 그리고 드라이버들의 복잡성이 지난 수십년간 빠르게 증가했습니다. 파이프라인 상태 객체(Pipeline State Object, PSO) 폭발은 더 이상 손쓸 수 없을 지경입니다. 어쩌다 100GB에 달하는 로컬 셰이더 파이프라인 캐시와 이들을 호스팅하는 거대한 클라우드 서버가 탄생하게 된 걸까요? 이젠 어떻게 우리가 GPU와 상호작용하기 위한 추상화와 API 표면을 줄일 수 있을지에 대한 방법을 논의하기 시작해야 할 때입니다.

업계에서의 저수준 그래픽스 API들의 변화 #

십년 전, 새로운 저수준 PC 그래픽스 API의 소개와 함께 실시간 컴퓨터 그래픽스 분야에 중대한 변화가 일어났습니다. AMD는 2013년 Xbox One과 Playstation 4의 부품 계약을 모두 따냈습니다. 그들의 새로운 GCN(Graphics Core Next) 아키텍쳐는 사실상 AAA(*역주: Triple-A 라고 부르며, 블록버스터급 규모를 의미합니다) 게임 개발을 위한 주력 플랫폼이 되었습니다. 해당 시점의 PC 그래픽스 API들이었던 DirectX 11과 OpenGL 4.5는 무거운 드라이버 오버헤드가 있었으며 싱글 스레드 렌더링을 위해 설계되어 있었습니다. AAA 게임 개발자들은 더 높은 성능의 API를 요구했습니다. DICE는 아예 AMD GCN에 특화된 PC 그래픽스 API인 Mantle 제작에 함께 참여하게 되었으며, 이에 응답하듯 Microsoft, Khronos, 그리고 Apple은 그들만의 저수준 API를 개발하기 시작했고, 그 결과 각각 DirectX 12, Vulkan, Metal이 탄생하게 되었습니다.

이러한 새로운 저수준 API들에 대한 초기 반응은 엇갈렸습니다. 합성 벤치마크들과 데모들은 이들이 이전 API들에 비해 상당한 성능 향상을 이루어냈음을 보여주었지만, Unreal Engine, Unity와 같은 주요한 게임 엔진들에서는 성능 향상이 보이지 않았습니다. 제가 Ubisoft에서 일할 때, 저희 팀은 기존에 개발되어 있던 DirectX 11 기반 렌더러를 DirectX 12로 포팅할 때 종종 성능 저하가 발생하는 것을 발견했습니다. 이는 무언가 잘못된 것이었습니다.

기존에 존재하던 고수준 API들(*역주: DirectX 11, OpenGL 등)은 최소한의 영구(Persistent) 상태만을 제공하며, 세부적인 상태 설정기와 개별적인 데이터 입력은 드로우 콜 호출 직전에 셰이더에 바인딩됩니다. 새로운 저수준 API 들은 셰이더 파이프라인 상태와 바인딩들을 영구 객체로 미리 묶음으로써 드로우 콜의 비용을 더 낮추는 것을 목표로 합니다. 이전까지의 GPU 아키텍쳐들은 매우 이질적(Heterogeneous)이었습니다. 데이터 리매핑, 유효성 검증(validation) 및 사전 업로드를 수행하는 것이 큰 도움이 되었습니다. 그러나 기존 게임 엔진들의 렌더링 하드웨어 아키텍쳐(RHI, Rendering Hardware Architecture)는 세밀한 즉각적(immediate) 모드 렌더링을 위해 설계된 반면, 새로운 저수준 API는 데이터를 영구 객체로 묶어야 했습니다.

이러한 비호환성을 해결하기 위해 새로운 저수준 그래픽스 리매핑 레이어가 RHI 아래에 생겨났습니다. 이 레이어는 이전에는 OpenGL과 DirectX 11 그래픽스 드라이버가 처리했던 복잡성을 담당하며 리소스를 추적하고 세분화된 동적 사용자 영역과 영구적인 저수준 GPU 상태 간의 매핑을 관리합니다. 이로 인해 그래픽스 프로그래머는 두 가지 구분된 역할로 전문화되기 시작했습니다. 새로운 저수준 ‘드라이버 레이어’와 RHI 계층에 집중하는 저수준(Low-level) 그래픽스 프로그래머들과, 그들이 구현한 RHI계층 위에서 시각적 알고리즘(비주얼 프로그래밍)에 집중하는 고수준(High-level) 그래픽스 프로그래머들로 말이죠. 물론 비주얼 프로그래밍 또한 물리 기반 라이팅 모델들, 컴퓨트 셰이더, 이후에는 레이 트레이싱이 등장하며 더 복잡해졌습니다.

모던 API? #

DirectX 12, Vulkan, 그리고 Metal은 종종 ‘모던 API(Modern API)’ 로 불려집니다. 이 API들은 이제 등장한 지 10년도 더 넘었습니다. 그들이 설계될 당시 지원하고자 했던 GPU들은 지금으로부터 13년 전의 제품이며, 이는 GPU의 역사에서는 놀라울 만큼 긴 시간입니다. 오래 전 GPU 아키텍쳐들은 오늘날 널리 사용하는 연산(Compute) 집약적인 워크로드보다 전통적인 정점 및 픽셀 셰이더 작업들에 최적화되어 있습니다. 그들은 제조사(Vendor) 별로 구분된 바인딩 모델들과 데이터 경로를 가지고 있습니다. 하드웨어 차이는 동일한 API 속에서 래핑되어야 했습니다. 이로 인해 사전에 생성된 영구 객체는 매핑, 업로드, 유효성 검증 및 바인딩 비용을 줄이는 데 매우 중요했습니다.

반면, 콘솔 API들과 Mantle은 그 당시로써는 선구적인 시각으로 설계된 AMD의 GCN 아키텍쳐만을 위해 독점적으로 디자인되었습니다. GCN은 복합적인 읽기/쓰기 캐시 계층과 텍스쳐/버퍼 디스크립터를 저장하는 스칼라 레지스터를 자랑하며 사실상 모든 것을 메모리처럼 취급했습니다(*역주: 포인터 연산과 같은 방식으로 모든 자원에 자유롭게 접근 가능하다는 것을 의미합니다). 데이터를 리매핑하는 데 어떠한 복잡한 API도 필요하지 않았고, (드로우 콜 이전에 필요한)사전 작업의 필요량이 상당하게 줄어들었습니다. 콘솔 API들과 Mantle은 단 하나의 최신 GPU 아키텍쳐만을 위해 설계했기 때문에 더 적은 API 복잡도을 가졌습니다.

10년이 지났고, GPU들은 상당한 진화를 거쳤습니다. 모든 최신 GPU 아키텍쳐들은 이제 일관성 있는 최종 레벨 캐시를 갖춘 완전한 캐시 계층 구조를 특징으로 합니다. PCIe ReBAR(*역주, AMD에선 동일한 기술을 SAM-Smart Access Memory-이라 부릅니다)나 UMA를 이용해 CPU는 GPU 메모리에 직접적으로 쓰기 동작이 가능하며, 64비트 GPU 포인터가 셰이더에서 직접적으로 지원됩니다. 텍스쳐 샘플러들은 바인딩이 필요가 없으므로(Bindless) CPU 드라이버가 디스크립터 바인딩을 구성할 필요가 없으며, 텍스쳐 디스크립터는 GPU 메모리(디스크립터 힙 으로 불립니다) 안에 배열 형태로 곧바로 저장될 수 있습니다. 만약 우리가 오늘날의 최신 GPU들을 위한 API를 설계한다면, 앞선 ‘모던 API’들의 특징인 영구적인 ‘유지 모드’ 객체 대부분은 필요하지 않을 것입니다. DirectX 12.0, Metal 1, Vulkan 1.0이 감수해야 했던 타협점들은 더 이상 필요하지 않습니다. API를 극적으로 단순화할 수 있습니다.

지난 10년은 ‘모던 API’들의 약점이 드러난 시간이었습니다. PSO 순열 폭발은 우리가 해결해야 할 가장 큰 문제입니다. 제조사들(Valve, Nvidia 등)은 서로 다른 각각의 아키텍쳐/드라이버 조합을 위한 테라바이트 단위의 PSO를 저장하기 위한 거대 규모의 클라우드 서버를 가지고 있으며, 유저들의 로컬 PSO 캐시 사이즈는 100GB를 초과하기도 합니다. 게이머들이 게임의 로딩 시간이 너무 오래 걸리고 끊김(스터터링)이 심하다고 불평하는 것이 전혀 놀랍지 않습니다.

GPU와 그래픽스 API의 역사 #

그래픽스 API의 표면을 벗겨내는 것에 대해 이야가히기 전에, 그래픽스 API들이 왜 이러한 방식으로 설계되었는지에 대한 역사적인 이해가 필요합니다. OpenGL은 일부러 느리게 만들어진 것이 아니며, Vulkan도 이유 없이 복잡하게 만든 것이 아닙니다(*역주: Vulkan은 RGB 삼각형 하나를 그리는 단순한 튜토리얼에도 1000줄이 넘는 코드가 필요한 것으로 악명높습니다). 10-20년 전 GPU 하드웨어들은 극도로 다양했으며 빠르게 진화했습니다. 이러한 다양한 하드웨어 조합을 위한 크로스 플랫폼 API를 설계하기 위해선 타협이 필요했습니다.

3dFX Voodoo 2 12MB (1998): 개별 프로세서와 이를 메모리 칩(각 프로세서당 1MB 칩 4개)과 연결하는 트레이스(trace)가 명확하게 보입니다. 이미지 © TechPowerUp.

고전(Classic)부터 시작해봅시다. 3dFX Voodoo 2 12MB (1998)은 세 개의 칩 설계를 가지고 있었는데, 이는 4MB 프레임버퍼 메모리와 연결된 하나의 단일 래스터라이저 칩과 각각 자신만의 4MB 텍스쳐 메모리와 연결된 두 개의 텍스쳐 샘플링 칩입니다. 기하 파이프라인과 프로그래밍 가능한 셰이더는 존재하지 않았습니다. CPU는 사전 변환된 삼각형 정점들을 래스터라이저에 보냈습니다. 래스터라이저는 전달받은 정점의 색상과 두 텍스쳐 샘플러를 어떻게 결합될지를 컨트롤하기 위해 구성 가능한 블렌딩 방정식을 가졌습니다. 두 텍스쳐 샘플러들은 서로간의 메모리 혹은 프레임버퍼의 값을 읽을 수 없었습니다. 그러므로 멀티 렌더 패스 역시 지원되지 않았죠. 하드웨어가 윈도우 합성을 지원하지 않았기 때문에 전용 2D 비디오 카드를 연결하기 위한 루프백 케이블이 있었습니다. 3D 렌더링은 오직 전체 화면 모드에서만 정상적으로 수행 가능했습니다. 3D 그래픽카드는 오늘날의 GPU 및 대규모 프로그래밍 가능한 SIMD 배열들과는 공통점을 찾아보기 힘든 매우 특수한 하드웨어였습니다. 이 시대의 하드웨어는 DirectX(1995)와 OpenGL(1992)의 설계애 막대한 영향을 미쳤습니다. 하위 호환성을 위해 API는 적극적인 변화 대신 점진적인 개선이 이루어졌고, 30년 전의 이러한 API설계 방식은 오늘날 우리가 소프트웨어를 작성하는 방식에 여전히 영향을 미치고 있습니다.

Nvidia의 Geforce 256은 GPU라는 용어를 만들어냈습니다. 해당 제품은 래스터라이저 외에도 최초로 기하 프로세서를 가졌습니다. 기하 프로세서, 래스터라이저 그리고 텍스쳐 샘플링 유닛은 모두 동일한 다이(die)에 통합되었고 메모리를 공유했습니다. 이에 발맞춰 DirectX 7은 두 가지 새로운 컨셉을 소개했습니다. 바로 렌더 타겟 텍스쳐(Render Target Textures)와 유니폼 상수(Uniform Constants)입니다. 멀티 패스 렌더링은 텍스쳐 샘플러들이 래스터라이저의 출력을 읽을 수 있음을 의미했으며, 이로 인해 3dFX Voodoo2의 별도 메모리 설계가 무용지물이 되었습니다.

기하 프로세서 API는 변환 행렬들(float4x4), 빛의 위치나 색상을 위한 유니폼 데이터 입력을 특징으로 합니다. 이에 대한 GPU의 구현 방식은 제조사들마다 다양했으나, 많은 제조사가 기하 엔진 내부에 작은 상수 메모리 블록을 내장하는 방식을 택했습니다. 물론 이것이 유일한 방법은 아니었습니다. OpenGL API에선 각 셰이더가 자신만의 전용 유니폼 데이터를 가질 수 있습니다. 이러한 설계는 드라이버가 상수를 셰이더 연산 스트림 안에 곧바로 임베드하는것이 가능하게 만들었으며, 이는 오늘날 OpenGL 4.6 및 OpenGL ES 3.2에도 여전히 남아 있는 API 특이점입니다.

그 당시 GPU들은 범용 읽기/쓰기 캐시가 없었습니다. 래스터라이저는 블렌딩과 깊이값 저장(Depth Buffering)을 위한 스크린 로컬 캐시를 가지고 있었고, 텍스쳐 샘플러는 데이터 프리페치를 위해 선형 보간된 정점 UV에 의존했습니다. DirectX 8 셰이더 모델 1.0에서 셰이더가 도입되었을 때, 픽셀 셰이더에서 텍스쳐의 UV를 계산하는 것은 지원되지 않았습니다. UV는 정점 단위로 계산되었으며, 하드웨어를 통해 보간되고 텍스쳐 샘플러로 곧장 전달되었습니다.

DirectX 9는 셰이더 명령어 제한을 크게 증가시켰지만, 셰이더 모델 2.0은 여전히 새로운 데이터 경로를 노출시키지 않았습니다. 정점/픽셀 셰이더 모두는 여전히 1:1 입/출력 방식으로 동작했으며, 사용자는 정점 및 속성(attributes)의 변환 계산과 픽셀 색상만 정의할 수 있었습니다. 프로그래머블한(*역주. ‘프로그래머블-Programmable’은 코드 단위로 통제 가능함을 의미합니다) load/store 연산도 지원되지 않았고, 정점 페치, 유니폼(상수) 메모리와 텍스쳐 샘플러라는 고정 기능(fixed-function) 입력 블록이 그대로 유지되었습니다. 정점 셰이더는 분리된 연산 단위였습니다. 인덱스 상수(float4 배열로 제한되었지만)와 같은 새로운 기능들을 얻었지만 여전히 텍스쳐 샘플링 지원은 미진했습니다.

Direct9 셰이더 모델 3.0은 명령어 제한을 65536개 까지 증가시켜 인간이 더 이상 셰이더 어셈블리를 작성하거나 유지보수하기 어렵게 만들었습니다. 이로 인해 HLSL(2002)과 GLSL(2002-2004)같은 고수준 쉐이딩 언어가 등장했습니다. 이러한 언어들은 각 셰이더 계산 요소들과의 1대1 대응 변환 설계를 채택했습니다. 각 셰이더 실행(Invocation)은 단일 데이터 요소(정점, 혹은 픽셀)에 대해 연산되었습니다. 프레임워크 스타일의 셰이더 설계는 그 이후 그래픽스 API 설계에 무거운 영향을 끼쳤습니다. 이것은 그 당시의 하드웨어들 강늬 차이를 추상화하는 매우 멋진 방법이었지만, 오늘날에는 확장성 문제를 드러내고 있습니다.

DirectX 11은 컴퓨트 셰이더, 범용 읽기-쓰기 버퍼, 그리고 Indirect Drawing의 지원에 대해 발표했고 이는 데이터 모델에 대한 중대한 변화(Shift)였습니다. GPU는 (상술한 기능들을 활용해)자체적으로 충분히 데이터를 공급받을 수 있게 되었습니다. 범용 버퍼의 포함은 셰이더 프로그램이 코드 수준에서 메모리 위치를 수정하고 접근할 수 있도록 했고, 이는 하드웨어 벤더들이 범용 캐시 계층을 구현하도록 강제해습니다. 셰이더들은 간단한 1대1 데이터 변환을 넘어서, 특수화되고 하드코딩된 데이터 경로의 종말을 알렸습니다. GPU 하드웨어는 범용 SIMD 설계를 향해 변화하기 시작했습니다. SIMD 유닛들은 이제 정점(Vertex), 픽셀(Pixel), 기하(Geometry), 헐(Hull), 도메인(Domain) 그리고 컴퓨트까지 서로 다른 모든 셰이더 타입들을 실행할 수 있게 되었습니다. 오늘날 이 프레임워크는 서로 다른 셰이더 시작 지점(Entry Point) 가집니다. 이는 많은 API 표면을 추가했고 구성을 어렵게 만들었습니다. 그 결과 GLSL과 HLSL은 여전히 활발한 라이브러리 생태계를 갖추지 못하고 있습니다.

DirectX 11은 수많은 버퍼 타입의 지원을 추가했는데, 각각은 특정한 하드웨어 데이터 경로의 특징을 수용하도록 설계되었습니다. 타입 지정 SRV(Shader Resource View)와 UAV(Unordered Access View), 바이트 주소 SRV & UAV, 구조화된(Structured) SRV & UAV, Append와 Consume(counter를 포함해서), 상수, 정점, 그리고 인덱스 버퍼 등입니다. 텍스쳐와 마찬가지로, DirectX에서 이 버퍼들은 불퉁명한 디스크립터를 활용합니다. 디스크립터들은 사이즈, 포맷, 프로퍼티들과 GPU 메모리상에서 데이터의 주소를 인코딩한 하드웨어 종속적인(일반적으로 128-256 비트의) 데이터 블롭입니다. DirectX 11를 지원하는 GPU들은 그들의 텍스쳐 샘플러들을 버퍼 로드 연산을 위한 지렛대로 사용합니다. 이것은 샘플러가 이미 타입 변환 하드웨어와 작은 읽기 전용 데이터 캐시를 가지고 있었던 점에서 자연스러운 결과였습니다. 타입 지정 버퍼들은동일 포맷의 텍스쳐로 지원되었으며, DirectX는 동일한 SRV 추상화를 텍스쳐와 버퍼 양쪽 모두에 사용했습니다.

불투명 버퍼 디스크립터의 사용은 버퍼 포맷이 셰이더 컴파일 시점엔 알 수 없음을 의미했습니다. 이러한 점은 텍스쳐 샘플러에 의해 관리되는 읽기 전용 버퍼들은 문제가 없었습니다. 읽기-쓰기 버퍼(DirectX의 UAV)는 초기에는 32비트와 128비트(float4) 유형으로 제한되었습니다. 이후 API 및 하드웨어 개정을 통해 UAV의 크기 제한은 점차 해결되었지만, 여전히 중요한 문제가 지속되었습니다. 바로 디스크립터가 간접 참조를 필요(포인터 포함)로 하고, 컴파일러 최적화는 제한적이며(데이터 유형을 런타임에만 알 수 있으므로), 포맷 변환 하드웨어가 (raw한 L1 캐시 로드 대비) 지연 시간을 발생시키고, 로드 시 확장은 레지스터를 더 오래 점유하며(사용 시 확장 대비), 디스크립터 관리는 CPU 드라이버의 복잡성을 증가시키고, 서로 다른 10개의 버퍼 타입을 지원해야 함으로 인해 API 자체도 복잡하다는 것입니다.
(*역주. “사용/로드 시 확장"의 확장(expand)은 UAV, Texel Buffer등에 패킹된 데이터-RGBA8 혹은 R11G11B10등-를 실제 데이터로 사용하기 위해 벡터/스칼라 레지스터에 언패킹하는 것을 의미합니다)

DirectX 11에서 구조화된 버퍼(StructuredBuffer)는 유저 정의 구조체 타입을 사용할 수 있는 유일한 버퍼 타입이었습니다. 다른 모든 버퍼 타입들은 단순한 스칼라/벡터 원소들의 균일한(Homogeneous) 배열과 동일하게 표현되었습니다. 불행하게도, 구조화된 버퍼는 다른 버퍼 타입들과 레이아웃이 호환되지 않았습니다. 사용자는 타입 지정 버퍼, 바이트 주소 버퍼, 또는 정점/인덱스 버퍼들로 구조화된 버퍼 뷰를 생성하는 것이 허용되지 않았습니다. 그 이유는 구조화된 버퍼가 내부적으로 특수한 SoAoS 스위즐 최적화를 사용했기 때문인데, 이는 오래된 vec4 아키텍쳐에서 중요했습니다. 이 하드웨어에 특화된 최적화로 인해 구조화된 버퍼의 사용성이 제한되었습니다.

DirectX 12는 모든 버퍼를 메모리에 선형적으로 만들어, 그들이 상호간에 호환될 수 있도록 만들었습니다. SM 6.2는 또한 load<T> 라는 문법적 설탕을 바이트 주소 버퍼를 위해 추가하여, 임의의 오프셋에서 깔끔한 구조체 로딩 구문을 사용할 수 있게 허용했습니다. 모든 오래된 버퍼 타입들은 여전히 하위 호환성을 위해 여전히 지원되며 모든 버퍼들은 여전히 불투명 디스크립터를 사용합니다. HLSL은 여전히 64비트 GPU 포인터 지원이 부족합니다. 반면에, Nvidia의 CUDA 컴퓨팅 플랫폼(2007)은 64비트 포인터에 완전히 의존했으나, 그 인기는 학술적인 영역에서만 존재했습니다. 그러나 오늘날 이(CUDA)는 선도적인 AI 플랫폼이며 최신 하드웨어 설계에 강력한 영향을 미치고 있습니다.

DirectX12가 출시되었을 때 16비트 레지스터와 16비트 수학 연산 지원은 체계적이지 못했습니다. 마이크로소프트는 초기에 DirectX12를 윈도우7로 백포팅(Backporting, 하위 지원 포팅)하지 않기로 하는 의문스러운 결정을 내렸습니다. Windows8을 대상으로 하는 쉐이더 바이너리들은 16비트 타입을 지원했으나, 대부분의 게이머들은 여전히 윈도우7을 사용하고 있었습니다. 개발자들은 두 세트의 쉐이더를 배포하고 싶어하지 않았습니다(*역주. 즉, 대부분의 게임 개발자들은 유저 커버리지를 위해 이 기능을 사용하지 않기로 결정했습니다). OpenGL의 lowp/mediump 사양 또한 난장판이었습니다. 비트 깊이가 제대로 표준화되지 않았습니다. mediump는 모바일 게임에서 인기 있는 최적화 옵션이었지만, 대부분의 PC 드라이버들은 이를 무시했기에, 게임 개발자들의 인생을 비참하게 만들었습니다. fp16 2배 속도 지원과 함께 PS4 Pro가 출시되기 전까지 AAA게임들은 대부분 16비트 수학 연산을 무시했습니다.

AI, 레이 트레이싱, 그리고 GPU 주도 렌더링(GPU-Driven Rendering)의 부상과 함께, GPU 제조사들은 그들의 원시 데이터 로드 경로를 최적화하는 것과 더 크고 빠른 범용 캐시를 제공하는 것에 집중하기 시작했습니다. 텍스쳐 샘플러를 통한 로드 라우팅(타입 변환)은 현대 쉐이더에서 종속 로드 체인이 읿반적이게 됨에 따라 매우 큰 지연 시간(latency)을 발생시킵니다. 하드웨어는 좁은(narrow) 8비트, 16비트, 그리고 64비트 타입과 포인터에 대한 네이티브 지원을 갖추게 되었습니다. (*역주. 종속 로드 체인-Dependent Load Chain-은 특정 텍스쳐를 샘플링하고, 그 결과로 다시 특정 텍스쳐를 샘플링하는 LUT같은 형식의 사용을 의미합니다)

대부분의 제조사들은 그들의 고정 기능 정점 페치(Fetch) 하드웨어를 폐기하고, 대신 정점 쉐이더에 표준 원시 로드 명령어를 생성하도록 했습니다. 완전히 프로그래밍 가능한 정점 페치는 개발자가 클러스터화된 GPU 주도 렌더링(Clustured GPU-Driven Rendering)과 같은 새로운 알고리즘을 작성할 수 있게 해주었습니다. 또한 고정 기능 하드웨어를 위한 트랜지스터 예산은 이제 다른 곳에 사용할 수 있게 되었습니다.

메쉬 셰이더는 래스터라이저 진화의 정점으로, 인덱스 중복 제거 하드웨어와 변환 후(Post-Transform) 캐시를 없앴습니다. 이러한 패러다임에서, 모든 입력은 원시 메모리로 취급되었습니다. 유저는 메쉬를 내부적으로 정점을 공유하는 독립적인 메쉬렛(Meshlet)으로 분할하는 책임을 집니다. 이러한 프로세스는 종종 오프라인에서 완료됩니다. GPU는 더 이상 각 드로우 콜 마다 병렬 인덱스 중복 제거를 수행할 필요가 없으므로, 전력과 트랜지스터를 아낄 수 있습니다. 오늘날 게임이 Nvidia의 매출의 10%만 차지하는 반면, AI는 90%를 차지하고 레이 트레이싱은 성장하고 있는 점을 고려할 때, 고정 기능 기하 하드웨어가 최소한의 기능만 남게 되고 드라이버들이 자동으로 정점 쉐이더를 메쉬 쉐이더로 변환하게 되는 것은 시간 문제일 가능성이 높습니다.

모바일 GPU는 타일 기반 렌더러입니다. 타일러(Tilers)은 개별적인 삼각형들을 작은 타일(일반적으로 16x16 에서 64x64 크기 사이의 픽셀들로 구성됨)들로 분류합니다. 메쉬 셰이더는 이 용도로 사용하기엔 너무 조잡(coarse)합니다(*역주. 오버스펙이라는 의미입니다). 메쉬렛을 작은 타일들로 분류하는 것은 심각한 지오메트리 오버셰이딩을 야기할 가능성이 높습니다. 깔끔한 수렴 경로가 없습니다. 우리는 여전히 정점 쉐이더 경로를 지원해야 합니다.

10년 전 DirectX 12.0, Vulkan 1.0, 그리고 Metal 1.0이 등장했을 때, 당시 존재하는 GPU 하드웨어들은 바인드리스 리소스를 폭넓게 지원하지 않았었습니다. API들은 하드웨에들 간의 차이를 추상화하기 위해 복잡한 바인딩 모델을 채택했습니다. DirectX 12는 스테이지당 128개의 리소스를 인덱싱하는 것을 허용했으며, Vulkan과 Metal은 초기에는 디스크립터 인덱싱을 아예 지원하지 않았습니다. 개발자들은 전통적인 바인딩 변경에 따른 오버헤드를 감소시키기 위해 기존의 우회 방법들을 사용해야만 했습니다. 지난 10년간 GPU 하드웨어는 크게 발전했으며 범용 바인드리스 SIMD 설계로 수렴했습니다.

이제 현대의 바인드리스 하드웨어 전용으로 설계한다면 그래픽 API와 셰이더 언어가 얼마나 더 단순해질 수 있는지 살펴봅시다.

Root arguments 루트 인수(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)를 사용합니다(구현 방법은 부록 참조). 이 함수는 구조체 struct {void* cpu, void *gpu}를 반환합니다. CPU 포인터는 영구 매핑된 GPU 메모리에 직접 쓰는 데 사용되며, GPU 포인터는 GPU 데이터 구조체에 저장하거나 디스패치 명령 인자로 전달할 수 있습니다.

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

특별한 유니폼 버퍼 타입이 필요할까요? 최신 셰이더 컴파일러는 자동적인 균일성(uniformity) 분석을 수행합니다. 명령어의 모든 입력이 균일(uniform)하면 출력도 균일합니다. 균일성은 셰이더 전체로 전파됩니다. 모든 최신 아키텍처는 스칼라 레지스터/로드 또는 이와 유사한 구성(Intel의 SIMD1 등)을 갖추고 있습니다. 균일성 분석은 벡터 로드를 스칼라 로드로 변환하는 데 사용되며, 이로써 레지스터를 절약하고 지연 시간을 줄입니다. 균일성 분석은 버퍼 타입(UBO vs SSBO)에 관계없이 동작합니다. 리소스는 읽기 전용이어야 합니다(그래서 GLSL에서는 항상 SSBO에 readonly 속성을 지정하고, DirectX 12에서는 UAV보다는 SRV를 선호하는 것입니다). 또한 컴파일러가 해당 포인터가 별칭(alias)이 아님을 증명할 수 있어야 합니다. C/C++의 const 키워드는 이 포인터를 통해 데이터를 수정할 수 없다는 뜻이지, 다른 읽기-쓰기 포인터가 동일한 메모리 영역을 별칭으로 사용하지 않음을 보장하지는 않습니다. C99는 이를 위해 restrict 키워드를 추가했으며, CUDA 커널에서도 이를 자주 사용합니다. Metal의 루트 포인터는 기본적으로 별칭이 없는(restrict) 상태이며, Vulkan과 DirectX 12의 버퍼 오브젝트도 마찬가지입니다. 우리도 컴파일러가 최적화를 더 자유롭게 수행할 수 있도록 동일한 규칙을 따라야 합니다.

(*역주, 균일성(Uniformity)이란 워프 내의 모든 스레드가 같은 값을 참조/사용함이 보장되었음을 의미합니다. 마찬가지로 GLSL에서 uniform 키워드를 사용하는 리소스 역시 쉐이더를 실행하는 임의의 스레드에 대해 해당 리소스가 항상 같은 값임이 보장된다는 걸 의미합니다)

셰이더 컴파일러가 컴파일 타임에 주소(포인터)의 균일성을 항상 증명할 수 있는 것은 아닙니다. 최신 GPU는 동적인 균일 주소 로드를 기회에 따라 최적화합니다. 메모리 컨트롤러가 벡터 로드 명령어의 모든 레인(Lane, SIMD에서의 각 데이터를 담는 경로)이 균일한 주소를 가지고 있음을 감지하면 SIMD 와이드 대신 단일 레인 로드를 수행합니다. 결과는 모든 레인으로 복제됩니다. 이 최적화는 투명하게 이루어지며, 셰이더 코드 생성이나 레지스터 할당에 영향을 주지 않습니다. 특히 새로운 빠른 원시 로드 경로와 결합하면, 동적으로 균일한 데이터로 인한 성능 저하는 과거에 비해 훨씬 작습니다.

일부 GPU 벤더(ARM Mali 및 Qualcomm Adreno)는 균일성 분석을 한 단계 더 심화시킵니다. 셰이더 컴파일러는 균일 로드(uniform load)와 균일 연산을 추출합니다. 셰이더 실행 전에 스칼라 사전 연산(Preamble)이 실행되며, 드로우/디스패치 전체에 대해 균일 메모리 로드와 연산이 한 번만 수행되고 그 결과는 특수 하드웨어 상수 레지스터(root constants가 사용하는 동일한 레지스터)에 저장됩니다.

위의 모든 최적화를 결합하면 고전적인 16KB/64KB 균일/상수 버퍼 추상화보다 균일 데이터를 처리하는 더 나은 방법을 제공합니다. 많은 GPU가 여전히 root constants, 시스템 값, 프리앰블(위의 단락 참조)을 위해 특수한 균일 레지스터를 가지고 있습니다.

Texture bindings 텍스처 바인딩 #

이상적으로는 텍스처 디스크립터가 GPU 메모리의 다른 데이터와 동일하게 동작함으로써, 다른 데이터와 함께 구조체(struct)에서 자유롭게 혼합될 수 있어야 합니다. 하지만 이러한 수준의 유연성을 모든 최신 GPU가 지원하지는 않습니다. 다행히 지난 10년 동안 바인드리스(bindless) 텍스처 샘플러 설계는 256비트 원시 디스크립터와 인덱싱된 디스크립터 힙이라는 두 가지 주요 방식으로 통합되었습니다.

AMD의 원시 디스크립터 방식은 GPU 메모리에서 256비트 디스크립터를 직접 컴퓨트 유닛의 스칼라 레지스터로 로드합니다. 8개의 연속된 32비트 스칼라 레지스터에 단일 디스크립터가 포함됩니다. SIMD 텍스처 샘플 명령어 실행 중, 셰이더 코어는 256비트 텍스처 디스크립터와 레인별 UV 좌표를 샘플러 유닛으로 전송합니다. 이를 통해 샘플러는 어떤 간접 참조도 없이 텍셀을 주소 지정하고 로드하는 데 필요한 모든 데이터를 얻게 됩니다. 단점은 256비트 디스크립터가 많은 레지스터 공간을 차지하며, 각 샘플 명령어마다 샘플러로 다시 전송해야 한다는 점입니다.

인덱스 기반 디스크립터 힙 방식은 32비트 인덱스를 사용합니다(구형 Intel 내장 GPU에서는 20비트). 32비트 인덱스는 구조체에 저장하기 쉽고 표준 SIMD 레지스터에 로드하기 좋으며 전달하기에도 효율적입니다. SIMD 샘플 명령어를 수행하는 동안 쉐이더 코어는 텍스처 인덱스와 레인별 UV를 샘플러 유닛으로 보냅니다. 샘플러는 힙 베이스 주소 + 텍스처 인덱스 * 스트라이드(현대 GPU에서는 256비트) 연산을 통해 얻어낸 디스크립터 힙 주소에서 디스크립터를 가져옵니다. 텍스처 힙 베이스 주소는 드라이버에 의해 추상화되거나(Vulkan 및 Metal), 사용자가 제공할 수 있습니다(DirectX 12의 SetDescriptorHeaps). 텍스처 힙 베이스 주소를 변경하면 내부 파이프라인 배리어가 발생할 수 있습니다(구형 하드웨어의 경우). 현대 GPU에서는 텍스처 힙의 64비트 베이스 주소가 종종 각 샘플 명령어 데이터의 일부로 포함되어 있어, 여러 힙에서 원활하게 샘플링이 가능합니다(레인별로 64비트 베이스 + 32비트 오프셋). 샘플러 유닛은 첫 번째 접근 후 간접 읽기를 피하기 위해 아주 작은 내부 디스크립터 캐시를 가지고 있습니다. 이러한 디스크립터 캐시는 디스크립터 힙이 수정될 때마다 무효화해야 합니다.

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

All of these differences can be wrapped under an unified texture descriptor heap abstraction. The de-facto texture descriptor size is 256 bits (192 bits on Apple for a separate texture descriptor, sampler is the remaining 32 bits). The texture heap can be presented as a homogeneous array of 256-bit descriptor blobs. Indexing is trivial. DirectX 12 shader model 6.6 provides a texture heap abstraction like this, but doesn’t allow direct CPU or compute shader write access to the descriptor heap memory. A set of APIs are used for creating descriptors and copying descriptors from the CPU to the GPU. The GPU is not allowed to write the descriptors. Today, we can remove this API abstraction completely by allowing direct CPU and GPU write to the descriptor heap. All we need is a simple (user-land) driver helper function for creating a 256-bit (uint64[4]) hardware specific descriptor blob. Modern GPUs have UMA or PCIe ReBAR. The CPU can directly write descriptor blobs into GPU memory. Users can also use compute shaders to copy or generate descriptors. The shader language has a descriptor creation intrinsic too. It returns a hardware specific uint64x4 descriptor blob (analogous to the CPU API). This approach cuts the API complexity drastically and is both faster and more flexible than the DirectX 12 descriptor update model. Vulkan’s VK_EXT_descriptor_buffer (https://www.khronos.org/blog/vk-ext-descriptor-buffer) extension (2022) is similar to my proposal, allowing direct CPU and GPU write. It is supported by most vendors, but unfortunately is not part of the Vulkan 1.4 core spec. 이러한 모든 차이는 통합된 텍스처 디스크립터 힙 추상화로 감쌀 수 있습니다. 사실상의 텍스처 디스크립터 크기는 256비트(Apple에서는 텍스처를 위해 디스크립터의 192비트를 사용한 후, 나머지 32비트에 샘플러 저장)입니다. 텍스처 힙은 256비트 디스크립터 블롭(Blob)의 균질한 배열로 제시될 수 있습니다. 인덱싱은 단순합니다. DirectX 12 셰이더 모델 6.6은 이와 같은 텍스처 힙 추상화를 제공하지만, 디스크립터 힙 메모리에 대한 직접적인 CPU 또는 컴퓨트 셰이더 쓰기 액세스를 허용하지 않습니다. 디스크립터를 생성하고 CPU에서 GPU로 디스크립터를 복사하기 위해 일련의 API가 사용됩니다. GPU는 디스크립터를 쓸 수 없습니다. 오늘날 우리는 디스크립터 힙에 대한 직접적인 CPU와 GPU 쓰기를 허용함으로써 이 API 추상화를 완전히 제거할 수 있습니다. 우리에게 필요한 것은 256비트(uint64[4]) 하드웨어 특정 디스크립터 블롭을 생성하는 간단한(사용자 공간) 드라이버 도우미 함수뿐입니다. 최신 GPU는 UMA 또는 PCIe ReBAR를 갖추고 있습니다. CPU는 GPU 메모리에 디스크립터 블롭을 직접 쓸 수 있습니다. 사용자는 컴퓨트 셰이더를 사용하여 디스크립터를 복사하거나 생성할 수도 있습니다. 셰이더 언어에도 디스크립터 생성 내장 함수가 있습니다. 하드웨어별 uint64x4 디스크립터 블롭(blob)을 반환합니다(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));

-작성중-

QnA #

Q. Lane?

A. 병렬 실행되는 워프 내의 개별 스레드

Q. A 32-bit heap index is just 4 bytes, we can send it per lane. In contrast, a 256-bit descriptor is 32 bytes. It is not feasible to fetch and send a full 256-bit descriptor per lane. » 32비트(4바이트) 인덱스를 사용하는 이유?

32-bit 인덱스:
- 작음 (4바이트)
- 32개 레인 = 128바이트 (한 번에 전송 가능)
- 충분한 용량(2^32개 텍스쳐)
- non-uniform 한 인덱싱에 최적
256-bit 디스크립터:
- 큼 (32바이트)
- 32개 레인 = 1024바이트(현실적으로 불가)
- 균일 인덱싱에서만 사용 가능(모든 레인이 서로 같은 디스크립터 세팅으로 이루어질 때)

GPU는 워프 내 레인들이 개별 스택 메모리를 가지지 않고(로컬 메모리를 가질 수 있지만 VRAM에 할당하므로 느림) 공유 레지스터 집합을 사용함. 이 공유 레지스터 파일은 총 512바이트.

만약 모든 레인에서 서로 다른 디스크립터를 사용해야 한다면? ex) 레이 트레이싱으로 32개 픽셀에서 광선을 쐈는데 모두가 다른 머티리얼의 오브젝트와 Intersect하는 경우

-> 디스크립터 인덱싱 -> 4Byte(32-bits) * 32 = 128 Bytes » 레지스터에 전부 올릴 수 있음

-> 디스크립터 데이터 -> 32Byte(256-bits) * 32 = 1024 Bytes » 레지스터 전체 용량 초과

따라서 디스크립터 데이터를 사용할 경우 워프 내 모든 스레드가 SIMT(Parallel)하게 동작이 불가능해져서 병목이 발생함.

Hamsik2rang