요약
OpenGL ES 3.0은 14년 된 API지만 그래픽스 입문 수업에는 여전히 쓸 만합니다.
스위스 SAE 인스티튜트 제네바에서 컴퓨터 그래픽스 입문 과목을 가르치는 엘리아스 파르한의 글입니다. 업계 행사에서 게임들이 최신 API로 옮겨 가는 흐름을 보고, 수업도 바꿔야 할지 다시 따져 봤습니다.
왜 중요한가
- 현장 교사는 입문 수업에서 최신 기능보다 이식성과 단순함을 더 중요하게 봤습니다.
- 강의 자료를 새 API로 모두 옮기는 비용이 커서, 전환하려면 그만한 이득이 확실해야 한다고 했습니다.
핵심 내용
- 같은 C++ 코드와 셰이더로 윈도, 리눅스, 안드로이드, Nintendo Switch에서 모두 돌릴 수 있습니다.
- WebGL2와 호환되어 학생들이 과제를 웹용으로 컴파일해 자기 블로그에 올릴 수 있습니다.
- 드라이버가 동기화를 맡아 초기 설정 코드가 짧은 대신, 드라이버 오버헤드(추가 처리 부담)를 감수합니다.
- 컴퓨트 셰이더, 간접 그리기, 하드웨어 레이트레이싱, 멀티스레드 렌더링은 설명만 하고 구현하지 않습니다.
- SDL GPU는 입문용으로 군더더기가 많고, WebGPU는 새 셰이더 언어까지 배워야 해서 택하지 않았습니다.
HN 반응
- OpenGL의 상태 기계(전역 상태를 바꿔 가며 그리는 방식)와 부실한 오류 보고 탓에 WebGPU가 낫다는 의견에, WebGPU도 이미 낡고 느리다는 반론이 맞섰습니다.
- 그래픽스 개념은 소프트웨어 렌더러를 직접 짜며 배우는 편이 낫다는 의견과, OpenGL 4.5·4.6이 수업에 알맞다는 교육자 경험담도 나왔습니다.
개인적으로는 OpenGL ES 3.0이든 어떤 OpenGL이든 가르치지 않겠습니다. 상태 머신( https://webgl2fundamentals.org/webgl/lessons/resources/webgl-state-diagram.html )과 끔찍한 오류 체계 때문에 버그를 추적하기가 어렵기 때문입니다. 대신 WebGPU를 가르치겠습니다. 이식성이 좋고 오류 메시지도 훌륭합니다.
반대하는 사람이 있으리라 생각합니다. 그래도 저는 WebGPU가 이해하기 더 쉽고, 오류 메시지가 더 낫고, 상태 머신이 없고, C++, Rust, JS/TS 등 여러 언어에서 쓸 수 있으며, 나중에 Metal이나 D3D12, Vulkan으로 넘어갈 때도 현대 GPU 프로그래밍에 더 가깝다고 주장하겠습니다.
게다가 OpenGL(과 ES)은 학생들이 맞닥뜨릴 수 있는 버그와 비호환성의 악몽인데, WebGPU는 그런 문제를 해결해 줍니다.
그렇긴 해도 기사에서 애플 플랫폼을 언급했는데, 학생들이 거기에 묶여 있다면 ANGLE을 쓸 수 있습니다.
GL의 프로그래밍 모델에 대해서는 대체로 동의하지만, 솔직히 WebGL2에서 고쳐진 문제도 있습니다. 검증과 오류 보고가 훨씬 나아졌고(브라우저 콘솔에 바로 뜨는 아주 유용한 오류 메시지처럼요), 현재 WebGPU 상태까지 포함해도 아마 모든 3D API 구현 가운데 버그가 가장 적고 이식성이 가장 좋을 겁니다.
가르칠 때는 보통 웹 브라우저에서 WebGL2나 WebGPU를 쓰겠습니다. 브라우저 환경에서는 첫 삼각형을 띄우기까지 필요한 보일러플레이트가 훨씬 적고, 수정-테스트 루프도 거의 즉각적이기 때문입니다.
현실에서는 버그가 널려 있고 읽기 어려운 오류 메시지도 많습니다.
보일러플레이트 문제라면, 보일러플레이트가 이미 처리된 저장소를 학생들에게 클론하게 하면 됩니다.
진짜 물어야 할 것은 학생들이 저수준 언어로 프로그래밍할 줄 알기를 바라는지 아닌지입니다. 프로그래밍의 현실이 어떤지 보게 할 것인지 아닌지요.
C/C++로 프로그래밍하고 오류 메시지를 디버깅하지 못하면 실무에서 어떻게 살아남겠습니까? LLM을 쓰겠지요.
문제는 네이티브 GL에서는 애초에 오류 메시지를 전혀 받지 못한다는 겁니다. 선택 사항인 KHR_debug 확장으로 디버그 메시지 콜백을 연결하지 않는 한 그렇고, 이 확장은 모든 환경에서 쓸 수 있는 것도 아닙니다. 내장 오류 체계인 glGetError()는 사실상 완전히 쓸모가 없습니다.
D3D, Vulkan, Metal 같은 다른 API에는 이런 문제가 없습니다. 모두 아주 유용한 메시지를 주는 훌륭한 검증 레이어가 있고, 브라우저에서 돌아가는 WebGL이나 WebGPU도 기본적으로 그런 검증 레이어를 갖추고 있습니다.
사소한 지적인데, 그건 사실이 아닙니다. GL 4.3부터는 최신 디버그 메시지 콜백이 코어에 들어 있어서 믿고 쓸 수 있습니다. 물론 macOS에서는 도움이 안 되겠지만, 최신 OpenGL을 대상으로 할 수 있다면 실제로는 문제가 되지 않습니다.
KHR_debug는 비동기로 호출되기 때문에 쓰기에도 좀 골치 아픕니다(물론 그게 원하는 동작이긴 하지만, 어려움이 있는 건 여전합니다).
"선택 사항인 KHR_debug 확장으로 디버그 메시지 콜백을 연결하지 않는 한, 이 확장은 모든 환경에서 쓸 수 있는 것도 아닙니다"
OpenGL이 예컨대 Direct3D보다 아름다운 점은 확장할 수 있다는 것이고, 그래서 원하면 그 기능을 직접 추가할 수 있습니다.
다행히 "아름다움은 보는 사람의 눈에 달렸다"고 하잖아요 ;) 저는 GL이나 Vulkan의 확장 난장판보다 D3D 방식이 확실히 더 좋아요.
하지만 WebGPU는 웹용으로 설계되고 2015년께의 하드웨어를 겨냥한 API라는 한계를 계속 안고 갈 겁니다.
OpenGL보다는 낫지만 큰 개선은 기대하지 마세요. Chrome 팀이 밀어붙이고 싶은 것 말고는요. Firefox나 Safari 팀이 1.0 이후 방향에 대해 할 말이 많이 남았을 것 같지도 않고요.
어떤 개선이 필요하다는 건가요? 제가 보기엔 거의 완성된 것 같고, 유지보수 모드(즉 안정된 상태)에 있는 게 오히려 좋다고 생각해요.
WebGPU의 BindGroup 객체를 통한 경직된 리소스 바인딩 모델은 이미 구식입니다(웃기게도 이 부분에서는 WebGPU가 실제로 WebGL2보다 느립니다. 적어도 바인딩을 자주, 예측할 수 없게 바꿔야 한다고 가정하면요).
이건 Vulkan 1.0 API의 제약이었고, WebGPU의 리소스 바인딩 모델을 그에 맞춰 설계하면 문제가 생기리라는 건 충분히 예측할 수 있었습니다. Vulkan에서는 성능을 조금 희생하더라도(그 영향이 실제로 중요한 곳은 안드로이드 폰과 리눅스 데스크톱뿐입니다) 얇은 추상화를 고안했어야 했고, 그랬다면 적어도 모든 플랫폼에서 WebGPU가 느려지는 일은 없었을 겁니다.
그런데 이제는 Vulkan 관리자들마저 이 문제를 깨닫고 훨씬 유연한 descriptor-heap 확장을 도입하고 있습니다(10년쯤 늦었지만, 안 하는 것보다는 낫죠).
WebGPU는 본질적으로 약 10년 전 3D API들의 단면을 얼려 놓은 것이고, GPU 하드웨어 상태로는 15~20년 전 수준입니다(다만 솔직히 망가진 바인딩 모델을 빼면 달리 할 수 있는 것은 별로 없었습니다. 제약 대부분이 브라우저용 3D API라면 반드시 지원해야 하는 모바일 GPU에서 오기 때문입니다).
모놀리식 파이프라인이에요. 이렇게 동작하는 하드웨어는 사실상 없고, 해시-후-캐시 설계는 구조를 경직시키고 오버헤드만 잔뜩 얹어요.
WGSL은, 아니 진짜 좀 그렇잖아요.
기능 목록이 우스울 만큼 구식이에요. 메시 셰이더도, 하드웨어 레이 트레이싱(HWRT)도, 협력 행렬/텐서(cooperative matrices/tensors) 같은 것도 없고요.
웹이라 신뢰할 수 없는 코드:tm: 때문에 보안 중심으로 설계돼서 호출 대부분이 우스울 만큼 느려요. 네, 데스크톱 구현도 마찬가지예요. 쓸 만한 WebGPU 구현은 어디에도 없어요.
구현하기도 쓰기도 간단하지 않아요. 사실상 Vulkan의 난이도에 장점은 하나도 없는 셈이죠...
동의하지 않습니다. WebGPU는 이미 구식이 된 완전히 쓸모없는 미들웨어이고, WebGL용 컴퓨트 셰이더 제안을 죽여 버렸다는 점이 거슬립니다. 게다가 WebGPU는 아직도 브라우저에서 기본으로 작동하지 않습니다.
wasm에서 WebGPU와 상호작용하는 것도 WebGL보다 느린 경우가 많습니다. API가 더 저수준이라 JS 쪽에서 GC 오버헤드가 더 생기기 때문입니다.
관련해서, 90년대에 훌륭한 OpenGL 튜토리얼을 내놓은 NeHe(Neon Helium)에게 감사를 전하고 싶습니다.
저도, 아마 다른 많은 분도 그의 강의에서 엄청난 도움을 받았을 겁니다.
NeHe의 튜토리얼은 지금도 온라인에 있어요.
https://nehe.gamedev.net/
향수에 젖게 되네요!
아마 제 경력은 그분 덕분일 겁니다. 그의 튜토리얼로 옛 고정 파이프라인 OpenGL API를 배운 것이 게임을 만들게 된 계기였고, 그 게임들 덕분에 가족 한 분이 자기 회사 인턴십 면접을 보라고 권했습니다. 그 모든 일이 이어져 (지금까지) 20년째 소프트웨어 엔지니어로 일하고 있습니다.
세상에, NeHe를 완전히 잊고 있었네요! 부모님 댁 어딘가에 그 강의 몇 개를 출력해 둔 게 아직 있을 거예요.
좋은 시절이었죠.
저는 어떤 API를 쓸 때보다 소프트웨어 래스터라이저와 레이 트레이서를 직접 짜면서 그래픽스를 더 많이 배웠습니다. 목표가 GPU 렌더링을 가르치는 것에 한정된다면 OpenGL이 다른 API보다 가르치기에 확실히 낫습니다. 하지만 목표가 그래픽스와 렌더링 개념을 가르치는 것이라면 OpenGL 같은 API는 그저 비참하고 역효과만 냅니다.
동의합니다. 다만 그 점에서는 새 API보다 OpenGL이 낫습니다. 레거시 OpenGL은 더 낫다고 말하고 싶고요.
원하는 건 뭐든 소프트웨어로 구현하고, 래스터라이제이션처럼 특정 부분만 GL에 대충 떠넘기면 됩니다. 나머지 보일러플레이트 코드는 최소한이 됩니다.
새 API에서는 본론에 들어가기까지 보일러플레이트 코드를 수백 줄 써야 합니다. 무게중심 좌표(barycentric coordinates)를 배워야 할 시간에 디스크립터 셋(descriptor sets)을 배우고 있는 겁니다. 그러고도 래스터라이제이션, 텍스처 매핑, 클리핑, 면 컬링은 배우지 못합니다. 여전히 고정 파이프라인이기 때문입니다.
100% CPU 렌더링으로 배울 때의 유일한 문제는 그 지점까지의 모든 것을 배우고 구현해야 하니 멋진 결과를 보기 전까지 인내심이 좀 필요하다는 점입니다.
동의하지 않습니다. 모든 그래픽스와 렌더링을 OpenGL이라는 렌즈로만 표현하려 들면 당연히 실패하고, 래스터라이제이션 중심의 OpenGL에서는 지저분한 우회 없이 레이 트레이싱으로 3D 렌더링 자체를 하는 것도 불가능합니다. 이건 분명한 사실입니다.
저를 고성능 그래픽스 프로그래밍과 병렬 이미지 처리로 이끈 근본적인 사고 전환, 즉 "아하!" 하는 순간은, 프래그먼트 셰이더라는 구속복 안에 갇혀 같은 출력 버퍼의 이웃 픽셀에 접근하지 못한 채 최종 픽셀을 독립적으로 계산하는 방법을 표현해야만 하는 상황에서 왔습니다. Vulkan에 비해 손을 잡아 주는 친절함과 상대적 단순함이 있고, 순수 소프트웨어 구현에 비해 미리 정해진 셰이더 파이프라인이라는 제약이 있는 OpenGL이야말로 제가 그래픽스 프로그래밍에 입문하는 데 필요했던 바로 그것입니다. 훌륭한 출발점이라고 생각합니다.
제가 그분 글을 해석하기로는, 투영 기하학 입문 같은 내용은 GPU 없이도 훨씬 쉽게 가르칠 수 있다는 얘기입니다.
네, 제 말이 그거예요. 고마워요.
안타깝지만 OpenGL의 목표는 그래픽스와 렌더링 개념을 가르치는 것이 아닙니다. DirectX, Vulkan, WebGL 등도 마찬가지입니다. 이런 API들은 배우기 쉬운 것이 아니라 성능을 우선해서 설계됩니다. 가르치고 배울 때는 먼저 소프트웨어로 래스터라이제이션과 레이 트레이싱부터 시작하는 것이 훌륭한 방법입니다! 그래픽스 개념을 먼저 익힐 수 있고, 더 빠르게 만들고 싶을 때 그래픽스 API를 배울 동기도 충분히 생기니까요.
제가 보기에 한 학기짜리 수업에서 그래픽스를 처음 배우는 학생들에게는 OpenGL 4.5/4.6이 딱 알맞은 지점입니다. SDL_GPU도 중간 단계로 고려해 볼 만합니다.
제 경험을 떠올려 보면, 그래픽스 개념을 배우는 와중에 새 API(OpenGL), 새 패러다임(GPU 프로그래밍), 새 언어(GLSL)를 한꺼번에 익히는 것은 부담이 큽니다. OpenGL 4.5와 4.6은 시작하기에 충분히 현대적이고, 제가 바탕으로 삼은 3.3 이상 내용을 배울 좋은 자료도 많습니다.
'왜 그런지'에 대한 제 논문은 제 웹사이트(mshah.io)에서 볼 수 있습니다.
저도 한동안 4.6 기반 튜토리얼을 만들고 있습니다. 첫 릴리스가 가까워지면 리뷰를 부탁드려야겠네요 :)
제 생각에 구버전 GL은 초보 프로그래머에게 가르치기가 더 편한 느낌입니다. 각각의 일을 하는 구체적인 함수가 따로따로 많아서, 장황하고 단계별로 풀어서 설명할 수 있거든요. 하지만 전달해야 할 내용 상당수는 숨겨진 상태 머신으로 가는 복잡한 인터페이스를 이해하는 일입니다. 또 한 번에 한 단계씩 하는 옛 인터페이스의 방식은 나쁜 습관을 만들고, 그 습관은 진지한 작업을 할 때 확장되지 않습니다.
4.6에서는 Direct State Access, Programmable Vertex Pulling, MultidrawIndirect를 쓸 수 있습니다. 이걸로 복잡성을 "상태 머신을 조작하는 수많은 함수"에서 구조체 배열을 다룰 때 malloc과 memcpy를 쓰는 것과 매우 비슷한 소수의 함수로 옮길 수 있습니다. 쉬운 일은 아니지만 아주 익숙하게 느껴질 겁니다. 눈에 보이고, 유연하고, 확장성이 있으며, 3D 렌더링의 핵심을 익힌 뒤 Vulkan으로 넘어갈 발판도 됩니다.
애덤 사비츠키가 말한 대로 더 이상 그다지 중요하지 않다는 데 동의하지만, 현대 기술이 어디서 왔는지 학생들에게 가르치는 데는 가치 있는 수업이라고도 생각합니다.
다만 입문, 튜토리얼, 간단한 예제, 한계 소개까지 딱 한 달 정도만 하고 넘어가는 것 말고는 그 이상 집중할 이유를 개인적으로 모르겠습니다. 그다음에는 DX12와 Metal도 비슷한 원리를 따른다는 배경 이야기를 곁들이며 Vulkan/WGPU로 넘어가면 됩니다.
그건 그것대로 지뢰밭이에요. DirectX 12는 다른 것들과 전혀 다른 독자적인 괴물이고, Vulkan은 이미 아키텍처가 세 번이나 바뀌어 수렁에 빠져 있고, WGPU는 현재 모델이 아니라 Vulkan 초기 버전(구식)을 바탕으로 하고 있죠. 이 중에서 3D 그래픽스 입문자가 올라타기 괜찮은 진입로가 있는 건 Metal뿐이에요.
그리고 NDA 때문에 다들 잊고 있는 NVN과 LibGNM(X)도 구석에 있습니다.
아, 그리고 XBox의 DirectX는 윈도의 DirectX와 같지 않습니다.
NDA로 흥한 자, NDA로 망하리라(적어도 교육과 인지도 면에서는요). 공평해 보이네요.
플레이스테이션과 닌텐도는 인지도 면에서 잘 지내고 있습니다. XBox는 덜하지만, 그건 DirectX NDA와는 무관하고 오히려 경영 실패 때문입니다.