API는 클라이언트 프로그램이 호출할 수 있는 일련의함수와 이름이 지정된정수 상수(예:십진법 3553에 해당하는 GL_TEXTURE_2D 상수)의 집합으로 정의된다. 함수 정의는 표면적으로C 언어와 유사하지만, 언어 독립적이다. 따라서 OpenGL은 많은언어 바인딩을 가지고 있으며, 가장 주목할 만한 것으로는웹 브라우저 내에서 3D 렌더링을 하기 위한자바스크립트 바인딩인WebGL(OpenGL ES 2.0 기반 API), C 바인딩인WGL,GLX 및CGL,iOS에서 제공하는 C 바인딩,안드로이드에서 제공하는자바 및 C 바인딩이 있다.
언어 독립적일 뿐만 아니라 OpenGL은 크로스 플랫폼이기도 하다. 사양서에는 OpenGL 컨텍스트를 획득하고 관리하는 주제에 대해 언급하지 않으며, 이를 하부의윈도 시스템의 세부 사항으로 남겨둔다. 같은 이유로 OpenGL은 오로지 렌더링에만 집중하며 입력, 오디오 또는 윈도잉과 관련된 API는 제공하지 않는다.
OpenGL은 더 이상 활발하게 개발되지 않고 있다. 2001년에서 2014년 사이에는 OpenGL 사양이 거의 매년 업데이트되었으며, 2009년에는 두 번(3.1, 3.2), 2010년에는 세 번(3.3, 4.0, 4.1)의 릴리스가 있었다. 최신 OpenGL 사양인 4.6은 3년의 공백기 후인 2017년에 출시되었으며, 11개의 기존 ARB 및 EXT[a] 확장을 코어 프로필에 포함하는 것으로 제한되었다.[10]
OpenGL의 활발한 개발은 2016년에 출시된벌컨 API(초기 개발 당시 코드명 glNext)를 위해 중단되었다. 2017년크로노스 그룹은 OpenGL ES의 새로운 버전을 내놓지 않을 것이라고 발표했으며[11][12] 그 이후로 벌컨 및 기타 기술 개발에 집중해 왔다.[13][14] 그 결과 최신 GPU가 제공하는 특정 기능(예:광선 추적)은 OpenGL 표준에서 지원되지 않는다. 그러나 벤더별 OpenGL 확장을 통해 최신 기능에 대한 지원이 제공될 수 있다.[15][16]
OpenGL 사양의 새 버전은 크로노스 그룹에 의해 출시되며, 각 버전은 다양한 신기능을 지원하도록 API를 확장한다. 각 버전의 세부 사항은 그래픽 카드 제조업체, 운영 체제 설계자, 그리고모질라 및구글과 같은 일반 기술 기업을 포함한 그룹 회원들 간의 합의를 통해 결정된다.[17]
코어 API에서 요구하는 기능 외에도,그래픽 처리 장치(GPU) 벤더는 확장의 형태로 추가 기능을 제공할 수 있다. 확장은 새로운 함수와 새로운 상수를 도입할 수 있으며, 기존 OpenGL 함수의 제한을 완화하거나 제거할 수 있다. 벤더는 다른 벤더나 크로노스 그룹 전체의 지원 없이도 맞춤형 API를 노출하기 위해 확장을 사용할 수 있으며, 이는 OpenGL의 유연성을 크게 높여준다. 모든 확장은 OpenGL 레지스트리에 수집되고 정의된다.[18]
OpenGL의 각 새 버전에서 도입되는 기능은 일반적으로 널리 구현된 여러 확장, 특히 ARB 또는 EXT 유형의 확장을 결합하여 형성된다.
OpenGL의 초기 버전은OpenGL Utility Library(GLU)라는 동반 라이브러리와 함께 출시되었다. 이는테셀레이션,밉맵 및기본 도형 생성과 같이 당시 하드웨어에서 지원될 가능성이 낮았던 간단하고 유용한 기능을 제공했다. GLU 사양은 1998년에 마지막으로 업데이트되었으며 현재는구식이 된 OpenGL 기능에 의존한다.
OpenGL 컨텍스트를 생성하는 것이 상당히 복잡한 과정이고운영체제마다 다르다는 점을 감안할 때, 자동 OpenGL 컨텍스트 생성은SDL,Allegro,SFML,FLTK,Qt를 포함한 여러 게임 개발 및 사용자 인터페이스라이브러리의 공통 기능이 되었다. 오로지 OpenGL 기능이 있는 윈도를 생성하기 위해 설계된 몇몇 라이브러리도 있다. 이러한 첫 번째 라이브러리는OpenGL 유틸리티 툴킷(GLUT)이었으며, 나중에freeglut로 대체되었다.GLFW는 더 최신의 대안이다.[20]
이러한 툴킷은 OpenGL 윈도를 생성 및 관리하고 입력을 관리하도록 설계되었지만, 그 이상의 기능은 거의 없다.[21]
GLFW – 크로스 플랫폼 윈도잉 및 키보드-마우스-조이스틱 핸들러이며, 게임 지향적이다.
freeglut – 크로스 플랫폼 윈도잉 및 키보드-마우스 핸들러이다. API는 GLUT API의 슈퍼셋이며, GLUT보다 더 안정적이고 최신 상태이다.
OpenGL 확장을 식별하고 로드하는 데 수반되는 과중한 작업량을 감안하여, 사용 가능한 모든 확장과 함수를 자동으로 로드하는 몇몇 라이브러리가 설계되었다. 예로는 OpenGL Easy Extension library(GLEE), OpenGL Extension Wrangler Library(GLEW) 및glbinding이 있다.자바 OpenGL, PyOpenGL 및WebGL과 같은 대부분의 언어 바인딩에 의해서도 확장은 자동으로 로드된다.
1980년대에는 크로스 플랫폼 라이브러리 없이 광범위한 그래픽 하드웨어에서 작동할 수 있는 소프트웨어를 개발하는 것이 큰 과제였다. 소프트웨어 개발자들은 각 하드웨어에 대해 맞춤형 인터페이스와 드라이버를 작성했다. 이는 비용이 많이 들었고 노력의 중복을 초래했다.
1990년대 초까지실리콘 그래픽스(SGI)는 워크스테이션용 3D 그래픽 분야의 선두주자였다. 그들의IRIS GL API[22][23]는 사용하기 더 쉽다고 여겨졌고,PHIGS와 같은 경쟁자보다 더 빠른 즉시 모드(immediate mode) 렌더링을 지원했기 때문에 업계 표준이 되었다.[24]
SGI의 경쟁사들(썬 마이크로시스템즈,휴렛 팩커드 및IBM 포함) 또한 PHIGS 표준의 확장을 통해 지원되는 3D 하드웨어를 시장에 내놓을 수 있었으며, 이는 SGI가 IRIS GL의 버전을OpenGL이라는 공개 표준으로 오픈 소스화하도록 압박했다.
그러나 SGI에는 IRIS GL에서 OpenGL로의 변경에 상당한 투자가 필요한 많은 고객이 있었다. 게다가 IRIS GL에는 3D 그래픽과 무관한 API 함수들이 있었다. 예를 들어, 윈도 시스템, 키보드 및 마우스 API를 포함하고 있었는데, 이는 부분적으로X 윈도 시스템과 썬의NeWS가 개발되기 전에 만들어졌기 때문이다.[25] IRIS GL 라이브러리는 SGI의 독점 그래픽 하드웨어와 밀접하게 연관되어 있었고, 하드웨어 특허와 영업 비밀로 인해 있는 그대로 오픈 소스화할 수 없었다. 이러한 요인들로 인해 SGI는 OpenGL에 대한 시장 지원이 성숙해지는 동안 고급 독점 API인Iris Inventor와Iris Performer 프로그래밍 API를 계속 지원해야 했다.
IRIS GL의 제한 사항 중 하나는 하부 하드웨어에서 지원하는 기능에만 접근할 수 있다는 것이었다. 그래픽 하드웨어가 기능을 기본적으로 지원하지 않으면 응용 프로그램은 이를 사용할 수 없었다. OpenGL은 하드웨어에서 지원되지 않는 기능의 소프트웨어 구현을 제공함으로써 이 문제를 극복했고, 상대적으로 저사양 시스템에서도 고급 그래픽을 사용할 수 있게 했다. OpenGL은 하드웨어 접근을 표준화하고, 하드웨어 인터페이스 프로그램(장치 드라이버)의 개발 책임을 하드웨어 제조업체로 밀어냈으며, 윈도잉 기능은 하부 운영 체제에 위임했다. 매우 다양한 종류의 그래픽 하드웨어가 있는 상황에서, 이와 같이 모두가 동일한 언어를 구사하게 만든 것은 소프트웨어 개발자에게 3D 소프트웨어 개발을 위한 상위 레벨의 플랫폼을 제공함으로써 놀라운 영향을 미쳤다.
1992년,[26] SGI는 향후 OpenGL 사양을 유지하고 확장할 기업 그룹인OpenGL Architecture Review Board(OpenGL ARB)의 창설을 주도했다. 2년 후, 그들은 또한 씬 그래프 API와 같은 요소를 포함하는 "OpenGL++"라는 것을 출시하려는 구상을 하기도 했다(아마도 그들의Performer 기술에 기반한 것으로 추정됨). 사양은 몇몇 관심 있는 당사자들 사이에서 유포되었으나 제품으로 만들어지지는 않았다.[27]
1996년에 출시된마이크로소프트의Direct3D는 결국 OpenGL의 주요 경쟁자가 되었다. 50명 이상의 게임 개발자가 1997년 6월 12일에 공개된 마이크로소프트에 보내는공개 서한에 서명하여, 회사가 OpenGL을 적극적으로 지원할 것을 촉구했다.[28] 1997년 12월 17일,[29] 마이크로소프트와 SGI는 OpenGL과 Direct3D 인터페이스를 통합하고 씬 그래프 API도 추가하는 것을 목표로 하는 공동 노력인Fahrenheit 프로젝트를 시작했다. 1998년에는 휴렛 팩커드가 프로젝트에 참여했다.[30] 초기에는 인터랙티브 3D 컴퓨터 그래픽 API 세계에 질서를 가져올 것이라는 기대를 모았으나, SGI의 재정적 제약, 마이크로소프트의 전략적 이유, 그리고 일반적인 업계 지원 부족으로 인해 1999년에 폐기되었다.[31]
2006년 7월, OpenGL Architecture Review Board는 OpenGL API 표준의 관리 권한을 크로노스 그룹으로 이전하기로 결정했다.[32][33]
후속작인 벌컨이나 메탈과 같은 최신 그래픽 API의 출현에도 불구하고, OpenGL은 여전히 널리 사용되는 표준으로 남아 있다. 이러한 지속적인 관련성은 새로운 확장 및 드라이버 최적화를 통한 지속적인 개발, 크로스 플랫폼 호환성, 그리고ANGLE 및 Zink와 같은 호환성 계층의 가용성이라는 여러 요인에 의해 뒷받침된다. 이러한 계층을 통해 OpenGL은 벌컨 및 메탈 위에서 효율적으로 실행될 수 있으며, 개발자들에게 지속적인 사용 또는 점진적인 전환을 위한 경로를 제공한다.[34][35][더나은출처필요]
그러나 그래픽 API 환경은 변화하고 있으며, 일부 기업들은 OpenGL에서 멀어지고 있다. 2018년 6월,애플은 자신들의 모든 플랫폼(iOS,MacOS 및TvOS)에서 OpenGL API를지원 중단했으며, 개발자들에게 2014년에 도입된 자신들의 독점메탈 API를 사용할 것을 강력히 권장하고 있다.[36]
게임 개발자들도 최신 API를 채택하기 시작했다. 1990년대 후반부터GLQuake[37]나둠 시리즈의 일부 게임에서 OpenGL을 사용해 온이드 소프트웨어는 2016년이드 테크 7 엔진에서 후속작인 벌컨으로 전환했다.[38] 그들은이드 테크 6 엔진의 업데이트에서 처음으로 벌컨을 지원했다. 이 회사가 OpenGL을 처음으로 라이선스하여 사용한 것은이드 테크 2로도 알려진Quake II engine에서였다.[39] 2023년 3월,밸브 코퍼레이션은 벌컨을 위해도타 2에서 OpenGL 지원을 제거했다.[40] Atypical Games는 삼성의 지원을 받아 애플 이외의 모든 플랫폼에서 OpenGL 대신 벌컨을 사용하도록 게임 엔진을 업데이트했다.[41]
OpenGL의 첫 번째 버전인 버전 1.0은 1992년 6월 30일에 마크 시걸과커트 애클리에 의해 출시되었다. 그 이후로 OpenGL은 가끔 사양의 새 버전을 출시함으로써 확장되어 왔다. 이러한 릴리스는 모든 준수 그래픽 카드가 지원해야 하는 기준 기능 세트를 정의하며, 이를 바탕으로 새로운 확장을 더 쉽게 작성할 수 있다. OpenGL의 각 새 버전은 그래픽 카드 벤더들 사이에서 널리 지원되는 여러 확장을 통합하는 경향이 있지만, 해당 확장의 세부 사항은 변경될 수 있다.
OpenGL 2.0은 원래3D랩스가 OpenGL이 정체되고 강력한 방향성이 부족하다는 우려를 해결하기 위해 구상했다.[62] 3D랩스는 표준에 대한 다수의 대규모 추가 사항을 제안했다. 당시 이들 대부분은 ARB에 의해 거부되었거나 3D랩스가 제안한 형태로 결실을 맺지 못했다. 그러나 C 스타일 셰이딩 언어에 대한 그들의 제안은 결국 완성되어 현재의GLSL(GLslang)이 탄생하게 되었다. 이전의 어셈블리 형태의 셰이딩 언어처럼, 고정 함수 정점 및 프래그먼트 파이프를셰이더로 대체할 수 있게 했으며, 이번에는 C와 유사한 고급 언어로 작성할 수 있게 되었다.
GLSL의 설계는 당시 사용 가능한 하드웨어의 한계에 대해 상대적으로 적은 타협을 한 것으로 유명했다. 이는 단순히 현재 사용 가능한 하드웨어 상태를 추적하기보다는 3D 가속기에 대해 야심 차고 미래 지향적인 목표를 설정하는 OpenGL의 초기 전통을 계승한 것이었다. 최종 OpenGL 2.0 사양[63]은 GLSL 1.10에 대한 지원을 포함한다.
OpenGL 3.0 출시 전, 새로운 리비전의 코드명은롱스피크였다. 원래 발표 당시 롱스피크는 OpenGL 역사상 첫 번째 주요 API 리비전으로 제시되었다. 이는 OpenGL의 작동 방식을 전면 개편하고 API에 근본적인 변화를 요구하는 것으로 구성되었다.
초안에서는 객체 관리에 대한 변경 사항이 도입되었다. GL 2.1 객체 모델은 OpenGL의 상태 기반 설계를 기반으로 구축되었다. 즉, 객체를 수정하거나 사용하려면 객체를 상태 시스템에 바인딩한 다음 상태를 수정하거나 바인딩된 객체를 사용하는 함수 호출을 수행해야 한다.
OpenGL이 상태 시스템을 사용하기 때문에 객체는 가변적(mutable)이어야 한다. 즉, 렌더링 파이프라인이 비동기적으로 해당 객체를 사용하고 있더라도 객체의 기본 구조가 언제든지 변경될 수 있다. 텍스처 객체는 2D에서 3D로 재정의될 수 있다. 이로 인해 모든 OpenGL 구현은 내부 객체 관리에 복잡성을 추가해야 한다.
롱스피크 API 하에서 객체 생성은원자적이 되며, 템플릿을 사용하여 한 번의 함수 호출로 생성될 객체의 속성을 정의한다. 그런 다음 객체는 여러 스레드에서 즉시 사용될 수 있다. 객체는 또한 불변(immutable)이 되지만, 그 내용은 변경 및 업데이트될 수 있다. 예를 들어, 텍스처는 이미지를 변경할 수 있지만 크기와 형식은 변경할 수 없다.
이전 버전과의 호환성을 지원하기 위해 기존의 상태 기반 API도 계속 사용할 수 있지만, 이후 버전의 OpenGL에서는 기존 API를 통해 새로운 기능이 노출되지 않는다. 이를 통해 대부분의CAD 제품과 같은 레거시 코드베이스를 계속 실행하는 동시에 다른 소프트웨어는 새로운 API를 기반으로 작성하거나 이식할 수 있게 할 예정이었다.
롱스피크는 원래 2007년 9월에 OpenGL 3.0이라는 이름으로 확정될 예정이었으나, 크로노스 그룹은 10월 30일에 사양을 출시하기 전에 해결하고자 하는 몇 가지 문제가 발생했다고 발표했다.[64] 그 결과 사양 공개가 지연되었고, 크로노스 그룹은 최종 OpenGL 3.0 사양이 출시될 때까지언론통제에 들어갔다.
최종 사양은 롱스피크 제안보다 훨씬 덜 혁신적인 것으로 밝혀졌다. 모든 즉시 모드 및 고정 기능(비셰이더 모드)을 제거하는 대신, 사양에는 이들을 구식(deprecated) 기능으로 포함했다. 제안된 객체 모델은 포함되지 않았으며, 향후 리비전에 이를 포함할 계획도 발표되지 않았다. 결과적으로 API는 기존의 몇몇 확장이 코어 기능으로 승격된 것 외에는 대체로 동일하게 유지되었다. 일부 개발자 그룹 사이에서 이 결정은 큰 소동을 일으켰으며,[65] 많은 개발자가 항의의 의미로DirectX로 전환하겠다고 공언했다. 대부분의 불만은 크로노스가 개발자 커뮤니티와 소통이 부족했다는 점과 많은 이들이 긍정적으로 보았던 여러 기능이 폐기되었다는 점에 집중되었다. 다른 불만 사항으로는 OpenGL 3.0을 사용하기 위해 DirectX 10 수준의 하드웨어가 필요하다는 점과 기하 셰이더 및 인스턴스 렌더링이 코어 기능에서 빠졌다는 점 등이 있었다.
다른 소식통들은 커뮤니티의 반응이 원래 제시된 것만큼 심각하지는 않았으며,[66] 많은 벤더가 업데이트에 대한 지지를 표명했다고 보고했다.[67][68]
OpenGL 3.0은 API의 향후 리비전을 단순화하기 위해 구식화(deprecation) 메커니즘을 도입했다. 구식으로 표시된 특정 기능은 윈도 시스템에서 전방 호환(forward-compatible) 컨텍스트를 요청함으로써 완전히 비활성화할 수 있다. 하지만 전체(full) 컨텍스트를 요청하면 이러한 구식 기능과 함께 OpenGL 3.0 기능을 계속 사용할 수 있다.
OpenGL 3.1은 굵은 선(wide lines)을 제외하고 버전 3.0에서 구식으로 지정된 모든 기능을 완전히 제거했다. 이 버전부터는 전체 컨텍스트를 사용하여 새로운 기능에 접근하거나, 전방 호환 컨텍스트를 사용하여 구식 기능에 접근하는 것이 불가능하다. 구현체가ARB_compatibility 확장을 지원하는 경우 전자의 규칙에 예외가 인정되지만, 이는 보장되지 않는다. GLSL 1.40에 대한 지원이 포함된다.
OpenGL 3.2는 사양을 코어 프로필(core profile)과 호환성 프로필(compatibility profile)로 나눔으로써 OpenGL 3.0에서 도입된 구식화 메커니즘을 더욱 발전시켰다. 호환성 컨텍스트에는 이전에 제거된 고정 기능 API(OpenGL 3.1과 함께 출시된 ARB_compatibility 확장과 동일)가 포함되지만, 코어 컨텍스트에는 포함되지 않는다. OpenGL 3.2에는 GLSL 버전 1.50으로의 업그레이드도 포함되었다.
OpenGL 3.3은 구형 하드웨어에 대한 지원을 유지하면서 OpenGL 4.0의 기능을 최대한 많이 유지하는 것을 목표로 소소한 추가 사항들을 포함했다.[54] 추가된 사항으로는 새로운 블렌딩 함수, 샘플러 객체 및 새로운 텍스처와 정점 포맷이 있다. 또한 GLSL 버전 3.30에 대한 지원이 추가되어, 이제 메이저 및 마이너 버전이 OpenGL과 일치하게 되었다.
하드웨어 지원: 엔비디아지포스 400 시리즈 이상, AMD라데온 HD 5000 시리즈 이상(일부 TeraScale GPU에서 에뮬레이션으로 구현된 FP64 셰이더), 인텔하스웰 프로세서의인텔 HD 그래픽 이상[69] (리눅스 메사: 아이비브리지 이상). 또한 이는 애플 macOS에서 지원하는 마지막 코어 프로필이다.
하드웨어 지원: AMD라데온 HD 5000 시리즈 이상(일부 TeraScale GPU에서 에뮬레이션으로 구현된 FP64 셰이더), 인텔하스웰 프로세서의인텔 HD 그래픽 이상.[69] (리눅스 메사: 스텐실 텍스처링이 없는 아이비브리지, 하스웰 이상), 엔비디아지포스 400 시리즈 이상. 가상 머신용 VIRGL 에뮬레이션은 메사 20부터 4.3 이상을 지원한다.
리눅스의메사 19.2는 인텔 브로드웰 이상의 제품에 대해 OpenGL 4.6을 지원한다.[78] 메사 20.0은 AMD 라데온 GPU를 지원하며,[79] 엔비디아 케플러 이상에 대한 지원은 진행 중이다. 21.1 버전부터 에뮬레이션 드라이버인 Zink와 소프트웨어 드라이버 LLVMpipe 또한 메사 21.0과 함께 지원한다.
윈도우 7 SP1,윈도우 10 버전 1803(2018년 4월 업데이트)의AMD Adrenalin 18.4.1 그래픽 드라이버가 AMD 라데온 HD 7700+, HD 8500+ 이상 제품에 대해 지원한다. 2018년 4월 출시.[80][81]
애플은 iOS 12와 macOS 10.14 모하비에서메탈을 위해 OpenGL을지원 중단했으나,애플 실리콘 기기를 포함하여macOS 14 소노마 시점까지 여전히 사용 가능하다.[85] 지원되는 마지막 OpenGL 버전은 2011년의 4.1이다.[86][87]MoltenVK의 제작자인 Molten의 독점 라이브러리인 MoltenGL은 OpenGL 호출을 메탈로 변환할 수 있다.[88]
벌컨 위에서 OpenGL을 구현하려는 여러 프로젝트가 있다. 구글의ANGLE 벌컨 백엔드는 2020년 7월에 OpenGL ES 3.1 준수를 달성했다.[89]메사 3D 프로젝트 또한 Zink라고 불리는 드라이버를 포함하고 있다.[90]
마이크로소프트의 Arm용윈도우 11은 메사 갈륨(Mesa Gallium)을 통해 DirectX 12 위에서 돌아가는 오픈 소스 OpenGL 구현체인 GLon12를 통해 OpenGL 3.3 지원을 추가했다.[91][92][93]
↑Kilgard, Mark J. (2001).《OpenGL programming for the X Window System》 6. print판. Graphics programming. Boston, Mass. Munich: Addison-Wesley. 6쪽.ISBN978-0-201-48359-8.
↑ARB와 EXT는 OpenGL 확장 식별자이다. 각 확장은 이를 개발한 회사의 이름을 기반으로 한 짧은 식별자와 연결된다. 예를 들어엔비디아의 경우NV이다. 만약 여러 벤더가 동일한 API를 사용하여 동일한 기능을 구현하기로 합의하면, 식별자 EXT를 사용하여 공유 확장이 출시될 수 있다. 이러한 경우 크로노스 그룹의 Architecture Review Board가 확장에 대해 명시적인 승인을 내릴 수도 있으며, 이 경우 식별자 ARB가 사용된다.[9]