为什么 Wayland 使用 OpenGL ES 而不是 OpenGL？

Question

据我所知，Wayland 不是使用 OpenGL 而是使用 OpenGL ES 进行 3D 渲染，通常用于嵌入式系统（Intel IGP 除外）。从长远来看，我读到 OpenGL 支持将被实施，但目前不是优先事项。

我想这是因为 OpenGL ES 更简单一些，但它似乎不是做出这样选择的强项。

我想知道这个决定的原因是什么，以及这个选择的后果是什么（对于 Linux 的未来将会是什么）。

更新：

在Wayland的常见问题是我之前关于要求在这里甚至思维拳头停止。如果我错了，请随时纠正我，但最后一部分似乎，至少，不是很清楚，恕我直言：

EGL 是唯一一个让我们避免依赖现有窗口系统的 GL 绑定 API，尤其是 X。

据我了解，事情没那么简单。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，所以在我看来这更像是一种解决方法，直到事情变得严重。这是首先在这里引发我的问题的句子之一。

如上所述，客户可以自由使用他们喜欢的任何渲染 API。

如果我没记错的话，这意味着将 XWayland 用于 OpenGL 应用程序和 Weston OpenGL ES，这似乎是句子所暗示的更大的交易，尤其是在 3D 渲染方面，更不用说 Wayland/Weston 的目标是替换 Xorg。

备案：

XWayland 是基于 X.Org 服务器代码库的一系列补丁，实现了运行在 Wayland 协议上的 X 服务器。这些补丁由 Wayland 开发人员开发和维护，以便在过渡到 Wayland 期间与 X11 应用程序兼容，[28] 并于 2014 年在 X.Org Server 的 1.16 版中主线。当用户从 Weston 内部运行 X 应用程序时，它要求 XWayland 为请求提供服务。

注意：我正在尝试更多地了解 Wayland/Weston，尤其是在 (3D) 渲染方面，但很难找到有关该主题的确切信息，尤其是因为似乎唯一真正精通 X11 的人似乎是 Wayland开发商。

据我目前所知，对于 OpenGL：

• 如果 OpenGL 函数调用是通过 GLX 接口进行的，它会回退到 XWayland，所以程序（真的）不使用 Wayland。

附录

似乎讨论超出了原始问题的范围，但它实际上与底层 OpenGL 接口/库相关联，并且很难将所有这些与原始问题分开。

由于这似乎是一个复杂而令人困惑的主题，因此这里有一些各种链接和引述，使我认为Wayland 本身并不真正支持OpenGL（而非 ES），而是通过 XWayland 回退到 X11：

EGL 在 Wayland 堆栈中做了什么

图中的 Wayland 服务器是带有 DRM 后端的 Weston。服务器 > 使用 GL ES 2 进行渲染，它通过调用 EGL 进行初始化。

黑客新闻评论

Wayland实际上非常稳定。Nvidia 在 Xwayland 中的 OpenGL 有问题（即 x11 应用程序的 3d 加速），否则，它应该可以工作。但是，使用 Wayland 时会出现疣。使用缩放时（也不必是小数），X11 应用程序会被放大，而不是缩小，从而导致模糊。不幸的是，Firefox 和 Chrome 本身都不支持 Wayland，谁想在计算机上以模糊模式使用他们最常用的应用程序？

为什么基于 GLX 的应用程序可以在 Ubuntu 上的 Wayland 上运行？

所以基于@genpfault 提供的链接：

所以基于@genpfault 提供的链接：

• XWayland 是 XOrg 的一部分，它在 Wayland 之上提供 X 服务器。任何与 X11 库链接并在 Wayland 下运行的应用程序都将自动使用 XWayland 作为其后端。所以 XWayland 的 GLX 部分是允许基于 GLX 的 OpenGL 应用程序在 Wayland 上运行的机制。
• 无法在基于 GLX 的应用程序中使用 MSAA 似乎是 XWayland 的一个已知错误，至少对于 Intel 和 AMD GPU 而言（参见 https://bugs.freedesktop.org/show_bug.cgi?id=98272）。但我找不到关于此事的任何其他信息。

Answer 1

你这个问题的前提是错误的。Wayland 根本不使用 OpenGL ES 或 OpenGL。让我们了解一下，以便正确理解软件堆栈：

1. Wayland 是一种 IPC 协议，允许客户端和合成器相互通信。虽然从技术上讲，libwayland 只是该协议的一个单一实现，不应单独使用它，但目前它仍然是唯一的实现，通常也称为“wayland”。它不是运行硬件的完整合成器。

2. Wayland Compositor 是一个应用程序，它使用 wayland 协议从客户端接收缓冲区并将其组合成显示在显示器上的单个图像。Wayland 协议对合成器本身的内部工作原理的假设相对较少。特别是，渲染技术的选择是完全开放的。核心协议定义的默认缓冲区类型是一个简单的共享内存缓冲区，GPU 不会以任何方式加速，主要用于仅使用 CPU 呈现其 UI 的简单应用程序。这种缓冲区类型在我们的例子中并不有趣，并且会在答案的其余部分中被方便地遗忘。

3. Weston 是 Wayland 合成器的参考实现。虽然它是由参与 libwayland 本身开发的人员开发的，但它不是 Wayland 生态系统的重要组成部分——它只是一个单一的合成器实现。如果您正在运行任何包含 Wayland 桌面环境的 Linux 发行版，您几乎肯定不会使用 Weston，而是使用其他一些合成器实现。Weston 使用 OpenGL ES 进行渲染——这主要是因为当前的 libGL 实现仍然链接到一些与 X 相关的库，并且 Weston 的创建者希望保持它的纯粹——这毕竟是一个参考实现。此外，它还使其与可能不支持完整 OpenGL 的嵌入式设备兼容。

4. EGL - libEGL 是一个包含胶水代码的库，允许初始化多种渲染上下文（不同版本的 OpenGL、OpenGL ES 或 OpenVG）。它还允许在此类上下文之间共享数据 - 即它允许传递用 OpenGL 渲染的帧缓冲区并将其传递给 OpenVG 以进行进一步处理。这些资源的共享可以跨进程边界发生 - 资源的接收者可能是与创建它的进程不同的应用程序。对共享资源（缓冲区）的引用可以通过多种方式在进程之间传递，例如通过兼容的wayland IPC 连接。以这种方式传递的缓冲区（EGL 图像）不会保留对用于获取它的渲染 API 的任何引用。虽然据称 EGL 层还负责将帧缓冲区绑定到底层操作系统元素（如窗口或显示器），但实际上这意味着与某些系统进程共享缓冲区，这些进程可以使用它来例如在窗口或特定的窗口中绘制它展示。因此，它只是上述功能的变体，而不是单独的功能。libEGL 是高度可扩展的，并且有大量可用的扩展列表，因此您的 libEGL 实现可能还负责其他不符合上述描述的任务。

5. GLX - EGL 的较旧且更有限的变体。它允许共享各种缓冲区，但只能在 X11 客户端和 X11 服务器之间共享。它固有地绑定到 X11 协议 - 如果客户端应用程序使用 X11 协议，它也可以使用 GLX。如果它使用 Wayland 协议，则不能。EGL 被开发作为它的替代品，以允许更广泛地共享此类数据。现代 X11 服务器也允许客户端使用 EGL 而不是 GLX。

所以Wayland技术不需要你使用OpenGL ES，甚至也没有模糊地指向它的方向。参考合成器 Weston 在内部使用它，但这对客户端渲染 API 没有影响。唯一的要求是您渲染的任何内容都可以转换为 EGL Image。由于这是 libEGL 的工作，客户端渲染 API 的选择仅取决于您的 libEGL 实现的限制。对于其他可能使用或不使用 OpenGL ES 渲染最终桌面图像的合成器来说也是如此。

libEGL 是 GPU 驱动程序软件的一部分（就像 libGL 一样），因此它是否允许将 OpenGL 缓冲区转换为 EGL 图像（然后在合成器端将 EGL 图像转换为 OpenGL ES 纹理）取决于您的硬件，但实际上几乎所有硬件都允许这样做，只要它完全支持完整的 OpenGL。这就是为什么你很难找到 Wayland 支持完整 OpenGL 的明确证据——wayland 根本不关心渲染技术。正如常见问题解答所说：

什么是绘图API？

“无论你想要什么，亲爱的”[...]

因此，是否支持 OpenGL 的问题超出了 Wayland 的范围。它实际上完全由 libEGL 和硬件的能力决定。

客户端应用程序必须使用特定的 API 来初始化其窗口和 GL(ES) 上下文。如果客户端应用程序使用 X11 API 创建它的窗口，那么它将连接到 XWayland 兼容性垫片，它假装是客户端的完整 X11 服务器。然后客户端将能够使用 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 协议或使用的合成器。

Answer 2

来自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。