WaylandがOpenGLではなくOpenGL ESを使用しているのはなぜですか？
私の知る限り、WaylandはOpenGLではなくOpenGL ESを3Dレンダリングに使用しています。これは通常、組み込みシステムで使用されます（Intel IGPを除く）。長期的には、OpenGLのサポートが実装されるが、今のところ優先事項ではないことを読んだ。
OpenGL ESの方がいくらか単純ですが、そのような選択をするための強力なポイントではないようです。
この決定の理由は何か、そしてこの選択の結果は（そしてLinuxの将来にとっては）何であるのかと思っていました。
更新：
Wayland FAQ は、ここで質問することさえ考える前に、私の最初のストップでした。私が間違っている場合は、遠慮なく訂正してください。しかし、最後の部分は、少なくとも非常に明確ではないようです。私見：
EGLは、既存のウィンドウシステム、特にXへの依存を回避できる唯一のGLバインディングAPIです。
私が理解している限り、それはそれほど単純ではありません。 EGLは、OpenGLおよびOpenGL ESなどのGL間のインターフェースです。 OpenGL ESの呼び出しは、Wayland/Westonを介して直接可能ですが、OpenGLのサポートにはXWaylandが必要です。
GLXは明らかにXの依存関係を取り込み、XドローアブルにGLを設定することだけを許可します。代替は、Wayland固有のGLバインディングAPI、たとえば、WaylandGLを記述することです。 。
したがって、この部分は私が上で言っていたことを参照しており、私の知る限り、Wayland開発チームはその別のルートを取ることを望んでいません。そのため、現時点では、Wayland/Westonを直接使用しないアプリケーションを移植しようとする人々は、OpenGL API呼び出しをOpenGL ES呼び出しに変換する必要があります。
もっと微妙な点は、libGL.soにGLXシンボルが含まれているため、そのライブラリにリンクするとすべてのX依存関係が取り込まれるということです。これは、Xのクライアント側をプルしないと、フルGLにリンクできないため、WestonはOpenGL ESを使用してレンダリングすることを意味します。
これは、少なくとも短期的には理解できるようです。それでも、長い目で見れば、Wayland開発チームはOpenGL APIも追加したいと考えているため、事態が深刻になるまでは、今のところ回避策のように思えます。これは、最初にここで私の質問を引き起こした文の1つです。
ただし、上記のように、クライアントは好きなレンダリングAPIを自由に使用できます。
私が間違っていないのであれば、つまり、OpenGLアプリケーションとWeston OpenGL ESにXWaylandを使用することを意味します。これは、特に3Dレンダリングに関しては、文が意味するより大きな問題であると思われ、Wayland/Westonが目的であることは言うまでもありません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です。サーバーは、GL ES 2を使用してレンダリングを実行します。ES2は、EGLを呼び出すことによって初期化されます。
ウェイランドは実際にはかなり安定しています。 Nvidiaは、Xwayland（つまり、x11アプリの3d accel）でOpenGLに問題があります。それ以外の場合は、動作するはずです。ただし、Waylandを使用すると、いぼができます。スケーリングを使用する場合（小数である必要もありません）、X11アプリはダウンスケールではなくアップスケールされ、ぼやけてしまいます。残念ながら、FirefoxもChrome=は、Waylandをネイティブでサポートしていません。また、コンピューターで最も使用されているアプリをぼやけたモードで使用したいですか？
GLXベースのアプリケーションをUbuntuのWaylandで実行できるのはなぜですか？
したがって、提供された@genpfaultのリンクに基づきます。
したがって、提供された@genpfaultのリンクに基づきます。
- XWaylandはXOrgの一部であり、Waylandの上にXサーバーを提供しています。 X11 libsにリンクされており、Waylandの下で実行されているアプリケーションは、自動的にXWaylandをバックエンドとして使用します。したがって、XWaylandのGLX部分は、GLXベースのOpenGLアプリケーションをWaylandで実行できるようにするメカニズムです。
- GLXベースのアプリケーションでMSAAを使用できないことは、少なくともIntelおよびAMDのGPUで、XWaylandの既知のバグのようです（cf. https://bugs.freedesktop.org/show_bug.cgi?id= 98272 ）。しかし、その件に関する追加情報は見つかりませんでした。
https://wayland.freedesktop.org/faq.html から：
WaylandはなぜEGLを使用するのですか？
EGLは、既存のウィンドウシステム、特にXへの依存関係を回避できる唯一のGLバインディングAPIです。GLXは明らかにX依存関係を取り込み、XドローアブルでのみGLを設定できるようにします。別の方法は、Wayland固有のGLバインディングAPI、たとえばWaylandGLを作成することです。
もっと微妙な点は、libGL.soにGLXシンボルが含まれているため、そのライブラリにリンクするとすべてのX依存関係が取り込まれるということです。これは、Xのクライアント側を取得せずに完全なGLにリンクできないため、WestonはOpenGL ESを使用してレンダリングすることを意味します。これにより、Westonは、完全なOpenGL APIをサポートしていないGPUで実行することもできます。
ただし、上記のように、クライアントは好きなレンダリングAPIを自由に使用できます。
あなたの質問の前提は間違っています。 WaylandはOpenGL ESまたはOpenGLをまったく使用しません。ソフトウェアスタックを正しく理解するために、次のことを行います。
WaylandはIPCプロトコルであり、クライアントとコンポジターが相互に通信できるようにします。技術的にはlibwaylandはそのプロトコルの単一の実装であり、それだけで識別される必要はありませんが、今のところは唯一の実装であり、一般に「ウェイランド」とも呼ばれます。ハードウェアを実行する完全なコンポジターではありません。
Wayland Compositorは、waylandプロトコルを使用してクライアントからバッファーを受信し、それをディスプレイに表示される単一の画像に構成するアプリケーションです。ウェイランドプロトコルは、コンポジター自体の内部動作についてはほとんど想定していません。特に、レンダリング技術の選択は完全に開かれたままです。コアプロトコルで定義されているデフォルトのバッファタイプは、GPUによって決して加速されない単純な共有メモリバッファであり、主にCPUのみを使用してUIをレンダリングする単純なアプリケーション向けです。このバッファタイプは、私たちのケースでは重要ではなく、残りの回答では都合よく忘れられます。
Westonは、waylandコンポジターのリファレンス実装です。 libwayland自体の開発に携わる人々によって開発されていますが、waylandエコシステムの本質的な部分ではなく、単一のコンポジター実装にすぎません。 Waylandデスクトップ環境を含むLinuxディストリビューションのいずれかを実行している場合、ほぼ間違いなくWestonではなく、他のコンポジター実装を使用しています。 WestonはレンダリングにOpenGL ESを使用します。これは主に、現在のlibGL実装がまだいくつかのX関連ライブラリにリンクしており、Westonの作成者が純粋な方法を維持したかったためです-これは結局のところ、リファレンス実装です。さらに、完全なOpenGLをサポートしていない可能性がある組み込みデバイスと互換性があります。
EGL-libEGLは、非常に多様な複数のレンダリングコンテキスト（異なるバージョンのOpenGL、OpenGL ES、またはOpenVG）の初期化を可能にするグルーコードを含むライブラリです。また、このようなコンテキスト間でデータを共有することもできます。つまり、OpenGLでレンダリングされたフレームバッファーを渡し、さらに処理するためにOpenVGに渡すことができます。これらのリソースの共有は、プロセスの境界を越えて発生する可能性があります。リソースの受信者は、リソースを作成したプロセスとは異なるアプリケーションである可能性があります。共有リソース（バッファ）への参照は、さまざまな方法でプロセス間で受け渡すことができます。互換性のあるウェイランド経由IPC接続。このような方法で渡されたバッファ（EGL画像）は、それを取得するために使用されるレンダリングAPIへの参照を保持しません。EGLレイヤーはフレームバッファをウィンドウやディスプレイなどの基盤となるOS要素にバインドすることも担当します。実際には、バッファをウィンドウや特定のディスプレイにペイントするために使用できるシステムプロセスとバッファを共有することを意味します。したがって、これは単なるバリエーションです。 libEGLは非常に拡張可能であり、利用可能な拡張機能の膨大なリストがあるため、libEGL実装は、上記の説明に適合しない他のタスクも担当している可能性があります。
GLX-EGLのより古く限定されたバリアント。 X11クライアントとX11サーバー間でのみ、さまざまな種類のバッファーを共有できます。これは本質的にX11プロトコルに関連付けられています。クライアントアプリケーションがX11プロトコルを使用している場合は、GLXも使用できます。ウェイランドプロトコルを使用している場合は使用できません。 EGLは、そのようなデータをより一般的に共有できるようにするために、その代わりとして開発されました。最新のX11サーバーでは、クライアントがGLXの代わりにEGLを使用することもできます。
そのため、ウェイランドテクノロジーでは、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とハードウェアの機能によってのみ決定されます。
クライアントアプリケーションは、ウィンドウとGL（ES）コンテキストを初期化するために、特定のAPIを使用する必要があります。クライアントアプリケーションがX11 APIを使用してウィンドウを作成する場合、クライアントアプリケーションは完全なX11サーバーのふりをしてXWayland互換性シムに接続します。その後、クライアントはGLXまたはEGL-on-X11のいずれかを使用して、そのコンテキストを初期化し、レンダリングされたバッファーをX11サーバーと共有できます。クライアントがWaylandクライアントAPIを使用してウィンドウを作成する場合、EGL-on-waylandを使用してコンテキストを初期化し、レンダリングされたバッファーをwaylandコンポジターと共有できます。ほとんどの場合、この選択はクライアント側の全体にあります。
Waylandに対応していない古いソフトウェアの多くは、X11 APIとGLXのみを使用しています。これは、開発中にWaylandとEGL APIが存在しない（または十分に成熟していない）ためです。さらに最近のソフトウェアは、互換性の理由からX11 APIのみを使用することがよくあります。ウェイランド以外のシステムはまだたくさんあります。 GTKやQTなどの最新のUIツールキットは、実際には複数の「バックエンド」をサポートしています。つまり、初期化時にセッションタイプを検出し、最も適切なAPIを使用してウィンドウと描画コンテキストを作成できます。ゲームは一般にそのようなツールキットを使用しないため、そのような検出の負担は完全に開発者にあります。そのようなプロジェクトの多くは実際に実装する必要がなく、X11と（Xwaylandを介した）ウェイランドセッションの両方でX11とGLXプロトコルに依存することがよくあります。したがって、ゲームがある場合、GLXを使用してOpenGLを初期化するということは、X11 APIを使用することを選択したということです。これは、ゲームがウェイランドまたはEGLをまったくサポートしていないためか、ゲームがOpenGLを初期化するためにEGLを使用しようとし、何らかの理由で失敗したかどうか、大量の追加情報なしでは判断できません。いずれにせよ、それはウェイランドプロトコルや使用されているコンポジターにまったく依存していません。
ドキュメントの全体は、他の回答で引用されているものもあるが、それらすべてを信頼しても構わなければ、十分に明確であると思う。私は認めます...その戦略は時々信頼できない結果をもたらす:-)。だからここにあなたの「確固たる証拠」があります。
Web検索[wayland opengl egl]： "リポジトリのwestonコンポジターを使用して、XのDebian Stableマシンで完全に動作しました" 。
私のコメントに従って、私が実行することを推奨したコマンドを以下に示します。
_$ git clone https://github.com/eyelash/tutorials/
cloning into 'tutorials'...
remote: Enumerating objects: 88, done.
remote: Total 88 (delta 0), reused 0 (delta 0), pack-reused 88
Unpacking objects: 100% (88/88), done.
$ cd tutorials
$ gcc -o wayland-egl wayland-egl.c -lwayland-client -lwayland-egl -lEGL -lGL
_$ ./wayland-egl & # a green square appears! $ ss --unix -a -p | grep wayland-egl u_str ESTAB 0 0 * 3920430 * 3921234 users:(("wayland-egl",pid=3260,fd=3)) $ ss --unix -a -p | grep 3921234 u_str ESTAB 0 0 /run/user/1001/wayland-0 3921234 * 3920430 users:(("gnome-Shell",pid=2271,fd=100),("gnome-Shell",pid=2271,fd=20)) u_str ESTAB 0 0 * 3920430 * 3921234 users:(("wayland-egl",pid=3260,fd=3))
このコードは、Waylandプロトコルを使用して、レンダリングバッファーをコンポジター_gnome-Shell_と共有しています。そして、OpenGLを使用してレンダリングします。 XWaylandサーバープロセス、X11プロトコル、またはOpenGL ES（GLES）APIを使用してこのプログラムを実行する方法はまったくありません。疑いの余地はないと思います。
ssテストの目的は、_wayland-egl_がXWaylandプロセスによって提供されるX11プロトコルソケットに接続されていないことを証明することです。 （プロセス=実行中のプログラム）。 XWaylandサーバーは、gnome-Shellやwestonとはまったく別のプロセスです。 westonはX11プロトコルをまったく話しません。 XWaylandはそうします。
対照的に：
$ glxgears >/dev/null 2>&1 & # spinning gears appear! $ ss --unix -a -p | grep glxgears u_str ESTAB 0 0 * 3924917 * 3922619 users:(("glxgears",pid=3310,fd=3)) $ ss --unix -a -p | grep 3922619 u_str ESTAB 0 0 * 3924917 * 3922619 users:(("glxgears",pid=3310,fd=3)) u_str ESTAB 0 0 @/tmp/.X11-unix/X0 3922619 * 3924917 users:(("Xwayland",pid=2307,fd=14))
また、_DISPLAY=:666_を設定すると、_wayland-egl_が引き続き実行できることがわかります。一方、xterm、またはglxgearsはX11サーバーを必要とし、偽のディスプレイ番号を設定すると実行できなくなります。 DISPLAYは、接続するディスプレイ番号を知るために、すべてのX11クライアントによって使用される標準の環境変数です。