14년 된 OpenGL ES 3.0을 여전히 강의에 쓰는 이유

기본 개념 제대로 잡아주는 방식이라 좋네. API 하나 익히면 나머지는 따라오니까.

근데 왜 GPU 프로그래밍은 CPU보다 이렇게 복잡한 거임? 언어 패러다임 문제인지 하드웨어 한계인지 궁금하더라. Vulkan 볼 때마다 드는 생각임.

복잡한 게 아니라 CUDA처럼 C/C++ 그대로 GPU로 컴파일하는 것도 있음. 문제는 GPU 코어가 수천 개라서 array[n * 1024] 단위로 데이터를 안 깔면 GPU가 놀게 된다는 거. 프로그램을 그 메모리 모델에 맞춰야 하고, 이게 절반 이상임.

역사적 경로 의존성도 큼. GPU는 처음부터 그래픽 가속용 고정 기능 장치였고, 그 파이프라인이 점점 복잡해지면서 유연해진 거임. 그래픽 밖 용도는 꼼수로 쓰다가 CUDA/OpenCL로 굳었고, Vulkan은 AMD Mantle을 기반으로 그 누수되는 추상화를 걷어내려는 시도고.

하드웨어 설계 한계가 제일 큼. GPU 아키텍처가 CPU보다 훨씬 다양해서 셰이더를 소스나 중간 표현으로 배포하고 런타임에 컴파일해야 함. CPU와 따로 도는 별도 RAM, 암묵적이거나 명시적인 동기화까지 붙으니까 복잡해지는 거. Sebastian Aaltonen의 No Graphics API 글 보면 군더더기를 얼마나 걷어낼 수 있는지 나옴.

전부 간접적이라 어려운 거임. 셰이더 컴파일하고, 텍스처와 버퍼 깔고, 오프셋과 포맷, 다음 데이터로 넘어가는 법까지 다 알려줘야 함. TypeGPU나 toucan 같은 게 이걸 감싸려고 하는데, 저수준 API라 결국 직접 해야 됨.

CPU도 ISA가 닫혀 있었으면 드라이버랑 OpenCPU API가 필요했을 거임. 차이는 CPU는 단일 스레드 성능, GPU는 느린 작업 수천 개를 동시에 돌린다는 점. Vulkan은 '마법 없는 저수준 API'랑 '서로 다른 GPU 아키텍처 지원'이라는 상충 요구를 같이 풀려다 지금 모양이 된 거고.

나는 CPU가 클라이언트, GPU 셰이더가 서버인 네트워크 앱으로 이해했음. 양쪽 다 짜고 프로토콜 정하고, 서버까지 클라이언트가 띄워야 하고, 드로우콜을 줄여야 하고. 성능이 빡빡해서 C++로 직접 IP 스택 짜는 쪽에 가까움.

성능 끝까지 짜면 CPU도 만만치 않음. GPU는 최적화 안 하면 벌점이 더 크게 돌아올 뿐임.

나는 API 안 쓰고 소프트웨어 래스터라이저랑 레이트레이서 짜면서 그래픽스를 더 배웠음. GPU 렌더링 자체가 목표면 OpenGL이 낫지만, 그래픽스 개념 가르치는 게 목표면 OpenGL은 오히려 방해됨.

반대임. 프래그먼트 셰이더라는 제약 안에서 이웃 픽셀 없이 최종 픽셀을 계산하는 법을 강제로 익히는 게 나한테는 결정적이었음. Vulkan보다 손이 덜 가고 파이프라인이 정해져 있는 OpenGL이 입문점으로는 딱 좋음.

GLES가 나쁜 선택은 아닌데 GL이랑 Vulkan 사이 중간이 있었으면 좋겠음. GL 최악은 스펙 안 읽으면 이해 못 하는 전역 상태임.

그 중간이 보통 DirectX 11인데, 특정 플랫폼에 묶여 있는 게 문제지.