it-swarm-ko.tech

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

KDE SC 4.5.0은 일부 비디오 카드에 문제가 있습니다. 릴리스시 아치가 여러 해결 방법을 권장했습니다 .

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

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

23
xenoterracide

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

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

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

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

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

직접 렌더링

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

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

16
Maciej Piechotka

먼저 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 driver )를 사용하도록 변경되었습니다. SuSE와 같은 일부 배포판에서는 특히 이전 동작으로 돌아 가기 위해이 패치를 패치했습니다. 원격 X 서버가 내부 소프트웨어 렌더러 중 하나와 정확히 일치하는 GLX 비주얼을 제공 한 경우에만 시작됩니다. (그렇지 않으면 일반적인 " 오류 : RGB를 얻을 수 없습니다. 더블 버퍼링 된 비주얼 ") 그러면 Mesa는 로컬 (응용 프로그램으로) CPU를 사용하여 모든 glFoo() 명령을 렌더링하고 래스터 이미지 (XPutImage())를 통해 결과를 원격 X 서버로 푸시합니다. LIBGL_ALWAYS_INDIRECT=1 설정 (Mesa 17.3 이전에는 모든 값이 작동하므로 1 또는 true )는 Mesa에 일반 직접 렌더링 또는 내부 소프트웨어 렌더러를 무시하고 이전과 같이 간접 렌더링을 사용하도록 지시합니다.

간접 렌더링 또는 직접 소프트웨어 렌더링을 선택하면 다음 두 가지에 영향을줍니다.

OpenGL 버전

  • 간접 렌더링은 일반적으로 OpenGL 1.4로 제한됩니다.
  • 직접 소프트웨어 렌더링은 Mesa 소프트웨어 래스터 라이저가 지원하는 모든 것을 지원할 것입니다 (아마도 OpenGL 2.1 이상).

공연

  • 응용 프로그램이 간접 연결 용으로 설계된 경우 (표시 목록을 사용하고 왕복 쿼리를 최소화 함) 합리적인 성능을 얻을 수 있습니다.
  • 응용 프로그램이 프레임 당 glGetInteger()과 같은 바보 같은 작업을 수행하는 경우 고속 LAN에서도 각 쿼리는 쉽게 1ms 또는 프레임 당 총 100ms를 차지하므로 10 FPS를 초과 할 수 없습니다. 너의 어플리케이션.
  • 렌더링로드가 너무 많지 않은 경우 동일한 응용 프로그램은 직접 소프트웨어 렌더링으로 성능이 우수 할 수 있습니다. 모든 glGetInteger() 호출은 마이크로 또는 나노초의 문제로 직접 응답하기 때문입니다.
  • 응용 프로그램이 백만 버텍스 디스플레이 목록을 만든 다음 많은 회전을 수행하면 반대쪽에 실제 GPU를 사용한 간접 렌더링이 훨씬 더 나은 성능을 제공합니다.
  • OpenGL 1.4와 2.x 만 사용할 수있는 응용 프로그램은 다른 코드 경로로 대체되어 성능에 영향을 줄 수 있습니다.

따라서 응용 프로그램과 네트워크 특성에 대한 정확한 세부 정보 없이는 직접 소프트웨어 렌더링 또는 간접 렌더링이 어떤 상황에서 더 나은지 말할 수 없습니다.

귀하의 경우 로컬 kwin 인스턴스를 실행중인 것 같습니다. 따라서 LIBGL_ALWAYS_INDIRECT의 효과는 로컬 X 서버에 대한 간접 렌더링을 강제하는 것입니다. 이것은 분명히 kwin의 동작을 변경하거나 (OpenGL 1.4 만 해당) 다른 버그를 피합니다.

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

14
Nathan Kidd