Как OpenGL работает на самом низком уровне? [закрытый]

на этот вопрос почти невозможно ответить, потому что OpenGL сам по себе является только интерфейсным API, и до тех пор, пока реализация придерживается спецификации и результат соответствует этому, это можно сделать любым способом.

вопрос, возможно, был: как работает драйвер OpenGL на самом низком уровне. Теперь это снова невозможно ответить в целом, так как драйвер тесно связан с какой-то аппаратной частью, которая может снова делать вещи, однако разработчик разработал оно.

поэтому вопрос должен был быть: "как это выглядит в среднем за кулисами OpenGL и графической системы?". Давайте посмотрим на это снизу вверх:

1. на самом низком уровне есть некоторые графические устройства. В настоящее время это графические процессоры, которые обеспечивают набор регистров, контролирующих их работу (какие именно регистры зависят от устройства), имеют некоторую программную память для шейдеров, объемную память для входных данных (вершины, текстуры и т. д.) и I / O канал к остальной части системы, по которой он получает / отправляет потоки данных и команд.

2. графический драйвер отслеживает состояние графических процессоров и все прикладные программы ресурсов, которые используют графический процессор. Также он отвечает за преобразование или любую другую обработку данных, отправляемых приложениями (преобразование текстур в пиксельформат, поддерживаемый графическим процессором, компиляция шейдеров в машинный код графического процессора). Кроме того, он предоставляет некоторые абстрактные, зависимые от драйвера интерфейс к прикладным программам.

3. тогда есть зависимая от драйвера клиентская библиотека OpenGL / драйвер. На Windows это получает загружается по прокси через opengl32.dll, в системах Unix это находится в двух местах:

   • Х11 комплектации GLX модуль и драйвер зависит от водителя ГБО
   • и /usr / lib / libGL. so может содержать некоторые зависимые от драйвера вещи для прямого рендеринга

   на MacOS X это бывает " OpenGL Рамки."

   именно эта часть переводит вызовы OpenGL, как вы это делаете, в вызовы определенных функций драйвера в части драйвера, описанной в (2).

4. наконец, фактическая библиотека API OpenGL, opengl32.dll в Windows, и на Unix /usr/lib/libGL.so; это в основном просто передает команды к реализации OpenGL собственно.

Как происходит фактическое общение не может быть обобщенный:

в Unix соединение 34 может происходить либо через сокеты (да, это может быть и происходит по сети, Если вы хотите), либо через общую память. В Windows библиотека интерфейса и клиент драйвера загружаются в адресное пространство процесса, так что это не так много общения, но простые вызовы функций и передача переменных/указателей. В MacOS X это похоже на Windows, только что нет разделения между интерфейсом OpenGL и клиентом драйвера (вот почему почему MacOS X так медленно идет в ногу с новыми версиями OpenGL, он всегда требует полного обновления операционной системы для доставки новой платформы).

связь между 3 2 может проходить через ioctl, чтение/запись или через отображение некоторой памяти в адресное пространство процесса и настройку MMU для запуска некоторого кода драйвера при каждом изменении этой памяти. Это очень похоже на любую операционную систему, так как вам всегда нужно пересекать границу ядра/пользователя: в конечном итоге вы идете через некоторые операции.

связь между системой и GPU происходит через периферийную шину и методы доступа, которые она определяет, поэтому PCI, AGP, PCI-E и т. д., которые работают через порт-I/O, память, отображенную I/O, DMA, IRQs.