Linux에서 저수준 3D 프로그래밍을 시작하고 있습니다. 고급 그래픽 API OpenInventor를 사용한 경험이 많습니다.
나는이 모든 것들이 어떻게 조화를 이루는지를 반드시 알아야 할 필요는 없다는 것을 알고 있습니다. 그러나 나는 단지 궁금합니다. OpenGL은 그래픽 응용 프로그램의 표준이라는 것을 알고 있습니다. Mesa3D는이 표준의 오픈 소스 구현 인 것 같습니다.
GLX와 DRI는 어디에 적합합니까? Wikipedia와 모든 웹 사이트를 파헤 치면서, 나는 그것이 어떻게 그것이 어떻게 진행되는지에 대한 설명을 아직 찾지 못했습니다. 하드웨어 가속은 어디서 발생합니까? 독점 드라이버는 이것과 어떤 관련이 있습니까?
답변:
OpenGL을 제외하고는 그 라이브러리를 사용한 적이 없지만, 위키 백과 페이지를 읽음으로써 추측하려고합니다.
당신은 메사에 대해 옳은 것 같습니다. 추가 정보는 다음과 같습니다.
"X 윈도우 시스템은 네트워크 컴퓨터에 기본 GUI를 제공하는 컴퓨터 소프트웨어 시스템 및 네트워크 프로토콜입니다. 하드웨어 추상화 계층을 만듭니다."
"Open Inventor는 OpenGL에 더 높은 수준의 프로그래밍을 제공하도록 설계된 C ++ 3D 그래픽 API입니다."
일을 단순화하기 위해 각 API의 시작 및 종료에서 발생하는 단순화 된 데이터 흐름 (및 명령)을 상상해 봅시다. 맨 처음에는 컴퓨터에서 실행되는 응용 프로그램 (컴파일 된 코드)이 있습니다. 마지막으로 화면에 이미지가 표시됩니다.
이러한 질문에 대한 답변을 제한 할 수있는 몇 가지 경우가 있습니다
.-컴퓨터에 그래픽 기능을 처리하기 위해 그래픽 카드 (GPU) 또는 CPU 만 있습니까?
-응용 프로그램이 x- 창 시스템의 창에 포함되어 있습니까?
-x 윈도우 시스템을 사용하는 경우 "x 서버"가 컴퓨터 또는 네트워크의 다른 컴퓨터에서 실행되고 있습니까?
GPU 드라이버가 있으면 GPU 용 드라이버가 있고 소프트웨어 렌더링에 Mesa가 있다고 가정합니다.
첫 번째 시나리오 : X Window 시스템을 사용하지 않고 OpenInventor로 작성된 그래픽 응용 프로그램을 실행하며 그래픽 카드가 없습니다. 프로그램 흐름은 다음과 매우 유사합니다.
Your application
↓ (uses functions of)
OpenInventor
↓ (calls functions declared by)
OpenGL
↓ (redirects function calls to implementation defined by)
Mesa
↓ (implemented OpenGL functions to be run on the CPU)
[Probably] Operating System rendering API
↓
3D Images on your screen
여기서 발생하는 것을 "소프트웨어 렌더링"이라고합니다. graphics 명령은 그래픽 하드웨어가 아니라 일반적으로 소프트웨어를 실행하는 프로세서 인 일반적인 CPU에 의해 처리됩니다.
두 번째 시나리오 : 이제 위와 동일한 조건에서 그래픽 카드가 있다고 상상해보십시오. 흐름은 다음과 같습니다.
Your application
↓ (uses functions of)
OpenInventor
↓ (calls functions declared by)
OpenGL
↓ (redirects function calls to implementation defined by)
Proprietary Drivers
↓ (converts OpenGL commands to GPU commands)
Graphic Card
↓
3D Images on your screen
이제 발생하는 것을 "하드웨어 가속"이라고하며 일반적으로 첫 번째 시나리오보다 빠릅니다.
세 번째 시나리오 : 이제 내가 읽은 몇 개의 Wikipedia 라인을 기반으로 X Window System 흐름 또는 적어도 내가 생각하는 방식을 소개하겠습니다.
그래픽 하드웨어와 API는 잠시 잊어 버리자. 흐름은 다음과 같아야합니다.
Your application (X Window System sees it as an "X Client")
↓ (sends requests defined by the X Window System Core Protocol)
X Server
↓ (convert your request to graphic commands)
[Probably] Operating System rendering API
↓
Windows or 2D images on your screen
X Window System을 사용할 때 화면과 응용 프로그램을 실행하는 컴퓨터는 "직접"연결되어 있지 않지만 네트워크를 통해 연결될 수 있습니다.
네 번째 시나리오 : 이전 예제에서 X 클라이언트 애플리케이션에 멋진 3D 그래픽 렌더링을 추가하려고한다고 가정하십시오. X Window System은 원래이 작업을 수행 할 수 없거나 적어도 OpenGL API 함수와 동등한 기능을 수행하려면 많은 복잡한 코드가 필요합니다.
다행히 GLX를 사용하여 OpenGL 명령에 대한 지원을 시스템에 추가 할 수 있습니다. 당신은 지금 :
Your application
↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
X Server with the GLX extension
↓ (convert your request to OpenGL commands)
OpenGL
↓ (redirects function calls to implementation defined by)
...
이제 첫 번째 시나리오에서 마지막 화살표를 "OpenGL"다음 화살표로 다시 연결할 수 있습니다. 화면에서 3D 이미지를 얻을 수 있습니다!
마지막으로 내가 DRI에 대해 이해하는 것에 대해 :
Mesa가 GPU에 액세스 할 수있게하여 첫 번째 시나리오의 흐름을 다음과 같이 수정합니다.
...
↓
Mesa
↓ (forwards OpenGL commands)
DRI
↓ (converts OpenGL commands to GPU commands)
Graphic Card
↓
3D Images on your screen
또한 서버와 클라이언트가 동일한 컴퓨터에 있고 GPU가 있다는 조건에서 GLX를 사용할 때 흐름을 단락시키는 것처럼 보입니다. 이 경우 네 번째 시나리오의 그래프는 단순히 다음과 같습니다.
Your application
↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
DRI
↓ ("catches" OpenGL commands and converts them to GPU commands)
Graphic Card
↓
3D Images on your screen
그게 다야!
이제 유닉스 환경의 전문가는 아니라는 점을 명심하십시오. 따라서 각 API의 문서를 연구하여 수행 할 수있는 작업을 정확하게 아는 것이 좋습니다.
이전 차트를 하나의 차트로 결합하면 이해하기가 더 쉬워 질 수 있습니다. 나는 당신에게 연습으로 보자!
OpenGL은 플랫폼에 구애받지 않습니다. 이는 OpenGL API가 플랫폼 독립적이라는 것을 의미합니다.
OpenGL 상태 및 버퍼는 일반적으로 컨텍스트라고하는 추상 객체에 의해 수집됩니다.
호스팅 플랫폼은 기본 플랫폼에 대한 OpenGL 컨텍스트를 작성하기위한 일부 API를 제공합니다. Windows에는 wgl * 루틴 (Windows for GL)이 있고 Unix에는 glX * 루틴 (GL for X)이 있습니다.
실제로 GLX는 OpenGL API를 사용하기 위해 애플리케이션이 OpenGL 컨텍스트를 작성할 수있게하는 API 일뿐입니다.
일반적인 WGL / GLX 작업은 창 생성, 오프 스크린 버퍼 생성, 스레드에서 OpenGL 컨텍스트를 현재로 설정, 그리기 버퍼 교체 등입니다.
대신 DRI는 XServer를 우회하여 그래픽 카드와 직접 통신 할 수있는 커널 계층으로, 실제로 OpenGL 루틴을 사용하여 응용 프로그램의 속도를 높입니다.
http://www.bitwiz.org.uk/s/how-dri-and-drm-work.html
DRI라고도하는 직접 렌더링 인프라는 X Window 시스템에서 안전하고 효율적인 방식으로 그래픽 하드웨어에 직접 액세스 할 수있는 프레임 워크입니다. X 서버, 여러 클라이언트 라이브러리 및 커널 (DRM, Direct Rendering Manager)에 대한 변경 사항이 포함됩니다. DRI의 가장 중요한 용도는 Mesa에 하드웨어 가속을 제공하는 빠른 OpenGL 구현을 만드는 것입니다. 3DFX, AMD (이전 ATI), Intel 및 Matrox에서 생산 된 칩셋 용 드라이버를 포함하여 여러 3D 가속 드라이버가 DRI 사양에 작성되었습니다.
간단히 말해 OpenGL은 그래픽 라이브러리 유형 및 사양입니다. 메사는 기본 암시입니다. DRI는 하드웨어 인터페이스 시스템입니다.
메사는 기본적으로 전체 프레임 워크를 나타냅니다. 그러나 Mesa 하드웨어 드라이버에 대해 말하고 있다고 가정합니다.
DRI는 기본적으로 하드웨어를 처리하기위한 커널 인터페이스입니다. 기술적으로 다른 용도로 사용될 수 있지만 Mesa 용으로 주로 Mesa 용으로 사용됩니다.
GLX는 X와의 모든 인터페이스 방법입니다 !!
각 부분이 무엇인지 이해하려면 그 부분이 어떻게 맞는지 알아야합니다.
프로그램은 모든 OpenGL 라이브러리와 인터페이스하도록 설계되었습니다.
GLX는 OpenGL을 X11과 인터페이스하거나 X11을 통해 인터페이스하는 수단입니다. "직접"인터페이스 또는 "간접"인터페이스가 있는지 여부에 따라 프로그램이이 문제에 대해 걱정하는지 여부에 따라 다릅니다.
libGL은 이것들에 대한 인터페이스입니다. Mesa 드라이버를 사용하는 경우 일반적으로 Mesa에서 제공합니다.
간접 설정에서는 다음과 같습니다. 응용 프로그램 프레임 워크 (예 : 하드 작성 응용 프로그램, 엔진 또는 추상화 API) | LibGL | 메사 드라이버 | DRI | 하드웨어
이 구성에서 GLX는 측면에서 사용되어 프로그램의 GL 사용과 다른 프로그램 간의 인터페이스를 처리합니다. X11 스택과의 통신이 필요한 작업을 수행하는 데 사용되는 GLX 전용 호출 외에 Window Manager와 같은 지원 프로그램 GLX는 거의 손대지 않습니다. 이 배열에서.
또한 명령 통과 및 공유 메모리를 사용하여이 시스템의 계층을 더욱 최적화 할 수 있습니다. 이는 대기 시간을 줄이고 하드웨어 액세스 속도를 향상시킵니다. 이것이 일반적으로 원하는 것입니다.
간접적으로 응용 프로그램 프레임 워크 | LibGL (사용자 측) | LibGLX | LibGL (X11 측면) | 메사 하드웨어 드라이버 | DRI | 하드웨어
이것의 장점은이 설정을 사용하기 위해 하드웨어와 직접 공유 메모리 버퍼가 필요하지 않다는 것입니다. (네트워크 클라이언트, 견고성 및 보안 설정 허용)
이 설정은 단일 비디오 카드를 공유하거나 이로 인해 네트워크를 통해 액세스하는 여러 VM에서 작동 할 수 있습니다. 새로운 확장 기능으로 인해 일부 형태의 공유 메모리 또는 가상 공유 "복제 된"메모리를 사용할 수 있지만 직접 렌더링 모드에서 볼 수있는 직접 비디오 메모리 액세스는 아닙니다.
단점은 X11과의 인터페이스에 파이프 또는 네트워크 소켓을 사용하면 최적화가 잘 된 프로그램에서 대기 시간이 최소화 될 수 있으며, 최적화되지 않은 프로그램에서는 프레임 속도가 크게 저하 될 수 있다는 점입니다.
네트워크 클라이언트,보다 강력한 보안이 필요한 설정 및 동일한 GL 스택을 통해 여러 운영 체제가 하드웨어를 공유해야하는 설정에 적합합니다. 최적의 거리는 아니지만 어느 정도의 하드웨어 가속을 제공합니다.