OpenGL
[image]
'''Open''' '''G'''raphics '''L'''ibrary
홈페이지
1992년 초에 컴퓨터 그래픽을 하드웨어 가속으로 처리(렌더링)함과 동시에 여러 분야에서 사용될 수 있도록 하는 범용성을 보장하기 위해 발표된 2D, 3D 그래픽 라이브러리이자 산업용 API로, 범용성이 있는 만큼 가장 광범위하게 사용되고 있다.
OpenGL 이전에는 1980년대 실리콘 그래픽스(SGI) 사에서 개발한 솔루션인 IRIS GL이 있었는데 여러 OS에서 사용할 수 있기 위해 필요한 범용성과 독립성을 고려하지 않고 만들었기 때문에 당시엔 하드웨어 뿐만 아니라 소프트웨어까지 제약이 심했던 솔루션이었다. 그래서 하드웨어와 운영체제에 제약을 받지 않는 범용적인 API 프로그래밍을 위한 OpenGL이 탄생하게 되었던 것.
2000년에 비영리 기술 컨소시엄인 크로노스 그룹이 설립되면서 GPGPU 병렬연산용 라이브러리인 OpenCL을 비롯한 다양한 용도의 라이브러리 및 API 로 확장 및 관리하기 시작했는데, 2006년 7월에 OpenGL도 크로노스 그룹에 의해 관리받는 것으로 전환되었다.
그래픽 쪽을 배울 때에는 꼭 접하게 된다. DirectX의 라이벌 격이라고 할 수 있다. 다만 DirectX는 그래픽 뿐만 아니라 사용자 입력과 포스피드백 같은 컨트롤러 제어, 음향쪽도 아우르고 있어 OpenGL과 1:1로 대응되지 않는다. OpenGL은 순수하게 그래픽 출력만을 담당하니까. 순수하게 OpenGL과 대응되는 부분은 DirectX 컴포넌트의 일부인 Direct3D다.
초창기에는 MS에서도 OpenGL을 지원했다. 현재까지도 그래픽카드 도움 없이 소프트웨어 렌더링인 CPU 가속으로는 OpenGL 1.1까지 지원한다. 그러다가, 독자솔루션인 DirectX를 내놓으면서 MS는 OpenGL은 전문가 산업용, DirectX는 가정용 컴퓨터 게임 그래픽용이라는 기믹을 만들어 퍼뜨렸는데 존 카맥이 OpenGL이 DirectX보다 훨씬 편리하게 게임에 사용이 가능하다고 직접 코드를 보이면서 글을 올렸고, MS는 존 카맥이 사용하기 힘들다면 다른 누구에게도 힘든게 맞다면서 꼬리를 내렸다. 그러나, 1998년 초 1.2 버전 이후 OpenGL은 3년 가까이 개선 과정없이 거듭된 문제를 터뜨렸고[1] DirectX는 1999년 하반기에 발표한 7.0 버전에서 크게 발전하여 결국 역전되고 말았다. 존 카맥도 이제는 DirectX가 더 낫다고 발언한 상황. 저 원인으로 MS의 음모론을 이야기하는 사람도 있는데, OpenGL 위원회에 MS 측 사람이 껴있긴 했지만 딱 한 명밖에 없어서 가능성은 희박하다. 그리고, 만약 저 한 명으로 인해 그런 짓을 터뜨린 거라면 그건 그냥 OpenGL 쪽이 무능하다는 얘기밖에 안 된다.
어쨌건 지금은 OpenGL도 절치부심해서 빠르게 발전하고 있으며, 특히나 모바일 게임시장이 뜨고 MS가 거기서 지지부진한 상황에서 상당한 우세를 보여주고 있다. 과거 하드웨어 T&L 시절에 비하면 트렌드에 뒤쳐지지 않을 정도로 잘 개선되고는 있지만, OpenGL 자체가 게임을 비롯한 멀티미디어만을 위한 존재가 아닌만큼 고려해야할 영역이 많은 API이다 보니 특정 업체인 MS가 본래 Windows 게임을 위해 개발했던 DirectX보다 앞선 기술을 채택하기 어려울 수밖에 없다는 점을 어느 정도 이해해야할 필요가 있다. 90년대 중반까지 DirectX보다 OpenGL이 더 우위였던 건 그래픽 API에 있어서 DirectX가 OpenGL보다 3년 늦게 발표된 후발 주자였기 때문에 가능했을 뿐이다.
현시점에서 OpenGL의 가장 큰 문제는 드라이버이다. 25년이 넘는 동안 OpenGL 스펙에 추가된 기능들이 엄청나게 많고 과거 1.x 시절의 API부터 4.x에 추가된 최신 API까지 드라이버에서 전부 지원하는 동시에 300여 개에 달하는 확장기능까지 제공해줘야 하는데, 이로 인해 드라이버의 복잡도는 상상을 초월하는 수준이다. 당연히 드라이버의 품질도 심각하게 뒤떨어질 수 밖에 없다. Direct3D처럼 관리주체의 통제를 기대할 수 없기 때문에 드라이버의 퀄리티는 순전히 GPU 제조사에 달려 있다.[2] 이러한 이유로 OpenGL 프로그래밍은 각종 GPU 드라이버 버그의 지뢰밭을 살금살금 피하면서 개발하는 과정의 연속이다. 사실상 무늬만 크로스플랫폼인 셈. 구글 크롬은 윈도 버전의 경우 OpenGL을 직접 사용하는 것을 포기하고 OpenGL 명령을 Direct3D로 변환해서 돌리는 ANGLE이라고 불리는 중간 레이어를 개발해서 사용하고 있으며 그 외 플랫폼의 경우 수백개에 달하는 드라이버 버그들을 하나하나씩 우회하는 엄청나게 복잡한 렌더링 패스가 구현되어 있다. 크로노스 그룹이 OpenGL을 놔두고 Vulkan을 만든 가장 큰 이유도 사실 이것이다. 도저히 드라이버가 관리가 안 되는 수준까지 왔기 때문. 그래서 Vulkan은 스펙을 최소화시켜서 드라이버의 역할을 최대한 줄이고 프로그래머들에게 많은 것을 위임하도록 설계되어 있다. 다만, 이로 인해 Vulkan의 개발 난이도는 엄청나게 올라가 버렸다. OpenGL의 그 외의 문제로는 전역 상태 머신 기반이라 멀티스레딩을 온전하게 사용할 수 없으며 상태머신의 내용을 추적하기 힘들기 때문에 버그를 만들기 쉽다는 점이 있다. 아무래도 API의 기본 틀은 1990년대 초반에 만들어진 것이니만큼 아무래도 요즘 프로그래밍 트렌드와 동떨어진 부분이 있다.
어지간한 그래픽 카드라면 둘 다 지원하는 경우가 많다. DirectX는 '''사실상 윈도우 전용이므로''' 타 운영체제(OS X, 리눅스 등)를 쓴다면 유일한 그래픽 라이브러리이기도 하다. 2010년대 시점에서는 일반인 시각으로 그놈이 그놈이다. 특히 안드로이드에서는 OpenGL이 메이저다.
OpenGL은 크게 GL, GLU('''U'''tility)로 나눠져 있다. GL은 기본적인 함수들로 구성되어 있고, GLU는 GL을 좀 더 편히 사용할 수 있도록 도와주는 래핑 함수로 구성되어 있다. 참고로 GL과 GLU 둘 다 업데이트가 끊긴 지 오래되었기 때문에, 실질적으로 OpenGL을 사용하려면 GLEW 같은 외부 확장 라이브러리를 활용해야 한다.
사실 OpenGL은 API는 인터페이스와 기능의 명세일 뿐이라, 실제 그 구현체인 라이브러리는 하나의 플랫폼에도 여럿 존재할 수 있고, 플랫폼 마다도 구현이 달라서 디바이스 컨텍스트 생성 따위의 부분이 플랫폼마다 모두 달라 완전한 크로스플랫폼은 아니다. 이 때문에 실제로 화면에 뭔가를 나타내려면 대체로 추가 라이브러리를 사용해야 한다. [3][4][5] 이 외에도 SDL 등과 연동해서 사용하기도 하는데 이는 대부분 크로스플랫폼을 지원한다.
대부분의 3D 그래픽이 그렇지만, 특히 OpenGL은 로우레벨 API이기 때문에 거의 모든걸 수동으로 해줘야 해서 깊이 있게 사용하려면 어느 정도 수학과 친해져야 한다. 최소한 공대 수준의 선형대수학과 미분기하학은 이해하고 있어야 하는데, 컴퓨터공학과 특성상 이산수학을 제외하면 대학레벨의 수학을 거의 배우지 않는 경우가 많기도 하고, 신기술이 추가되면서 요구하는 수학 수준이 점점 올라가는 추세라는 점이 문제다. 단순히 API를 가져다 쓰는 정도라면 기초 미적분과 벡터 수준의 지식만 가지고도 되기는 하겠으나, 피상적인 접근에만 머무르게 될 것이다. 물론 그래픽스 자체를 연구하는 게 아니라면 그 정도로도 별 문제없기는 하다.
관련 교재와 서적으로는 Red Book과 Blue Book(레퍼런스 매뉴얼), Orange Book, Superbible이 대표적이다.
애플이 매우 사랑하여[6] OS X[7]의 모든 시스템 그래픽은 OpenGL로 가속되어 표시된다.[8] 그러나 OpenGL 4.1 버전 이후 드라이버 업데이트를 전혀 하지 않아 애플 환경에서 OpenGL을 이용하는 개발자들에게 원성을 사고 있다가, WWDC 2014에서 자체 개발한 그래픽 라이브러리인 Metal 라이브러리를 새로 공개하였고, WWDC 2015에는 macOS용 Metal 라이브러리를 추가 공개하면서 앞으로의 macOS, iOS, tvOS용 앱들이 Metal 라이브러리로 개발될 것이라 발표하였다. 안드로이드, 리눅스 등의 타 플랫폼에서는 여전히 OpenGL을 사용하고 있지만, 모바일 시장의 한 축이었던 iOS에서의 점유율은 확실히 잃어버리게 되었다. 언리얼 엔진, 유니티 엔진 등의 주요 게임 엔진들은 Metal을 정식 지원하고 있다.
2015년 3월, 차세대 OpenGL인 Vulkan이 최초 공개되었다.
최신 버전은 2017년 7월 31일 발표된 4.6 버전이다. #
2.0 버전부터 GLSL을 이용한 '''셰이더 프로그래밍 언어'''를 정식으로 지원하기 시작했으나 사실, 셰이더 프로그래밍 언어 자체는 OpenGL의 탄생과 함께 시작되었다. 초기에는 ARB AL라고도 부르는 '''Architecture Review Board 어셈블리 언어'''가 그것으로 벤더 입장인 하드웨어 제조사들을 주도로 추가된 확장 기능 컨셉[9]이다보니 OpenGL이 그렇게 중요시 하던 범용성이 무시되었기 때문에 어떤 그래픽카드에서는 잘 돌아가고 다른 어떤 그래픽카드에서는 돌아가지 않는 등 전체적으로 중구난방일 수밖에 없었으며, 1998년 1.2.1 버전에 들어서야 범용성이 있는 ARB_multitexture 명령어를 시작으로 2001년 1.3 버전부터 ARB가 붙여진 공식 확장 기능들이 대거 추가되었지만[10] 결정적으로 어셈블리어로 다뤄야 하다보니 진입장벽이 엄청 높았다.
개념 자체는 2000년 11월에 발표된 MS의 DirectX 8.0의 셰이더 어셈블리 언어보다 8년 이상 먼저 내세운 것에 의의 있는 셰이더 프로그래밍 언어라고 볼 수 있지만 2002년에 MS가 진입장벽을 대폭 낮춘 고수준 셰이더 프로그래밍 언어인 HLSL을 재빠르게 발표함으로써 OpenGL 측에서도 2004년에 이와 비슷한 개념을 지닌 GLSL이 발표되었다. 2.0 버전까진 셰이더 프로그래밍 언어를 이용하지 않는 이전의 방식으로도 화면에 폴리곤을 출력할 수 있었지만, 3.0 버전부터는 GLSL을 사용하지 않으면 화면에 폴리곤을 출력할 수 없게끔 필수가 되었다.
교육기관 등에서는 최신버전을 숙지하기 위해서는 구버전부터 개념을 익히는게 중요하다는 명목으로 아직도 1.0 버전을 가지고 수업을 하고 있는 경우가 많다.[11] OpenGL 1.0은 폴리곤 연산 등 개념만 익히는 것을 추천하고 실무 개발시에는 OpenGL 1.x 대나 2.x 대를 사용한 개발은 추천하지 않는다.
OpenGL 3.x 부터 많은 개선이 있었으며, 테셀레이션 기능이 제외된 3.3 버전을 쓸 수 없는 정 여의치 않는 상황이라면 최소한 고수준 셰이더 프로그래밍 언어를 사용할 수 있는 2.0 버전 이상을 사용하여 개발하는 것이 추천된다. 대표적인 차이로 2.0까지는 primitives를 그릴 때 glBegin()과 glEnd()를 사용하는 것에 비해, 3.0 이후부터 이 기능은 Deprecated 되었다. glBegin()의 대표적인 문제점으로는 멀티코어 프로세서가 대중화된 현대 컴퓨팅 환경에서 병렬 처리가 거의 불가능하다는 점을 꼽을 수 있으며 각 오브젝트를 그려 낼 때 glBegin()을 호출해야 하므로 오버헤드 문제가 일어났기 때문이다.
이 때문에 OpenGL 2.0 이전과 3.0 이후는 OpenGL의 큰 틀을 공유하긴 하지만, DirectX 9 이전과 10 이후의 차이처럼 렌더 파이프라인 구조의 차이가 있는 개선된 API라고 보는 편이 좋다. 다른 비유로 C++98과 C++11의 관계라고 볼 수 있다.
특히 이런 레거시 OpenGL의 가장 큰 문제는 고정 파이프라인을 사용하는데다 일반 소비자용 그래픽카드 들의 드라이버에 해당 성능을 제한을 걸어 둔 관계로 쿼드로나 라데온 프로와 같은 워크스테이션용 드라이버에서 내는 성능에 비해 아주 처참한 성능이 나오게 된다.
그에 비해 셰이더 기반을 사용하는 모던 OpenGL 3.0 이후의 경우 소비자용 그래픽카드 에서도 성능차이가 없거나 오히려 더 높다. Viewport 2.0 가 포함된 Autodesk Maya(3.2)나 Cinema 4D(4.1), Blender(3.3), 또는 둠(2016)(4.6)이 그 예.
그리고 Vulkan이 상대적으로 개발하기 어렵고 하위 호환도 지원하지 않는 상황이라, OpenGL을 활용한 프로젝트가 아직 더 많이 개발되고 있다. 이는 DirectX 12도 마찬가지로, DirectX 11과 12가 투 트랙으로 개발되고 있으며 현재까지는 DirectX 11의 사용 빈도가 더 높은 상황이다.
그렇지만, OpenGL이 지속적으로 업데이트 되면서 최신 하드웨어의 기능을 지원해 나갈 것인가에 대해서는 회의적이다. 예를 들어 NVIDIA의 RTX 그래픽카드가 지원하는 레이트레이싱 가속 기능의 경우, Vulkan과 DirectX12 버젼의 API는 만들었지만, OpenGL의 경우 지원하지 않는다. OpenGL의 경우 이를 활용하려면 Cuda 기반의 Optix(Nvidia 자체 API)를 사용해 레이트레이싱 가속 기능을 사용한 뒤, OpenGL에서 결과물 이미지만 받아온 후 그려야 한다. 파이프라인을 재구성하기 어려운 OpenGL의 특성 때문인듯 하다. 물론, 또 다른 RTX 그래픽카드의 특징인 Mesh Shader의 경우 파이프라인을 재구성해야 했음에도 불구하고 OpenGL도 지원을 해주었지만, 레이트레이싱 가속 기능은 그렇지 않다.
최신 버전은 2015년 8월에 발표한 3.2 버전이다. 임베디드 시스템 등에서 사용할 수 있게 몇 가지 잘 사용되지 않는 함수를 제거한 API. 안드로이드 시스템과 iOS에서 그래픽 가속을 위해 사용된다.
OpenGL ES 1.0은 OpenGL 1.3을, OpenGL ES 1.1은 OpenGL 1.5를, OpenGL ES 2.0은 OpenGL 2.0을 베이스로 만들어졌다. 다만, OpenGL ES 2.0은 OpenGL 2.1 버전까지 사용 가능했던 고정 파이프라인이 제거[12]되었기 때문에 사실상 GLSL이 필수가 된 OpenGL 3.0과 비슷하게 사용된다. OpenGL ES 3.0은 OpenGL 4.3을 베이스로 만들어졌다.
이 문서를 참고.
'''Open''' '''G'''raphics '''L'''ibrary
홈페이지
1. 개요
1992년 초에 컴퓨터 그래픽을 하드웨어 가속으로 처리(렌더링)함과 동시에 여러 분야에서 사용될 수 있도록 하는 범용성을 보장하기 위해 발표된 2D, 3D 그래픽 라이브러리이자 산업용 API로, 범용성이 있는 만큼 가장 광범위하게 사용되고 있다.
2. 상세
OpenGL 이전에는 1980년대 실리콘 그래픽스(SGI) 사에서 개발한 솔루션인 IRIS GL이 있었는데 여러 OS에서 사용할 수 있기 위해 필요한 범용성과 독립성을 고려하지 않고 만들었기 때문에 당시엔 하드웨어 뿐만 아니라 소프트웨어까지 제약이 심했던 솔루션이었다. 그래서 하드웨어와 운영체제에 제약을 받지 않는 범용적인 API 프로그래밍을 위한 OpenGL이 탄생하게 되었던 것.
2000년에 비영리 기술 컨소시엄인 크로노스 그룹이 설립되면서 GPGPU 병렬연산용 라이브러리인 OpenCL을 비롯한 다양한 용도의 라이브러리 및 API 로 확장 및 관리하기 시작했는데, 2006년 7월에 OpenGL도 크로노스 그룹에 의해 관리받는 것으로 전환되었다.
그래픽 쪽을 배울 때에는 꼭 접하게 된다. DirectX의 라이벌 격이라고 할 수 있다. 다만 DirectX는 그래픽 뿐만 아니라 사용자 입력과 포스피드백 같은 컨트롤러 제어, 음향쪽도 아우르고 있어 OpenGL과 1:1로 대응되지 않는다. OpenGL은 순수하게 그래픽 출력만을 담당하니까. 순수하게 OpenGL과 대응되는 부분은 DirectX 컴포넌트의 일부인 Direct3D다.
초창기에는 MS에서도 OpenGL을 지원했다. 현재까지도 그래픽카드 도움 없이 소프트웨어 렌더링인 CPU 가속으로는 OpenGL 1.1까지 지원한다. 그러다가, 독자솔루션인 DirectX를 내놓으면서 MS는 OpenGL은 전문가 산업용, DirectX는 가정용 컴퓨터 게임 그래픽용이라는 기믹을 만들어 퍼뜨렸는데 존 카맥이 OpenGL이 DirectX보다 훨씬 편리하게 게임에 사용이 가능하다고 직접 코드를 보이면서 글을 올렸고, MS는 존 카맥이 사용하기 힘들다면 다른 누구에게도 힘든게 맞다면서 꼬리를 내렸다. 그러나, 1998년 초 1.2 버전 이후 OpenGL은 3년 가까이 개선 과정없이 거듭된 문제를 터뜨렸고[1] DirectX는 1999년 하반기에 발표한 7.0 버전에서 크게 발전하여 결국 역전되고 말았다. 존 카맥도 이제는 DirectX가 더 낫다고 발언한 상황. 저 원인으로 MS의 음모론을 이야기하는 사람도 있는데, OpenGL 위원회에 MS 측 사람이 껴있긴 했지만 딱 한 명밖에 없어서 가능성은 희박하다. 그리고, 만약 저 한 명으로 인해 그런 짓을 터뜨린 거라면 그건 그냥 OpenGL 쪽이 무능하다는 얘기밖에 안 된다.
어쨌건 지금은 OpenGL도 절치부심해서 빠르게 발전하고 있으며, 특히나 모바일 게임시장이 뜨고 MS가 거기서 지지부진한 상황에서 상당한 우세를 보여주고 있다. 과거 하드웨어 T&L 시절에 비하면 트렌드에 뒤쳐지지 않을 정도로 잘 개선되고는 있지만, OpenGL 자체가 게임을 비롯한 멀티미디어만을 위한 존재가 아닌만큼 고려해야할 영역이 많은 API이다 보니 특정 업체인 MS가 본래 Windows 게임을 위해 개발했던 DirectX보다 앞선 기술을 채택하기 어려울 수밖에 없다는 점을 어느 정도 이해해야할 필요가 있다. 90년대 중반까지 DirectX보다 OpenGL이 더 우위였던 건 그래픽 API에 있어서 DirectX가 OpenGL보다 3년 늦게 발표된 후발 주자였기 때문에 가능했을 뿐이다.
현시점에서 OpenGL의 가장 큰 문제는 드라이버이다. 25년이 넘는 동안 OpenGL 스펙에 추가된 기능들이 엄청나게 많고 과거 1.x 시절의 API부터 4.x에 추가된 최신 API까지 드라이버에서 전부 지원하는 동시에 300여 개에 달하는 확장기능까지 제공해줘야 하는데, 이로 인해 드라이버의 복잡도는 상상을 초월하는 수준이다. 당연히 드라이버의 품질도 심각하게 뒤떨어질 수 밖에 없다. Direct3D처럼 관리주체의 통제를 기대할 수 없기 때문에 드라이버의 퀄리티는 순전히 GPU 제조사에 달려 있다.[2] 이러한 이유로 OpenGL 프로그래밍은 각종 GPU 드라이버 버그의 지뢰밭을 살금살금 피하면서 개발하는 과정의 연속이다. 사실상 무늬만 크로스플랫폼인 셈. 구글 크롬은 윈도 버전의 경우 OpenGL을 직접 사용하는 것을 포기하고 OpenGL 명령을 Direct3D로 변환해서 돌리는 ANGLE이라고 불리는 중간 레이어를 개발해서 사용하고 있으며 그 외 플랫폼의 경우 수백개에 달하는 드라이버 버그들을 하나하나씩 우회하는 엄청나게 복잡한 렌더링 패스가 구현되어 있다. 크로노스 그룹이 OpenGL을 놔두고 Vulkan을 만든 가장 큰 이유도 사실 이것이다. 도저히 드라이버가 관리가 안 되는 수준까지 왔기 때문. 그래서 Vulkan은 스펙을 최소화시켜서 드라이버의 역할을 최대한 줄이고 프로그래머들에게 많은 것을 위임하도록 설계되어 있다. 다만, 이로 인해 Vulkan의 개발 난이도는 엄청나게 올라가 버렸다. OpenGL의 그 외의 문제로는 전역 상태 머신 기반이라 멀티스레딩을 온전하게 사용할 수 없으며 상태머신의 내용을 추적하기 힘들기 때문에 버그를 만들기 쉽다는 점이 있다. 아무래도 API의 기본 틀은 1990년대 초반에 만들어진 것이니만큼 아무래도 요즘 프로그래밍 트렌드와 동떨어진 부분이 있다.
어지간한 그래픽 카드라면 둘 다 지원하는 경우가 많다. DirectX는 '''사실상 윈도우 전용이므로''' 타 운영체제(OS X, 리눅스 등)를 쓴다면 유일한 그래픽 라이브러리이기도 하다. 2010년대 시점에서는 일반인 시각으로 그놈이 그놈이다. 특히 안드로이드에서는 OpenGL이 메이저다.
OpenGL은 크게 GL, GLU('''U'''tility)로 나눠져 있다. GL은 기본적인 함수들로 구성되어 있고, GLU는 GL을 좀 더 편히 사용할 수 있도록 도와주는 래핑 함수로 구성되어 있다. 참고로 GL과 GLU 둘 다 업데이트가 끊긴 지 오래되었기 때문에, 실질적으로 OpenGL을 사용하려면 GLEW 같은 외부 확장 라이브러리를 활용해야 한다.
사실 OpenGL은 API는 인터페이스와 기능의 명세일 뿐이라, 실제 그 구현체인 라이브러리는 하나의 플랫폼에도 여럿 존재할 수 있고, 플랫폼 마다도 구현이 달라서 디바이스 컨텍스트 생성 따위의 부분이 플랫폼마다 모두 달라 완전한 크로스플랫폼은 아니다. 이 때문에 실제로 화면에 뭔가를 나타내려면 대체로 추가 라이브러리를 사용해야 한다. [3][4][5] 이 외에도 SDL 등과 연동해서 사용하기도 하는데 이는 대부분 크로스플랫폼을 지원한다.
대부분의 3D 그래픽이 그렇지만, 특히 OpenGL은 로우레벨 API이기 때문에 거의 모든걸 수동으로 해줘야 해서 깊이 있게 사용하려면 어느 정도 수학과 친해져야 한다. 최소한 공대 수준의 선형대수학과 미분기하학은 이해하고 있어야 하는데, 컴퓨터공학과 특성상 이산수학을 제외하면 대학레벨의 수학을 거의 배우지 않는 경우가 많기도 하고, 신기술이 추가되면서 요구하는 수학 수준이 점점 올라가는 추세라는 점이 문제다. 단순히 API를 가져다 쓰는 정도라면 기초 미적분과 벡터 수준의 지식만 가지고도 되기는 하겠으나, 피상적인 접근에만 머무르게 될 것이다. 물론 그래픽스 자체를 연구하는 게 아니라면 그 정도로도 별 문제없기는 하다.
관련 교재와 서적으로는 Red Book과 Blue Book(레퍼런스 매뉴얼), Orange Book, Superbible이 대표적이다.
애플이 매우 사랑하여[6] OS X[7]의 모든 시스템 그래픽은 OpenGL로 가속되어 표시된다.[8] 그러나 OpenGL 4.1 버전 이후 드라이버 업데이트를 전혀 하지 않아 애플 환경에서 OpenGL을 이용하는 개발자들에게 원성을 사고 있다가, WWDC 2014에서 자체 개발한 그래픽 라이브러리인 Metal 라이브러리를 새로 공개하였고, WWDC 2015에는 macOS용 Metal 라이브러리를 추가 공개하면서 앞으로의 macOS, iOS, tvOS용 앱들이 Metal 라이브러리로 개발될 것이라 발표하였다. 안드로이드, 리눅스 등의 타 플랫폼에서는 여전히 OpenGL을 사용하고 있지만, 모바일 시장의 한 축이었던 iOS에서의 점유율은 확실히 잃어버리게 되었다. 언리얼 엔진, 유니티 엔진 등의 주요 게임 엔진들은 Metal을 정식 지원하고 있다.
2015년 3월, 차세대 OpenGL인 Vulkan이 최초 공개되었다.
3. 종류
3.1. OpenGL
최신 버전은 2017년 7월 31일 발표된 4.6 버전이다. #
2.0 버전부터 GLSL을 이용한 '''셰이더 프로그래밍 언어'''를 정식으로 지원하기 시작했으나 사실, 셰이더 프로그래밍 언어 자체는 OpenGL의 탄생과 함께 시작되었다. 초기에는 ARB AL라고도 부르는 '''Architecture Review Board 어셈블리 언어'''가 그것으로 벤더 입장인 하드웨어 제조사들을 주도로 추가된 확장 기능 컨셉[9]이다보니 OpenGL이 그렇게 중요시 하던 범용성이 무시되었기 때문에 어떤 그래픽카드에서는 잘 돌아가고 다른 어떤 그래픽카드에서는 돌아가지 않는 등 전체적으로 중구난방일 수밖에 없었으며, 1998년 1.2.1 버전에 들어서야 범용성이 있는 ARB_multitexture 명령어를 시작으로 2001년 1.3 버전부터 ARB가 붙여진 공식 확장 기능들이 대거 추가되었지만[10] 결정적으로 어셈블리어로 다뤄야 하다보니 진입장벽이 엄청 높았다.
개념 자체는 2000년 11월에 발표된 MS의 DirectX 8.0의 셰이더 어셈블리 언어보다 8년 이상 먼저 내세운 것에 의의 있는 셰이더 프로그래밍 언어라고 볼 수 있지만 2002년에 MS가 진입장벽을 대폭 낮춘 고수준 셰이더 프로그래밍 언어인 HLSL을 재빠르게 발표함으로써 OpenGL 측에서도 2004년에 이와 비슷한 개념을 지닌 GLSL이 발표되었다. 2.0 버전까진 셰이더 프로그래밍 언어를 이용하지 않는 이전의 방식으로도 화면에 폴리곤을 출력할 수 있었지만, 3.0 버전부터는 GLSL을 사용하지 않으면 화면에 폴리곤을 출력할 수 없게끔 필수가 되었다.
교육기관 등에서는 최신버전을 숙지하기 위해서는 구버전부터 개념을 익히는게 중요하다는 명목으로 아직도 1.0 버전을 가지고 수업을 하고 있는 경우가 많다.[11] OpenGL 1.0은 폴리곤 연산 등 개념만 익히는 것을 추천하고 실무 개발시에는 OpenGL 1.x 대나 2.x 대를 사용한 개발은 추천하지 않는다.
OpenGL 3.x 부터 많은 개선이 있었으며, 테셀레이션 기능이 제외된 3.3 버전을 쓸 수 없는 정 여의치 않는 상황이라면 최소한 고수준 셰이더 프로그래밍 언어를 사용할 수 있는 2.0 버전 이상을 사용하여 개발하는 것이 추천된다. 대표적인 차이로 2.0까지는 primitives를 그릴 때 glBegin()과 glEnd()를 사용하는 것에 비해, 3.0 이후부터 이 기능은 Deprecated 되었다. glBegin()의 대표적인 문제점으로는 멀티코어 프로세서가 대중화된 현대 컴퓨팅 환경에서 병렬 처리가 거의 불가능하다는 점을 꼽을 수 있으며 각 오브젝트를 그려 낼 때 glBegin()을 호출해야 하므로 오버헤드 문제가 일어났기 때문이다.
이 때문에 OpenGL 2.0 이전과 3.0 이후는 OpenGL의 큰 틀을 공유하긴 하지만, DirectX 9 이전과 10 이후의 차이처럼 렌더 파이프라인 구조의 차이가 있는 개선된 API라고 보는 편이 좋다. 다른 비유로 C++98과 C++11의 관계라고 볼 수 있다.
특히 이런 레거시 OpenGL의 가장 큰 문제는 고정 파이프라인을 사용하는데다 일반 소비자용 그래픽카드 들의 드라이버에 해당 성능을 제한을 걸어 둔 관계로 쿼드로나 라데온 프로와 같은 워크스테이션용 드라이버에서 내는 성능에 비해 아주 처참한 성능이 나오게 된다.
그에 비해 셰이더 기반을 사용하는 모던 OpenGL 3.0 이후의 경우 소비자용 그래픽카드 에서도 성능차이가 없거나 오히려 더 높다. Viewport 2.0 가 포함된 Autodesk Maya(3.2)나 Cinema 4D(4.1), Blender(3.3), 또는 둠(2016)(4.6)이 그 예.
그리고 Vulkan이 상대적으로 개발하기 어렵고 하위 호환도 지원하지 않는 상황이라, OpenGL을 활용한 프로젝트가 아직 더 많이 개발되고 있다. 이는 DirectX 12도 마찬가지로, DirectX 11과 12가 투 트랙으로 개발되고 있으며 현재까지는 DirectX 11의 사용 빈도가 더 높은 상황이다.
그렇지만, OpenGL이 지속적으로 업데이트 되면서 최신 하드웨어의 기능을 지원해 나갈 것인가에 대해서는 회의적이다. 예를 들어 NVIDIA의 RTX 그래픽카드가 지원하는 레이트레이싱 가속 기능의 경우, Vulkan과 DirectX12 버젼의 API는 만들었지만, OpenGL의 경우 지원하지 않는다. OpenGL의 경우 이를 활용하려면 Cuda 기반의 Optix(Nvidia 자체 API)를 사용해 레이트레이싱 가속 기능을 사용한 뒤, OpenGL에서 결과물 이미지만 받아온 후 그려야 한다. 파이프라인을 재구성하기 어려운 OpenGL의 특성 때문인듯 하다. 물론, 또 다른 RTX 그래픽카드의 특징인 Mesh Shader의 경우 파이프라인을 재구성해야 했음에도 불구하고 OpenGL도 지원을 해주었지만, 레이트레이싱 가속 기능은 그렇지 않다.
3.1.1. OpenGL 버전 일람
- OpenGL 1.0 : 1992년 1월 (EXT 계열, 그밖에 독자적인 이름이 붙여진 확장 명령어 포함)
- OpenGL 1.1 : 1997년 3월
- OpenGL 1.2 : 1998년 3월
- OpenGL 1.2.1 : 1998년 10월 (ARB 계열의 확장 명령어 추가)
- OpenGL 1.3 : 2001년 8월
- OpenGL 1.4 : 2002년 7월
- OpenGL 1.5 : 2003년 7월
- OpenGL 2.0 : 2004년 9월 (GLSL 1.1 포함)
- OpenGL 2.1 : 2006년 7월 (GLSL 1.2 포함)
- OpenGL 3.0 : 2008년 8월 (GLSL 1.3 포함)
- OpenGL 3.1 : 2009년 3월 (GLSL 1.4 포함)
- OpenGL 3.2 : 2009년 8월 (GLSL 1.5 포함)
- OpenGL 3.3 : 2010년 3월 (GLSL 3.3 포함)
- OpenGL 4.0 : 2010년 3월 (GLSL 4.0 포함)
- OpenGL 4.1 : 2010년 7월 (GLSL 4.1 포함)
- OpenGL 4.2 : 2011년 8월 (GLSL 4.2 포함)
- OpenGL 4.3 : 2012년 8월 (GLSL 4.3 포함)
- OpenGL 4.4 : 2013년 7월 (GLSL 4.4 포함)
- OpenGL 4.5 : 2014년 8월 (GLSL 4.5 포함)
- OpenGL 4.6 : 2017년 7월 (GLSL 4.6 포함)
3.2. OpenGL ES
최신 버전은 2015년 8월에 발표한 3.2 버전이다. 임베디드 시스템 등에서 사용할 수 있게 몇 가지 잘 사용되지 않는 함수를 제거한 API. 안드로이드 시스템과 iOS에서 그래픽 가속을 위해 사용된다.
OpenGL ES 1.0은 OpenGL 1.3을, OpenGL ES 1.1은 OpenGL 1.5를, OpenGL ES 2.0은 OpenGL 2.0을 베이스로 만들어졌다. 다만, OpenGL ES 2.0은 OpenGL 2.1 버전까지 사용 가능했던 고정 파이프라인이 제거[12]되었기 때문에 사실상 GLSL이 필수가 된 OpenGL 3.0과 비슷하게 사용된다. OpenGL ES 3.0은 OpenGL 4.3을 베이스로 만들어졌다.
3.2.1. OpenGL ES 버전 일람
- OpenGL ES 1.0 : 2003년 7월 (OpenGL 1.3 기반)
- OpenGL ES 1.1 : 2004년 9월 (OpenGL 1.5 기반)
- OpenGL ES 2.0 : 2007년 3월 (OpenGL 2.0~3.0 기반)
- OpenGL ES 3.0 : 2012년 8월 (OpenGL 4.3 기반)
- OpenGL ES 3.1 : 2014년 3월
- OpenGL ES 3.2 : 2015년 8월
3.3. Vulkan
이 문서를 참고.
4. 관련 문서
[1] 사실 문제라고 하기는 뭣 한게 오늘날 기준으로 너무 자주 버전업되어서 쫓아가지 못 하는 개발 업체들의 모습을 보면 맞는 길이다. 하지만, 당시 하드웨어 성능으로 보면 틀린 길이었고 덕분에 점유율을 많이 잃게 되었다.[2] 크로노스 그룹은 컨소시엄이라서 MS가 전부 쥐고 흔드는 Direct3D 진영에 비해서 통제력이 약할 수 밖에 없다. 그나마 최근에 test suite의 보강으로 드라이버 퀄리티 컨트롤을 하려는 노력을 하고 있는 상황이다.[3] 해당 라이브러리는 1996년(!) 이후로 업데이트된 적이 없다. OS X는 10.10에서 결국 Deprecated 처리되어 사용시 경고가 뜨게 되었다. OpenGL 공식 위키에서 대안으로 FreeGLUT이나 GLFW 등을 추천하고 있으니 관심있는 위키러는 찾아보도록 하자. [4] OpenGL에 입문할 때 FreeGLUT/GLFW, GLEW 이 2가지는 기본적으로 설치하고 시작하는 것이 좋다. 참고로, FreeGLUT보다 GLFW가 더 복잡하고 다양한 기능을 제공한다.[5] GLFW로 화면을 구동하고 GLAD 라이브러리로 시작하는 것을 추천한다. FreeGLUT은 윈도우에서 설정한 해상도보다 16픽셀 줄어드는 문제가 있으며 Imgui 같은 플러그인 사용에도 제한이 있다. GLEW는 새로운 확장 지원이 느리다. 반면 GLAD 라이브러리는 직접 필요한 것들을 포함하여 구성할 수 있다.[6] 사실 윈도우 이외의 OS에서는 OpenGL을 빼면 다른 선택지가 없다.[7] OS X v10.2이후부터[8] Mac OS X 이후에 등장한 Windows Vista부터, 즉 Aero UI 적용 이후부터는 윈도우도 그래픽 가속을 하게 되었다. 당연하지만 기반 API는 DirectX이다.[9] 보통 일반적인 벤더에서 제공하는 확장 기능은 EXT가 붙는 명령어였지만 영향력이 큰 일부 벤더들은 EXT가 아닌 독자적인 이름으로 붙여서 제공했는데 NVIDIA는 NV, MS는 WIN, 인텔은 INTEL로 하는 식이었다. 참고로 MS는 DirectX라는 독자적인 API 개발에 박차를 가함으로써 2003년 3월에 탈퇴했다.[10] 물론 기존의 EXT가 붙여진 확장 명령어들도 꾸준히 추가되었다. ARB에 비해 비중이 줄어들었을 뿐.[11] 물론 교수 입장에서는 이전부터 다뤄온 구버전에 익숙해서인 것도 있지만, 트렌드에 민감한 교수에겐 본인의 의지와 상관없이 학교 커리큘럼 차원에서 OpenGL 1.0을 다루는 교재가 채택됨으로써 어쩔 수 없이 다뤄야 하는 속사정도 있다. 가끔씩 OpenGL 1.0 교재 따윈 장식으로 두고 급하게 따로 준비한 프레젠테이션으로 강의하는 패기 넘치는(?) 교수도 있다.[12] OpenGL 3.0이 발표되기 1년 전에 선행되었다. GLSL 필수로 전환된건 본가쪽 OpenGL이 아닌 모바일/임베디드용인 OpenGL ES부터 시작된 셈.