DirectCompute (Direct3D 11/12) ではCUDAおよびOpenCL同様に、OSのウィンドウシステム（ユーザーインターフェイス）とは直接関連しない完全なオフスクリーンオブジェクトであるDirect3Dデバイスおよびデバイスコンテキストを作成するだけで、コンピュート機能を利用することが可能となっている（コンピュートシェーダーの実行つまりコンピュートカーネルの発行には、DXGIスワップチェーンの作成およびプレゼンテーションは不要）[68]。一方、OpenGL APIは必ずレンダリングコンテキストを作成してから使用する必要があり、また描画命令を発行するためにはレンダリングコンテキストをバインドするサーフェイスを、OSのウィンドウシステムに関与するAPIを利用して作成する必要がある（例えばWindowsの場合はウィンドウDCまたはメモリDCといったGDIのデバイスコンテキストが必要）[69][70]。OpenGL 4.3では汎用計算向けのコンピュートシェーダーが搭載されたが、この制約のためにOpenGLでコンピュートシェーダーを利用する場合は必ずOSのウィンドウシステムへのアクセスが必要となってしまう。シミュレーションの可視化など、OpenGLコンピュートシェーダーを必ずグラフィックス連携用途に使うことを前提としている場合は大きな問題にならないが、完全なオフスクリーンで純粋にコンピュート機能を利用しようとする場合には障壁となりうる（OpenGL 4.6時点での代替策、すなわち完全オフスクリーンでのコンピュート実行はOpenCLに頼らざるを得ない）。
マルチスレッド対応

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

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

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

なおGoogleによるANGLE（英語版）プロジェクト[85]のように、Windows上でDirect3D APIをラップしてOpenGL API (OpenGL ES API) をエミュレートすることで、OpenGLドライバーの品質問題を回避しているものも存在する[86][87]。ANGLEプロジェクトでは他にも、Vulkan APIをラップしてOpenGL ES APIをエミュレートすることで、OpenGLドライバーの品質問題だけでなく、パフォーマンスを改善する取り組みが行なわれており、WindowsだけでなくLinuxやAndroidでも利用できる[88]。
DirectXとの関係「Microsoft DirectX#OpenGLとの関係」も参照

この節は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方）
出典検索?: "OpenGL" ? ニュース ・ 書籍 ・ スカラー ・ CiNii ・ J-STAGE ・ NDL ・ dlib.jp ・ ジャパンサーチ ・ TWL（2015年2月）

この節には独自研究が含まれているおそれがあります。問題箇所を検証し出典を追加して、記事の改善にご協力ください。議論はノートを参照してください。（2015年2月）

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

DirectXは主にWindowsやXboxプラットフォームでのゲーム開発等で多く用いられる（Linux上でDirectXを動作させるCedegaなどの例もある）。対してOpenGLはクロスプラットフォームであり、Windowsだけでなく様々なOSに実装が提供されている。