Який взаємозв'язок між OpenGL, GLX, DRI та Mesa3D?


17

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

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

То куди підходять GLX та DRI? Копаючись у Вікіпедії та на всіх цих веб-сайтах, я ще не знайшов пояснення, як все це відбувається разом. Де відбувається прискорення обладнання? Що з цим мають стосуватися власні драйвери?

Відповіді:


15

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

Вам здається правильним щодо Меси. Ось додаткова інформація, яку ми маємо:

"Система вікон X - це система комп'ютерного програмного забезпечення та мережевий протокол, що забезпечує основні графічні інтерфейси для мережевих комп'ютерів. Вона створює апаратний рівень абстракції."

"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-віконну систему, чи працює "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 System або, принаймні, як я вважаю, на основі кількох прочитаних рядків Вікіпедії.
Давайте забудемо про графічне обладнання та 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, ваш екран та комп'ютер, з якого ви запускаєте свою програму, можуть бути не «підключені» безпосередньо, але можуть бути підключені через мережу.

Четвертий сценарій: припустимо, ви хочете додати фантазійні 3D-графічні візуалізації до своєї програми X Client із попереднього прикладу. Мені здається, що система X Window спочатку не спроможна цього зробити, або, принаймні, це вимагало б багато перекрученого коду для виконання еквівалента функції OpenGL API.
На щастя, ви можете використовувати 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 отримати доступ до GPU, щоб це змінило потік нашого першого сценарію в:

...
  ↓
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, щоб точно знати, що вони можуть зробити.
Поєднання попереднього діаграми в єдиний може полегшити розуміння. Я дозволю це як вправу для вас!


1
це лише теорія, заснована на дедукції з кількох речень. це не правда.
KawaiKx

8

OpenGL - це агностик платформи; це означає, що API OpenGL не залежить від платформи.

Стани та буфери OpenGL збираються абстрактним об'єктом, який зазвичай називають контекстом.

Хостинг-платформа несе відповідальність за надання деякого API для створення контексту OpenGL для базової платформи. У Windows є wgl * підпрограми (Windows для GL), у Unix є glX * підпрограми (GL для X).

Дійсно, GLX - це не що інше, як API, який дозволяє додатку створювати OpenGL контекст для того, щоб використовувати OpenGL API.

Поширені операції WGL / GLX - це створення вікна, створення буфера поза екраном, зробити контекст OpenGL поточним на потоці, поміняти буфери малювання ...

Натомість DRI - це шар ядра, який дозволяє безпосередньо спілкуватися з графічною картою, минаючи XServer, дійсно прискорюючи додаток за допомогою процедур OpenGL.


3

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

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


2

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

Меса в основному відноситься до всього фреймворку. Однак я припускаю, що ви говорите про апаратний драйвер Mesa.

DRI - це в основному інтерфейс ядра для обробки обладнання. Це технічно можна використовувати для інших речей, але він був зроблений для Меси і в основному використовується для Меси.

GLX - це все, що інтерфейс для X !!

Щоб зрозуміти, що таке кожна частина, ти повинен знати, як вона поєднується.

Програма призначена для взаємодії з будь-якою бібліотекою openGL.

GLX - це засіб взаємодії OpenGL з X11 або через нього. Залежно від того, чи є у вас "Прямий" інтерфейс або "Непрямий" інтерфейс, залежить, чи буде ваша програма перейматися цим.

Інтерфейс для них є libGL. Зазвичай надається Mesa, якщо ви використовуєте драйвер Mesa.

У непрямому налаштуванні він іде наступним чином: Application Framework (тобто жорстко написаний додаток, двигун чи абстракція API) | LibGL | Mesa Driver | DRI | Обладнання

У цій конфігурації GLX просто використовується на боці для обробки взаємозв'язку між використанням програми GL та вашими іншими програмами. За винятком специфічних GLX-дзвінків, які використовуються для того, щоб вимагати зв’язку стека X11, і його програм підтримки (таких як менеджери вікон) GLX багато в чому не стосується. у цій домовленості.

Крім того, для подальшої оптимізації шарів у цій системі можна використовувати команду проходження та загальну пам'ять. Це все зменшує затримки та покращує швидкість доступу до обладнання. Це те, чого ти зазвичай хочеш.

Для непрямого - це Ваша Прикладна Рамка | LibGL (сторона користувача) | LibGLX | LibGL (сторона X11) | Драйвер апаратного забезпечення Mesa | DRI | Обладнання

Перевагою цього є те, що для використання цієї установки вам не потрібен прямий буфер спільної пам’яті з обладнанням. (Дозвіл для мережевих клієнтів, а також більш надійність та більш безпечне налаштування.)

Ця установка може працювати через декілька віртуальних машин, які обмінюються однією відеокарткою або навіть доступ через мережу через це. Деякі форми спільної пам’яті або віртуальної спільної «клонованої» пам’яті можуть використовуватися за рахунок більш нових розширень, але це не прямий доступ до відеопам'яті, знайдений у режимі прямого візуалізації.

Недоліком є ​​те, що використання трубопроводів або мережевих розеток для взаємодії з X11 може бути повільним, як мінімум, впроваджуючи затримки в добре оптимізованих програмах, і в гіршому випадку, різко знижуючи частоту кадрів на погано оптимізованих.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.