# 그래픽스 API가 필요 없는 시대를 향하여 > Clean Markdown view of GeekNews topic #25126. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25126](https://news.hada.io/topic?id=25126) - GeekNews Markdown: [https://news.hada.io/topic/25126.md](https://news.hada.io/topic/25126.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2025-12-17T06:59:34+09:00 - Updated: 2025-12-17T06:59:34+09:00 - Original source: [sebastianaaltonen.com](https://www.sebastianaaltonen.com/blog/no-graphics-api) - Points: 7 - Comments: 1 ## Summary 현대 GPU는 이미 **64비트 포인터와 바인드리스 리소스**를 완벽히 지원하지만, DirectX 12나 Vulkan 같은 기존 API는 여전히 10년 전의 복잡한 바인딩 모델에 묶여 있습니다. 글에서 제안하는 차세대 설계는 **C/C++ 포인터 기반 메모리 접근**과 단일 루트 포인터를 통해 파이프라인·배리어·바인딩 구조를 통합하며, GPU 메모리와 셰이더 언어를 직접 연결하는 단순한 모델을 제시합니다. 이는 DirectX 13이나 Vulkan 2.0이 지향해야 할, GPU 중심의 새로운 그래픽스 API 패러다임으로 읽힙니다. ## Topic Body - 지난 10년간 **DirectX 12, Vulkan, Metal** 등 저수준 그래픽스 API는 GPU 성능을 끌어올렸지만, 복잡성과 유지비용이 급격히 증가함 - 현대 GPU는 **완전한 캐시 계층, 64비트 포인터, 바인드리스(bindless) 리소스**를 지원해 기존의 복잡한 상태 객체와 바인딩 모델이 불필요해짐 - 제안된 설계는 **C/C++ 포인터 기반 메모리 접근**과 **단일 64비트 루트 포인터**를 사용해 렌더링 파이프라인을 대폭 단순화 - **PSO 폭발, 리소스 배리어, 복잡한 바인딩 API**를 제거하고, GPU 메모리와 셰이더 언어를 직접 연결하는 구조를 제시 - 이 접근은 **현대 GPU 아키텍처에 최적화된 차세대 API**로, DirectX 13이나 Vulkan 2.0이 지향해야 할 방향을 제시함 --- ### 저수준 그래픽스 API의 변화 - 2013년 Xbox One과 PS4의 **AMD GCN 아키텍처**가 AAA 게임 개발의 표준이 되며, Mantle·DirectX 12·Vulkan·Metal 같은 저수준 API가 등장 - 즉, 이들은 **2013년 전후 GPU 아키텍처**를 기준으로 설계됨 - 기존 **DirectX 11/OpenGL**은 단일 스레드 렌더링과 높은 드라이버 오버헤드로 한계가 있었음 - 이들 API는 **사전 컴파일된 파이프라인 객체(PSO)** 로 드로우콜 비용을 줄였지만, 엔진 구조와 맞지 않아 복잡성이 증가 - 결과적으로 엔진 내부에 또 다른 “로우레벨 드라이버 계층”이 생겨, 그래픽스 프로그래머의 역할이 세분화됨 ### 역사적 배경: 왜 이렇게 복잡해졌는가 - 초기 GPU는 분리된 메모리와 고정 기능 파이프라인 중심 구조였음 - OpenGL·DirectX는 **하드웨어 다양성 추상화**를 위해 상태 기반·객체 기반 설계를 채택 - DirectX 11까지도 텍스처·버퍼가 **불투명 디스크립터**로 관리됨 - 이러한 설계가 이후 API까지 **관성처럼 유지**됨 ### 현대 GPU와 API의 불일치 - 현재 GPU는 **일관된 캐시 계층, PCIe ReBAR, 64비트 포인터, 바인드리스 텍스처**를 지원 - **CPU가 GPU 메모리를 직접 쓰고 GPU가 즉시 읽는 구조** 가능 - 이러한 환경에서는 **PSO·디스크립터 세트·바인딩 테이블** 같은 구조가 불필요 - PSO 캐시 폭증 문제로 인해 수백 GB의 캐시가 필요하며, 이는 **로딩 지연과 스터터링**의 원인 - 새로운 API는 이러한 구시대적 구조를 제거하고 **단순한 포인터 기반 접근**으로 전환 가능 ### GPU 메모리 관리의 단순화 - 기존 Vulkan/DirectX 12는 **리소스 생성 후 힙 호환성 조회**가 필요해 비효율적 - 제안된 방식은 **gpuMalloc/gpuFree** 형태의 단순 API로 GPU 메모리를 직접 할당 - CPU가 직접 GPU 메모리를 매핑해 초기화 가능 - 대용량 데이터는 복사 명령으로 전송해 **DCC 압축 및 swizzle 처리** 수행 - CPU 매핑 주소와 GPU 주소를 구분하며, **gpuHostToDevicePointer**로 변환 ### 데이터와 셰이더 언어의 현대화 - CUDA·Metal·OpenCL처럼 **C/C++ 포인터 기반 셰이더 언어**를 사용 - 구조체 단위의 **와이드 로드(128비트 이상)** 로 효율적 메모리 접근 가능 - DirectX의 **ByteAddressBuffer**나 **텍셀 버퍼**는 더 이상 최적이 아님 - GLSL/HLSL은 포인터 미지원으로 **재사용 가능한 셰이더 라이브러리 생태계 부재**, 반면 CUDA는 풍부한 라이브러리로 발전 ### 루트 인자와 데이터 구조 - GPU 커널은 **단일 64비트 포인터**를 입력받아 구조체로 캐스팅 - CPU와 GPU가 동일한 C/C++ 헤더를 공유해 데이터 구조 일관성 확보 - **const/restrict** 키워드로 컴파일러 최적화 유도, 불필요한 UBO/SSBO 구분 제거 - 현대 GPU의 **스칼라 레지스터 프리로딩**과 **동적 유니폼 최적화**를 활용 ### 텍스처 바인딩의 단순화 - 모든 텍스처를 **256비트 디스크립터 배열(힙)** 로 관리, CPU·GPU가 직접 쓰기 가능 - **32비트 인덱스 기반 접근**으로 비균일(non-uniform) 텍스처 샘플링 지원 - DirectX 12 SM 6.6의 디스크립터 힙보다 단순하며, **Vulkan VK_EXT_descriptor_buffer**와 유사 - 텍스처 객체 생성·업로드·샘플링이 모두 **GPU 메모리 포인터 기반**으로 통합 ### 셰이더 파이프라인과 상수 - 파이프라인 생성은 단순히 **셰이더 IR 로드 후 gpuCreatePipeline 호출** - 루트 시그니처, 디스크립터 세트, 바인딩 정의 불필요 - **정적 상수(struct 기반)** 로 셰이더 특수화 상수를 대체, **PSO 조합 폭발** 문제 완화 - 상수 구조체에 GPU 포인터 포함 가능, 런타임 주소를 직접 하드코딩 가능 ### 배리어와 동기화의 단순화 - 기존 API의 **리소스별 배리어 리스트**는 현대 GPU 구조와 불일치 - 제안된 모델은 **큐/스테이지 단위 비트필드 플래그**만 사용 - **gpuBarrier(before, after, hazard)** 형태로 단순화, 리소스 추적 불필요 - **gpuSignalAfter / gpuWaitBefore** 명령으로 타임라인 세마포어와 유사한 GPU→GPU 동기화 구현 ### 커맨드 버퍼와 렌더링 - **일회성(transient) 커맨드 버퍼**만 사용, Vulkan의 복잡한 재사용 모델 제거 - **gpuBeginRenderPass / gpuEndRenderPass** 로 렌더 타깃 설정 및 클리어 수행 - 렌더패스 간 자동 배리어 없음, 병렬 렌더링 및 깊이 프리패스 최적화 가능 ### 래스터 파이프라인 단순화 - **버텍스/픽셀 셰이더**는 포인터 기반 데이터 접근으로 바인딩 API 제거 - **GpuDepthStencilState**, **GpuBlendState**를 PSO에서 분리해 조합 수 감소 - 모바일 GPU는 **프레임버퍼 fetch intrinsic**으로 프로그래머블 블렌딩 지원 - PSO는 최소한의 상태(토폴로지, 포맷, 샘플 수 등)만 포함 ### 간접 드로우와 GPU 구동 렌더링 - 모든 인자(data, arguments)를 **GPU 포인터**로 전달 - **gpuDrawIndexedInstancedIndirectMulti** 로 멀티드로우 지원 - GPU가 직접 루트 데이터와 드로우 인자를 생성 가능, 완전한 **GPU-driven 렌더링** 구현 ### 툴링과 호환성 - 포인터 기반 구조는 **CUDA/Metal 디버거**처럼 심볼 정보를 통해 추적 가능 - 가상 메모리로 보호되어 보안 문제 없음, 잘못된 접근 시 페이지 폴트 발생 - **MoltenVK, Proton** 사례처럼 기존 DirectX/Vulkan/Metal API를 변환 계층으로 호환 가능 ### 최소 사양 및 결론 - **Nvidia Turing(2018)** , **AMD RDNA1(2019)** , **Intel Xe1(2022)** , **Apple M1(2020)** 등은 모두 제안된 기능 지원 - 요즘 GPU는 이미 **바인드리스·64비트 포인터·일관 캐시** 구조로 바뀌었음 - **API만이 과거의 추상화에 발목 잡혀 있음** - 새로운 API는 **DirectX 11보다 단순하고, Vulkan보다 빠르며, Metal보다 유연** - 차세대 **Vulkan 2.0 / DirectX 13**은 이러한 **완전 바인드리스 설계**로 전환해야 하고, HLSL/GLSL 대신 **C/C++ 포인터 기반 셰이더 언어**로 생태계 확장을 추진해야 함 ## Comments ### Comment 47863 - Author: neo - Created: 2025-12-17T06:59:35+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46293062) - 이 글은 **Vulkan**과 **DX12**의 불필요한 부분을 잘 보여주는 훌륭한 글임 요즘 DX12는 버퍼 포인터조차 지원하지 않아 사실상 방치된 느낌이고, Vulkan도 2.0으로 정리되지 않아 **확장 기능**이 제대로 구현되지 않은 드라이버가 많음 만약 이런 새로운 API가 존재한다면, OpenGL을 그 위에서 훨씬 빠르게 에뮬레이션할 수 있고, SDL3 GPU 같은 것도 3~4배 성능 향상을 얻을 수 있을 것 같음 - 현재 **DirectX 문서화** 상태가 너무 안 좋음 Frank Luna의 책도 최신 기능을 다루지 않고, Learn 사이트나 GitHub 샘플, 레퍼런스 문서를 뒤져야 함 Vulkan도 마찬가지로 복잡한데, 설령 2.0이 나와도 특히 **Android** 같은 주요 플랫폼에서 실제로 어떻게 쓸 수 있을지 의문임 - 이 모든 게 **PCI Resizable BAR** 요구사항 때문이 아닐까 생각함 Intel Arc를 제외하면 대부분의 GPU가 reBAR 없이도 동작하지만, Microsoft나 Intel이 이를 UEFI에서 강제해야 **bindless texture** 같은 기능을 안정적으로 쓸 수 있을 것 같음 다만 이 경우 지원 가능한 하드웨어의 하한선이 생기고, 2020년 이전 메인보드에서는 지원이 들쭉날쭉함 - 글의 핵심 동기가 빠져 있음 블로그 인덱스에 따르면 “지난 10년간 그래픽스 API와 셰이더 언어의 복잡성이 급격히 증가했으며, 이제는 **추상화 계층을 단순화**해 개발 효율과 성능을 높이고 미래 GPU 워크로드에 대비해야 한다”는 취지임 - 이건 마치 **NVMe**가 등장한 이유와 비슷함 SSD가 처음엔 IDE/SATA 인터페이스를 재활용했지만, 회전식 디스크 전제를 버리고 새 전송 방식을 만들어야 진정한 성능을 낼 수 있었음 그래픽스 API도 그런 **레거시 제약**을 버려야 할 시점이라는 비유로 보임 - 나는 **Sebastian Aaltonen**의 작업을 오래 지켜봐서 편향이 있을 수도 있지만, 이번 글은 정말 훌륭함 앞으로의 방향은 **소프트웨어 렌더링으로의 회귀**라고 생각함 다만 이번에는 그 알고리즘과 데이터 구조가 하드웨어 가속을 받는다는 점이 다름 이미 VFX 업계에서는 이런 흐름이 진행 중이며, 약 5년 전 **OTOY**가 OctaneRender를 CUDA 기반으로 포팅한 것도 그 예임 - GPU 내부에는 **고정 기능 하드웨어**가 많아, 이를 버리면 성능이 크게 떨어질 것임 셰이더 타입들은 이런 파이프라인 사이를 메우는 역할을 하므로 완전한 소프트웨어화는 현실적이지 않음 - 사실 이런 변화는 이미 일부 일어나고 있음 예를 들어 **Unreal Engine의 Nanite**는 작은 삼각형을 처리할 때 GPU의 **compute shader**로 동작하는 소프트웨어 래스터라이저를 사용함 - 글의 디테일이 인상적이었음 일부만 이해했지만, 앞으로의 **그래픽스 API 설계 참고서**가 될 것 같음 대부분의 게이머에게 Vulkan/DX12는 큰 이득이 아니었고, PSO 문제로 여러 게임이 고생했음 Vulkan이 개선 중이지만 WebGPU는 초기 Vulkan 설계의 제약을 그대로 물려받았음 하드웨어가 빠르게 진화하는 상황에서 너무 저수준 API로 간 게 실수였을 수도 있음 오히려 **CUDA**처럼 범용 컴퓨팅 중심의 접근이 더 나은 방향일지도 모름 - **Mantle**이 그립다는 생각이 듦 단점도 있었지만, 하드웨어를 직접 다루는 느낌이 있었고, **Xbox 360** 개발 때가 가장 즐거웠음 - **Switch의 그래픽스 API**도 비슷하게 훌륭함 Nvidia와 Nintendo가 설계했는데, 콘솔 중 가장 직관적인 API라고 생각함 - 이 글을 읽고 나니 **역사적인 순간**을 목격한 기분이 듦 - 관련된 프로젝트로 보이는 [Google Toucan](https://github.com/google/toucan)을 떠올림 - 이 글이 예전 기억을 많이 떠올리게 함 API 설계자들이 고려하는 추가 요소로는 * **GPU 가상화** — 여러 애플리케이션이 GPU 리소스를 공유할 수 있게 하는 기능 (예: D3D residency API) * **정의되지 않은 동작(Undefined Behavior)** — 애플리케이션이 의도치 않게 이를 의존할 경우, 새로운 API로의 이식이 어려워짐 - 왜 Microsoft가 새로운 **DirectX 버전**을 내지 않는지 궁금함 DirectX Ultimate이나 12.2도 사실상 DX12와 동일함 **Unreal Engine** 같은 미들웨어의 영향으로 자체 API의 중요성이 줄어든 걸까, 아니면 EPIC이 새로운 API를 제안해야 할까 생각함 - 이런 논의는 주로 **FOSS 커뮤니티**에서만 활발함 실제 게임 개발자는 RHI(Rendering Hardware Interface)를 만들어 게임 개발에 집중함 **레이 트레이싱**과 **메시 셰이더**가 가장 큰 혁신이었지만, 여전히 활용이 적어 더 나아가지 않는 듯함 - 어느 정도는 둘 다 맞음 Unreal, Unity 같은 엔진의 **중앙집중화**로 API 혁신에 대한 관심이 줄었고, GPU 쪽에서만 발전이 이어짐 CPU API는 여전히 단순한 버퍼 매핑 수준임 과거 **테셀레이션 셰이더**가 등장했을 때처럼, 새로운 하드웨어 변화가 있어야 진전이 있을 것 같음 - **Valve**가 SteamOS용 자체 그래픽스 API를 만들 가능성이 있을지 궁금함 - 사실 **Vulkan의 복잡성**에는 Valve의 책임도 큼 Vulkan 초기 개발 단계에서 Valve가 주요 주도자 중 하나였다고 들었음