내가 아는 한 Wayland는 OpenGL을 사용하지 않고, 일반적으로 임베디드 시스템(Intel IGP 제외)에서 사용되는 3D 렌더링용 OpenGL ES를 사용합니다. 장기적으로는 OpenGL 지원이 구현될 것으로 알고 있지만 현재로서는 이것이 우선순위가 아닙니다.
OpenGL ES가 약간 더 단순하기 때문인 것 같지만, 이것이 선택을 하는 데 있어서 큰 장점은 아닌 것 같습니다.
나는 이 결정의 이유가 무엇인지, 그리고 이 선택이 (리눅스의 미래를 위해) 어떤 결과를 가져오는지 알고 싶습니다.
고쳐 쓰다:
이것웨이랜드 FAQ이곳에 물어보기 전 첫 번째 방문지였습니다. 내가 틀렸다면 자유롭게 정정해 주세요. 하지만 적어도 마지막 부분은 약간 불분명한 것 같습니다. 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을 사용할 수도 있습니다.
따라서 wayland 기술은 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이 지원되는지 여부에 대한 질문은 wayland의 범위를 벗어납니다. 이는 실제로 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 프로토콜이나 사용된 신디사이저에 전혀 의존하지 않습니다.
답변2
~에서https://wayland.freedesktop.org/faq.html:
Wayland가 EGL을 사용하는 이유는 무엇입니까?
EGL은 기존 창 시스템(특히 X)에 대한 종속성을 피할 수 있는 유일한 GL 바인딩 API입니다. GLX는 분명히 X 종속성을 도입하고 X 드로어블에만 GL을 설정할 수 있도록 허용합니다. 또 다른 접근 방식은 WaylandGL과 같은 Wayland 관련 GL 바인딩 API를 작성하는 것입니다.
더 미묘한 점은 libGL.so에 GLX 기호가 포함되어 있으므로 이 라이브러리에 대해 링크하면 모든 X 종속성이 발생한다는 것입니다. 즉, X 클라이언트를 가져오지 않고는 전체 GL에 연결할 수 없으므로 Weston은 렌더링에 OpenGL ES를 사용합니다. 또한 이를 통해 Weston은 전체 OpenGL API를 지원하지 않는 GPU에서 실행할 수 있습니다.
그러나 위에서 언급한 것처럼 클라이언트는 원하는 렌더링 API를 자유롭게 사용할 수 있습니다.
답변3
나는 당신이 이 모든 문서(일부는 다른 답변에서 인용됨)를 기꺼이 믿고 싶다면 전체 내용이 충분히 명확하다고 생각합니다. 나는 인정합니다...때때로 이 전략은 신뢰할 수 없는 결과를 낳습니다 :-). 그래서 이것은 당신의 "스모킹 건"입니다.
웹 검색 [wayland opengl egl]:"저장소의 weston 합성기를 사용하면 내 Debian X 안정적인 컴퓨터에서 완벽하게 작동합니다.".
내 의견에 따르면 다음과 같은 명령을 실행하도록 권장합니다.
$ 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를 사용하여 이 프로그램을 실행하는 것은 절대 불가능합니다. 나는 그것에 대해 의심의 여지가 없다고 생각합니다.
테스트의 목적은 XWayland 프로세스에서 제공하는 X11 프로토콜 소켓에 대한 연결이 없음 ss을 입증하는 것입니다 . wayland-egl(프로세스 = 실행 중인 프로그램). XWayland 서버는 gnome-shell 또는 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, glxgearsX11 서버가 필요하며, 잘못된 표시 번호를 설정하면 해당 서버가 실행되지 않습니다. DISPLAY연결할 모니터 번호를 파악하기 위해 모든 X11 클라이언트에서 사용하는 표준 환경 변수입니다.
답변4
tl; 박사는 이렇게 대답했습니다.
EGL != OpenGL ES
EGL은 렌더 버퍼를 관리하기 위한 라이브러리입니다.
OpenGL, OpenGL ES 또는 OpenVG와 같은 API는 이러한 렌더 버퍼에 직접 렌더링할 수 있습니다.
Wayland가 자체 렌더 버퍼 관리 대신 EGL을 사용하는 이유는 무엇입니까?
실제로 Wayland에는 자체 렌더버퍼( wl_buffer)가 있지만 내부 구조는 구현에 따라 다르며 성능상의 이유로 Wayland에서는 클라이언트가 GPU 프레임버퍼에 직접 렌더링할 수 있도록 허용합니다. 직접 렌더링 모드에서는 렌더버퍼 모델이 필요합니다. 화면에 표시되지만 동시에 프로세스 간에 렌더 버퍼를 공유하며 두 경우 모두 이미 존재하고 잘 지원되는 EGL을 통해 달성할 수 있는데 Wayland에서는 왜 이를 사용하지 않습니까?
그렇다면 Wayland는 항상 EGL을 사용하지 않았습니까?
Wayland 클라이언트는 간접 렌더링 모드에서 EGL을 사용하지 않습니다. 즉, 클라이언트는 화면에 직접 렌더링하지 않고 공유 메모리 버퍼(클라이언트와 컴포지터 간에 공유)에 렌더링합니다. 그러나 합성기는 여전히 EGL을 사용하여 이 버퍼의 내용을 화면에 렌더링할 수 있습니다. 또한 Vulkan API를 사용할 때 Vulkan은 EGL 버퍼에 렌더링하지 않으므로 EGL은 관련되지 않습니다. Vulkan은 확장 기능을 사용하여 Wayland 표면에 직접 렌더링할 수 있습니다 VK_KHR_wayland_surface(어쨌든 뒤에서 EGL을 사용할 수도 있지만 그건 여러분이 상관할 일이 아닙니다).