Каковы отношения между OpenGL, GLX, DRI и Mesa3D?

17

Я начинаю заниматься низкоуровневым 3D-программированием в Linux. У меня большой опыт использования графического API более высокого уровня OpenInventor.

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

Так где же подходят GLX и DRI? Покопавшись в Википедии и на всех этих сайтах, мне еще предстоит найти объяснение, как именно все это сочетается. Где происходит аппаратное ускорение? При чем здесь проприетарные драйверы?

ТТВ
источник

Ответы:

15

За исключением OpenGL, я никогда не использовал эти библиотеки, но я попытаюсь угадать, читая страницы википедии, как вы.

Вы правы насчет Мезы. Вот дополнительная информация, которую мы имеем:

«Система X Window представляет собой компьютерную программную систему и сетевой протокол, который обеспечивает базовые графические интерфейсы для сетевых компьютеров. Он создает уровень абстрагирования оборудования».

«GLX позволяет программам, желающим использовать OpenGL, делать это в пределах окна, предоставляемого системой X Window.
GLX состоит из трех частей:
- API, обеспечивающий функции OpenGL.
- Расширение протокола X, которое позволяет клиенту отправлять 3D команды рендеринга - расширение X-сервера, которое получает команды рендеринга от клиента и передает их в установленную библиотеку OpenGL.
Если клиент и сервер работают на одном компьютере и доступна ускоренная 3D-видеокарта, первые два компонента могут быть обойденным DRI. Клиентской программе тогда разрешен прямой доступ к графическому оборудованию. "

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

«Open Inventor - это C ++ 3D графический API, разработанный для обеспечения более высокого уровня программирования для OpenGL»

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

Есть несколько случаев, на которые я
возьму ответы на эти вопросы: - есть ли на вашем компьютере графическая карта (GPU) или только процессор для обработки графических функций?
- Ваше приложение встроено в окно системы x-window?
-если вы используете систему x window, работает ли «сервер x» на вашем компьютере или на другом компьютере в сети?
Я предполагаю, что у вас есть драйверы для вашего GPU, если у вас есть, и что у вас есть Mesa для рендеринга программного обеспечения).

Первый сценарий: вы запускаете графическое приложение, написанное с помощью OpenInventor, без использования X Window System, и у вас нет графической карты. Ход программы будет очень похож на:

Your application
  ↓ (uses functions of)
OpenInventor
  ↓ (calls functions declared by)
OpenGL
  ↓ (redirects function calls to implementation defined by)
Mesa
  ↓ (implemented OpenGL functions to be run on the CPU)
[Probably] Operating System rendering API
  ↓
3D Images on your screen

То, что здесь происходит, называется «программным рендерингом»: графические команды не обрабатываются никаким графическим оборудованием, а вместо этого - вашим обычным процессором, процессором, который обычно запускает программное обеспечение.

Второй сценарий: теперь представьте, что при тех же условиях, что и выше, у вас есть графическая карта. Поток будет выглядеть примерно так:

Your application
  ↓ (uses functions of)
OpenInventor
  ↓ (calls functions declared by)
OpenGL
  ↓ (redirects function calls to implementation defined by)
Proprietary Drivers
  ↓ (converts OpenGL commands to GPU commands)
Graphic Card
  ↓
3D Images on your screen

То, что происходит сейчас, называется «аппаратным ускорением», обычно быстрее, чем в первом сценарии.

Третий сценарий: теперь давайте представим поток системы X Window, или, по крайней мере, как я думаю, основываясь на нескольких строках Википедии, которые я прочитал.
Давайте на время забудем о графическом оборудовании и API. Поток должен выглядеть так:

Your application (X Window System sees it as an "X Client")
  ↓ (sends requests defined by the X Window System Core Protocol)
X Server
  ↓ (convert your request to graphic commands)
[Probably] Operating System rendering API
  ↓
Windows or 2D images on your screen

Обратите внимание, что при использовании X Window System ваш экран и компьютер, с которого вы запускаете приложение, могут быть не «подключены напрямую», а могут быть подключены через сеть.

Четвертый сценарий: предположим, что вы хотите добавить причудливую трехмерную графику в приложение X Client из предыдущего примера. Мне кажется, что система X Window изначально не способна сделать это, или, по крайней мере, для выполнения эквивалента функции API OpenGL потребуется много сложного кода.
К счастью, вы можете использовать GLX для добавления поддержки команд OpenGL в систему. Теперь у вас есть:

Your application
  ↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
X Server with the GLX extension
  ↓ (convert your request to OpenGL commands)
OpenGL
  ↓ (redirects function calls to implementation defined by)
 ...

Теперь вы можете подключить эту последнюю стрелку к той, которая после «OpenGL» в первом сценарии: вы можете получить 3D изображения на вашем экране!

Напоследок о том, что я думаю о DRI:
кажется, что Mesa имеет доступ к графическому процессору, так что это изменило бы поток нашего первого сценария на:

...
  ↓
Mesa
  ↓ (forwards OpenGL commands)
DRI
  ↓ (converts OpenGL commands to GPU commands)
Graphic Card
  ↓
3D Images on your screen

Кроме того, кажется, что это приводит к короткому замыканию потока при использовании GLX, учитывая, что его сервер и клиент находятся на одном компьютере и у вас есть графический процессор. В этом случае график нашего четвертого сценария просто станет:

Your application
  ↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
DRI
  ↓ ("catches" OpenGL commands and converts them to GPU commands)
Graphic Card
  ↓
3D Images on your screen

Это оно !
Имейте в виду, что я не специалист в среде Unix, поэтому мой лучший совет - изучить документацию каждого из этих API, чтобы точно знать, что они могут делать.
Объединение предыдущего графика в один может облегчить понимание. Я позволил вам это как упражнение!

WIP
источник
1
это просто теория, основанная на выводе из нескольких предложений. это не правда
KawaiKx
8

OpenGL не зависит от платформы; это означает, что OpenGL API не зависит от платформы.

Состояния и буферы OpenGL собираются абстрактным объектом, обычно называемым контекстом.

Платформа хостинга отвечает за предоставление некоторого API для создания контекста OpenGL для базовой платформы. В Windows есть подпрограммы wgl * (Windows для GL), в Unix - подпрограммы glX * (GL для X).

Действительно, GLX - это не что иное, как API, который позволяет приложению создавать контекст OpenGL, чтобы использовать API OpenGL.

Обычные операции WGL / GLX - это создание окна, создание внеэкранного буфера, создание контекста OpenGL в потоке, замена буферов рисования ...

Вместо этого DRI - это уровень ядра, который позволяет напрямую взаимодействовать с графической картой, минуя XServer, действительно ускоряя приложение, используя подпрограммы OpenGL.

Лука
источник
3

http://www.bitwiz.org.uk/s/how-dri-and-drm-work.html

Инфраструктура прямого рендеринга, также известная как DRI, является платформой, обеспечивающей безопасный и эффективный прямой доступ к графическому оборудованию в системе X Window. Он включает в себя изменения X-сервера, нескольких клиентских библиотек и ядра (DRM, Direct Rendering Manager). Наиболее важным применением DRI является создание быстрых реализаций OpenGL, обеспечивающих аппаратное ускорение для Mesa. Несколько 3D-ускоренных драйверов были написаны для спецификации DRI, включая драйверы для чипсетов производства 3DFX, AMD (ранее ATI), Intel и Matrox.

KawaiKx
источник
2

Проще говоря, OpenGL - это тип и спецификация графической библиотеки. Меса является базовой имплиментацией. DRI - это система аппаратного интерфейса.

Меза в основном относится ко всей структуре. Тем не менее, я предполагаю, что вы говорите о драйвере аппаратного обеспечения Mesa.

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

GLX - это то, как все это взаимодействует с X !!

Чтобы понять, что такое каждая часть, вы должны знать, как она сочетается друг с другом.

Программа предназначена для взаимодействия с любой библиотекой openGL.

GLX - это средство для взаимодействия OpenGL с X11 или через него. В зависимости от того, есть ли у вас «прямой» интерфейс или «косвенный» интерфейс, зависит, будет ли ваша программа беспокоиться об этом.

libGL в значительной степени является интерфейсом для них. Обычно он предоставляется Mesa, если вы используете драйвер Mesa.

При косвенной настройке это происходит следующим образом: Application Framework (т. Е. Жестко написанное приложение, Engine или Abstraction API) | LibGL | Меса Драйвер | DRI | аппаратные средства

В этой конфигурации GLX просто используется на стороне для управления взаимодействием между использованием GL вашей программы и другими программами. Помимо вызовов, специфичных для GLX, используемых для выполнения задач, требующих взаимодействия стека X11 и его программ поддержки (таких как Window Manager), GLX в основном не затронут. в этой договоренности.

Кроме того, сквозная передача команд и общая память могут использоваться для дальнейшей оптимизации слоев в этой системе. Все это уменьшает задержки и повышает скорость доступа к оборудованию. Это то, что вы обычно хотите.

Для стороннего - это Your Application Framework | LibGL (сторона пользователя) | LibGLX | LibGL (сторона X11) | Mesa Аппаратный драйвер | DRI | аппаратные средства

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

Из-за этого эта настройка может работать на нескольких виртуальных машинах, совместно использующих одну видеокарту или даже имеющих доступ к сети. Некоторые формы разделяемой памяти или виртуальной разделяемой «клонированной» памяти могут использоваться из-за более новых расширений, но это не прямой доступ к видеопамяти, обнаруживаемый в режиме прямого рендеринга.

Недостатком является то, что использование каналов или сетевых сокетов для взаимодействия с X11 может быть медленным, по крайней мере, вносить задержки в хорошо оптимизированные программы и, в худшем случае, резко снижать частоту кадров в плохо оптимизированных.

Этот тип настройки лучше подходит для сетевых клиентов, для установок, требующих более надежной защиты, и для установок, в которых нескольким операционным системам необходимо совместно использовать оборудование, используя один и тот же стек GL. Это далеко не оптимально, но дает некоторую степень аппаратного ускорения.

Роберт Вм Рудисуэли
источник