Почему Wayland использует OpenGL ES вместо OpenGL?
Изhttps://wayland.freedesktop.org/faq.html:
Why does Wayland use EGL?
EGL is the only GL binding API that lets us avoid dependencies on existing window systems, in particular X. GLX obviously pulls in X dependencies and only lets us set up GL on X drawables. The alternative is to write a Wayland specific GL binding API, say, WaylandGL.
A more subtle point is that libGL.so includes the GLX symbols, so linking to that library will pull in all the X dependencies. This means that we can't link to full GL without pulling in the client side of X, so Weston uses OpenGL ES to render. This also enables Weston to run on GPUs which don't support the full OpenGL API.
As detailed above, clients are however free to use whichever rendering API they like.
Я думаю, что все документы, некоторые из которых цитируются в других ответах, достаточно ясны, если вы готовы доверять им всем. Я признаю... иногда эта стратегия дает ненадежные результаты :-). Вот вам и ваши "убедительные доказательства".
Веб-поиск [wayland opengl egl]:«Прекрасно работал на моей машине со стабильной версией Debian в X, используя компоновщик weston из репозиториев» .
Вот команды, которые я рекомендовал вам выполнять согласно моим комментариям:
$ 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 или API OpenGL ES (GLES ). Я не думаю, что это оставляет место для сомнений.
Цель теста ss— доказать, что wayland-eglне подключен к сокету протокола X11 -, который обслуживается процессом XWayland. (процесс = работающая программа ). Сервер XWayland — это отдельный процесс от оболочки gnome -или вестона. Уэстон вообще не говорит по протоколу 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, чтобы узнать, к какому номеру дисплея подключаться.
Посылка вашего вопроса неверна. Wayland вообще не использует OpenGL ES или OpenGL. Давайте разберемся, чтобы добиться правильного понимания стека программного обеспечения:
Wayland — это протокол IPC, который позволяет клиентам и компоновщику общаться друг с другом. Хотя технически libwayland является всего лишь одной реализацией этого протокола и не должен отождествляться исключительно с ним, на данный момент он остается единственной реализацией и обычно также называется «wayland». Это не полноценный композитор, работающий на вашем оборудовании.
Wayland Compositor — это приложение, использующее протокол wayland для получения буферов от клиентов и объединения их в единое изображение, отображаемое на дисплее. Протокол Wayland делает относительно мало предположений о внутренней работе самого компоновщика. В частности, выбор технологии рендеринга остается полностью открытым. Тип буфера по умолчанию, определенный основным протоколом, представляет собой простой буфер с общей памятью, который никаким образом не ускоряется графическим процессором и предназначен в основном для простых приложений, которые отображают свой пользовательский интерфейс, используя только ЦП. Этот тип буфера в нашем случае не интересен, и в остальной части ответа его удобно будет забыть.
Weston — эталонная реализация компоновщика Wayland. Хотя он разработан людьми, участвующими в разработке самого libwayland, он не является существенной частью экосистемы wayland -, это всего лишь отдельная реализация композитора. Если вы используете какой-либо из дистрибутивов Linux, включающий среду рабочего стола wayland, вы почти наверняка используете не Weston, а какую-то другую реализацию компоновщика.Weston использует OpenGL ES для рендеринга -это в основном продиктовано тем фактом, что текущие реализации libGL по-прежнему связаны с некоторыми библиотеками, связанными с X -, и создатели Weston хотели сохранить его в чистом виде -это эталонная реализация после все. Кроме того, это делает его совместимым со встроенными устройствами, которые могут не поддерживать полную версию OpenGL.
EGL -libEGL — это библиотека, которая содержит связывающий -код, позволяющий инициализировать несколько контекстов рендеринга огромного разнообразия (OpenGL, OpenGL ES или OpenVG в разных версиях ). Он также позволяет обмениваться данными между такими контекстами -, т. е. позволяет передавать буфер кадра, созданный с помощью OpenGL, и передавать его в OpenVG для дальнейшей обработки. Совместное использование этих ресурсов может происходить через границы процессов -. Получателем ресурса может быть приложение, отличное от процесса, который его создал. Ссылка на общий ресурс (буфер )может передаваться между процессами различными способами, например. через совместимое соединение Wayland IPC. Буфер (EGL Image ), переданный таким образом, не сохраняет никакой ссылки на API рендеринга, использованный для его получения. Хотя утверждается, что уровень EGL также отвечает за привязку буферов кадра к базовым элементам ОС, таким как окна или дисплеи, на практике это означает совместное использование буферов с некоторым системным процессом, который может использовать его, например, для. нарисуйте его в окне или на определенном дисплее. Следовательно, это всего лишь вариант вышеперечисленного функционала, а не отдельная функция. libEGL сильно расширяем, и существует огромный список доступных расширений, поэтому ваша реализация libEGL может также отвечать за другие задачи, которые не подходят под приведенное выше описание.
GLX -более старый и более ограниченный вариант EGL. Это позволяет совместно использовать буферы различных типов, но только между клиентом X11 и сервером X11.Он изначально привязан к протоколу X11 -, если клиентское приложение использует протокол X11, он также может использовать GLX. Если он использует протокол Wayland, он не может. EGL был разработан как его замена, чтобы обеспечить более широкий обмен такими данными. Современные серверы X11 также позволяют клиентам использовать EGL вместо GLX.
Таким образом, технология Wayland не требует от вас использования OpenGL ES и даже не указывает направление ее использования. Эталонный компоновщик Weston использует его для внутренних целей, но это не влияет на клиентский API рендеринга. Единственное требование состоит в том, что все, что вы визуализируете, может быть преобразовано в изображение EGL. Поскольку это работа libEGL, выбор API рендеринга на стороне клиента диктуется только ограничениями вашей реализации libEGL. Это также верно для других компоновщиков, которые могут использовать или не использовать OpenGL ES для рендеринга окончательного изображения рабочего стола.
libEGL является частью драйвера графического процессора (. libGL ), поэтому возможность преобразования буфера OpenGL в изображение EGL (и последующего преобразования изображения EGL в текстуру OpenGL ES на стороне компоновщика )зависит от вашего оборудования, но на практике практически каждое оборудование позволяет это, пока он вообще поддерживает полный OpenGL. Вот почему вам трудно найти окончательное доказательство того, что wayland полностью поддерживает OpenGL -wayland вообще не заботится о технологии рендеринга. Как говорится в FAQ:
What is the drawing API?
"Whatever you want it to be, honey"[...]
Таким образом, вопрос о поддержке OpenGL выходит за рамки компетенции Wayland. На самом деле это определяется исключительно возможностями libEGL и аппаратного обеспечения.
Клиентское приложение должно использовать определенный API для инициализации своих окон и контекстов GL (ES ). Если клиентское приложение использует X11 API для создания своих окон, то оно будет подключаться к прокладке совместимости XWayland, которая притворяется для клиента полноценным сервером X11.Затем клиент сможет использовать либо GLX, либо EGL -на -X11 для инициализации своих контекстов и совместного использования отображаемых буферов с сервером X11. Если клиент использует клиентский API wayland для создания своих окон, он сможет использовать EGL -на -wayland для инициализации своих контекстов и совместного использования отображаемых буферов с компоновщиком wayland. Этот выбор в большинстве случаев лежит полностью на стороне клиента.
Многие старые программы, которые не поддерживают Wayland -, используют только X11 API и GLX -просто потому, что wayland и EGL API не существовали (или не были достаточно зрелыми )во время разработки. Даже более современное программное обеспечение часто использует только X11 API из соображений совместимости, -все еще существует довольно много не -систем wayland. Современные наборы инструментов пользовательского интерфейса, такие как GTK или QT, фактически поддерживают несколько «бэкендов», что означает, что они могут определять тип сеанса при инициализации и использовать наиболее подходящий API для создания окон и контекстов рисования. Поскольку игры обычно не используют такие инструменты, бремя такого обнаружения полностью ложится на их разработчиков. Немногие проекты, подобные этому, утруждают себя его реализацией, и они часто полагаются на протокол X11 и GLX как в сеансах X11, так и в сеансах wayland (через Xwayland ). Поэтому, если ваша игра использует GLX для инициализации OpenGL, это означает, что она решила использовать X11 API. Связано ли это с тем, что игра вообще не поддерживает wayland или EGL, или же игра пыталась использовать EGL для инициализации OpenGL и по какой-то причине потерпела неудачу, я не могу судить без тонны дополнительной информации. В любом случае, это никоим образом не зависит от протокола wayland или используемого компоновщика.