Как GPU поддерживают как OpenGL, так и DirectX API?

Я пытаюсь понять, как OpenGL и DirectX работают с графической картой.

Если я пишу программу в OpenGL, которая делает треугольник, а другая в DirectX, которая делает то же самое, что именно происходит с стороной GPU?

При запуске программы каждый вызов библиотеки OpenGL и каждый вызов библиотеки DirectX будут генерировать код для графического процессора, а машинный код GPU, созданный из двух программ, будет таким же? (Например, если DirectX и OpenGL похожи на Java Bytecode, предварительно скомпилированные, то, когда он фактически работает, он создает одно и то же)

Или у GPU есть 2 разных набора команд, по одному для каждого. Я имею в виду, что отличает OpenGL и DirectX для графического процессора, как он может различать два API?

Разве это отличается от перспективы программиста?

Ответ 1

Я уже ответил тем, что здесь В Windows, как OpenGL отличается от DirectX?

полная цитата из одного из ответов следует

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

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

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

На самом низком уровне есть какое-то графическое устройство. В настоящее время это графические процессоры, которые предоставляют набор регистров, контролирующих их работу (которые точно регистрируются на устройстве) имеют некоторую программную память для шейдеров, объемную память для входных данных (вершин, текстур и т.д.) И канал ввода-вывода для остальных системы, в которой он получает/отправляет данные и командные потоки.
Графический драйвер отслеживает состояние GPU и все прикладные программы ресурсов, которые используют графический процессор. Также он отвечает за преобразование или любую другую обработку данных, отправленных приложениями (преобразовать текстуры в пиксельный формат, поддерживаемый графическим процессором, компилировать шейдеры в машинный код графического процессора). Кроме того, он предоставляет некоторые абстрактные, зависимые от драйверов интерфейсы для прикладных программ.
Затем есть драйверная библиотека/драйвер 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, всегда требует полного обновления операционной системы для доставки нового рамки).

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

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