На це питання майже неможливо відповісти, оскільки OpenGL сам по собі є лише інтерфейсним API, і доки реалізація дотримується специфікації, а результат відповідає цьому, це можна зробити будь-яким способом.
Можливо, запитання було: як працює драйвер OpenGL на найнижчому рівні? Зараз на це знову неможливо відповісти загалом, оскільки драйвер тісно пов’язаний з якоюсь апаратною частиною, яка може знову робити те, що розробник розробив.
Тож питання мало бути: "Як це виглядає в середньому за лаштунками OpenGL та графічної системи?". Давайте подивимось на це знизу вгору:
На найнижчому рівні є якийсь графічний пристрій. На сьогоднішній день це графічні процесори, які забезпечують набір регістрів, що контролюють їх роботу (які регістри точно залежать від пристрою), мають деяку програмну пам'ять для шейдерів, об'ємну пам'ять для вхідних даних (вершини, текстури тощо) та канал вводу-виводу для решти системи, через яку він отримує / надсилає потоки даних та команд.
Графічний драйвер відстежує стан графічних процесорів і всі прикладні програми, що використовують графічний процесор. Також він відповідає за перетворення або будь-яку іншу обробку даних, надісланих програмами (перетворення текстур у піксельний формат, що підтримується графічним процесором, компіляція шейдерів у машинному коді графічного процесора). Крім того, він надає деякий абстрактний, залежний від драйвера інтерфейс для прикладних програм.
Потім є драйверна бібліотека / драйвер OpenGL клієнта. У Windows це завантажується через проксі через opengl32.dll, в системах Unix це знаходиться в двох місцях:
- Модуль X11 GLX та драйвер GLX, що залежать від драйвера
- та /usr/lib/libGL.so може містити деякі матеріали, що залежать від драйвера, для прямого візуалізації
У MacOS X це "OpenGL Framework".
Саме ця частина перекладає виклики OpenGL, як ви це робите, у виклики специфічних для драйвера функцій у частині драйвера, описаній у (2).
Нарешті, фактична бібліотека API OpenGL, opengl32.dll в Windows та на Unix /usr/lib/libGL.so; це переважно просто передає команди власне реалізації OpenGL.
Те, як відбувається фактичне спілкування, не можна узагальнити:
У Unix підключення 3 <-> 4 може відбуватися або через сокети (так, може, і переходить через мережу, якщо ви цього хочете), або через спільну пам'ять. У Windows бібліотека інтерфейсу та клієнт драйвера завантажуються в адресний простір процесу, тому це не стільки спілкування, скільки прості виклики функцій та передача змінних / покажчиків. У MacOS X це схоже на Windows, тільки в тому, що між інтерфейсом OpenGL та клієнтом драйвера немає розділення (саме тому MacOS X так повільно йде в ногу з новими версіями OpenGL, що завжди потрібно повне оновлення операційної системи, щоб доставити нову рамки).
Зв'язок між 3 <-> 2 може проходити через ioctl, читати / писати або через відображення деякої пам'яті в адресний простір процесу та налаштування MMU для запуску деякого коду драйвера щоразу, коли вносяться зміни до цієї пам'яті. Це дуже схоже на будь-яку операційну систему, оскільки вам завжди потрібно переходити межу ядра / країни користувача: Зрештою, ви проходите певний системний виклик.
Зв'язок між системою та графічним процесором відбувається через периферійну шину та способи доступу, які вона визначає, отже, PCI, AGP, PCI-E тощо, які працюють через порти-входи / виходи, введені / виведені в пам'ять введення-виведення, DMA, IRQ.