LIBGL_ALWAYS_INDIRECT = 1은 실제로 무엇을합니까?


22

KDE SC 4.5.0에는 광산을 포함한 일부 비디오 카드에 문제가 있습니다. 릴리스시 Arch는 몇 가지 해결 방법을 권장했습니다 . 그 중 하나는

KDE를 시작하기 전에 "LIBGL_ALWAYS_INDIRECT = 1"내보내기

나는 그것이 가장 쉽고 가장 좋은 방법이라고 결정했다. 그러나 그것이 무엇을하는지 또는 그것이 시스템에 어떤 영향을 미치는지 모르겠습니다. 기본값보다 느립니까? 문제를 주시하고 문제가 해결되면 나중에 사용 중지해야한다는 것을 기억해야하나요?

답변:


13

간접 렌더링은 GLX 프로토콜이 OpenGL 명령을 전송하는 데 사용되고 X.org가 실제 드로잉을 수행함을 의미합니다.

직접 렌더링 은 응용 프로그램이 먼저 mesa를 통해 X.org와 통신하지 않고 하드웨어에 직접 액세스 할 수 있음을 의미합니다.

직접 렌더링은 컨텍스트를 X.org 프로세스로 변경할 필요가 없으므로 더 빠릅니다.

설명 : 두 경우 모두 렌더링이 GPU에 의해 수행됩니다 (또는 기술적으로 GPU에 의해 수행 될 수 있음). 그러나 간접 렌더링에서는 프로세스가 다음과 같습니다.

  1. 프로그램이 명령을 호출합니다
  2. GLX 프로토콜에 의해 명령이 X.org로 전송됩니다
  3. X.org는 하드웨어 (예 : GPU)를 호출하여 그리기

직접 렌더링

  1. 프로그램이 명령을 호출합니다
  2. 명령이 GPU로 전송됩니다

OpenGL은 네트워크를 통해 작동 할 수있는 방식으로 설계 되었기 때문에 간접 렌더링이 더 빠르기 때문에 아키텍처를 순진하게 구현하는 것입니다. 즉, 한 번에 많은 명령을 보낼 수 있습니다. 그러나 컨텍스트 스위치 및 처리 프로토콜에 소요되는 CPU 시간과 관련하여 약간의 오버 헤드가 있습니다.


이것은 내 CPU가 비디오 칩 대신 렌더링 atm을 수행하고 있음을 의미합니까?
xenoterracide

3
두 경우 모두 가속이있는 경우 GPU가 드로잉을 수행하지만 추가 오버 헤드가 있습니다. 가속화되지 않은 그리기는 매우 느리며 효과가 필요하지 않습니다. LIBGL_ALWAYS_INDIRECT=1즉, 복합 wm과 같은 OpenGL의 고급 사용에는 일반적으로 간접 렌더링 해결 방법이 필요합니다.
Maciej Piechotka

14

첫째, LIBGL_ALWAYS_INDIRECTMesa 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 만 해당) 다른 버그를 피합니다.

근본적인 문제가 해결되었을 때이 플래그를 제거하려고합니다.


참고 : 다른 사용자는 nVidia를 사용 하여이 작업을 수행 할 수 있습니다 : __GL_ALLOW_UNOFFICIAL_PROTOCOL ... 나는 gnome-session-wayland (3.18) 원격 앱 개념 증명을 위해 이것을 사용하고 있습니다.
elika kohen
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.