На этот вопрос практически невозможно ответить, потому что 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.