私が知っている限り、WaylandはOpenGLを使用せず、通常は組み込みシステム（Intel IGPを除く）で使用される3Dレンダリング用のOpenGL ESを使用します。長期的にはOpenGLサポートが実装されることがわかっていますが、現時点ではこれが優先順位ではありません。
OpenGL ESが少し単純なためだと思いますが、これが選択をする上で大きな利点ではないようです。
私はこの決定の理由が何であるか、そしてこの選択が（Linuxの将来のために）どのような結果をもたらすかを知りたいと思います。
修正する:
これウェイランドのよくある質問ここに尋ねる前の最初の訪問地でした。私が間違っていたら自由に訂正してください。しかし、少なくとも最後の部分は少し不明瞭なようです。 IMHO：
EGLは、既存のウィンドウシステム（特にX）に依存しないようにする唯一のGLバインディングAPIです。
私が知っている限り、それほど単純ではありません。 EGLはOpenGLと他のGLの間のインターフェースです。そしてOpenGL ES。 OpenGL ESの呼び出しはWayland/Weston経由で直接行うことができますが、OpenGLをサポートするにはXWaylandが必要です。
GLXは明らかにX依存関係を導入し、XドローアブルにのみGLを設定できるようにします。別のアプローチは、WaylandGLなどのWayland関連のGLバインディングAPIを作成することです。
したがって、この部分は私が上で述べたものと関連しており、私が理解しているように、Wayland開発チームはこの代替ルートを望んでいません。したがって、現在Wayland / Westonを直接使用していないアプリケーションを移植したい人は、OpenGL API呼び出しをOpenGL ES呼び出しに変換する必要があります。
より微妙なことは、libGL.soにGLXシンボルが含まれているため、このライブラリにリンクするとすべてのX依存関係が発生することです。つまり、XクライアントをインポートしないとGL全体に接続できないため、WestonはレンダリングにOpenGL ESを使用します。
少なくとも短期的には、これは理解できるようです。しかし、長期的にWayland開発チームはOpenGL APIを追加することを望んでいるので、状況が深刻になる前の解決策のように見えます。これは私の質問を最初に促した文の一つです。
ただし、上記のように、クライアントは必要なレンダリングAPIを自由に使用できます。
私が正確に覚えているなら、これはOpenGLアプリケーションのためにXWaylandとWeston OpenGL ESの間で選択することを意味します。これは、文が暗示するよりも多くを意味するようです。特にWayland / Westonはもちろん、3Dレンダリングに関しては、目標はXorgを置き換えることです。
XWaylandは、Waylandプロトコルで実行されるXサーバーを実装するためのX.Orgサーバーコードベースへの一連のパッチです。このパッチは、Waylandへの移行中にX11アプリケーションとの互換性のためにWayland開発者によって開発および維持され、[28] 2014年にX.Org Serverバージョン1.16で主流化されました。ユーザーがWeston内でXアプリケーションを実行すると、XWaylandに要求を受け入れるように要求します。
注：私は特に（3D）レンダリングに関してWayland / Westonについてもっと学びたいと思いますが、このトピックに関する確実な情報を見つけるのは難しいです。特にX11に精通している唯一の人がWayland開発者になるには
これまで私が知っている限り、OpenGLの場合：
- OpenGL 関数の呼び出しが GLX インタフェースを介して行われると XWayland に置き換えられるため、プログラムは実際に Wayland を使用しません。
付録
ディスカッションは元の質問の範囲外であるように見えますが、実際には基本的なOpenGLインターフェース/ライブラリに関連しており、すべてを元の質問から分離することは困難です。
これは複雑で混乱しているトピックのように思えるので、ここにOpenGL（ESではない）がそうではないと思わせるいくつかの異なるリンクと参照があります。本物Wayland自体でサポートされていますが、XWaylandを介してX11に戻ります。
写真のWaylandサーバーはDRMバックエンドを備えたWestonです。 Server> GL ES 2を使用してレンダリングし、EGLを呼び出して初期化します。
Waylandは実際に非常に安定しています。 NvidiaはXwayland（x11アプリケーションの3Dアクセラレーションなど）でOpenGLに問題があります。それ以外の場合は動作します。しかし、Waylandでは、いくつかの欠点があります。ズーム（小数点である必要はありません）を使用すると、X11アプリケーションは縮小するのではなくズームインしてぼやけます。残念ながら、FirefoxやChromeは基本的にWaylandをサポートしていません。
UbuntuのWaylandでGLXベースのアプリケーションを実行できるのはなぜですか？
したがって、@genpfaultが提供したリンクによると：
したがって、@genpfaultが提供したリンクによると：
- XWaylandは、Waylandの上にXサーバーを提供するXOrgの一部です。 X11ライブラリに関連付けられ、Waylandで実行されているすべてのアプリケーションは自動的にXWaylandをバックエンドとして使用します。したがって、XWaylandのGLX部分は、GLXベースのOpenGLアプリケーションをWaylandで実行できるようにするメカニズムです。
- GLXベースのアプリケーションでMSAAを使用できないことは、少なくともIntelおよびAMD GPUの場合、XWaylandの既知のバグであるようです（参照： https://bugs.freedesktop.org/show_bug.cgi?id=98272）。ただし、この問題に関するその他の情報が見つかりません。
ベストアンサー1
質問の前提が間違っています。 WaylandはOpenGL ESまたはOpenGLをまったく使用しません。ソフトウェアスタックを正しく理解するためにこれを理解しましょう。
Waylandは、クライアントとコンポジターが互いに通信できるようにするIPCプロトコルです。 libwaylandは技術的にプロトコルの単一の実装であるため、個別に識別してはいけませんが、現在は唯一の実装であり、一般的に「wayland」とも呼ばれます。ハードウェアを実行する完全なシンセサイザーではありません。
Wayland Compositorは、waylandプロトコルを使用してクライアントからバッファを受信し、それを単一の画像にまとめてディスプレイに表示するアプリケーションです。 Waylandプロトコルは、シンセサイザー自体の内部動作について比較的ほとんど想定していません。特に、レンダリング技術の選択は完全にオープンである。コアプロトコルによって定義されたデフォルトのバッファタイプは単純な共有メモリバッファであり、何らかの方法でGPUアクセラレーションが適用されず、UIレンダリングにCPUのみを使用する単純なアプリケーションに適しています。私たちの場合、このバッファタイプは興味深いものではなく、残りの答えでは簡単に忘れられます。
WestonはWaylandシンセサイザーのリファレンス実装です。 libwaylandの自己開発に参加した人たちが開発しましたが、waylandエコシステムの重要な部分ではなく、単なるシンセサイザーの実装に過ぎません。 Waylandデスクトップ環境を含むLinuxディストリビューションを実行している場合は、Westonを使用せずに他のコンポジタ実装を使用していることはほぼ確実です。 WestonはレンダリングにOpenGL ESを使用します。これは、主に現在のlibGL実装がいくつかのX関連ライブラリにリンクされており、Westonのクリエイターがそれを純粋な方法で維持したいからです。これは最終的に参照実装です。また、OpenGL全体をサポートしていない内蔵デバイスとも互換性があります。
EGL - libEGLは、複数のレンダリングコンテキスト（OpenGL、OpenGL ES、またはOpenVGのさまざまなバージョン）を初期化できるグルーコードを含むライブラリです。また、これらのコンテキスト間でデータを共有できます。つまり、OpenGLを使用してレンダリングされたフレームバッファを渡し、さらに処理するためにOpenVGに渡すことができます。これらのリソースはプロセス境界を超えて共有できます。リソース受信者は、リソースを作成したプロセスとは異なるアプリケーションにすることができます。共有リソース（バッファ）への参照は、互換性のあるWayland IPC接続など、さまざまな方法でプロセス間で渡すことができます。この方法で渡されたバッファ（EGLイメージ）は、それを取得するために使用されたレンダリングAPIへの参照を保持しません。 EGL層は、フレームバッファを基本オペレーティングシステム要素（ウィンドウやモニタなど）にバインドする役割も担っていると主張していますが、実際には、ウィンドウに描画するために使用できるシステムプロセスとバッファを共有することを意味します。または特定のウィンドウ。展示する。したがって、これは上記の機能の変形であり、別の機能ではありません。 libEGLはスケーラビリティが高く、利用可能な拡張がたくさんあるため、libEGLの実装は上記の説明に合わない他の作業を担当できます。
GLX - EGLのより古い、制限されたバリエーションです。さまざまな種類のバッファ共有が可能ですが、X11 クライアントと X11 サーバー間でのみ可能です。これは本質的にX11プロトコルに関連しています。クライアントアプリケーションがX11プロトコルを使用している場合は、GLXも使用できます。 Waylandプロトコルを使用している場合はそうではありません。 EGLは、そのようなデータをより広範囲に共有できるように置き換えるために開発されました。最新のX11サーバーでは、クライアントはGLXの代わりにEGLを使用することもできます。
したがって、ウェイランド技術はOpenGL ESの使用を必要とせず、OpenGL ESを使用する方向を明確に指示しません。リファレンスシンセサイザーWestonが使用内部的には、これはクライアント側のレンダリングAPIには影響しません。唯一の要件は、レンダリングするすべてのアイテムをEGLイメージに変換できることです。これはlibEGLの操作なので、クライアントレンダリングAPIの選択はlibEGL実装の制限にのみ依存します。最終的なデスクトップイメージをレンダリングするためにOpenGL ESを使用する場合と使用しない場合がある他のシンセサイザーの場合も同様です。
libEGLはGPUドライバソフトウェア（libGLと同様）の一部であるため、OpenGLバッファをEGLイメージに変換（およびシンセサイザ側でEGLイメージをOpenGL ESテクスチャに後続変換）できるかどうかはハードウェアによって異なりますが、実際にはすべてのハードウェア完全なOpenGLサポートしている限りこれを許可します。これがWaylandが完全なOpenGLをサポートしているという明確な証拠を見つけるのが難しい理由です。 waylandはレンダリング技術にまったく興味がありません。 FAQによると：
図面APIとは何ですか？
「希望どおりにしてください、蜂蜜」 [… ]
したがって、OpenGLがサポートされているかどうかに関する質問は、ウェイランドの範囲外です。これは実際にはlibEGLとハードウェアの機能によってのみ決定されます。
クライアントアプリケーションは、特定のAPIを使用してウィンドウとGL（ES）コンテキストを初期化する必要があります。クライアントアプリケーションがX11 APIを使用してウィンドウを作成すると、クライアントとして偽装されている完全なX11サーバーであるXWayland互換シムに接続されます。これにより、クライアントはGLXまたはEGL-on-X11を使用してコンテキストを初期化し、レンダリングバッファをX11サーバーと共有できます。クライアントがWaylandクライアントAPIを使用してウィンドウを作成する場合は、EGL-on-waylandを使用してコンテキストを初期化し、レンダーバッファをWaylandコンポジターと共有できます。ほとんどの場合、選択は次のものに依存します。完全クライアント側から。
Waylandをサポートしていない古いソフトウェアの多くは、X11 APIとGLXのみを使用しています。これは、単に開発中にWaylandおよびEGL APIが存在しなかったか、または十分に成熟していなかったためです。互換性の理由から、最新のソフトウェアは通常X11 APIのみを使用します。 Wayland以外のシステムもまだかなりあります。 GTKやQTなどの最新のUIツールキットは、実際には複数の「バックエンド」をサポートしています。つまり、初期化時にセッションタイプを検出し、最も適切なAPIを使用してウィンドウと描画コンテキストを生成できます。ゲームは通常これらのツールキットを使用しないため、これらの検出に対する負担は完全に開発者にあります。このようなプロジェクトは実際にこれを実装するのに苦労せず、通常はX11およびwaylandセッション（Xwayland経由）よりもX11およびGLXプロトコルに依存しています。したがって、GLXを使用してOpenGLを初期化するゲームがある場合は、X11 APIを使用することを選択したという意味です。ゲームがWaylandやEGLをまったくサポートしていないのか、ゲームがEGLでOpenGLを初期化しようとしましたが、何らかの理由で失敗したため、多くの追加情報がなければわかりません。いずれにせよ、Waylandプロトコルや使用されているシンセサイザーにはまったく依存しません。