OpenGL

OpenGLは、クロノス・グループ (Khronos Group}

1. 概要
-----

OpenGLは、SGIをはじめ、ヒューレット・パッカード 、サン・マイクロシステムズ、IBM、SONY-NEWSなどのUNIXワークステーションの他、Linux、FreeBSDなどのPC UNIXに加え、Windows、macOS等で使用できるクロスプラットフォームなグラフィックスAPIである。また、携帯電話、PDA、家電など組み込み用途向けのサブセット版であるOpenGL ES  規格も存在する。

オープン標準として公開され、幅広い処理系に対応しているため、家庭用・業務用問わず広く普及している。描画デバイスの実装を隠蔽する抽象化層として機能するため、移植性が高い。また、描画演算処理をOpenGLに対応する専用ハードウェア  に委ねることで非常に高速に動作し、CPUのみによるソフトウェア描画と比較して高いフレームレートを維持したまま高解像度かつ複雑な3Dグラフィックスをリアルタイム描画できる3Dグラフィックスの描画では、特にラスタライズ処理の負荷が高く、画面解像度や3Dシーンの複雑度が上がるとCPUでは描画速度を維持することができなくなる。専用のラスタライザユニットを搭載し、また並列処理能力の高いGPUに処理を委譲することで、スケーラビリティを確保することができる。}}。有償・無償の豊富な補助ライブラリがあるのも特色として挙げられる。Windows, Mac OS, Linux, BSD等の様々なOSの上で利用可能であり、個人でも無料のソフトウェア群のみでGPUの能力を最大限に利用できる3Dプログラミング環境を整備できる。開発・実行環境として広範なプラットフォームをサポートすることから、3次元コンピュータグラフィックスの学習や学術研究、クロスプラットフォームなクローズドソース/オープンソースソフトウェア開発などにも適している。

OpenGL APIはC言語関数群の形で提供され、またクロノスグループが策定・公開しているのは、OpenGL API仕様のドキュメントおよびC/C++用のヘッダーファイルだが、FortranやJavaなどの他言語向けのラッパー／バインディングも存在する。

2004年に発表されたOpenGL 2.0で高級シェーディング言語  を標準化するなど、GPUの進化に合わせて多様な機能を持つようになってきている。

仕様が公開されてから暫くの間は、DirectX  と比較した場合に、ポリゴン数を稼いで高精度なモデル描画を行うことは得意だが、ゲーム用のエフェクト処理が貧弱であった。そのため、利用者からはCADや3次元可視化等の業務用に強いという見方がなされていた。しかし、OpenGL 4.0のリリース以降はGPUの進化に合わせたOpenGL APIの対応が進み、主要な機能に関しては、OpenGL 4.3以降とDirectX 11  以降との差異はほとんど無くなっている。とはいえ、OpenGLとDirect3Dは、その設計思想の違いから1対1で対応するものではないため、移植性は完全ではなく、また性能面ではハードウェアおよびドライバーのOpenGL/Direct3D最適化レベルに依存するため、利用分野やプラットフォームに応じた住み分けも依然として根強く残っている。

なお、例えばOpenGLプログラマブルシェーダーを利用するには特定のバージョン以降のOpenGLに対応したハードウェアが必要であるなど、OpenGL対応を謳っているデバイスでも最新のOpenGL機能が使えるとは限らない。また、Intel GMAやIntel HD Graphicsなどのように、DirectX 9.0cには対応するがOpenGL 2.0には対応しなかったり、DirectX 10には対応するがOpenGL 3.2には対応しなかったり、DirectX 11には対応するがOpenGL 4.3には対応しなかったり、さらにはOSによってOpenGLの対応バージョンに違いがあったりと、DirectXと比べて同等世代のOpenGLへの対応が遅い環境も存在する。

2. 歴史
-----

元々はSGIが自社ワークステーションで使用していたIRIS GLというライブラリを改良し、移植性を高めたものである。

1992年以降は、OpenGL Architecture Review Board  により監修される事となる。このARBには、3Dlabs、Apple、AMD、デル、エバンス・アンド・サザランド、HP、IBM、インテル、Matrox、NVIDIA、シリコングラフィックス、サン・マイクロシステムズが参加している。2006年9月21日以降からは、100以上の企業で構成される標準化団体クロノス・グループ  へ管理が移行し、OpenGL ARB Working Group  となった。

オープンな仕様であるため、各種OSに移植または互換GLが作成され、またグラフィックチップベンダーもオープンソースOS用のドライバーを用意するなど汎用性に富むライブラリとなっている。ベンダー独自の機能にも、「拡張」という形で柔軟に対応できるため、いち早く最新の3Dグラフィックスハードウェアによる先進技術を利用できる反面、ハードウェアを限定した汎用性のないアプリケーションも開発できてしまう。ベンダー拡張の中には、のちに標準仕様として取り込まれたものもある。

OpenGLの標準化はDirectX  と比較すると遅い傾向にある。OpenGL 3.0以降、仕様の更新頻度は高まってきており、テッセレーションの標準化に関してはリリース時期にそれほど時間差はなかったが、コンピュートシェーダーの標準化に関しては時間差が大きかった。しかし、OpenGLのほうが先行して導入・標準化し、のちにDirectXが追従した機能もいくつか存在する。Adaptive Scalable Texture CompressionやEricsson Texture CompressionのようにOpenGL/OpenGL ESでしかサポートされていないものもあるかつてDirect3DでのASTCサポートが計画されていたが、2019年現在、実現には至っていない。

3. コード例
-------

C/C++向けのOpenGLコード例を示す。

OpenGL 2.xまでの固定機能で三角形を描画する例。 // Direct3D デバイス／デバイスコンテキストとは異なり、 // 描画ターゲットとなる OpenGL レンダリングコンテキストは暗黙のグローバルステートとなっており、 // 関数引数に対して明示的に指定しない。 // コンテキストはスレッドローカル変数として管理される。 // https://www.khronos.org/opengl/wiki/OpenGL_Context glDisable; glBegin; { glColor3f; glVertex2f; glColor3f; glVertex2f; glColor3f; glVertex2f; } glEnd; 他にも、ユーザーメモリ頂点配列／エレメント配列や、頂点バッファ／エレメントバッファを利用した、より高速な描画方法がある。なお、Direct3Dの頂点宣言・頂点レイアウトに似た機能として Vertex Array Object  および Vertex Attribute が存在するが、Direct3Dのように頂点バッファと頂点属性を完全に分離して扱えるものではない。頂点宣言・頂点レイアウトの互換機能 GL_ARB_vertex_attrib_binding が標準化されているのはOpenGL 4.3/ES 3.0以降である。

3.1. プログラマブルシェーダー
-----------------

プログラマブルシェーダーを利用する場合は、GLSL言語等を使いシェーダープログラムを別途作成して、glUseProgram関数を使ってあらかじめレンダリングコンテキストにプログラムオブジェクトをセットしてから描画関数を呼び出す必要がある。

4. 補助・拡張ライブラリ
-------------

OpenGLそのものは、ハードウェアおよびデバイスドライバー層に近い低次のライブラリである。そのため、よりアプリケーションソフトウェア層に近い、多くの高次の補助・拡張ライブラリが存在する。主に、3D描画機能を簡易化・拡張するもの、ウインドウシステムをサポートするもの、グラフィックス面以外の機能を付加するものに分けられる。

4.1. C/C++向け
------------

OpenGL Utility Library - カメラや球、円筒、曲面などの取り扱いを補助する
GLX - X Window SystemでOpenGLを利用するためのライブラリ
WGL  - Microsoft WindowsでOpenGLを利用するためのライブラリ 
Core OpenGL, Apple Graphics Library, NSOpenGL  - macOSでOpenGLを利用するためのライブラリ
EGL  - OpenGL ES, OpenVGといったKhronosの描画APIと、下層のプラットフォーム固有ウィンドウシステムをつなぐインターフェイス
GLUT - クロスプラットフォームのOpenGL対応ウィジェット・ツールキット
FreeGLUT - GLUTの機能を強化した、上位互換ライブラリ
OpenGL User Interface Library - GLUTをベースにしたウィジェットライブラリ
AUX - ウィジェット・ツールキットであるが、古くなっておりGLUTの使用が推奨されている
OpenGL Easy Extension library - OpenGL拡張の使用を容易にするライブラリ。開発は停止しており、公式バージョンの配布もされていない。
OpenGL Extension Wrangler Library - GLSLなどのOpenGL拡張の使用を容易にするライブラリ。OpenGL 4.6に対応。
GLFW - クロスプラットフォームのOpenGL対応フレームワークツールキット。OpenGL ESおよびVulkanにも対応。
GLUS  - 公式のクロスプラットフォームなユーティリティ。OpenGL ESにも対応
OpenGL Mathematics  - GLSLライクに記述できるC++向けの算術ライブラリ
OpenSceneGraph
FLTK - クロスプラットフォームのOpenGL対応ウィジェット・ツールキット
Open Inventor
ToGL - Valve Softwareが開発した、Direct3DからOpenGLへの変換レイヤー
SDL - クロスプラットフォームなマルチメディアライブラリ

4.2. その他の言語向け
-------------

C/C++以外の主要なOpenGL言語バインディングとライブラリには以下のようなものがある。

OpenTK - C#向けのローレベルなOpenGL/OpenGL ES/OpenALバインディング
Java OpenGL  - Java向けのバインディング
Java 3D - JOGL上に構築されるJava向けのシーングラフベース高レベルライブラリ
LWJGL - Java向けのゲーム開発用ライブラリなお、WebGLはJavaScript向けの単なるラッパーや言語バインディングではなく、OpenGL ES派生の別規格である。

DirectXやVulkanとは異なり、具体的な公式ソフトウェア開発キット  や開発者向けのソフトウェアスイートは提供されていない。KhronosによるOpenGL SDKのサイトでは、APIリファレンスへのリンクや、補助ライブラリおよび開発ツールへのリンクが記載されているのみである。NVIDIAのように、自社GPU向けのOpenGL拡張ヘッダーや開発ツールを含むSDKを提供しているベンダーもある。

5. バージョンの変遷
-----------

5.1. OpenGL 1.1
---------------

テクスチャに対応。Windowsの標準ドライバーおよびWGLで標準サポートされているのは、このOpenGL 1.1である。

5.2. OpenGL 1.5
---------------

2003年にリリースされたOpenGL 1.5では、拡張機能としてプログラマブルシェーダーのための高級言語に初めて対応した。

5.3. OpenGL 2.x
---------------

2004年にリリースされたOpenGL 2.0では、シェーディング言語GLSLのバージョン1.1対応が標準仕様として盛り込まれた。

5.4. OpenGL 3.x
---------------

2008年にリリースされたOpenGL 3.0では、肥大化したOpenGL APIセット自体のシェイプアップを目的として2.x以前の世代を切り捨てる大幅なアップデートが行われ、多くの機能が非推奨・廃止予定になった。翌2009年3月に発表されたOpenGL 3.1では固定機能シェーダーが標準仕様から取り除かれ、拡張機能扱いとなった。また同年8月に発表されたOpenGL 3.2では、Direct3D 10で導入されたジオメトリシェーダーに正式対応した。固定機能シェーダーの廃止やジオメトリシェーダーの対応などは、Direct3D 10の仕様と合致している。

5.5. OpenGL 4.x
---------------

2010年3月11日に OpenGL 4.0 を発表。Direct3D 11のハル シェーダー、テッセレータおよびドメイン シェーダーに相当する、テッセレーション制御シェーダー、テッセレーション プリミティブ ジェネレーターおよびテッセレーション評価シェーダーが搭載された。

2010年7月26日に OpenGL 4.1 を発表。シェーダープログラムバイナリの取得やビューポート配列の対応など。

2011年8月8日に OpenGL 4.2 を発表。シェーダーにおけるアトミックカウンターの実装など。

2012年8月6日に OpenGL 4.3 を発表。Direct3D 11のコンピュート シェーダーと同様のGPGPU用演算シェーダーが追加搭載された。また、次世代テクスチャ圧縮技術であるAdaptive Scalable Texture Compressionのサポートが公式拡張として定義された。

2013年7月22日に OpenGL 4.4 を発表。バッファ制御や非同期クエリ対応など。

2014年8月11日に OpenGL 4.5 を発表。Direct State Access  対応など。

2015年8月10日にOpenGL 2015 ARB Extensionsとして、OpenGL ES 3.2互換機能やシェーダーの並列コンパイル機能などが拡張として追加された。

2017年7月31日に OpenGL 4.6 を発表。SPIR-Vの導入、Vulkan/Direct3Dとの相互運用性の強化など。

以前はOpenGL仕様のアップデートの速度や頻度はDirect3Dに比べて非常にゆっくりとしたものであったが、OpenGL 4の機能の中にはDirect3D 11と同等あるいはそれ以上に素早く追加されたものもある。

5.6. Vulkan
-----------

SIGGRAPH 2014で、レガシーな設計が蓄積しているOpenGLをリセットし、ゼロから構築し直して刷新する、次世代の標準3D API規格の策定が始められることがアナウンスされた。このとき、マルチスレッド対応やシェーディング中間言語などの近代的な技術が導入されることが発表された。

GDC 2015では、新規格の名称が"Vulkan"となることが発表され、Direct3D 12同様のコマンドキューベースのマルチスレッドレンダリング機能や、OpenCLとのプログラミング基盤共通化をもたらすSPIR-V中間表現を導入することが明らかにされた。また、VulkanにはAMD独自のローレベルグラフィックスAPIであるMantleが要素技術として取り込まれることが発表された。

2016年2月16日、Vulkan 1.0の正式仕様がリリースされた。

なお、Vulkanはハードウェアの詳細な制御を可能とするローレベルAPIである一方、従来のOpenGLはCPU-GPU間の同期などの煩雑な処理を自動で行なってくれる上位層のAPIとして、今後もメンテナンスおよびアップデートが継続されることになっている。

6. 弱点
-----

OpenGL 3.xで固定機能を分離するなどのシェイプアップは図られたが、しかしOpenGLは互換性維持という名目で、1.xや2.x時代に設計された古いAPI構造の大部分をいまだに踏襲している。一方で競合APIのDirect3Dは互換性を切り捨てながらも思い切った仕様変更により、APIをその当時の技術トレンドや先進技術に即した形で洗練してきた。またDirect3Dは公式ドキュメントが充実していることや、習得がしやすいことも評価されている。実際にOpenGL仕様そのものに対して、開発者から不満の声も上がっている。ここではOpenGLの弱点や問題点、および不足機能に関して記述する。

6.1. 文字列の描画
-----------

OpenGL単体では、Windows GDIやCore Graphicsのような高レベルの文字列描画用APIが用意されていない [1] [2] [3] ため、あらかじめ文字が描画されたテクスチャを利用するか、プラットフォーム依存の高レベルAPIと連携する必要がある。NVIDIA拡張としてはGL_NV_Path_Rendering [4][5]が存在し、高レベルなプリミティブ描画のGPUアクセラレーションやフォントもサポートするが、標準化はされていない。

なお、Direct3Dも同様に文字列描画が弱点であるが、Direct3D 10.1以降ではDirect2DやDirectWriteといった複雑な2D描画や文字列描画に特化した高レベル派生APIおよびDirect3Dとの相互運用・連携機能も整備されている。また、WPFではハードウェアに応じてDirect3Dが使用されるが、Direct2D/DirectWriteのようにAPIが高レベルに抽象化されており、複雑な2D描画や文字列描画にはDirect3DやOpenGLを直接使用するよりも向いている。

6.2. マルチGPU
-----------

Direct3DではDXGIアダプターを列挙することで、複数のGPUを搭載したシステムにおいて任意のGPUを選択的に使用することが可能となっている。これにより、複数のGPUを利用して各々にGPGPU演算処理を分散実行させ、アプリケーションソフトウェアの並列処理性能を向上させるといった使い方ができる。一方、OpenGLで複数のGPUを選択的に使用したり、それぞれのGPUに対してレンダリングコンテキストやリソースを作成したりする機能はOpenGL 4.6時点でも標準化されていない。Windows環境においては、2006年にNVIDIAからWGL_NV_gpu_affinity、2009年にAMDからWGL_AMD_gpu_associationというWGL拡張がそれぞれ提供されているが、AMD拡張のほうはRadeonでもFireProでも使用できる [6] ものの、NVIDIA拡張のほうはGeForceでは使用できず、Quadroのみの対応となっている [7]。Windows以外のプラットフォームではAMDによるX Window System向けのGLX拡張GLX_AMD_gpu_associationのみで、NVIDIAからは提供されておらず、アプリケーション側からリソースを割り当てるGPUを個別に指定する手段がない。

なお、NVIDIA SLIに対応した複数のGPUを用いてSLI構成を行なうことによりGPUドライバー側で分散処理を実行させることはできるが、SLIは主にOpenGLやDirect3Dにおけるグラフィックスフレームのレンダリングを自動的に分散処理して高速化する技術であり、SLI環境下でのGPGPU分散処理を行なう場合は注意点や制約が存在する。同様にAMD CrossFire  も分散レンダリングのためのマルチGPU技術であり、またDirect3D 9/10/11およびOpenGLアプリケーションでCrossFireを利用するにはフルスクリーンモードで動作している必要がある。さらに、AMDマルチGPU環境でOpenCLを利用したGPGPU分散処理を行なう場合、CrossFire  をOFFにすることが推奨されている。なお、SLIやCrossFire/CrossFireXではメモリのミラーリングが行なわれるため、複数のGPUを搭載していても、使用できるメモリ総量は各GPUメモリの合計値とはならない。一方、DirectX 12ではSLIやCrossFireといったベンダー独自技術に依存しない形でマルチGPUにネイティブ対応し、標準で分散レンダリングを可能とするほか、複数GPUのビデオメモリを単一のメモリプールに統合することも可能となっている。

また、Adobe PhotoshopではバージョンCS4以降、OpenGLによるハードウェアアクセラレーションが導入されているが、マルチGPU環境は推奨されていない。

6.3. コンピュート機能とウィンドウ／レンダリングコンテキスト
--------------------------------

DirectCompute  ではCUDAおよびOpenCL同様に、OSのウィンドウシステムとは直接関連しない完全なオフスクリーンオブジェクトであるDirect3Dデバイスおよびデバイスコンテキストを作成するだけで、コンピュート機能を利用することが可能となっている。一方、OpenGL APIは必ずレンダリングコンテキストを作成してから使用する必要があり、また描画命令を発行するためにはレンダリングコンテキストをバインドするサーフェイスを、OSのウィンドウシステムに関与するAPIを利用して作成する必要がある。OpenGL 4.3では汎用計算向けのコンピュートシェーダーが搭載されたが、この制約のためにOpenGLでコンピュートシェーダーを利用する場合は必ずOSのウィンドウシステムへのアクセスが必要となってしまう。シミュレーションの可視化など、OpenGLコンピュートシェーダーを必ずグラフィックス連携用途に使うことを前提としている場合は大きな問題にならないが、完全なオフスクリーンで純粋にコンピュート機能を利用しようとする場合には障壁となりうる。

6.4. マルチスレッド対応
--------------

Direct3D 11ではイミディエイトコンテキスト／ディファードコンテキストという形で、マルチコアCPUにおいてマルチスレッドを活用して描画パフォーマンスを向上する仕組みが導入され、Direct3D 12ではさらにコマンドキューベースのマルチスレッドレンダリング機能による描画効率の向上が図られているが、OpenGLでは4.6時点で相当機能をサポートしていない。また、Direct3D 11ではデバイスインターフェイスのメソッド呼び出しがスレッドセーフであり、サブスレッドからのリソース生成や複数のスレッドからのリソース同時生成に標準で対応しているが、OpenGLではレンダリングコンテキストを作成したスレッドのみがリソースを扱えるようになっているため、サブスレッドでリソース生成を行なうにはwglShareLists関数やglXCreateContext関数といったプラットフォーム依存のAPIを利用して明示的にコンテキスト共有を行なう必要がある。OpenGL 4.6ではGL_KHR_parallel_shader_compileとして複数のシェーダーの並列コンパイルに対応したが、コア機能ではなく拡張扱いである。

6.5. ドライバー品質とGLSLコンパイラー
-----------------------

Direct3D  にはWHQL  というドライバー品質保証の仕組みが存在するが、OpenGLコミュニティ総体にはそういったドライバー認証システムは存在していなかった [8]。またDirect3Dとは違ってOpenGLおよびOpenGL ESドライバーはベンダーや個々の製品によって出来不出来の差が激しく、このドライバー品質問題に関して開発者やユーザーから不満の声が上がっていた。さらに、GLSLのリファレンスコンパイラー実装はKhronosグループによって提供されているものの、OpenGL/OpenGL ESにおいてはシェーダープログラムの共通バイトコード仕様が定義されていないためにGLSLオフラインコンパイラーは存在せず、シェーダープログラムのコンパイルはベンダーごとのドライバーに実装されたGLSLオンラインコンパイラーによって実行時になされる。しかし、OpenGL仕様にはエラーハンドリングなどに関して厳密に規定されていないあいまいな部分が存在することから、現実問題としてベンダーごとにコンパイラーの挙動が異なるという処理系依存動作を許可してしまっているのが実態であり、これがアプリケーション開発者の負担増加につながり、またドライバーやアプリケーションプログラムにおけるバグの温床となってしまう。

OpenGL 4.4以降においては、Khronosグループによる品質保証制度を新設し、品質問題の改善を進めることとなった。また、OpenGLの後継APIとなるVulkanでは、前述のようにシェーダープログラムの中間言語としてSPIR-Vを採用している。OpenGL 4.6ではSPIR-Vのサポートがコア機能として組み込まれた。

なおGoogleによるANGLEプロジェクトのように、Windows上でDirect3D APIをラップしてOpenGL API  をエミュレートすることで、OpenGLドライバーの品質問題を回避しているものも存在する。ANGLEプロジェクトでは他にも、Vulkan APIをラップしてOpenGL ES APIをエミュレートすることで、OpenGLドライバーの品質問題だけでなく、パフォーマンスを改善する取り組みが行なわれており、WindowsだけでなくLinuxやAndroidでも利用できる。

7. DirectXとの関係
--------------

OpenGLは3Dグラフィックスを専門的に扱うライブラリである。対してMicrosoft DirectXは、ゲーム開発での利用を主な用途としており、グラフィックスのみならずサウンドや入力関連のAPIを含んでいる点で性質が異なる。 なお、OpenGLと直接比較されるべきAPIは、DirectX製品の一部、グラフィックスを司るDirect3Dである。

DirectXは主にWindowsやXboxプラットフォームでのゲーム開発等で多く用いられる。対してOpenGLはクロスプラットフォームであり、Windowsだけでなく様々なOSに実装が提供されている。Windows環境ではDirectXとOpenGLを両立させることも可能である。

発祥がワークステーションであることやクロスプラットフォームであることから、CADや工業デザイン、科学技術計算や医療での視覚化等の業務分野では、クロスプラットフォームなアプリケーションに限らずWindows専用アプリケーションであっても、Direct3D等のエンタテインメント用途重視のグラフィックスAPIよりもOpenGLが用いられることが多い。そのため、ワークステーションや業務向けのGPUやビデオカード製品には、OpenGLに最適化された仕様のものが販売される傾向がある。OpenGL向けと称されているGPUにはNVIDIA社の『NVIDIA Quadro/NVIDIA RTX』シリーズや、AMD  の『AMD FirePro/AMD Radeon Pro 』シリーズが存在し、デバイスドライバーを含めた仕様がOpenGL用に最適化されている。しかしその反面、これらの製品はDirectX  への最適化が甘く、DirectXを使用したアプリケーションにおける性能が芳しくない傾向もある例えば同じTU104チップを採用し、TDPとVRAM搭載量以外の主要スペックがほぼ同一の「Quadro RTX 5000」と「GeForce RTX 2080 SUPER」を比較したとき、Direct3DのベンチマークスコアはGeForceのほうが上である、またバージョン2022以降はDirect3D 12が優先的に使用されるようになっているが、テスト済みの認定ハードウェアにはゲーミング用途のコンシューマー向け製品は含まれておらず、プロフェッショナル向け製品のみである。

GeForceやRadeonのようなコンシューマー向けGPUのWindowsドライバーは、OpenGLではなくDirect3Dに最適化されているが、コンシューマー向けGPUとWindowsドライバーによるOpenGLが、常にDirect3Dよりも遅いわけではない。

なお、WindowsだけでなくLinuxおよびMac  に対してもGPUベンダーからOpenGL対応のドライバーが供給されているが、Macに関してはWindowsおよびLinuxと異なり、そもそもベンダーが正式対応しているハードウェアが限られている。

シリコングラフィックスとマイクロソフトはかつてOpenGLとDirect3Dの統合を目標として、Fahrenheitと呼ばれる3DグラフィックスAPIの共同開発を1997年に開始したことがあるが、1999年の末までに計画は事実上頓挫している。また、マイクロソフト社はOpenGL ARBの設立時のメンバーでもあったが、2003年に脱退した。その後、シリコングラフィックスの倒産やOpenGL仕様のKhronosグループへの移管など紆余曲折を経て、2014年にはOpenGL 4.5の発表とともに、マイクロソフトがKhronosグループに参加することが明らかになった。

8. OpenCLとの関係
-------------

OpenGL仕様を管理しているKhronosグループによって同様に管理されているオープン仕様のAPIとして、GPGPUを含む異種計算資源混在環境用の並列コンピューティングAPIであるOpenCLが存在する。OpenCLにはDirect3DおよびOpenGLのグラフィックスリソースを扱うことのできる相互運用機能が存在するが、一方でOpenGLはバージョン4.3でDirectX同様にGPGPU用の演算シェーダーを導入している。ただし、OpenCLは依然としてヘテロジニアス環境に特化した幅広いプラットフォーム対応APIであるが、OpenGLの演算シェーダーはよりグラフィックス用途に特化したGPGPU用のものとなり、競合するというよりはむしろ相補的な役割を担うことになる。

9. macOSでの非推奨化
--------------

2018年6月5日、AppleはWWDC 2018でOpenGL/OpenCLの非推奨化を発表し、macOS MojaveにおいてOpenGL/OpenCLは非推奨APIとなった。macOSがネイティブにサポートするOpenGLのバージョンは4.1が最後となっている。

OpenGLの代替として推奨されているAPIはMetalであるが、MetalはVulkan同様、OpenGLよりもハードウェア層に近いローレベルAPIであり、アプリケーション開発向けというよりミドルウェア開発向けに位置する。

10. 脚注
------

10.1. 注釈
--------

10.2. 出典
--------

11. 関連項目
--------

DirectX
Direct3D
Mantle 
Metal 
Vulkan 
GLSL
OpenCL
OpenAL
OpenGL ES
OpenSL ES
Mesa 3D
VirtualGL

12. 外部リンク
---------

[9]
[10]
Khronos Group
[11]
[12]
[13]
[14]
[15] - 通称「赤本 」と呼ばれる解説書
[16] - 通称「青本 」と呼ばれるリファレンス
[17] - FAQ
[18]