OpenGL
概要

OpenGLは、SGIをはじめ、ヒューレット・パッカード (HP)、サン・マイクロシステムズ（現オラクル）、IBM、SONY-NEWSなどのUNIXワークステーションのほか、Linux、FreeBSDなどのPC UNIXに加え、Windows、macOS等で使用できるクロスプラットフォームなグラフィックスAPIである。また、モバイルデバイスや家電など組み込み用途向けのサブセット版であるOpenGL ES (OpenGL for Embedded Systems) 規格も存在する。そのほか、航空機や車載ソリューションといったセーフティクリティカルシステム向けのOpenGL SC（英語版）規格も存在する。
オープン標準として公開され、幅広い処理系に対応しているため、家庭用・業務用問わず広く普及している。描画デバイスの実装を隠蔽する抽象化層として機能するため、移植性が高い。また、描画演算処理をOpenGLに対応する専用ハードウェア (GPU) に委ねることで非常に高速に動作し（ハードウェアアクセラレーション）、CPUのみによるソフトウェア描画と比較して高いフレームレートを維持したまま高解像度かつ複雑な3Dグラフィックスをリアルタイム描画できる。有償・無償の豊富な補助ライブラリがあることも特色として挙げられる。Windows, Mac OS, Linux, BSD等の様々なオペレーティングシステム (OS) の上で利用可能であり、個人でも無料のソフトウェア群のみでGPUの能力を活用した3Dプログラミング環境を整備できる。開発・実行環境として広範なプラットフォームをサポートすることから、3次元コンピュータグラフィックスの学習や学術研究、クロスプラットフォームなクローズドソース/オープンソースソフトウェア開発などにも適している。
OpenGL APIはC言語関数群の形で提供され、またクロノスグループが策定・公開しているのは、OpenGL API仕様のドキュメントおよびC/C++用のヘッダーファイルだが、FortranやJavaなどの他言語向けのラッパー／バインディングも存在する。OpenGLの実装は、主にハードウェアベンダーまたはオペレーティングシステム (OS) によって提供されるデバイスドライバーである。
OpenGLの最初の仕様では、テクスチャマッピングが標準的にサポートされておらず、1997年のOpenGL 1.1でようやく拡張機能から必須機能に格上げとなるなど、ゲーム開発によく使われるようなエフェクト処理のサポートが弱かった。2004年に発表されたOpenGL 2.0で高水準シェーディング言語 (GLSL) を標準化したが、その後もDirectX (Direct3D) と比べて標準化が遅く、必須機能としてのサポート追加は数年遅れとなることが多かった。しかし、OpenGL 4.0のリリース以降はGPUの進化に合わせたOpenGL APIの対応が進み、主要な機能に関しては、OpenGL 4.3以降とDirectX 11 (Direct3D 11) 以降との差異はほとんど無くなっている。とはいえ、OpenGLとDirect3Dは、その設計思想の違いから1対1で対応するものではないため、移植性は完全ではなく、また性能面ではハードウェアおよびドライバーのOpenGL/Direct3D最適化レベルに依存するため、利用分野やプラットフォームに応じた住み分けも依然として根強く残っている。
しかし、OpenGLは根本的なAPI設計が古く、すでに最新のCPUやGPUの性能を十分に引き出すことができなくなっており、またデバイスドライバー実装の品質管理などにも問題を抱えている。2016年に後継のVulkanが発表された後は、OpenGLのバージョンアップはほとんどなされていない。また、標準化に時間のかかるオープン仕様のAPIよりも、MetalやDirect3Dといった特定のプラットフォーム専用APIのほうがOSのアーキテクチャと親和性の高い独自機能あるいは先進的機能を導入しやすく、性能や安定性の面でも有利であるため、OpenGLは非推奨扱いになったり、ドライバーが提供されなくなったりしている環境も存在する。後述の#Vulkan、#macOSでの非推奨化、#ARM版Windowsでの利用も参照のこと。
なお、例えばOpenGLプログラマブルシェーダーを利用するには特定のバージョン以降のOpenGLに対応したハードウェアが必要であるなど、OpenGL対応を謳っているデバイスでも最新のOpenGL機能が使えるとは限らない。また、Intel GMAやIntel HD Graphicsなどのように、DirectX 9.0c（シェーダーモデル3.0）には対応するがOpenGL 2.0には対応しなかったり、DirectX 10（シェーダーモデル4.0）には対応するがOpenGL 3.2には対応しなかったり、DirectX 11（シェーダーモデル5.0）には対応するがOpenGL 4.3には対応しなかったり、さらにはOSによってOpenGLの対応バージョンに違いがあったりと、DirectXと比べて同等世代のOpenGLへの対応が遅い環境も存在する。
もともとOpenGLはワークステーション発祥のグラフィックスAPIであり、工業製品などの設計・製造の過程で用いられるCAD/CAM/CAEで必要となる正確・高精度なモデル描画を最優先の用途としていた。また、ポリゴンの頂点座標変換や陰影計算などのジオメトリ処理を当初からグラフィックス処理専用チップに実行させることが前提であったため、OpenGL対応ハードウェアを利用することで大量のポリゴンの高速な描画を実現することができた。一方、Direct3Dでは当初ジオメトリ処理にCPUを用いており、ハードウェアT&Lに対応したのは1999年リリースのDirect3D 7以降である。またDirect3Dは正確性よりも描画速度が優先されるゲームグラフィックス用途に最適化されていたため、きわどい位置でポリゴンが交差した場合など、描画結果が正確でない場合があった。そのため、利用者からはOpenGLのほうがCADや3次元可視化などの業務用に強いという見方がなされていた。
業務用の製品として、正確なモデル描画や安定した動作を保証したビデオカード（グラフィックスカード）が存在し、これらは主にハードウェアやデバイスドライバーがOpenGLに最適化されていることが謳われている。ただし、Direct3D 11.xとOpenGL 4.xの違いはすでにほとんどなくなっており、Direct3Dであってもドライバーレベルの対応によってOpenGL同様の高精度・高安定性を実現できるようになっていること、またDirect3D 12に至っては両者をしのぐ機能や速度性能を実現していることから、業務用のアプリケーションソフトウェアであってもWindowsではOpenGLによる描画モードのサポートを終了し、Direct3Dのみをサポートする事例も増えている。詳細は後述の#DirectXとの関係を参照のこと。
のちにWindowsだけでなくmacOSやLinuxなどにも移植あるいはマルチプラットフォーム展開されるPCゲーム開発でもOpenGLが利用されるようになった。AndroidやiOSといったモバイルOSで利用可能なOpenGL ESは、OpenGLと類似のAPIであり、異なるOS間でコードを相互移植・流用しやすいというメリットもある。しかし、Windows以外のプラットフォームでもVulkanやMetalといった後発のローレベルAPIによる置き換えが進んでいる。Linux上でWindowsアプリケーションを直接実行させるためのWindows APIエミュレーションレイヤーであるWineでは、従来はDirect3D互換実装のバックエンドにOpenGLが使われていたが、Vulkanをバックエンドに使うライブラリも開発されている。Unreal EngineやUnityといったゲームエンジンでは、ゲーム開発者はグラフィックスAPIを直接利用する必要がなく、実行環境に応じて自動的に最適なAPIによるレンダリングバックエンド実装が使われるが、従来のOpenGL/OpenGL ESに加えてローレベルAPIのサポートも追加されている。
クロスプラットフォームなアプリケーションフレームワークでも3Dグラフィックス機能のサポートにOpenGLが使われることが多く、例えばQtはバージョン5.xまでOpenGLに依存していたが、バージョン6.0にてWindowsではDirect3Dを、macOSではMetalをデフォルトのレンダリングバックエンドとして利用する抽象化レイヤーが導入された。