OpenGL

1. 개요

OpenGL은 3차원 그래픽스 렌더링을 위한 API(Application Programming Interface)로, 점, 선, 다각형과 같은 기본 도형을 픽셀 형식으로 변환하여 화면에 표시하는 역할을 한다. 1992년 SGI에 의해 처음 출시되었으며, 이후 OpenGL 아키텍처 검토 위원회(ARB)를 거쳐 2006년부터는 크로노스 그룹에서 관리하고 있다. OpenGL은 다양한 버전으로 발전해 왔으며, 각 버전마다 새로운 기능과 확장이 추가되었다. OpenGL은 3D 그래픽스 API인 DirectX와 경쟁하며, 2017년 OpenGL 4.6 버전을 마지막으로 더 이상 버전 업데이트는 이루어지지 않고 사양서 유지보수만 진행되고 있다. 또한 Vulkan(벌칸)이라는 차세대 API가 OpenGL의 뒤를 잇고 있다.

2. 역사

1980년대에는 다양한 종류의 그래픽 하드웨어에서 작동하는 소프트웨어를 개발하는 것이 매우 어려웠다. 소프트웨어 개발자들은 각각의 하드웨어에 맞춰 인터페이스와 드라이버를 직접 만들어야 했고, 이는 많은 비용과 노력을 요구했다.

1990년대 초, 실리콘 그래픽스(SGI)는 워크스테이션용 3차원 그래픽스 분야의 선두 주자였다. SGI가 개발한 IRIS GL API는 사용하기 쉽고 즉시 모드 렌더링을 지원하여 업계의 사실상의 표준으로 자리 잡았다. 이는 개방형 표준이었던 PHIGS보다 더 널리 사용되었는데, PHIGS는 사용하기 어렵고 기능적으로 뒤처진다는 평가를 받았다. 그러나 썬 마이크로시스템즈, 휴렛 패커드, IBM 등 SGI의 경쟁사들이 PHIGS 표준을 확장하여 지원하는 3차원 하드웨어를 시장에 출시하면서 SGI의 시장 점유율은 점차 약화되었다. 시장에서의 영향력을 유지하기 위해 SGI는 IrisGL API를 공개 표준으로 전환하기로 결정했는데, 이것이 바로 OpenGL의 시작이다.

OpenGL의 첫 번째 버전인 1.0은 1992년 6월 30일 마크 시걸(Mark Segal)과 커트 애클리(Kurt Akeley)에 의해 출시되었다. 같은 해, SGI는 OpenGL 사양을 유지하고 발전시킬 기업 컨소시엄인 OpenGL 아키텍처 검토 위원회(OpenGL Architecture Review Board, ARB)의 설립을 주도했다. ARB는 이후 여러 버전의 사양을 발표하며 OpenGL을 꾸준히 확장해 나갔다.

1996년 마이크로소프트(Microsoft)가 Direct3D를 출시하면서 OpenGL의 주요 경쟁자로 부상했다. 1997년에는 마이크로소프트와 SGI가 OpenGL과 Direct3D 인터페이스 통합을 목표로 하는 Fahrenheit 프로젝트를 시작했으나, SGI의 재정적 어려움, 마이크로소프트의 전략적 판단 변화, 업계 지원 부족 등으로 인해 1999년에 중단되었다.

2006년 7월, OpenGL ARB는 OpenGL API 표준의 제어권을 크로노스 그룹(Khronos Group)에 이전하기로 투표했다. 크로노스 그룹 관리 하에서 OpenGL은 4.6 버전(2017년 출시)까지 발전했지만, 2016년 후속 API인 Vulkan이 발표된 이후 OpenGL의 주요 업데이트는 거의 이루어지지 않고 있다. 레이 트레이싱과 같은 최신 기술은 표준에서 지원되지 않는다.

Vulkan이나 Metal과 같은 새로운 그래픽 API의 등장과 애플(Apple Inc.) 등 일부 주요 기업들의 지원 축소에도 불구하고, OpenGL은 여전히 플랫폼 간 호환성과 ANGLE 같은 호환성 계층 덕분에 널리 사용되고 있다. Mesa 3D는 OpenGL의 대표적인 오픈 소스 구현체로, 리눅스 등 여러 플랫폼에서 하드웨어 가속을 지원한다.

2.1. 초기 역사 (1980년대 ~ 1990년대 초)

1980년대에는 다양한 종류의 그래픽 하드웨어에서 작동하는 소프트웨어를 개발하는 것이 큰 어려움이었다. 소프트웨어 개발자들은 각각의 하드웨어에 맞춰 인터페이스와 드라이버를 직접 만들어야 했고, 이는 많은 비용과 노력을 요구했다.

1990년대 초, 실리콘 그래픽스(SGI)는 워크스테이션용 3차원 그래픽스 분야의 선두 주자였다. SGI가 개발한 IRIS GL API는 사용하기 쉽고 즉시 모드 렌더링을 지원하여 업계의 사실상 표준으로 자리 잡았다. 이는 개방형 표준이었던 PHIGS보다 더 널리 사용되었는데, PHIGS는 사용하기 어렵고 기능적으로 뒤처진다는 평가를 받았다.

그러나 썬 마이크로시스템즈, 휴렛 패커드, IBM 등 SGI의 경쟁사들이 PHIGS 표준을 확장하여 지원하는 3차원 하드웨어를 시장에 출시하면서 SGI의 시장 점유율은 점차 약화되었다. 시장에서의 영향력을 유지하기 위해 SGI는 IrisGL API를 공개 표준으로 전환하기로 결정했는데, 이것이 바로 OpenGL의 시작이다.

하지만 SGI에게는 IRIS GL 기반 시스템에 상당한 투자를 한 고객들이 많았기 때문에 즉각적인 전환은 어려웠다. 또한 IRIS GL은 3차원 그래픽스와 직접 관련이 없는 기능들도 포함하고 있었다. 예를 들어, X 윈도 시스템이나 썬 마이크로시스템즈의 NeWS보다 먼저 개발되었기 때문에 자체적인 윈도잉, 키보드, 마우스 API를 가지고 있었다. 라이선스 및 특허 문제 역시 IRIS GL을 그대로 공개하기 어렵게 만드는 요인이었다. 이러한 이유로 SGI는 OpenGL에 대한 시장의 지원이 자리를 잡을 때까지 기존의 고급 독점 API인 Open Inventor와 Iris Performer를 계속 지원해야 했다.

IRIS GL의 또 다른 한계는 하드웨어가 기본적으로 지원하는 기능에만 접근할 수 있다는 점이었다. 만약 그래픽 하드웨어가 특정 기능을 지원하지 않으면, 애플리케이션에서 해당 기능을 사용할 수 없었다. OpenGL은 이 문제를 해결하기 위해 하드웨어에서 지원하지 않는 기능이라도 소프트웨어적으로 구현하여 제공했다. 이를 통해 상대적으로 성능이 낮은 시스템에서도 고급 그래픽 기능을 활용할 수 있게 되었다. OpenGL은 하드웨어 접근을 표준화하고, 하드웨어 인터페이스 프로그램(장치 드라이버) 개발의 책임을 하드웨어 제조사에 넘겼으며, 윈도잉 기능은 운영 체제에 맡겼다. 이렇게 다양한 종류의 그래픽 하드웨어가 동일한 언어(API)를 사용하게 되면서, 소프트웨어 개발자들은 3차원 소프트웨어를 더 쉽게 개발할 수 있는 상위 수준의 플랫폼을 갖게 되었다.

1992년, SGI는 OpenGL 사양을 유지하고 발전시킬 기업 컨소시엄인 OpenGL 아키텍처 검토 위원회(OpenGL ARB)의 설립을 주도했다. 이 위원회에는 3Dlabs, 애플, AMD(구 ATI), 델, 에반스 앤드 서더랜드, HP, IBM, 인텔, Matrox, 엔비디아, 실리콘 그래픽스, 썬 마이크로시스템즈(현 오라클) 등이 참여했다.

2.2. OpenGL 아키텍처 리뷰 위원회 (ARB) 설립과 발전 (1992년 ~ 2006년)

1980년대에는 다양한 그래픽 하드웨어에서 작동하는 소프트웨어를 개발하는 것이 매우 어려웠다. 소프트웨어 개발자는 각 하드웨어에 맞는 사용자 정의 인터페이스와 드라이버를 작성해야 했으며, 이는 많은 비용과 중복된 노력을 발생시켰다.

1990년대 초, 실리콘 그래픽스(SGI)는 워크스테이션용 3D 그래픽 분야를 선도하고 있었다. SGI의 IRIS GL API는 사실상의 산업 표준으로 자리 잡았으며, 개방형 표준인 PHIGS보다 널리 사용되었다. 이는 IRIS GL이 사용하기 쉽고 즉시 모드 렌더링을 지원했기 때문으로 평가받았다. 반면 PHIGS는 사용하기 어렵고 기능이 부족하다는 인식이 있었다.

SGI의 경쟁사들(썬 마이크로시스템즈, 휴렛 팩커드, IBM 등)도 PHIGS 표준 확장을 통해 3D 하드웨어를 시장에 출시하기 시작했다. 이러한 경쟁 환경 속에서 SGI는 IRIS GL을 기반으로 한 공개 표준인 OpenGL을 만들기로 결정했다. 하지만 기존 IRIS GL 고객들의 전환 비용 문제와 IRIS GL 자체의 라이선스 및 특허 문제, 그리고 3D 그래픽과 관련 없는 윈도잉, 키보드, 마우스 API 등의 기능 포함 문제로 인해 SGI는 OpenGL 시장이 성숙할 때까지 자체적인 Iris Inventor 및 Iris Performer API를 계속 지원해야 했다.

IRIS GL의 한계 중 하나는 하드웨어가 지원하는 기능만 사용할 수 있다는 점이었다. OpenGL은 하드웨어가 지원하지 않는 기능을 소프트웨어적으로 구현하여 이 문제를 해결했고, 이를 통해 비교적 낮은 성능의 시스템에서도 고급 그래픽 기능을 사용할 수 있게 되었다. 또한 OpenGL은 하드웨어 접근을 표준화하고, 장치 드라이버 개발 책임을 하드웨어 제조사에 넘겼으며, 윈도잉 기능은 운영 체제에 맡겼다. 이를 통해 다양한 그래픽 하드웨어가 동일한 언어를 사용하게 되어, 3D 소프트웨어 개발자에게 더 높은 수준의 개발 플랫폼을 제공하는 중요한 계기가 되었다.

1992년, SGI는 OpenGL 사양을 유지하고 발전시킬 기업 컨소시엄인 OpenGL 아키텍처 검토 위원회(OpenGL Architecture Review Board, ARB)의 설립을 주도했다. ARB에는 3Dlabs, 애플, AMD(구 ATI), 델, 에반스 앤드 서더랜드, HP, IBM, 인텔, Matrox, 엔비디아, 실리콘 그래픽스, 썬 마이크로시스템즈(현 오라클) 등 주요 기업들이 참여했다. 2년 후인 1994년경, SGI는 장면 그래프 API 등을 포함하는 "OpenGL++"라는 개념을 제시하고 일부 관계자들과 사양을 공유하기도 했으나, 실제 제품으로 이어지지는 않았다.

OpenGL의 첫 번째 버전인 1.0은 1992년 6월 30일 마크 세갈(Mark Segal)과 커트 애클리(Kurt Akeley)에 의해 출시되었다. 이후 ARB는 새로운 버전의 사양을 발표하며 OpenGL을 꾸준히 확장해 나갔다. 각 버전은 호환 그래픽 카드가 지원해야 하는 기본 기능 집합을 정의하고, 새로운 확장 기능을 쉽게 개발할 수 있는 기반을 제공했다. 새로운 버전은 주로 여러 그래픽 카드 제조사에서 널리 구현된 확장 기능들을 통합하는 방식으로 발전했다.

그래픽 처리 장치(GPU) 제조사들은 코어 API 외에도 확장(extension) 형태로 추가 기능을 제공할 수 있었다. 확장은 새로운 함수나 새로운 상수를 도입할 수 있으며, 기존 OpenGL 함수에 대한 제한을 완화하거나 제거할 수 있다. 공급업체는 다른 공급업체 또는 크로노스 그룹 전체의 지원 없이도 사용자 지정 API를 노출하기 위해 확장을 사용할 수 있으며, 이는 OpenGL의 유연성을 크게 향상시켰다. 모든 확장은 OpenGL 레지스트리에 수집되어 정의된다. 각 확장은 이를 개발한 회사의 이름을 기반으로 하는 짧은 식별자와 연결된다. 예를 들어, 엔비디아(Nvidia)의 식별자는 NV이다. 여러 공급업체가 동일한 API를 사용하여 동일한 기능을 구현하는 데 동의하면, 식별자 EXT를 사용하여 공유 확장이 릴리스될 수 있다. 이러한 경우, 크로노스 그룹의 아키텍처 검토 위원회가 해당 확장에 대한 명시적인 승인을 제공하는 경우도 있으며, 이 경우 식별자 ARB가 사용된다. OpenGL 1.2.1 버전부터 ARB 확장 개념이 공식적으로 도입되었다.

1996년 마이크로소프트(Microsoft)가 Direct3D를 출시하면서 OpenGL의 주요 경쟁자로 부상했다. 이에 50명 이상의 게임 개발자들은 1997년 6월 12일, 마이크로소프트에 OpenGL을 적극적으로 지원할 것을 촉구하는 공개 서한을 발표하기도 했다. 같은 해 12월 17일, 마이크로소프트와 SGI는 OpenGL과 Direct3D 인터페이스를 통합하고 장면 그래프 API를 추가하는 것을 목표로 하는 Fahrenheit 프로젝트를 공동으로 시작했다. 1998년에는 휴렛 팩커드도 이 프로젝트에 합류했다. 이 프로젝트는 초기에 3D 그래픽 API 분야에 질서를 가져올 가능성을 보여주었으나, SGI의 재정적 어려움, 마이크로소프트의 전략적 판단 변화, 그리고 업계 전반의 지원 부족으로 인해 결국 1999년에 중단되었다.

2006년 7월, OpenGL ARB는 OpenGL API 표준의 제어권을 크로노스 그룹(Khronos Group)에 이전하기로 투표했다. 이는 OpenGL 역사에서 중요한 전환점이 되었다.

다음은 1992년부터 2006년까지 발표된 주요 OpenGL 버전과 기능이다.

2.3. 크로노스 그룹으로의 관리 이관 (2006년 ~ 현재)

2006년 7월, OpenGL 아키텍처 검토 위원회는 OpenGL API 표준의 제어권을 크로노스 그룹(Khronos Group)에 이전하기로 결정했다. 이후 OpenGL 사양의 새로운 버전은 크로노스 그룹에서 출시하며, 각 버전은 다양한 새로운 기능을 지원하도록 API를 확장한다. 각 버전의 세부 사항은 그래픽 처리 장치(GPU) 제조업체, 운영 체제 설계자, 그리고 모질라(Mozilla) 및 구글(Google)과 같은 일반 기술 회사를 포함하는 그룹 구성원 간의 합의에 의해 결정된다.

크로노스 그룹으로 관리 이관된 이후에도 OpenGL은 꾸준히 발전해왔다. 2006년 2.1 버전부터 2017년 4.6 버전까지 여러 차례 업데이트가 이루어졌으며, 주요 업데이트 내용은 다음과 같다.

코어 API에서 요구하는 기능 외에도, GPU 공급업체는 '확장(extension)' 형태로 추가 기능을 제공할 수 있다. 확장은 새로운 함수와 상수를 도입하거나 기존 함수의 제한을 완화하여 OpenGL의 유연성을 높인다. 모든 확장은 OpenGL 레지스트리에 수집 및 정의된다. 확장은 개발 회사 이름 기반의 식별자(예: 엔비디아(Nvidia)의 NV)를 가지며, 여러 공급업체가 동의한 확장은 EXT, 크로노스 그룹의 승인을 받은 확장은 ARB 식별자를 사용한다. OpenGL의 새로운 버전 기능은 주로 널리 구현된 ARB 또는 EXT 확장 기능들을 통합하여 구성된다.

그러나 OpenGL은 더 이상 활발하게 개발되지 않고 있다. 가장 최신 버전인 4.6은 2017년에 출시되었으며, 이는 이전 버전 출시 후 3년 만의 업데이트였고 기존 확장 기능을 코어 프로파일에 포함하는 수준에 그쳤다. 2016년에 출시된 Vulkan API가 OpenGL의 활발한 개발을 대체했으며, 초기에는 glNext라는 코드명으로 불렸다. 2017년 크로노스 그룹은 OpenGL ES의 새로운 버전 개발 중단을 발표하고 Vulkan 및 다른 기술 개발에 집중하고 있다. 이로 인해 레이 트레이싱과 같은 최신 GPU 기능은 OpenGL 표준에서 지원되지 않지만, 공급업체별 확장을 통해 지원될 수는 있다.

Vulkan과 같은 후속 API의 등장과 주요 기업들의 지원 축소에도 불구하고, OpenGL은 여전히 널리 사용되는 표준으로 남아 있다. 이는 새로운 확장 기능 및 드라이버 최적화를 통한 지속적인 개발 노력, 플랫폼 간 호환성, 그리고 ANGLE 및 Zink와 같은 호환성 계층 덕분이다. 이 계층들은 OpenGL이 Vulkan이나 Metal 위에서 효율적으로 실행되도록 하여 개발자들이 계속 사용하거나 점진적으로 전환할 경로를 제공한다.

그래픽 API 환경 변화에 따라 일부 기업들은 OpenGL 지원을 축소하거나 중단하고 있다. 2018년 6월, 애플(Apple Inc.)은 모든 플랫폼(iOS, macOS, tvOS)에서 OpenGL API 지원을 중단하고 자체 API인 Metal 사용을 권장했다. 게임 개발사들도 새로운 API를 채택하고 있다. id 소프트웨어(id Software)는 id Tech 7 엔진에서 Vulkan으로 전환했고, 밸브 코퍼레이션(Valve Corporation)은 도타 2에서 OpenGL 지원을 제거했다. Atypical Games는 삼성의 지원을 받아 비 애플 플랫폼에서 Vulkan을 사용하도록 게임 엔진을 업데이트했다.

크로노스 그룹이 OpenGL 개발을 사실상 중단했다는 시각도 있으나, 공식적인 지원 종료 발표는 없었다. 구글의 퓨시아(Fuchsia) OS는 기본적으로 Vulkan을 사용하지만, ANGLE 변환 계층을 통해 Vulkan 위에서 OpenGL을 지원할 계획이다.

2.4. OpenGL 버전별 세부 확장

OpenGL 사양의 새로운 버전은 크로노스 그룹에서 출시하며, 각 버전은 다양한 새로운 기능을 지원하도록 API를 확장한다. 각 버전의 세부 사항은 그래픽 카드 제조업체, 운영 체제 설계자, 그리고 모질라(Mozilla) 및 구글(Google)과 같은 일반 기술 회사를 포함하는 그룹 구성원 간의 합의에 의해 결정된다.

코어 API에서 요구하는 기능 외에도, 그래픽 처리 장치(GPU) 공급업체는 확장(extension) 형태로 추가 기능을 제공할 수 있다. 확장은 새로운 함수와 새로운 상수를 도입할 수 있으며, 기존 OpenGL 함수에 대한 제한을 완화하거나 제거할 수 있다. 공급업체는 다른 공급업체 또는 크로노스 그룹 전체의 지원 없이도 사용자 지정 API를 노출하기 위해 확장을 사용할 수 있으며, 이는 OpenGL의 유연성을 크게 향상시킨다. 모든 확장은 OpenGL 레지스트리에 수집되어 정의된다.

각 확장은 이를 개발한 회사의 이름을 기반으로 하는 짧은 식별자와 연결된다. 예를 들어, 엔비디아(Nvidia)의 식별자는 NV이며, 이는 확장 이름 GL_NV_half_float, 상수 GL_HALF_FLOAT_NV 및 함수 glVertex2hNV()의 일부이다. 여러 공급업체가 동일한 API를 사용하여 동일한 기능을 구현하는 데 동의하면, 식별자 EXT를 사용하여 공유 확장이 릴리스될 수 있다. 이러한 경우, 크로노스 그룹의 아키텍처 검토 위원회(Architecture Review Board, ARB)가 해당 확장에 대한 명시적인 승인을 제공하는 경우도 있으며, 이 경우 식별자 ARB가 사용된다.

OpenGL의 각 새로운 버전에서 도입된 기능은 일반적으로 ARB 또는 EXT 유형의 여러 널리 구현된 확장의 결합된 기능으로 구성된다. OpenGL의 첫 번째 버전인 1.0 버전은 1992년 6월 30일에 마크 세갈(Mark Segal)과 커트 에이클리(Kurt Akeley)에 의해 출시된 이후, 사양의 새로운 버전을 통해 꾸준히 확장되어 왔다. 이러한 릴리스는 모든 호환 그래픽 카드가 지원해야 하는 기본 기능 집합을 정의하며, 이를 기반으로 새로운 확장을 더 쉽게 작성할 수 있도록 돕는다.

OpenGL은 2001년부터 2014년까지 주로 매년 업데이트되었으나, 가장 최신 사양인 4.6 버전은 2017년에 출시된 이후 활발한 개발이 이루어지지 않고 있다. 이는 2016년에 출시된 Vulkan API로 개발 초점이 옮겨갔기 때문이다. 그 결과, 레이 트레이싱과 같은 최신 GPU 기능은 OpenGL 표준에서 지원되지 않지만, 공급업체별 확장을 통해 여전히 새로운 기능이 제공될 수 있다. 각 버전별 주요 기능과 통합된 확장 기능에 대한 자세한 내용은 해당 버전의 하위 섹션에서 다룬다.

2.4.1. OpenGL 1.1

1997년 3월 4일에 출시되었다. 이 버전의 주요 기능으로는 텍스처 객체(Texture Object)와 정점 배열(Vertex Array)이 도입되었다. OpenGL의 새로운 버전은 일반적으로 널리 구현된 여러 확장 기능(Extension)을 통합하여 만들어지는데, OpenGL 1.1은 다음과 같은 주요 확장 기능들을 코어 API에 포함시켰다.

2.4.2. OpenGL 1.2

1998년 3월 16일에 출시되었다. 주요 변경 사항은 다음과 같다.

* 3D 텍스처 지원이 추가되었다.
* BGRA 및 패킹된 픽셀 형식을 지원하게 되었다.
* 이미지 처리 애플리케이션에 유용한 이미징 하위 집합(imaging subset)이 도입되었다.

1998년 10월 14일에는 1.2.1 버전이 출시되어 ARB 확장 개념이 도입되었다.

OpenGL 1.2는 다음 확장을 코어 기능으로 통합했다.

2.4.3. OpenGL 1.2.1

1998년 10월 14일에 출시되었다. 이 버전의 가장 큰 특징은 ARB 확장 개념을 도입한 것이다.

OpenGL 확장은 GPU 공급업체가 코어 API에서 요구하는 기능 외에 추가적인 기능을 제공하는 방법이다. 확장을 통해 새로운 함수나 상수를 도입할 수 있으며, 기존 OpenGL 함수의 제한을 완화하거나 제거할 수도 있다. 공급업체는 다른 공급업체나 크로노스 그룹 전체의 지원 없이도 자체적인 API를 노출하기 위해 확장을 사용할 수 있다. 모든 확장은 OpenGL 레지스트리에 수집되어 정의된다.

각 확장은 이를 개발한 회사의 이름을 기반으로 하는 짧은 식별자와 연결된다. 예를 들어, 엔비디아(Nvidia)의 식별자는 NV이다. 여러 공급업체가 동일한 API를 사용하여 동일한 기능을 구현하는 데 동의하면, 식별자 EXT를 사용하여 공유 확장이 릴리스될 수 있다. 이러한 경우, 크로노스 그룹의 아키텍처 검토 위원회(Architecture Review Board, ARB)가 해당 확장에 대한 명시적인 승인을 제공하는 경우도 있으며, 이 경우 식별자 ARB가 사용된다. OpenGL 1.2.1에서 도입된 ARB 확장 개념은 이렇게 공식적으로 승인된 확장을 의미하며, 이후 OpenGL 버전 업데이트 시 이러한 ARB 확장들이 코어 기능으로 통합되는 경우가 많다.

2.4.4. OpenGL 1.3

2001년 8월 14일에 출시되었다. 주요 기능으로 큐브 매핑(ARB_texture_cube_map), 다중 텍스처링(ARB_multitexture), 다중 샘플링(ARB_multisample), 텍스처 압축(ARB_texture_compression) 등이 추가되었으며, 이는 여러 ARB 확장을 코어 기능으로 통합한 것이다.

아래는 OpenGL 1.3과 관련된 주요 ARB 확장 기능 목록이다.

2.4.5. OpenGL 1.4

2002년 7월 24일에 출시되었다. 주요 기능으로 깊이 텍스처, GL슬랭 지원이 추가되었다.

2.4.6. OpenGL 1.5

2003년 7월 29일에 출시되었다. 이 버전에서는 정점 버퍼 객체(VBO)와 폐색 쿼리 기능이 새롭게 추가되었다.

주요 추가 기능과 관련된 확장은 다음과 같다.

2.4.7. OpenGL 2.0

2004년 9월 7일에 출시되었다. 주요 특징은 다음과 같다.
* GLSL 버전 1.1을 도입하여 프로그래밍 가능한 셰이딩을 지원했다.
* 다중 렌더 대상 (Multiple Render Targets, MRT) 기능을 통해 여러 버퍼에 동시에 렌더링할 수 있게 되었다.
* 텍스처 크기가 2의 거듭제곱이 아니어도 되는 비-2의 거듭제곱 (Non-Power-of-Two, NPOT) 텍스처를 지원했다.
* 포인트 스프라이트 (Point Sprites) 기능을 추가했다.
* 양면 스텐실 (Two-sided stencil) 기능을 지원했다.

2.4.8. OpenGL 2.1

2006년 7월 2일에 출시되었다. 이 버전에서는 GLSL 버전이 1.2로 업데이트되었으며, 픽셀 버퍼 객체(PBO, Pixel Buffer Object)와 sRGB 텍스처 기능이 추가되었다.

다음은 OpenGL 2.1에 통합된 주요 확장 기능이다.

2.4.9. OpenGL 3.0

OpenGL 3.0은 2008년 8월 11일에 출시되었다. 이 버전은 GLSL 1.3 버전을 지원하며, 주요 기능으로는 텍스처 배열, 조건부 렌더링, 프레임 버퍼 객체(FBO) 등이 도입되었다.

OpenGL 3.0의 코어 프로파일에서는 이전 버전에서 사용되던 일부 기능들이 폐지 예정(deprecated)으로 지정되었다. 대표적으로 프리미티브 그리기를 기록하고 재생하는 Display List 기능과, `glBegin()`/`glEnd()` 블록을 사용하여 프리미티브를 그리는 방식이 이에 해당한다。이는 API를 현대화하고 효율성을 높이기 위한 변화였다.

OpenGL 3.0은 여러 확장 기능들을 표준 사양으로 통합했다. 주요 통합된 확장 기능들은 다음과 같다.

2.4.10. OpenGL 3.1

OpenGL 3.1은 2009년 3월 24일에 출시되었으며, GLSL 1.4 버전을 지원한다. 이 버전에서는 인스턴싱(Instancing), 텍스처 버퍼 객체(Texture Buffer Objects), 균일 버퍼 객체(Uniform Buffer Objects), 프리미티브 재시작(Primitive Restart) 등의 주요 기능이 추가되었다.

OpenGL 3.1에 통합된 주요 확장 기능은 다음과 같다.

2.4.11. OpenGL 3.2

OpenGL 3.2는 2009년 8월 3일에 출시되었다. 이 버전은 GLSL 1.5 버전을 지원하며, 주요 기능으로 지오메트리 셰이더와 다중 샘플링 텍스처가 도입되었다.

OpenGL 3.2는 다음과 같은 크로노스 그룹의 ARB(Architecture Review Board) 확장들을 코어 기능으로 통합했다.

2.4.12. OpenGL 3.3

OpenGL 3.3은 2010년 3월 11일에 출시되었다. 이 버전은 GLSL 3.30 버전을 지원하며, OpenGL 4.0 사양의 기능 중 가능한 많은 부분을 이전 버전에서도 사용할 수 있도록 가져오는 것(백포트)에 중점을 두었다.

OpenGL 3.3 코어 프로파일에 통합된 주요 ARB 확장 기능은 다음과 같다.

2.4.13. OpenGL 4.0

OpenGL 4.0은 2010년 3월 11일에 출시되었으며, GLSL 4.00 버전을 지원한다. 주요 기능으로는 GPU 테셀레이션과 64비트 정밀도 셰이더 지원이 추가되었다.

다음은 OpenGL 4.0에 포함된 주요 확장 기능 목록이다.

2.4.14. OpenGL 4.1

OpenGL 4.1은 2010년 7월 26일에 출시되었으며, GLSL 4.10 버전을 지원한다.

주요 기능으로는 개발자 친화적인 디버그 출력 기능과 OpenGL ES 2.0과의 호환성 향상이 있다.

다음은 OpenGL 4.1에 포함된 주요 확장 기능이다.

2.4.15. OpenGL 4.2

2011년 8월 8일에 출시되었다. 이 버전은 GLSL 4.20을 지원하며, 다음과 같은 주요 기능이 추가되었다.

* 셰이더 내 원자 카운터(Atomic counter) 지원
* 변환 피드백(Transform feedback) 인스턴스 그리기 지원
* 셰이더 패킹(Shader packing) 기능 지원
* 성능 개선

OpenGL 4.2는 여러 ARB 확장을 코어 기능으로 통합했다. 주요 관련 확장은 다음과 같다.

2.4.16. OpenGL 4.3

출시일: 2012년 8월 6일

GLSL 4.30 버전을 지원한다. 주요 기능으로는 GPU 병렬 처리를 활용하는 컴퓨트 셰이더, 셰이더 스토리지 버퍼 객체, 고품질 ETC2/EAC 텍스처 압축, 메모리 보안 강화, 다중 응용 프로그램 견고성 확장, OpenGL ES 3.0과의 호환성 등이 있다.

다음은 OpenGL 4.3과 함께 도입된 확장 기능 목록이다.

2.4.17. OpenGL 4.4

2013년 7월 22일에 출시되었다. GLSL 버전은 4.40이다.

주요 기능은 다음과 같다:
* 버퍼 배치 제어
* 효율적인 비동기 쿼리
* 셰이더 변수 레이아웃
* 효율적인 다중 객체 바인딩
* Direct3D 응용 프로그램의 간소화된 포팅
* 바인드리스 텍스처 확장
* 희소 텍스처 확장

OpenGL 4.4와 관련된 주요 크로노스 그룹 승인 확장(ARB Extensions)은 다음과 같다.

2.4.18. OpenGL 4.5

OpenGL 4.5는 2014년 8월 11일에 출시되었으며, GLSL 4.50 버전을 지원한다.

주요 기능은 다음과 같다:
* 직접 상태 접근 (Direct State Access, DSA): 객체의 상태를 직접 수정하여 API 호출 오버헤드를 줄이고 코드를 간결하게 만든다.
* 플러시 제어 (Flush Control): 명령어 실행 흐름 제어를 통해 CPU와 GPU 간의 동기화 부담을 줄여 성능을 개선한다.
* 견고성 (Robustness): GPU 리셋과 같은 예외 상황 발생 시 애플리케이션의 안정성을 높이고 오류 복구를 지원한다.
* [[OpenGL ES]] 3.1 호환성: 모바일 환경에서 널리 사용되는 OpenGL ES 3.1 API 및 셰이더와의 호환성을 강화하여 플랫폼 간 코드 공유를 용이하게 한다.
* [[DirectX|DX11]] 에뮬레이션 기능: 마이크로소프트의 Direct3D 11과 유사한 기능을 일부 포함하여, Direct3D 기반 애플리케이션을 OpenGL로 전환하는 작업을 단순화한다.

OpenGL 4.5는 여러 기존 확장 기능들을 코어 표준으로 통합했다. 주요 통합된 확장 기능은 아래 표와 같다.

2.4.19. OpenGL 4.6

GLSL 4.60 버전을 지원하며, 2017년 7월 31일에 출시되었다. OpenGL 4.6은 주로 기존의 11개 ARB 및 EXT 확장을 코어 프로파일에 통합하는 데 중점을 두었다. 주요 추가 기능으로는 보다 효율적인 지오메트리 처리 및 셰이더 실행, 오류 컨텍스트 없음(KHR_no_error), 폴리곤 오프셋 클램프(ARB_polygon_offset_clamp), SPIR-V, 이방성 필터링(ARB_texture_filter_anisotropic) 등이 있다.

OpenGL 4.6에 통합된 확장 기능은 다음과 같다.

3. 설계

OpenGL 규격은 2차원 및 3차원 그래픽을 그리기 위한 추상적인 API를 정의한다. 이 API는 주로 하드웨어 가속 (예: GPU)을 통해 구현되도록 설계되었지만, CPU에서 실행되는 소프트웨어만으로도 구현할 수 있다. API 자체는 클라이언트 프로그램에서 호출할 수 있는 여러 함수들과, `GL_TEXTURE_2D` (십진수 3553에 해당)와 같은 명명된 정수 상수들로 구성된다. 함수 정의는 표면적으로 C 언어와 유사하지만, 실제로는 특정 프로그래밍 언어에 종속되지 않는다.

이러한 언어 독립성 덕분에 OpenGL은 다양한 언어 바인딩을 가지고 있다. 대표적으로 웹 브라우저용 WebGL (JavaScript 바인딩, OpenGL ES 2.0 기반), WGL, GLX, CGL (C 바인딩), iOS 및 Java/Android 환경에서 제공하는 C 바인딩 등이 있다. API 구현은 주로 하드웨어 제조사나 운영체제가 제공하는 장치 드라이버를 통해 이루어진다.

OpenGL은 언어뿐만 아니라 플랫폼 간에도 독립적인 크로스 플랫폼 API이다. 규격 자체는 OpenGL 컨텍스트를 얻거나 관리하는 방법, 즉 특정 윈도우 시스템과의 상호작용에 대해서는 명시하지 않고, 각 운영체제나 환경의 구현에 맡긴다. 따라서 OpenGL은 순수하게 렌더링 작업에만 집중하며, 입력 처리, 오디오 재생, 창 관리와 같은 기능은 제공하지 않는다.

OpenGL은 프로그래머에게 단일 API를 제공함으로써 서로 다른 3차원 가속기 간의 복잡한 상호작용을 단순화하고, 모든 구현체가 완전한 OpenGL 기능 집합을 지원하도록 (필요하다면 소프트웨어 에뮬레이션을 통해서라도) 강제함으로써 하드웨어 플랫폼 간의 성능 및 기능 차이를 감추는 것을 목표로 한다. 렌더링 장치의 구체적인 구현을 숨기는 추상화 계층 역할을 하여 높은 이식성을 제공하며, 하드웨어 가속을 통해 고속 렌더링이 가능하다.

OpenGL은 SGI를 시작으로 다양한 UNIX 워크스테이션, Linux, FreeBSD, Windows, macOS 등 여러 플랫폼에서 사용할 수 있다. 모바일 기기 및 임베디드 시스템을 위한 서브셋 버전인 OpenGL ES와 안전 필수 시스템용 OpenGL SC 규격도 존재한다. 오픈 표준으로 공개되어 다양한 환경에서 널리 사용되며, 풍부한 보조 라이브러리가 존재한다.

초기 버전에서는 게임 개발에 필요한 기능 지원이 부족했지만, OpenGL 2.0에서 고수준 셰이딩 언어인 GLSL을 표준화하고 이후 버전을 거치며 기능을 보강하여 OpenGL 4.3 이후에는 Direct3D 11과 기능적으로 큰 차이가 없어졌다. 그러나 설계 사상의 차이로 인해 완벽한 상호 호환성은 없으며, 성능은 하드웨어 및 드라이버 최적화 수준에 따라 달라진다.

OpenGL은 화면(프레임 버퍼)에 그리는 것을 전제로 설계되었으며, 폴리곤과 같은 기본 도형을 래스터화하여 3D 그래픽을 실시간으로 구현한다. 레이 트레이싱과 같은 방식은 표준으로 지원하지 않는다. 깊이 정보를 위한 뎁스 버퍼, 마스크 처리를 위한 스텐실 버퍼, 고정밀 색상 합성을 위한 축적 버퍼 등을 지원한다. 프로그래머블 셰이더의 도입으로 표현력이 크게 향상되었다.

하지만 OpenGL은 오래된 API 설계를 유지하고 있어 최신 하드웨어의 성능을 완전히 활용하기 어렵고, 장치 드라이버 구현의 품질 관리 등에도 문제를 안고 있다는 비판이 있다. 2016년 후속 API인 Vulkan이 발표된 이후로는 OpenGL의 주요 업데이트가 거의 이루어지지 않고 있다.

3.1. 그래픽 파이프라인

OpenGL의 동작은 점, 선, 다각형과 같은 기본 도형을 그리고, 이를 픽셀 형식으로 변환하는 것을 허용한다. 이러한 일은 OpenGL 상태 머신(OpenGL State Machine)이라는 그래픽스 파이프라인을 통하여 이루어진다.

4. 예제

wiki

glClear( GL_COLOR_BUFFER_BIT );

이 문장은 색상 버퍼를 지워 화면을 빈 화면으로 만든다.


glMatrixMode( GL_PROJECTION ); /* 뒤이어 나타나는 행렬 명령이 투영행렬에 영향을 줌 */
glLoadIdentity(); /* 투영행렬을 단위 행렬로 초기화 함 */
glFrustum( -1, 1, -1, 1, 1, 1000 ); /* 투시투영행렬을 적용시킴 */

위 문장은 투영행렬을 초기화한 후, 가시 영역을 표현하는 행렬로 삼차원 절두체 행렬을 사용한다는 명령이다. 이 행렬은 카메라에 상대적인 공간에서 표현되는 객체를 OpenGL의 투영 공간으로 변환시키는 역할을 한다.


glMatrixMode( GL_MODELVIEW ); /* 뒤이어 나타나는 행렬 명령이 모델뷰행렬에 영향을 줌 */
glLoadIdentity(); /* 모델뷰행렬을 단위행렬로 초기화 함 */
glTranslatef( 0, 0, -3 ); /* z 축으로 3 단위만큼 모델뷰를 평행이동시킴 */

위 문장은 모델뷰 행렬을 단위행렬로 초기화한다. 이 행렬은 모델에 상대적인 좌표로부터 카메라 공간으로의 변환을 정의하는 행렬이다.


glBegin( GL_POLYGON ); /* 다각형을 만든다 */
glColor3f( 0, 1, 0 ); /* 현재 색상을 녹색으로 설정한다 */
glVertex3f( -1, -1, 0 ); /* 다각형에 필요한 정점을 만든다 */
glVertex3f( -1, 1, 0 ); /* 다각형에 필요한 정점을 만든다 */
glVertex3f( 1, 1, 0 ); /* 다각형에 필요한 정점을 만든다 */
glVertex3f( 1, -1, 0 ); /* 다각형에 필요한 정점을 만든다 */
glEnd(); /* 다각형 만드는 일을 종료시킨다 */

위의 명령은 XY 평면 위에 녹색의 다각형을 그리는 작업을 수행한다.

5. 관련 기술

1980년대에는 다양한 그래픽 하드웨어에서 작동하는 소프트웨어를 개발하는 것이 매우 어려운 일이었다. 개발자들은 각기 다른 하드웨어에 맞춰 인터페이스와 드라이버를 따로 만들어야 했고, 이는 많은 비용과 노력을 요구했다.

1990년대 초, 실리콘 그래픽스(SGI)는 워크스테이션용 3차원 그래픽스 분야를 선도하고 있었다. SGI의 IRIS GL API는 사실상의 산업 표준으로 자리 잡으며, 기존의 개방형 표준인 PHIGS를 무색하게 했다. IRIS GL은 사용하기 쉬웠고 즉시 모드 렌더링을 지원했지만, PHIGS는 사용하기 어렵고 기능적으로 뒤처진다는 평가를 받았다.

그러나 썬 마이크로시스템즈, 휴렛 패커드, IBM 등 경쟁사들이 PHIGS 표준 기반의 3차원 하드웨어를 출시하며 SGI의 시장 점유율을 위협하기 시작했다. 이에 SGI는 시장 영향력을 유지하기 위해 자사의 IRIS GL API를 개방형 표준으로 전환하기로 결정했고, 이것이 바로 OpenGL의 시작이 되었다.

5.1. 벌칸 (Vulkan)

SIGGRAPH 2014에서 기존 OpenGL 설계를 재검토하고 처음부터 다시 구축하는 차세대 표준 3D API 규격, 'OpenGL Next Generation'(glNext)의 제정이 발표되었다. 이 새로운 API는 멀티스레드 처리와 셰이딩 중간 언어 같은 현대적인 기술 도입을 목표로 했다.

이후 GDC 2015에서 이 새로운 규격의 공식 명칭이 벌칸(Vulkan^독일어)으로 결정되었음이 발표되었다. 벌칸은 Direct3D 12와 유사하게 커맨드 큐 기반의 멀티스레드 렌더링 기능을 지원하며, OpenCL과 프로그래밍 기반을 공유하는 SPIR-V 중간 표현을 도입하는 것이 특징이다. 또한, AMD의 로우 레벨 그래픽 API인 Mantle의 요소 기술이 벌칸에 채택되었다.

과거 "Next Generation OpenGL Initiative"(glNext)라는 이름으로 알려졌던 벌칸은 OpenGL과 OpenGL ES를 하나의 공통 API로 통합하려는 재설계의 결과물이다. 벌칸 API의 첫 번째 버전인 1.0은 2016년 2월 16일에 정식으로 출시되었으며, 기존 OpenGL 버전들과 하위 호환성을 가지지 않는다.

벌칸은 하드웨어의 세부적인 제어를 가능하게 하는 로우 레벨 API이기 때문에, 개발자가 배우기 어렵고 작성해야 할 코드의 양이 많아진다는 단점이 있다. 반면, 기존의 OpenGL은 CPU와 GPU 간의 동기화 같은 복잡한 처리를 자동으로 관리해주는 상위 레벨 API로서 벌칸에 비해 배우기 쉽다는 장점이 있으며, 오랜 기간 축적된 코드 자산과 노하우를 가지고 있다. 크로노스 그룹은 벌칸 출시 초기에는 OpenGL의 유지보수와 업데이트를 지속할 예정이라고 밝혔으나, 2017년에 발표된 OpenGL 4.6 버전을 마지막으로 OpenGL의 새로운 버전 개발은 사실상 중단되었고, 이후에는 기존 사양의 유지보수만 이루어지고 있다.

5.2. OpenGL 지원 라이브러리

OpenGL 자체는 하드웨어 및 장치 드라이버 계층에 가까운 저수준 라이브러리다. 따라서 응용 프로그램 개발을 돕는 다양한 고수준 보조 및 확장 라이브러리가 존재한다. 특히 OpenGL 컨텍스트 생성 및 관리는 복잡하고 운영 체제마다 다르므로, 많은 라이브러리가 이 기능을 제공한다. 또한 OpenGL 확장 기능을 식별하고 로드하는 작업을 자동화하는 라이브러리도 있다.

윈도우 생성 및 관리 툴킷
이러한 툴킷은 OpenGL 창을 생성 및 관리하고 키보드, 마우스 등 입력을 처리하는 데 중점을 둔다.
* GLUT: 초기의 윈도우 시스템 독립적인 OpenGL 프로그램 작성을 돕는 도구였으나, 현재는 유지보수가 중단되었다.
* freeglut: GLUT를 대체하는 라이브러리로, GLUT API의 상위 집합이며 더 안정적이고 최신 기능을 지원한다. 크로스플랫폼 윈도우 및 키보드, 마우스 핸들러를 제공한다.
* GLFW: 크로스플랫폼 윈도우, 키보드, 마우스, 조이스틱 핸들러를 제공하는 이식 가능한 프레임워크로, 게임 개발에 주로 사용된다.

멀티미디어 라이브러리
게임과 같은 멀티미디어 애플리케이션 개발에 유용하며, OpenGL 창 생성 기능 외에도 입력, 사운드 등의 기능을 제공한다.
* SDL (Simple DirectMedia Layer): C API를 사용하는 크로스플랫폼 멀티미디어 라이브러리다.
* SFML: C++ API를 기반으로 하며 C#, Java, Haskell, Go 등 다양한 언어 바인딩을 지원하는 크로스플랫폼 멀티미디어 라이브러리다.
* Allegro 5: 게임 개발에 중점을 둔 C API 기반의 크로스플랫폼 멀티미디어 라이브러리다.

GUI (그래픽 사용자 인터페이스) 툴킷
애플리케이션에 버튼, 체크박스 등 그래픽 사용자 인터페이스 요소를 추가하는 기능을 제공한다.
* GLUI: GLUT를 기반으로 만들어진 GUI 툴킷이다.
* FLTK: 작고 빠른 크로스플랫폼 C++ 위젯 라이브러리다.
* Qt: 크로스플랫폼 C++ 위젯 툴킷으로, 데스크톱 GL과 OpenGL ES 간의 차이를 추상화하는 여러 OpenGL 헬퍼 객체를 제공한다.
* wxWidgets: 크로스플랫폼 C++ 위젯 툴킷이다.

확장 로딩 라이브러리
OpenGL 확장 기능을 식별하고 로드하는 작업을 자동화하여 개발 편의성을 높인다.
* GLee: OpenGL 확장을 쉽게 사용할 수 있도록 돕는 단순한 라이브러리다.
* GLEW: 널리 사용되는 OpenGL 확장 로딩 라이브러리다.
* glbinding: 사용 가능한 모든 확장 및 함수를 자동으로 로드하도록 설계된 라이브러리다.
* 대부분의 언어 바인딩(JOGL, PyOpenGL 등)에서도 확장 자동 로드 기능을 제공한다.

기타 유틸리티 라이브러리
* GLU: 초기 OpenGL과 함께 제공되었던 보조 라이브러리로, 테셀레이션, 밉맵 생성 등 간단한 기능을 제공했다. 현재는 폐지된 OpenGL 기능에 의존한다.
* GLM: GLSL 규격에 기반한 OpenGL을 위한 C++ 수학 툴킷이다.
* Glux: OpenGL 유틸리티 및 보조 기능을 제공하는 라이브러리다.

5.3. 기타 3D 그래픽스 API

* Mesa 3D: OpenGL의 오픈 소스 구현체이다. 순수 소프트웨어 렌더링을 수행할 수 있으며, BSD, 리눅스 및 기타 플랫폼에서 직접 렌더링 인프라를 활용하여 하드웨어 가속을 사용할 수도 있다. 20.0 버전부터 OpenGL 표준 버전 4.6을 구현한다.

* VirtualGL: 원격지 X 서버로 렌더링된 이미지를 보내주는 OpenGL 3D 모델 서버이다.
* Direct3D: 마이크로소프트사에서 개발한 OpenGL의 경쟁 API이다.
* RISpec: 픽사에서 개발한 실사 오프라인 렌더링을 위한 공개 API이다.

5.4. 기타 2D 그래픽스 API

* 카이로 - 여러 운영체제에서 사용할 수 있는 벡터 그래픽 툴킷.
* GTK+ - 여러 운영체제에서 사용할 수 있는 그래픽 위젯 툴킷.
* Qt - 여러 운영체제에서 사용할 수 있는 그래픽 위젯 툴킷.
* wxWidgets - 여러 운영체제에서 사용할 수 있는 그래픽 위젯 툴킷.

6. 문제점 및 한계

OpenGL은 여러 가지 문제점과 한계를 가지고 있다.

문자열 렌더링

OpenGL 자체에는 GDI/GDI+ (Windows)나 Core Graphics (macOS)와 같은 고수준 문자열 렌더링 API가 없다. 따라서 문자열을 표시하려면 미리 문자가 그려진 텍스처를 이용하거나, 각 운영체제 플랫폼에 맞는 API(예: Windows의 wglUseFontOutlines() 함수)와 연동해야 한다. 크로스 플랫폼 유틸리티 라이브러리인 GLUT 등을 사용하면 간단한 문자열 렌더링은 가능하지만, 기능이 매우 제한적이어서 주로 디버깅 용도로 사용된다. NVIDIA는 고도의 렌더링과 글꼴 지원을 위한 GL_NV_Path_Rendering 확장을 제공하지만, 이는 표준 기능은 아니다.

이에 비해 Direct3D는 Direct2D나 DirectWrite와 같은 2D 및 문자열 렌더링에 특화된 API와 연동 기능이 잘 갖추어져 있어, 복잡한 문자열 처리에 더 유리하다.

멀티 GPU 지원 부족

Direct3D는 DXGI를 통해 시스템에 장착된 여러 GPU 중 특정 GPU를 선택하여 사용할 수 있다. 이를 이용해 DirectCompute 같은 GPGPU 기술에서 여러 GPU에 작업을 분산시켜 처리 성능을 높일 수 있다. 하지만 OpenGL은 버전 4.6 기준으로 여러 GPU를 선택적으로 사용하거나 각 GPU에 리소스를 할당하는 기능이 표준화되어 있지 않다.

Windows 환경에서는 NVIDIA의 WGL_NV_gpu_affinity나 AMD의 WGL_AMD_gpu_association 같은 WGL 확장을 통해 제한적으로 멀티 GPU를 활용할 수 있지만, 이마저도 제약이 있다. 예를 들어 NVIDIA 확장은 전문가용 Quadro 카드에서만 작동하며, GeForce에서는 사용할 수 없다. 다른 운영체제에서는 AMD의 X 윈도 시스템용 GLX_AMD_gpu_association 확장만 존재한다.

SLI나 CrossFire 같은 기술을 사용하면 드라이버 수준에서 렌더링 작업을 분산시킬 수 있지만, 이는 주로 게임 그래픽 성능 향상을 위한 기술이며 GPGPU 활용에는 제약이 따른다. 또한 이 기술들은 메모리를 미러링하기 때문에 GPU 개수만큼 사용 가능한 메모리가 늘어나지 않는다. 반면 DirectX 12는 운영체제 차원에서 멀티 GPU를 네이티브로 지원하여, 벤더 기술에 의존하지 않고 분산 렌더링 및 메모리 통합이 가능하다. 이러한 이유로 어도비 포토샵과 같이 OpenGL 가속을 사용하는 일부 소프트웨어는 멀티 GPU 환경을 권장하지 않기도 한다.

컴퓨트 기능 사용 시 윈도우 시스템 의존성

DirectCompute는 CUDA나 OpenCL처럼 운영체제의 윈도우 시스템(사용자 인터페이스)과 직접적인 연관 없이도 컴퓨트 기능을 사용할 수 있다. 즉, 화면 출력을 위한 윈도우 생성 없이도 순수하게 계산 작업만 수행할 수 있다.

하지만 OpenGL은 API를 사용하기 위해 반드시 '렌더링 컨텍스트'를 생성해야 하며, 이 컨텍스트는 운영체제의 윈도우 시스템과 관련된 서피스(화면 또는 메모리상의 그리기 영역)에 연결되어야 한다. OpenGL 4.3부터 GPGPU를 위한 컴퓨트 셰이더가 도입되었지만, 이러한 구조적 제약 때문에 OpenGL 컴퓨트 셰이더를 사용하려면 반드시 윈도우 시스템과 연동해야 한다. 이는 시뮬레이션 결과를 화면에 바로 시각화하는 등 그래픽 연동이 필수적인 경우에는 큰 문제가 되지 않지만, 화면 출력 없이 순수하게 계산 능력만 활용하려는 경우에는 불편함이 따를 수 있다. 현재로서는 완전한 오프스크린 컴퓨팅은 OpenCL 등에 의존해야 한다.

멀티스레드 지원 미흡

Direct3D 11은 '디퍼드 컨텍스트'라는 개념을 도입하여 멀티코어 CPU 환경에서 여러 스레드를 활용해 렌더링 명령을 준비하고 실행함으로써 성능을 높일 수 있다. Direct3D 12는 이를 더욱 발전시켜 멀티스레드 효율성을 극대화했다. 또한 Direct3D 11에서는 여러 스레드에서 동시에 리소스를 생성하는 것이 비교적 자유롭다.

반면 OpenGL은 4.6 버전까지 이러한 네이티브 멀티스레드 렌더링 지원 기능이 부족하다. 기본적으로 OpenGL 렌더링 컨텍스트는 그것을 생성한 스레드에서만 사용할 수 있다. 다른 스레드에서 리소스를 생성하거나 사용하려면 wglShareLists() (Windows)나 glXCreateContext() (Linux) 같은 플랫폼 종속적인 API를 사용하여 명시적으로 컨텍스트를 공유해야 하는 번거로움이 있다. OpenGL 4.6에서 여러 셰이더를 병렬로 컴파일하는 GL_KHR_parallel_shader_compile 확장이 추가되었지만, 이는 표준 코어 기능이 아닌 확장 기능으로 제공된다.

드라이버 품질 및 GLSL 컴파일러 문제

Windows의 Direct3D 드라이버는 WHQL이라는 품질 인증 시스템을 통해 일정 수준의 안정성을 보장받지만, OpenGL 커뮤니티 전체에는 오랫동안 이러한 표준화된 드라이버 인증 시스템이 부재했다. 이로 인해 그래픽 카드 제조사나 제품별로 OpenGL 드라이버의 품질 편차가 심각했으며, 이는 개발자와 사용자 모두에게 불만 요소로 작용했다.

또한, OpenGL의 셰이딩 언어인 GLSL은 크로노스 그룹에서 레퍼런스 컴파일러 구현을 제공하지만, 셰이더 프로그램의 공통된 중간 형식(바이트코드) 사양이 없어 각 그래픽 카드 드라이버에 포함된 컴파일러가 실행 시간에 소스 코드를 직접 컴파일한다. 문제는 OpenGL 사양 자체에 모호한 부분이 존재하여, 제조사별 컴파일러의 동작이 미묘하게 달라 동일한 코드라도 특정 환경에서만 오류가 발생하는 등 예측 불가능한 문제를 야기하고 개발자의 부담을 가중시켰다.

이러한 문제를 해결하기 위해 크로노스 그룹은 OpenGL 4.4 이후 자체적인 품질 보증 제도를 도입하여 개선을 추진하고 있다. 또한 OpenGL의 후속 API인 Vulkan에서는 SPIR-V라는 표준 중간 언어를 채택했으며, OpenGL 4.6에서도 SPIR-V 지원이 코어 기능으로 추가되었다.

한편, 구글이 주도하는 ANGLE 프로젝트는 Direct3D, Vulkan, Metal 등 다른 그래픽스 API를 기반으로 OpenGL ES API를 에뮬레이션하는 라이브러리이다. 이는 원래 브라우저의 WebGL 구현을 위해 시작되었지만, 불안정한 네이티브 OpenGL 드라이버를 우회하고 더 안정적인 다른 API(특히 Windows의 Direct3D)를 활용하여 호환성과 성능을 개선하려는 목적으로도 사용되고 있다.

7. DirectX와의 관계

OpenGL은 3차원 그래픽스를 전문적으로 다루는 라이브러리인 반면, DirectX는 게임 개발에서의 이용을 주된 목적으로 하며 그래픽스뿐만 아니라 사운드 및 입력 관련 API까지 포함하고 있다는 점에서 차이가 있다. 따라서 OpenGL과 직접 비교할 대상은 DirectX의 구성 요소 중 그래픽스를 담당하는 Direct3D이다.

DirectX는 주로 Windows나 Xbox 플랫폼에서의 게임 개발 등에 많이 사용된다. 반면 OpenGL은 크로스 플랫폼을 지원하여 Windows뿐만 아니라 Linux, macOS 등 다양한 운영체제에서 구현되어 제공된다. Windows 환경에서는 DirectX와 OpenGL을 모두 사용할 수 있다.

OpenGL은 워크스테이션에서 시작되었고 크로스 플랫폼을 지원한다는 특징 때문에, CAD, 산업 디자인, 과학 기술 계산 및 의료 분야에서의 시각화 등 업무 분야에서 널리 사용되어 왔다. 이는 크로스 플랫폼 애플리케이션뿐만 아니라 Windows 전용 애플리케이션에서도 마찬가지였다. 과거에는 이러한 업무용 분야에서 엔터테인먼트 용도가 주였던 Direct3D보다 OpenGL이 선호되는 경향이 있었다. 이러한 배경으로 인해 워크스테이션이나 업무용 GPU 및 비디오 카드 제품 중에는 OpenGL에 최적화된 사양을 갖춘 제품들이 판매되었다. 대표적으로 NVIDIA의 Quadro/RTX 시리즈나 AMD의 FirePro/Radeon Pro 시리즈가 있으며, 이들은 장치 드라이버를 포함한 전체 사양이 OpenGL에 맞춰 최적화되어 있다. 하지만 이런 제품들은 상대적으로 DirectX(Direct3D)에 대한 최적화가 부족하여, DirectX 기반 애플리케이션에서는 성능이 떨어지는 경향을 보이기도 한다. 또한 일부 업무용 소프트웨어는 드라이버의 품질이나 안정성을 이유로 OpenGL/Direct3D 사용 여부와 관계없이 이러한 전문가용 그래픽 하드웨어 제품만을 공식 지원하기도 한다. 예를 들어, Windows 버전의 AutoCAD는 과거 OpenGL을 사용했으나, 버전 2008부터는 Windows Vista 환경에서 Direct3D를 사용하기 시작했고, 버전 2022 이후로는 Direct3D 12를 우선적으로 사용하지만, 인증된 하드웨어 목록에는 소비자용 제품이 아닌 전문가용 제품만 포함된다。

그러나 최근 Vulkan이나 Metal과 같은 새로운 로우 레벨 API가 등장하고 OpenGL의 발전이 정체되면서, 업무용 및 디자인용 소프트웨어에서도 OpenGL 지원을 중단하는 사례가 나타나고 있다. Windows 버전의 Shade3D는 버전 17을 마지막으로 OpenGL 지원을 종료하고 버전 18부터는 Direct3D만 지원하며, Vectorworks는 버전 2022부터 OpenGL 대신 DirectX/Metal을 사용하기 시작했다。

GeForce나 Radeon과 같은 일반 소비자용 GPU의 Windows용 드라이버는 주로 Direct3D에 최적화되어 있지만, 그렇다고 해서 소비자용 GPU와 Windows 드라이버 환경에서 OpenGL이 항상 Direct3D보다 느린 것은 아니며, 경우에 따라서는 OpenGL이 더 빠른 성능을 보이기도 한다。

GPU 제조사들은 Windows뿐만 아니라 Linux 및 macOS용 OpenGL 지원 드라이버도 제공하고 있다. 다만 macOS의 경우, Windows나 Linux와 달리 제조사가 공식적으로 지원하는 하드웨어가 제한적이다。

과거 실리콘 그래픽스와 마이크로소프트는 OpenGL과 Direct3D의 통합을 목표로 1997년 Fahrenheit라는 3D 그래픽스 API 공동 개발을 시작하기도 했으나, 이 계획은 1999년 말 사실상 중단되었다. 마이크로소프트는 OpenGL ARB 설립 당시 멤버였으나 2003년에 탈퇴했다. 이후 여러 변화를 거쳐 2014년 OpenGL 4.5 발표와 함께 마이크로소프트가 OpenGL 사양 관리 주체인 Khronos 그룹에 다시 참여하게 되었다。

8. macOS에서의 지원 중단

2018년 6월 5일, 애플(Apple Inc.)은 WWDC 2018에서 macOS, iOS, tvOS 등 모든 자사 플랫폼에서 OpenGL 및 OpenCL API를 비권장(deprecated)한다고 발표했다. 이는 macOS Mojave부터 적용되었으며, 애플은 개발자들에게 2014년에 도입된 자체 그래픽 API인 Metal을 대신 사용하도록 강력히 권장하고 있다.

이에 따라 macOS에서 네이티브로 지원하는 OpenGL의 마지막 버전은 4.1 버전에 머물러 있다. 애플이 대체재로 권장하는 Metal은 Vulkan과 유사한 로우 레벨 API로, 하드웨어에 더 가깝게 접근할 수 있지만 OpenGL보다 직접적인 애플리케이션 개발보다는 미들웨어 개발에 더 적합한 특성을 가진다.

9. ARM 버전 Windows에서의 이용

마이크로소프트 서피스 Pro X와 같이 ARM 아키텍처 기반 Windows 환경에서는 기본적으로 opengl32.dll 및 glu32.dll 파일이 제공되지만, GPU 제조사가 ARM용 OpenGL 드라이버를 제공하지 않는 경우가 많아 OpenGL 1.2 이후 버전의 기능을 사용하기 어렵다.

이를 해결하기 위해 마이크로소프트는 ARM 버전의 윈도우 10 및 윈도우 11에서 OpenCL, OpenGL, Vulkan 애플리케이션을 실행할 수 있도록 호환 기능 팩(Compatibility Pack)을 제공하고 있다. 이 호환 기능 팩은 DirectX 12 기반으로 만들어진 매핑 레이어이며, Mesa 프로젝트에서 가져온 라이브러리 등을 포함한다. 2024년 6월 기준으로 이 호환 기능 팩을 통해 OpenGL 3.3 버전까지의 기능을 사용할 수 있다.

퀄컴의 SoC인 스냅드래곤 X Elite에 내장된 아드레노 GPU의 경우, 향후 매핑 레이어를 통해 OpenGL 4.6 버전까지 지원될 예정이다.