За исключением 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, чтобы точно знать, что они могут делать.
Объединение предыдущего графика в один может облегчить понимание. Я позволил вам это как упражнение!
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.
источник
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.
источник
Проще говоря, 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. Это далеко не оптимально, но дает некоторую степень аппаратного ускорения.
источник