첫째, LIBGL_ALWAYS_INDIRECT
Mesa 3D 클라이언트 측 OpenGL 구현 (libGL.so)과 관련된 플래그입니다. 다른 공급 업체의 바이너리 드라이버 (예 : NVIDIA)에서는 작동하지 않습니다.
둘째, 귀하의 질문에 직접 대답하기 위해 마지막으로 깃발이 다음과 같이 작동하는 Mesa 코드를 보았습니다.
Mesa가 간접 X 서버로 작업 할 때 ~ 2008 년 이전 (예 : ssh -X
로컬 서버가 아닌 서버에 디스플레이를 명시 적으로 설정했거나 원격 X 서버에서 제공 한 GLX 비주얼 목록을 GLX 응용 프로그램에서 사용할 수있게 만들었습니다. 애플리케이션은 glXChooseVisual ()을 호출하고 Mesa는 일치하는 것이 합리적이라는 것을 알게되고, 후속 glFoo()
호출은 원격 X 서버에 연결된 libGL (GPU와 같은)에 의해 실행되는 원격 X 서버로 전송됩니다.
2008 년 말에 Mesa는 원격 X 연결을 위해 내부 소프트웨어 OpenGL 렌더러 ( Xlib 드라이버 ) 를 사용하도록 변경되었습니다 . SuSE와 같은 일부 배포판에서는 특히 이전 동작으로 돌아 가기 위해이 패치를 패치했습니다. 원격 X 서버가 내부 소프트웨어 렌더러 중 하나와 정확히 일치하는 GLX 비주얼을 제공 한 경우에만 시작됩니다. (그렇지 않으면 " 오류 : RGB, 이중 버퍼링 비주얼을 얻을 수 없음 "이라는 공통점이 표시 됩니다.) 이러한 비주얼이 발견되면 Mesa는 glFoo()
로컬 (응용 프로그램) CPU로 모든 명령을 렌더링 하고 래스터 이미지 ( XPutImage()
) 를 통해 원격 X 서버로 결과 ; 설정 LIBGL_ALWAYS_INDIRECT=1
(Mesa 17.3 이전에는 모든 값이 작동하므로 1 또는 true를 사용해야 함))는 Mesa에 일반 직접 렌더링 또는 내부 소프트웨어 렌더러를 무시하고 이전과 같이 간접 렌더링을 사용하도록 지시합니다.
간접 렌더링 또는 직접 소프트웨어 렌더링을 선택하면 다음 두 가지에 영향을줍니다.
OpenGL 버전
- 간접 렌더링은 일반적으로 OpenGL 1.4로 제한됩니다.
- 직접 소프트웨어 렌더링은 Mesa 소프트웨어 래스터 라이저가 지원하는 모든 것을 지원할 것입니다 (아마도 OpenGL 2.1 이상).
공연
- 응용 프로그램이 간접 연결 용으로 설계된 경우 (표시 목록을 사용하고 왕복 쿼리를 최소화 함) 합리적인 성능을 얻을 수 있습니다.
- 응용 프로그램이
glGetInteger()
프레임 당 100 회 와 같은 멍청한 짓 을하더라도 빠른 LAN에서도 각 쿼리는 쉽게 1ms 또는 프레임 당 총 100ms를 차지하므로 응용 프로그램에서 10FPS를 초과 할 수 없습니다.
- 렌더링로드가 너무 무겁지 않은 경우 동일한 응용 프로그램이 직접 소프트웨어 렌더링으로 매우 잘 수행 될 수 있습니다. 모든
glGetInteger()
호출은 마이크로 또는 나노초의 문제로 직접 응답하기 때문입니다.
- 응용 프로그램이 백만 버텍스 디스플레이 목록을 만든 다음 많은 회전을 수행하면 반대쪽에 실제 GPU를 사용한 간접 렌더링이 훨씬 더 나은 성능을 제공합니다.
- OpenGL 1.4와 2.x 만 사용할 수있는 응용 프로그램은 다른 코드 경로로 대체되어 성능에 영향을 줄 수 있습니다.
따라서 응용 프로그램과 네트워크 특성에 대한 정확한 세부 정보 없이는 직접 소프트웨어 렌더링 또는 간접 렌더링이 어떤 상황에서 더 나은지 말할 수 없습니다.
귀하의 경우 로컬 kwin 인스턴스를 실행하는 것으로 보이므로 LIBGL_ALWAYS_INDIRECT
로컬 X 서버에 간접 렌더링을 강제 하는 것이 효과입니다 . 이것은 분명히 kwin
동작을 변경하거나 (OpenGL 1.4 만 해당) 다른 버그를 피합니다.
근본적인 문제가 해결되었을 때이 플래그를 제거하려고합니다.