OpenGL 자체는 프론트 엔드 API 일 뿐이며 구현이 사양을 준수하고 결과가 이에 부합하는 한 원하는 방식으로 수행 할 수 있기 때문에이 질문에 답하기가 거의 불가능합니다.
질문은 다음과 같을 수 있습니다. OpenGL 드라이버가 최하위 수준에서 어떻게 작동합니까? 이제 드라이버가 일부 하드웨어에 밀접하게 연결되어 있기 때문에 일반적으로 대답 할 수 없습니다. 개발자가 설계 한대로 작업을 다시 수행 할 수 있습니다.
따라서 질문은 "OpenGL과 그래픽 시스템 뒤에서 평균적으로 어떻게 보이는가?"여야합니다. 아래에서 위로 살펴 보겠습니다.
가장 낮은 수준에는 일부 그래픽 장치가 있습니다. 요즘 이들은 동작을 제어하는 레지스터 세트 (정확히 장치에 따라 달라짐)를 제공하는 GPU로 셰이더 용 프로그램 메모리, 입력 데이터 (정점, 텍스처 등) 용 대량 메모리 및 나머지에 대한 I / O 채널이 있습니다. 데이터 및 명령 스트림을 수신 / 전송하는 시스템의.
그래픽 드라이버는 GPU 상태 및 GPU를 사용하는 모든 리소스 응용 프로그램을 추적합니다. 또한 응용 프로그램에서 보낸 데이터를 변환하거나 다른 처리를 담당합니다 (텍스처를 GPU에서 지원하는 픽셀 형식으로 변환하고 GPU의 기계어 코드에서 셰이더를 컴파일합니다). 또한 응용 프로그램에 대한 추상적 인 드라이버 종속 인터페이스를 제공합니다.
그런 다음 드라이버 종속 OpenGL 클라이언트 라이브러리 / 드라이버가 있습니다. Windows에서는 opengl32.dll을 통해 프록시에 의해로드되며 Unix 시스템에서는 다음 두 위치에 있습니다.
- X11 GLX 모듈 및 드라이버 종속 GLX 드라이버
- 및 /usr/lib/libGL.so에는 직접 렌더링을위한 드라이버 종속 항목이 포함될 수 있습니다.
MacOS X에서 이것은 "OpenGL 프레임 워크"입니다.
OpenGL 호출을 (2)에 설명 된 드라이버 부분의 드라이버 특정 기능에 대한 호출로 변환하는 것은이 부분입니다.
마지막으로 실제 OpenGL API 라이브러리, Windows의 opengl32.dll 및 Unix /usr/lib/libGL.so; 이것은 대부분 명령을 OpenGL 구현에 적절하게 전달합니다.
실제 의사 소통이 어떻게 발생하는지 일반화 할 수 없습니다.
Unix에서 3 <-> 4 연결은 소켓 (예, 원하는 경우 네트워크를 통해) 또는 공유 메모리를 통해 발생할 수 있습니다. Windows에서 인터페이스 라이브러리와 드라이버 클라이언트는 둘 다 프로세스 주소 공간에로드되므로 그렇게 많은 통신이 아니라 간단한 함수 호출과 변수 / 포인터 전달입니다. MacOS X에서 이것은 Windows와 유사합니다. 단지 OpenGL 인터페이스와 드라이버 클라이언트 사이에 분리가 없다는 점만 있습니다 (MacOS X가 새로운 OpenGL 버전을 따라 잡는 데 너무 느리기 때문에 항상 새로운 버전을 제공하려면 전체 운영 체제 업그레이드가 필요합니다.) 뼈대).
3 <-> 2 사이의 통신은 ioctl, 읽기 / 쓰기 또는 일부 메모리를 프로세스 주소 공간에 매핑하고 해당 메모리가 변경 될 때마다 일부 드라이버 코드를 트리거하도록 MMU를 구성 할 수 있습니다. 이것은 커널 / 유저 랜드 경계를 항상 넘어야하기 때문에 모든 운영 체제에서 매우 유사합니다. 궁극적으로 시스템 호출을 거치게됩니다.
시스템과 GPU 간의 통신은 주변 버스와 정의 된 액세스 방법을 통해 이루어집니다. 따라서 PCI, AGP, PCI-E 등은 Port-I / O, Memory Mapped I / O, DMA, IRQ를 통해 작동합니다.