Как работает интерфейс программы OpenGL с разными графическими картами

Question

Из того, что я понимаю (исправьте меня, если я ошибаюсь), OpenGL api преобразует вызовы функций, написанные программистом в исходном коде, в конкретные вызовы драйвера gpu нашей графической карта. Затем драйвер gpu может действительно отправлять инструкции и данные на графическую карту через некоторый аппаратный интерфейс, такой как PCIe, AGP или PCI.

Мой вопрос в том, что openGL знает, как взаимодействовать с разными графическими картами, поскольку в основном существуют только 3 типа физических соединений (PCIe, AGP и PCI)?

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

Я просто не получаю большую картину.

Answer 1

Это копия my answer на вопрос "How does OpenGL work at the lowest level?" (вопрос помечен для удаления, поэтому я добавляю некоторую избыточность здесь).

---

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

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

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

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

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

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

   • X11 GLX модуль и драйвер зависит драйвер GLX
   • и /usr/lib/libGL.so может содержать некоторые связанные с драйвером материалы для прямого рендеринга

   На MacOS X это, оказывается, «OpenGL Framework».

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

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

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

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

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

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