OpenGL
歴史
元々はSGIが自社ワークステーションで使用していたIRIS GLというライブラリを改良し、移植性を高めたものである。
1992年以降は、OpenGL Architecture Review Board (ARB) により監修される事となる。このARBには、3Dlabs、アップル、AMD（旧ATI）、デル、Evans & Sutherland、HP、IBM、インテル、Matrox、NVIDIA、シリコングラフィックス、サン・マイクロシステムズ（現オラクル）が参加している。2006年9月21日以降からは、100以上の企業で構成される標準化団体クロノス・グループ (The Khronos Group) へ管理が移行し、OpenGL ARB Working Group (OpenGL ARB WG) となった。
オープンな仕様であるため、各種OSに移植または互換GLが作成され、またグラフィックチップベンダーもオープンソースOS用のドライバを用意するなど汎用性に富むライブラリとなっている。ベンダー独自の機能にも、「拡張」（Extension）という形で柔軟に対応できるため、いち早く最新の3Dグラフィックスハードウェアによる先進技術を利用できる反面、ハードウェアを限定した汎用性のないアプリケーションも開発できてしまう。ベンダー拡張の中には、のちに標準仕様として取り込まれたものもある。
OpenGLの標準化はDirectX (Direct3D) と比較すると遅い傾向にある。OpenGL 3.0以降、仕様の更新頻度は高まってきており、テッセレーションの標準化（DirectX 11.0とOpenGL 4.0）に関してはリリース時期にそれほど時間差はなかったが、コンピュートシェーダーの標準化（DirectX 11.0とOpenGL 4.3）に関しては時間差が大きかった。しかし、OpenGLのほうが先行して導入・標準化し、のちにDirectXが追従した機能もいくつか存在する。
プログラマブルシェーダー
プログラマブルシェーダーを利用する場合は、GLSL言語等を使いシェーダープログラムを別途作成して、glUseProgram()関数を使ってあらかじめレンダリングコンテキストにプログラムオブジェクトをセットしてから描画関数を呼び出す必要がある。
補助・拡張ライブラリ
OpenGLそのものは、ハードウェアおよびデバイスドライバー層に近い低次のライブラリである。そのため、よりアプリケーションソフトウェア層に近い、多くの高次の補助・拡張ライブラリが存在する。主に、3D描画機能を簡易化・拡張するもの、ウインドウシステムをサポートするもの、グラフィックス面以外の機能を付加するものに分けられる。
OpenGL 1.1
テクスチャに対応。Windowsの標準ドライバーおよびWGLで標準サポートされているのは、このOpenGL 1.1である。
OpenGL 1.5
2003年にリリースされたOpenGL 1.5では、拡張機能としてプログラマブルシェーダーのための高級言語（GLSL 1.0）に初めて対応した。
OpenGL 2.x
2004年にリリースされたOpenGL 2.0では、シェーディング言語GLSLのバージョン1.1対応が標準仕様として盛り込まれた。
OpenGL 3.x
2008年にリリースされたOpenGL 3.0では、肥大化したOpenGL APIセット自体のシェイプアップを目的として2.x以前の世代を切り捨てる大幅なアップデートが行われ、多くの機能が非推奨・廃止予定になった。翌2009年3月に発表されたOpenGL 3.1では固定機能シェーダーが標準仕様から取り除かれ、拡張機能扱いとなった。また同年8月に発表されたOpenGL 3.2では、Direct3D 10で導入されたジオメトリシェーダーに正式対応した。固定機能シェーダーの廃止やジオメトリシェーダーの対応などは、Direct3D 10の仕様と合致している。
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用演算シェーダーが追加搭載された。また、次世代テクスチャ圧縮技術であるASTCのサポートが公式拡張として定義された。
2013年7月22日に OpenGL 4.4 を発表。バッファ制御や非同期クエリ対応など。
2014年8月11日に OpenGL 4.5 を発表。Direct State Access (DSA) 対応など。
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と同等あるいはそれ以上に素早く追加されたものもある。
Vulkan
SIGGRAPH 2014で、レガシーな設計が蓄積しているOpenGLをリセットし、ゼロから構築し直して刷新する、次世代の標準3D API規格（OpenGL Next Generation, glNext）の策定が始められることがアナウンスされた。このとき、マルチスレッド対応やシェーディング中間言語などの近代的な技術が導入されることが発表された。
GDC 2015では、新規格の名称が"Vulkan"（ドイツ語で"火山"）となることが発表され、Direct3D 12同様のコマンドキューベースのマルチスレッドレンダリング機能や、OpenCLとのプログラミング基盤共通化をもたらすSPIR-V中間表現を導入することが明らかにされた。また、VulkanにはAMD独自のローレベルグラフィックスAPIであるMantleが要素技術として取り込まれることが発表された。
2016年2月16日、Vulkan 1.0の正式仕様がリリースされた。
なお、Vulkanはハードウェアの詳細な制御を可能とするローレベルAPIである一方、従来のOpenGLはCPU-GPU間の同期などの煩雑な処理を自動で行なってくれる上位層のAPIとして、今後もメンテナンスおよびアップデートが継続されることになっている。
弱点
OpenGL 3.xで固定機能を分離するなどのシェイプアップは図られたが、しかしOpenGLは互換性維持という名目で、1.xや2.x時代に設計された古いAPI構造の大部分をいまだに踏襲している。一方で競合APIのDirect3Dは互換性を切り捨てながらも思い切った仕様変更により、APIをその当時の技術トレンドや先進技術に即した形で洗練してきた。またDirect3Dは公式ドキュメントが充実していることや、習得がしやすいことも評価されている。実際にOpenGL仕様そのものに対して、開発者から不満の声も上がっている  。ここではOpenGLの弱点や問題点、および不足機能に関して記述する。
文字列の描画
OpenGL単体では、Windows GDIやCore Graphicsのような高レベルの文字列描画用APIが用意されていない  ため、あらかじめ文字が描画されたテクスチャを（画像ファイルから読み込むなどして）利用するか、プラットフォーム依存の高レベルAPI（例えばWindowsの場合はwglUseFontOutlines()関数など）と連携する必要がある（クロスプラットフォームのユーティリティライブラリであるGLUTなどを使用すると、文字・文字列を描画することができるが、その機能はごく限られており、あくまでデバッグ用途などの簡易的なサポートにとどまる）。NVIDIA拡張としてはGL_NV_Path_Renderingが存在し、高レベルなプリミティブ描画のGPUアクセラレーションやフォントもサポートするが、標準化はされていない。
なお、Direct3Dも同様に文字列描画が弱点であるが、Direct3D 10.1以降ではDirect2DやDirectWriteといった複雑な2D描画や文字列描画に特化した高レベル派生APIおよびDirect3Dとの相互運用・連携機能も整備されている。また、WPFではハードウェアに応じてDirect3Dが使用されるが、Direct2D/DirectWriteのようにAPIが高レベルに抽象化されており、複雑な2D描画や文字列描画にはDirect3DやOpenGLを直接使用するよりも向いている。
マルチGPU
Direct3DではDXGIアダプターを列挙することで、複数のGPUを搭載したシステムにおいて任意のGPUを選択的に使用することが可能となっている。これにより、（CUDAやOpenCLのように）複数のGPUを利用して各々にGPGPU演算処理を分散実行させ、アプリケーションソフトウェアの並列処理性能を向上させるといった使い方ができる。一方、OpenGLで複数のGPUを選択的に使用したり、それぞれのGPUに対してレンダリングコンテキストやリソースを作成する機能はOpenGL 4.5時点でも標準化されていない。Windows環境においては、2006年にNVIDIAからWGL_NV_gpu_affinity 、2009年にAMDからWGL_AMD_gpu_associationというWGL拡張がそれぞれ提供されているが、AMD拡張のほうはRadeonでもFireProでも使用できるものの、NVIDIA拡張のほうはGeForceでは使用できず、Quadroのみの対応となっている。Windows以外のプラットフォームではAMDによるX Window System向けのGLX拡張GLX_AMD_gpu_associationのみで、NVIDIAからは提供されておらず、アプリケーション側からリソースを割り当てるGPUを個別に指定する手段がない。
なお、NVIDIA SLIに対応した複数のGPUを用いてSLI構成を行なうことによりGPUドライバー側で分散処理を実行させることはできるが、SLIは主にOpenGLやDirect3Dにおけるグラフィックスフレームのレンダリングを自動的に分散処理して高速化する技術であり、SLI環境下でのGPGPU分散処理を行なう場合は注意点や制約が存在する（NVIDIA GPUにおけるGPGPUはすべてCUDA基盤を利用しているため、このSLI環境における制約はCUDA/OpenCL/DirectCompute/OpenGL Compute Shaderを問わない）。また、AMDマルチGPU環境でOpenCLを利用したGPGPU分散処理を行なう場合、CrossFire (CrossFireX) をOFFにすることが推奨されている。なお、SLIやCrossFire/CrossFireXではメモリのミラーリングが行なわれるため、複数のGPUを搭載していても、使用できるメモリ総量は各GPUメモリの合計値とはならない。一方、DirectX 12（WDDM 2.0）ではSLIやCrossFireといったベンダー独自技術に依存しない形でマルチGPUにネイティブ対応し、標準で分散レンダリングを可能とするほか、複数GPUのビデオメモリを単一のメモリプールに統合することも可能となっている 。
また、Adobe PhotoshopではバージョンCS4以降、OpenGLによるハードウェアアクセラレーションが導入されているが、マルチGPU環境は推奨されていない。
コンピュート機能（GPGPU機能）とウィンドウ／レンダリングコンテキスト
DirectCompute (Direct3D 11) ではCUDAおよびOpenCL同様に、ウィンドウウィジェットとは直接関連しない完全なオフスクリーンオブジェクトであるDirect3Dデバイスおよびデバイスコンテキストを作成するだけで、コンピュート機能を利用することが可能となっている（コンピュートシェーダーの実行つまりコンピュートカーネルの発行には、DXGIスワップチェーンの作成およびプレゼンテーションは不要）。一方、OpenGL APIは必ずレンダリングコンテキストを作成してから使用する必要があり、そのためにまずはレンダリングコンテキストをバインドするウィンドウウィジェットを作成する必要がある。OpenGL 4.3では汎用計算向けのコンピュートシェーダーが搭載されたが、この制約のためにOpenGLでコンピュートシェーダーを利用する場合は必ずOSのユーザーインターフェイス要素へのアクセスが必要となってしまう。シミュレーションの可視化など、OpenGLコンピュートシェーダーを必ずグラフィックス連携用途に使うことを前提としている場合は大きな問題にならないが、完全なオフスクリーンで純粋にコンピュート機能を利用しようとする場合には障壁となりうる（OpenGL 4.5時点での代替策、すなわち完全オフスクリーンでのコンピュート実行はOpenCLに頼らざるを得ない）。
マルチスレッド対応
Direct3D 11ではイミディエイトコンテキスト／ディファードコンテキストという形で、マルチコアCPUにおいてマルチスレッドを活用して描画パフォーマンスを向上する仕組みが導入され、Direct3D 12ではさらにコマンドキューベースのマルチスレッドレンダリング機能による描画効率の向上が図られているが、OpenGLでは4.5時点で相当機能をサポートしていない。また、Direct3D 11ではデバイスインターフェイスのメソッド呼び出しがスレッドセーフであり、サブスレッドからのリソース生成や複数のスレッドからのリソース同時生成に標準で対応している（同時利用可能なスレッド数はドライバーに依存する）が、OpenGLではレンダリングコンテキストを作成したスレッドのみがリソースを扱えるようになっているため、サブスレッドでリソース生成を行なうにはwglShareLists()関数やglXCreateContext()関数といったプラットフォーム依存のAPIを利用して明示的にコンテキスト共有を行なう必要がある。
ドライバー品質とGLSLコンパイラー
Direct3D (Windows) にはWHQL (Windows Hardware Quality Lab) というドライバー品質保証の仕組みが存在するが、OpenGLコミュニティ総体にはそういったドライバー認証システムは存在していなかった。また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のサポートがコア機能として組み込まれた。
なおANGLEプロジェクトのように、Windows上でDirect3D APIをラップしてOpenGL APIをエミュレートすることで、OpenGLドライバーの品質問題を回避しているものも存在する 。
OpenCLとの関係
OpenGL仕様を管理しているKhronosグループによって同様に管理されているオープン仕様のAPIとして、GPGPUを含む異種計算資源混在環境（ヘテロジニアス環境）用の並列コンピューティングAPIであるOpenCLが存在する。OpenCLにはDirect3DおよびOpenGLのグラフィックスリソースを扱うことのできる相互運用機能が存在するが、一方でOpenGLはバージョン4.3でDirectX同様にGPGPU用の演算シェーダーを導入している。ただし、OpenCLは依然としてヘテロジニアス環境に特化した幅広いプラットフォーム対応APIであるが、OpenGLの演算シェーダーはよりグラフィックス用途に特化したGPGPU用のものとなり、競合するというよりはむしろ相補的な役割を担うことになる。
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であり、アプリケーション開発向けというよりミドルウェア開発向けに位置する。