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

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

KDE SC 4.5.0에는 일부 그래픽 카드(내 그래픽 카드 포함)에 몇 가지 문제가 있습니다. 출시 후Arch는 여러 솔루션을 권장합니다. 그 중 하나는

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

나는 이것이 가장 쉽고 좋은 방법이라고 생각합니다. 그러나 나는 그것이 무엇을 하는지, 그것이 내 시스템에 어떤 영향을 미치는지 전혀 모릅니다. 기본값보다 느린가요? 이 문제를 계속 주시하고 문제가 해결되면 비활성화해야 합니까?

답변1

간접 렌더링은 OpenGL 명령을 전송하는 데 GLX 프로토콜이 사용되고 X.org가 실제 그리기를 수행한다는 의미입니다.

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

직접 렌더링은 X.org 프로세스에 대한 컨텍스트를 변경할 필요가 없기 때문에 더 빠릅니다.

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

  1. 프로그램 호출 명령
  2. 명령은 GLX 프로토콜을 통해 X.org로 전송됩니다.
  3. X.org는 하드웨어(예: GPU)를 호출하여 그림을 그립니다.

직접 렌더링

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

OpenGL은 네트워크를 통해 작동할 수 있도록 설계되었기 때문에 간접 렌더링은 여러 명령을 한 번에 전송할 수 있는 단순한 아키텍처 구현보다 빠릅니다. 그러나 컨텍스트 전환 및 프로토콜 처리에 소요되는 CPU 시간 측면에서 약간의 오버헤드가 있습니다.

답변2

첫 번째 LIBGL_ALWAYS_INDIRECT는 Mesa 3D 클라이언트 OpenGL 구현(libGL.so)과 관련된 플래그입니다. 다른 공급업체(예: NVIDIA)의 바이너리 드라이버에서는 작동하지 않습니다.

둘째, 귀하의 질문에 직접 대답하기 위해 마지막으로 Mesa 코드를 살펴보았는데 플래그가 작동하는 방식은 다음과 같습니다.

2008년 이전에는 Mesa가 간접 X 서버를 사용했을 때(예를 들어 ssh -X디스플레이를 로컬이 아닌 서버로 설정한 경우) 원격 X 서버에서 제공하는 GLX 시각 효과 목록을 GLX 응용 프로그램에서 사용할 수 있게 만들었습니다. 응용 프로그램은 glXChooseVisual()을 호출하고 Mesa는 합당한 일치 항목을 찾은 다음 후속 glFoo()호출은 원격 X 서버로 전송됩니다. 여기서 호출은 원격 X 서버가 연결된 모든 libGL(GPU일 수 있음)에 의해 실행됩니다.

2008년 말쯤에 Mesa에서 뭔가 변경되어 자체 소프트웨어인 OpenGL 렌더러를 사용하기를 원했습니다(Xlib 드라이버) 원격 X 연결의 경우. (SuSE와 같은 일부 배포판에서는 이전 동작으로 되돌리기 위해 특별히 패치를 적용했습니다.) 이는 원격 X 서버가 내부 소프트웨어 렌더러 중 하나와 정확히 일치하는 GLX 시각적 개체를 제공하는 경우에만 적용됩니다. (그렇지 않으면 당신은 분명해질 것입니다, "오류: RGB, 이중 버퍼 시각 효과를 얻을 수 없습니다.".) 이러한 시각적 개체가 발견되면 Mesa는 glFoo()로컬(애플리케이션에 대한) CPU를 사용하여 모든 명령을 렌더링하고 결과를 래스터 이미지( XPutImage())를 통해 원격 X 서버에 푸시합니다. 설정 LIBGL_ALWAYS_INDIRECT=1(Mesa 17.3 이전에는 모든 값이 작업을 수행하세요. 그때부터 사용해야 합니다.1또는진짜)는 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에만 해당) 다른 버그를 방지합니다.

근본적인 문제가 해결되면 반드시 이 플래그를 제거하고 싶을 것입니다.

관련 정보