로딩로딩중

OpenGL

최근 수정 시각:

Open Graphics Library 홈페이지

파일:external/www.opengl.org/opengl-4-logo.gif

1. 개요2. 상세3. 종류
3.1. OpenGL
3.1.1. OpenGL 버전 일람
3.2. OpenGL ES
3.2.1. OpenGL ES 버전 일람
3.3. Vulkan
3.3.1. Vulkan 버전 일람
4. 관련 문서

1. 개요[편집]

1992년 초에 컴퓨터 그래픽을 하드웨어 가속으로 처리(렌더링)함과 동시에 여러 분야에서 사용될 수 있도록 하는 범용성을 보장하기 위해 발표된 2D, 3D 그래픽 라이브러리이자 산업용 API로 범용성이 있는만큼 가장 광범위하게 사용되고 있다.

2. 상세[편집]

OpenGL 이전에는 1980년대 실리콘 그래픽스(SGI) 사에서 개발한 솔루션인 IRIS GL이 있었는데 여러 OS에서 사용할 수 있기 위해 필요한 범용성과 독립성을 고려하지 않고 만들었기 때문에 당시엔 하드웨어 뿐만 아니라 소프트웨어까지 제약이 심했던 솔루션이었다. 그래서 하드웨어와 운영체제에 제약을 받지 않는 범용적인 API 프로그래밍을 위한 OpenGL이 탄생하게 되었던 것.

2000년에 비영리 기술 컨소시엄인 크로노스 그룹이 설립되면서 GPGPU 병렬연산용 라이브러리인 OpenCL을 비롯한 다양한 용도의 라이브러리 및 API꾸러미로 확장 및 관리하기 시작했는데 2006년 7월에 OpenGL도 크로노스 그룹에 의해 관리받는 것으로 전환되었다.

그래픽쪽을 배울 때에는 꼭 접하게 된다. DirectX라이벌 격이라고 할 수 있다.[1]

초창기에는 MS에서도 OpenGL을 지원했다. 현재까지도 그래픽카드 도움 없이 소프트웨어 렌더링인 CPU 가속으로는 OpenGL 1.1까지 지원한다. 그러다가, 독자솔루션인 DirectX를 내놓으면서 MS는 OpenGL은 전문가 산업용, DirectX는 가정용 컴퓨터 게임 그래픽용이라는 기믹을 만들어 퍼뜨렸는데 존 카맥이 OpenGL이 DirectX보다 훨씬 편리하게 게임에 사용이 가능하다고 직접 코드를 보이면서 글을 올렸고, MS는 존 카맥이 사용하기 힘들다면 다른 누구에게도 힘든게 맞다면서 꼬리를 내렸다. 그러나, 1998년 초 1.2버전 이후 OpenGL은 3년 가까이 개선 과정없이 거듭된 병크를 터뜨렸고[2] 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 제조사에 달려 있다. [3] 이러한 이유로 OpenGL 프로그래밍은 각종 GPU 드라이버 버그의 지뢰밭을 살금살금 피하면서 개발하는 과정의 연속이다. 사실상 무늬만 크로스플랫폼인 셈. 구글 크롬은 윈도 버전의 경우 OpenGL을 직접 사용하는 것을 포기하고 OpenGL 명령을 Direct3D로 변환해서 돌리는 ANGLE이라고 불리는 중간 레이어를 개발해서 사용하고 있으며 그 외 플랫폼의 경우 수백개에 달하는 드라이버 버그들을 하나하나씩 우회하는 엄청나게 복잡한 렌더링 패스가 구현되어 있다. 크로노스 그룹이 OpenGL을 놔두고 Vulkan을 만든 가장 큰 이유도 사실 이것이다. 도저히 드라이버가 관리가 안 되는 수준까지 왔기 때문. 그래서 Vulkan은 스펙을 최소화시켜서 드라이버의 역할을 최대한 줄이고 프로그래머들에게 많은 것을 위임하도록 설계되어 있다.

어지간한 그래픽 카드라면 둘 다 지원하는 경우가 많다. DirectX는 사실상 윈도우 전용이므로운영체제(OS X, 우분투 등)를 쓴다면 유일한 그래픽 라이브러리이기도 하다. 2010년대 시점에서는 일반인 시각으로 그놈이 그놈이다. Windows Phone을 제외한 모바일 운영 체제, 특히 안드로이드)에서는 OpenGL이 메이저다.

OpenGL은 크게 GL, GLU(Utility)로 나눠져 있다. GL은 기본적인 함수들이 구현되어 있고, GLU는 좀 더 편히 사용할 수 있도록 함수가 짜여 있다.

사실 OpenGL은 API는 인터페이스와 기능의 명세일 뿐이라 크로스플랫폼이 맞지만, 실제 그 구현체인 라이브러리는 하나의 플랫폼에도 여럿 존재할 수 있고, 플랫폼 마다도 구현이 달라서 디바이스 컨텍스트 생성따위의 부분이 플랫폼마다 모두 달라 완전한 크로스플랫폼이 아니며 이 때문에 실제로 화면에 뭔갈 나타내려면 대체로 추가 라이브러리를 사용해야 하는데, 이때 사용하는 것이 GLUT이다.[4] 이 외에도 SDL등과 연동해서 사용하기도 하는데 이는 대부분 크로스플랫폼을 지원한다.

대부분의 3D 그래픽이 그렇지만, 특히 OpenGL은 로우레벨 API이기 때문에 거의 모든걸 수동으로 해줘야 해서 깊이 있게 사용하려면 어느 정도 수학과 친해져야 한다. 물론, 기본적인 내용에서는 요구하는 수학이 기초적인 공대 수준의 선형대수학과 미분기하학 정도라 그리 어렵지는 않지만, 컴퓨터 공학과 특성상 저쪽과 별 관련없는 이산수학을 제외하면 대학레벨의 수학을 거의 배우지 않는 경우가 많기도 하고, 특히나 신기술이 추가되면서 요구하는 수학 수준도 점점 올라가는 추세이다. 단순히 API를 가져다 쓰는 정도라면 벡터 수준의 지식만 가지고도 되기는 하겠으나, 피상적인 접근에만 머무르게 될 것이다.

관련 교재와 서적으로는 Red Book과 Blue Book(레퍼런스 매뉴얼), Orange Book, Superbible이 대표적이다.

애플이 매우 사랑하여[5] OS X[6]의 모든 시스템 그래픽은 OpenGL로 가속되어 표시된다.[7] 그러나 OpenGL 4.1버전 이후 드라이버 업데이트를 전혀 하지 않아 애플 환경에서 OpenGL을 이용하는 개발자들에게 원성을 사고 있다가, WWDC 2014에서 자체 개발한 iOS용 그래픽 라이브러리인 Metal 라이브러리를 새로 공개하였고, WWDC 2015에는 macOS용 Metal 라이브러리를 추가 공개하면서 앞으로의 macOS, iOS, tvOS용 앱들이 Metal 라이브러리로 개발될 것이라 발표하였다. OpenGL에대한 입장은 특별히 밝히지 않았다.[8] 그러나 2018년 가을 출시 예정인 macOS 10.14버전 모하비에서 OpenGL과 OpenCL 지원을 완전히 중단한다고 발표했다. OpenGL 지원은 현재 존재하는 드라이버를 유지하는 것으로 동결한다고 한다.[9]

2015년 3월, 차세대 OpenGL인 Vulkan이 최초 공개되었다.

3. 종류[편집]

3.1. OpenGL[편집]

최신 버전은 2017년 7월 31일 발표된 4.6 버전이다. #
2.0 버전부터 GLSL을 이용한 셰이더 프로그래밍 언어를 정식으로 지원하기 시작했으나 사실, 셰이더 프로그래밍 언어 자체는 OpenGL의 탄생과 함께 시작되었다. 초기에는 ARB AL라고도 부르는 Architecture Review Board 어셈블리 언어가 그것으로 벤더 입장인 하드웨어 제조사들을 주도로 추가된 확장 기능 컨셉[10]이다보니 OpenGL이 그렇게 중요시 하던 범용성이 무시되었기 때문에 어떤 그래픽카드에서는 잘 돌아가고 다른 어떤 그래픽카드에서는 돌아가지 않는 등 전체적으로 중구난방일 수밖에 없었으며, 1998년 1.2.1 버전에 들어서야 범용성이 있는 ARB_multitexture 명령어를 시작으로 2001년 1.3 버전부터 ARB가 붙여진 공식 확장 기능들이 대거 추가되었지만[11] 결정적으로 어셈블리 언어로 다뤄야 하다보니 진입장벽이 엄청 높았다.
개념 자체는 2000년 11월에 발표된 MS의 DirectX 8.0의 셰이더 어셈블리 언어보다 8년 이상 먼저 내세운 것에 의의 있는 셰이더 프로그래밍 언어라고 볼 수 있지만 2002년에 MS가 진입장벽을 대폭 낮춘 고수준 셰이더 프로그래밍 언어인 HLSL을 재빠르게 발표함으로써 OpenGL 측에서도 2004년에 이와 비슷한 개념을 지닌 GLSL이 발표되었다. 2.0 버전까진 셰이더 프로그래밍 언어를 이용하지 않는 이전의 방식으로도 화면에 폴리곤을 출력할 수 있었지만, 3.0 버전부터는 GLSL을 사용하지 않으면 화면에 폴리곤을 출력할 수 없게끔 필수가 되었다.

교육기관 등에서는 최신버전을 숙지하기 위해서는 구버전부터 개념을 익히는게 중요하다는 명목으로 아직도 1.0 버전을 가지고 수업을 하고 있는 경우가 많다.[12] 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, 11의 차이처럼 렌더 파이프라인 구조의 차이가 있는 개선된 API라고 보는 편이 좋다. 다른 비유로 C++98과 C++11의 관계라고 볼 수 있다.

Vulkan이 워낙 개발하기 어렵기도 해서 그런지 DirectX 12로 개발하기 어려워 DirectX 11과 12가 투 트랙으로 개발되고 있는 것처럼 OpenGL도 Vulkan이 발표된 이후에도 계속 함께 개발되고 있다.

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 버전까지 사용 가능했던 고정 파이프라인이 제거[13]되었기 때문에 사실상 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[편집]

2015년 3월 3일에 열린 GDC 2015에서 공식으로 소개된 새 API이다. OpenGL NG, glNext 등으로 불리다가 Vulkan이라는 이름으로 발표되었다. AMD에서 맨틀의 문서를 모두 지원하여 표준으로 제정되고 있으며, OpenGL이 본래 크로스 플랫폼을 타겟으로 삼았던 것과는 다르게 x86-64 기반과 ARM 기반의 태생적인 하드웨어 성능 차이로 인해서 모바일 플랫폼만 OpenGL ES로 분리[14]시켜 사용되었다면, Vulkan은 시대에 맞게 처음부터 PC, 모바일, VR 등 더 다양한 플랫폼들을 모두 대응하는 것이 목표라는 점. 어찌보면 Vulkan이야말로 진정한 크로스 플랫폼의 2D/3D 그래픽 API일지도... 맨틀이나 DirectX 12처럼 하드웨어 직접 접근 3D 그래픽스 API인 만큼 CPU 오버헤드를 줄이는데 일조할 것으로 보인다.

Vulkan은 특정한 고수준 셰이더 언어를 선호하지 않고 SPIR-V 바이트 코드를 받아들인다는 규정만 존재한다. 따라서 GLSL이 아닌 셰이더 언어도 번역만 SPIR-V로 하면 Vulkan에서 그대로 사용할 수 있다. 단, 현재까지 일반적으로 Vulkan과 함께 사용되는 고수준 셰이더 언어는 OpenGL과 마찬가지로 GLSL이다. Vulkan 1.1에서 Direct3D의 메모리 레이아웃을 native하게 지원하기로 해서 GLSL과 HLSL의 차별도 사실상 없어졌다. HLSL to SPIR-V 컴파일러도 이미 존재한다.[15]


Vulkan과 OpenGL ES의 비교 영상(좌: Vulkan / 우: OpenGL ES)

Vulkan 드라이버 개발에는 AMD, Imagination, Intel, NVIDIA, Qualcomm 이 참여하고 있으며, 데모, 샘플, 엔진 개발에는 ARM, Cinder, Imagination Technology, LunarG, MoltenGL, Norbert Nopper, NVIDIA, Sascha Willems, Unreal Engine 이 참여하고 있다.

그러나 GDC 2015의 Vulkan은 공식으로 처음 소개되었을 뿐, 아직 완성된 버전은 아니었기 때문에 완성된 Vulkan의 공개는 2016년 이후로 예정되었다가 2016년 2월 16일에 Vulkan 1.0이 발표되었다. 발표 직후에 NVIDIA, AMD, intel의 그래픽 지원 베타 드라이버가 각각 발표되었다.

  • NVIDIA Geforce GPU (자세한 사항은 https://developer.nvidia.com/vulkan-driver 참조)

    • TITAN 시리즈

    • GeForce TITAN 시리즈

    • GeForce 10 시리즈[16]

    • GeForce 900(M) 시리즈 : GeForce 910M처럼 페르미 아키텍처를 사용한 제품을 제외한 모든 모델

    • GeForce 800M 시리즈 : GeForce 820M처럼 페르미 아키텍처를 사용한 제품을 제외한 모든 케플러 아키텍처 기반의 모델

    • GeForce 700(M) 시리즈 : GeForce GT 705처럼 페르미 아키텍처를 사용한 제품을 제외한 모든 케플러 아키텍처 기반의 모델

    • GeForce 600(M) 시리즈 : GeForce GT 610, 620, 630[17]처럼 페르미 아키텍처를 사용한 제품을 제외한 모든 케플러 아키텍처 기반의 모델


  • AMD Radeon GPU

    • AMD Radeon™ RX VEGA Series graphics

    • AMD Radeon™ RX 500 Series graphics

    • AMD Radeon™ RX 400 Series graphics

    • AMD Radeon™ Rx 300 Series graphics

    • AMD Radeon™ Rx 200 Series graphics

    • AMD Radeon™ HD 8000 Series graphics for OEM systems (HD 8570 이상)

    • AMD Radeon™ HD 8000M Series graphics for notebooks

    • AMD Radeon™ HD 7000 Series graphics (GCN 아키텍처 기반의 HD 7730 이상)

    • AMD Radeon™ HD 7000M Series graphics for notebooks (HD 7730M 이상)

    • AMD RYZEN 2000U Series APUs (codenamed “Raven Ridge”)

    • AMD A6/A8/A10/FX™ 9000 Series APUs (codenamed “Bristol Ridge”)

    • AMD A6/A8/A10/FX™ 8000 Series APUs (codenamed “Carrizo”)

    • AMD A6/A8/A10 PRO-7000 Series APUs (codenamed “Kaveri”)

    • AMD A4/A6/A8/A10-7000 Series APUs (codenamed “Kaveri”)

    • AMD E1-2000, E2-3000, A4-5000, A6-5000, and A4 Pro-3000 Series APUs (codenamed “Kabini”) #

    • AMD A4-1200, A4-1300 and A6-1400 Series APUs (codenamed “Temash”)

    • AMD E1/A4/A10 Micro-6000 Series APUs (codenamed “Mullins”)

    • AMD E1/E2/A4/A6/A8-6000 Series APUs (codenamed “Beema”)



Windows에서 Vulkan API를 사용하기 위해서는 Windows 7 SP1 이상이어야 하며, 이 사이트에서 자신의 기기가 Vulkan API를 지원하는지 확인할 수 있다. 지원 운영체제는 ARM/x86 안드로이드 7.0 누가 이상[20], 64비트 윈도우, 64비트 리눅스이다. 아직 개발중인 베타 프로그램으로 깃허브에 코드가 공개되어있다.

여담으로, 애플 iOS는 공개당시에는 지원하지 않았다. 아마 애플은 Metal API를 독자적으로 쓰기에, Vulkan API는 굳이 지원할 필요가 없기에 그런것 같다. 이전 설명에는 메탈 API가 성능상 낫지 않다고 되어 있는데, 아난드텍의 화웨이 P10 벤치마크에서는 둘이 비슷한 이점을 가진다고 분석하고 있다. 그리고 벤치마크 상으로는 메탈을 지원하는 아이폰 7이 벤치마크에서 훨씬 더 높은 이득을 가져가고 있음을 보여주었다. 아난드텍은 Vulkan의 이점이 드러나려면 좀더 시간이 흐른 후일 것이라고 평하였다. 이는 iPad, 64비트 앱에서 볼 수 있듯 상대적으로 앱 시장이 적극적으로 신기술에 반응하는 특성도 영향을 끼친 듯 하다.

2018년 2월부터 기존의 상용 라이브러리인 MoltenVK가 오픈소스로 공개되면서, Vulkan을 Metal로 번역하는 방식으로 우회적으로 macOSiOS에서 Vulkan 지원을 시작하였다.#

2018년 7월 1일 현재 다음의 제약이 존재한다.

  • Tesselation Shader와 Geometry shader는 지원되지 않는다. (macOS상에서 Metal이 지원하지 않기 때문)

  • Event 관련 함수는 지원되지 않는다.

    • vkCreateEvent() / vkDestroyEvent() / vkGetEventStatus() / vkSetEvent() / vkResetEvent() / vkCmdSetEvnet() / vk CmdResetEvent() / vkCmdWaitEvents()

  • Sparse 메모리 함수의 일부가 지원되지 않는다.

    • vkGetImageSparseMemoryRequirements() / vkGetPhysicalDeviceSparseImageFormatProperties() / vkQueueBindSparse()

  • Application-controlled memory allocation은 무시된다.

    • vkAllocationCallbacks

  • 제한적인 texture specific swizzle만 지원된다.

3.3.1. Vulkan 버전 일람[편집]

  • Vulkan 1.0 : 2016년 2월 16일

  • Vulkan 1.1 : 2018년 3월 7일

4. 관련 문서[편집]

[1] 다만 DirectX는 그래픽 뿐만 아니라 사용자 입력과 포스피드백 같은 컨트롤러 제어, 음향쪽도 아우르고 있어 OpenGL과 1:1로 대응되지 않는다. OpenGL은 순수하게 그래픽 출력만을 담당하니까.[2] 사실 병크라고 하기는 뭣 한게 오늘날 기준으로 너무 자주 버전업되어서 쫓아가지 못 하는 개발 업체들의 모습을 보면 맞는 길이다. 하지만, 당시 하드웨어 성능으로 보면 틀린 길이었고 덕분에 점유율을 많이 잃게 되었다.[3] 크로노스 그룹은 컨소시엄이라서 MS가 전부 쥐고 흔드는 Direct3D 진영에 비해서 통제력이 약할 수 밖에 없다. 그나마 최근에 test suite의 보강으로 드라이버 퀄리티 컨트롤을 하려는 노력을 하고 있는 상황이다.[4] 해당 라이브러리는 1996년(!) 이후로 업데이트된 적이 없다. OS X는 10.10에서 결국 Deprecated 처리되어 사용시 경고가 뜨게 되었다. OpenGL 공식 위키에서 대안으로 FreeGLUT이나 GLFW 등을 추천하고 있으니 관심있는 위키러는 찾아보도록 하자. 디바이스 컨텍스트에 관한 지식을 쌓은 후 WGL이나 GLX 등을 이용해 네이티브하게 구현해버려도 상관은 없지만 그러면 크로스플랫폼과는 영영 이별인지라(...)[5] 사실 윈도우 이외의 OS에서는 OpenGL을 빼면 다른 선택지가 없다.[6] OS X v10.2이후부터[7] Mac OS X 이후에 등장한 Windows Vista부터, 즉 Aero UI 적용 이후부터는 윈도우도 그래픽 가속을 하게 되었다. 당연하지만 기반 API는 DirectX[8] 이때까지만 해도 상황의 심각성을 확실히 깨닫지 못하였고, "애플이 OpenGL을 버린다고 해서 개발자들이 버리는 것은 아니며, 결국 Mac 전용 앱이 아니라면 Metal을 쓰는 개발자는 적을 것이다. OpenGL로 짠 게임이나 그래픽 툴이 윈도우로 나올 때 상대적으로 Mac과 Linux에 포팅이 쉽다. 근데 아예 API를 바꿔버린다면 포팅될 때 매우 많은 노력이 들어가게 된다. OpenGL로 포팅된 게임에는 WOW 같은 게임이 있다." 라는 분석이 본 문단에 기재되어 있었다.[9] 후술할 Vulkan 역시 공식 지원하지 않으므로 매우 파급력이 큰 결정이다.[10] 보통 일반적인 벤더에서 제공하는 확장 기능은 EXT가 붙는 명령어였지만 영향력이 큰 일부 벤더들은 EXT가 아닌 독자적인 이름으로 붙여서 제공했는데 NVIDIA는 NV, MS는 WIN, 인텔은 INTEL로 하는 식이었다. 참고로 MS는 DirectX라는 독자적인 API 개발에 박차를 가함으로써 2003년 3월에 탈퇴했다.[11] 물론 기존의 EXT가 붙여진 확장 명령어들도 꾸준히 추가되었다. ARB에 비해 비중이 줄어들었을 뿐.[12] 물론 교수 입장에서는 이전부터 다뤄온 구버전에 익숙해서인 것도 있지만, 트렌드에 민감한 교수에겐 본인의 의지와 상관없이 학교 커리큘럼 차원에서 OpenGL 1.0을 다루는 교재가 채택됨으로써 어쩔 수 없이 다뤄야 하는 속사정도 있다. 가끔씩 OpenGL 1.0 교재따윈 장식으로 두고 급하게 따로 준비한 프레젠테이션으로 강의하는 패기 넘치는(?) 교수도 있다.[13] OpenGL 3.0이 발표되기 1년 전에 선행되었다. GLSL 필수로 전환된건 본가쪽 OpenGL이 아닌 모바일/임베디드용인 OpenGL ES부터 시작된 셈.[14] 과거에는 OpenGL조차 게임용으로 쓰기 복잡해서 게임용으로만 간추려진 MiniGL을 별도로 제공한 적이 있었다. 특정 용도를 위해 불필요한 기능을 제거한 취지만 보면 현재 OpenGL ES와 다를 바 없다.[15] google shaderc [16] 이 제품군 이상부터는 기본적으로 지원하므로 따로 모델명을 표기하지 않는다.[17] 초기형 모델 한정. 2013년 6월에 출시된 후기형 모델은 케플러 아키텍처 기반이다.[18] 공식인증은 아직 받지 않았지만, Adreno 420에서 코어당 유닛 2개를 뺀 Adreno 418이 공식지원이기에, 굳이 공식인증을 받지 않아도 불칸 API를 지원 한다. 허나 구글 레퍼런스 기기인 넥서스 6가 7.1 소스코드에 불칸관련드라이버가 배제된채 적용된 것이 소스코드 확인결과 확정되었기에, 넥서스 6가 지원불가 판정이 나면서 가능할지 불가능할지 미지수가 되었다.[19] 공식인증은 Mali-T8XX/7XX밖에 받지 않았지만, 초기 베타버전때는 Mali-T6XX시리즈로 불칸 API를 개발했기에 Mali-T6XX는 공식인증 받지 않아도 하드웨어적으로는 지원한다. 또한 불칸 첫 베타버전 공개 당시때, 엑시노스 5420으로 불칸 구동을 시연했다.[20] 그런데 삼성이 갤럭시 S7에서 마시멜로에 불칸을 올렸다! 물론 크로노스 그룹과 구글의 협조가 있어서 가능했던 것이지만.