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 역시 그 방향으로 점점 나아가고 있다.
HLSL에 대한 인력 부족은 우리 팀에 매우 큰 문제였다. 우리는 새로운 셰이더 모델 기능을 지속적으로 공개해야 한다는 막대한 압박을 받아왔지만, 새로운 하드웨어 기능을 노출하는 동시에 사용자의 생산성을 높이기 위해 HLSL 자체를 발전시킬 만큼 충분히 큰 팀을 가져본 적이 없다. 그 결과 여러 단기적인 결정들이 이어졌다. 우리는 지름길을 택했고 막대한 기술 부채를 떠안게 되었는데, 그중 가장 대표적인 사례는 DXC가 10년도 더 지난 LLVM 3.7에 묶여 있다는 점이다.
냉정한 진실은, 훌륭한 프로그래밍 언어와 컴파일러는 어떤 플랫폼이 갖춰야 할 기본 요건일 뿐, 그것만으로 더 많은 하드웨어나 소프트웨어 라이선스를 판매하게 만들지는 않는다는 점이다. 그렇다고 해서 품질이 나쁜 언어와 컴파일러가 문제가 되지 않는 것은 아니다. 오히려 그것들은 개발자들에게 과도한 부담을 주어 양질의 소프트웨어를 출시하는 능력을 저해하고, 이는 결국 매출에 부정적인 영향을 미친다.
나는 아직 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세기 초 미국의 만화가. 아주 단순한 일을 하기위해 지나치게 복잡한 프로세스를 가진 장치나 절차를 풍자함 [본문으로]
'Technical Report > Graphics Tech Reports' 카테고리의 다른 글
| 2025 TA Campus 수업 문서 링크 (0) | 2026.01.20 |
|---|---|
| GPU Works Graphs(1) (0) | 2025.09.04 |
| [번역중]Microflake theory (0) | 2025.07.14 |
| GPU Specification compare PS5/XBOX Series X/Adreno/PC (0) | 2025.05.24 |
| [번역]Forward vs Deferred vs Forward+ Rendering with DirectX 11(2) Deferred Rendering (0) | 2025.05.12 |
