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

2014年8月11日に OpenGL 4.5 を発表[33]。Direct State Access (DSA) 対応など[38]。

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

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

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

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

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

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

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

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

OpenGL単体では、Windows GDIやCore Graphicsのような高レベルの文字列描画用APIが用意されていない [1] [2] [3] ため、あらかじめ文字が描画されたテクスチャを（画像ファイルから読み込むなどして）利用するか、プラットフォーム依存の高レベルAPI（例えばWindowsの場合はwglUseFontOutlines()関数[52]など）と連携する必要がある（クロスプラットフォームのユーティリティライブラリであるGLUTなどを使用すると、文字・文字列を描画することができるが、その機能はごく限られており、あくまでデバッグ用途などの簡易的なサポートにとどまる）。NVIDIA拡張としてはGL_NV_Path_Rendering [4][5][53][54]が存在し、高レベルなプリミティブ描画のGPUアクセラレーションやフォントもサポートするが、標準化はされていない。

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

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

なお、NVIDIA SLIに対応した複数のGPUを用いてSLI構成を行なうことによりGPUドライバー側で分散処理を実行させることはできるが、SLIは主にOpenGLやDirect3Dにおけるグラフィックスフレームのレンダリングを自動的に分散処理して高速化する技術であり、SLI環境下でのGPGPU分散処理を行なう場合は注意点や制約が存在する[60]（NVIDIA GPUにおけるGPGPUはすべてCUDA基盤を利用しているため、このSLI環境における制約はCUDA/OpenCL/DirectCompute/OpenGL Compute Shaderを問わない）。