Що насправді робить LIBGL_ALWAYS_INDIRECT = 1?

У KDE SC 4.5.0 є деякі проблеми з деякими відеокартами, включаючи мою. Після звільнення Arch рекомендував кілька способів вирішення . Один з яких був

експортувати "LIBGL_ALWAYS_INDIRECT = 1" перед запуском KDE

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

Непряме візуалізація означає, що протокол GLX буде використовуватися для передачі команд OpenGL, а X.org виконає реальний малюнок.

Пряме візуалізація означає, що програма може отримати доступ до обладнання безпосередньо без зв'язку з X.org спочатку через mesa.

Пряме візуалізація відбувається швидше, оскільки не вимагає зміни контексту в процесі X.org.

Уточнення: в обох випадках надання здійснюється GPU (або технічно - це може здійснювати GPU). Однак у непрямому візуалізації процес виглядає так:

1. Програма викликає команди (и)
2. Команди (и) надсилаються на X.org за протоколом GLX
3. X.org закликає апаратно (тобто GPU) малювати

При прямій візуалізації

1. Програма викликає команди (и)
2. Команди (и) надсилаються до GPU

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

По-перше, LIBGL_ALWAYS_INDIRECTце прапор, пов'язаний з реалізацією OpenGL на стороні клієнта Mesa 3D (libGL.so). Він не працюватиме з бінарними драйверами інших постачальників (наприклад, NVIDIA).

По-друге, щоб відповісти прямо на ваше запитання, востаннє я подивився на код Mesa, прапор працює так:

До ~ 2008 року, коли Mesa працював з непрямим сервером X (наприклад, ви зробили ssh -Xабо явно встановив ваш дисплей на не локальний сервер), це зробить список графічних зображень GLX, наданих віддаленим сервером X, доступним для вашої програми GLX. Виклики програми, наприклад, glXChooseVisual () та Mesa знайдуть щось розумне для узгодження, а наступні glFoo()дзвінки будуть відправлені на віддалений сервер X, де вони виконуються будь-яким libGL, до якого підключений віддалений сервер X (швидше за все, ваш GPU).

Наприкінці 2008 року Mesa було змінено настільки, що він хотів використовувати свій внутрішній програмний рендер OpenGL ( драйвер Xlib ) для віддалених підключень X. (Деякі дистрибутиви на зразок SuSE спеціально зафіксували це, щоб повернутися до старої поведінки.) Це спричинило б лише, якщо віддалений сервер X запропонував GLX-візуальне зображення, що точно відповідає одному із внутрішніх програмного рендерінгу. (В іншому випадку ви отримаєте загальне: " Помилка: не вдалося отримати RGB, подвійний буфер візуального ".) Якщо такий візуальний файл був знайдений, Mesa видасть усі glFoo()команди з локальним (для додатків) процесором і натисне результат на віддалений сервер X через растрові зображення ( XPutImage()); Налаштування LIBGL_ALWAYS_INDIRECT=1(до Mesa 17.3 будь-яке значення спрацювало б, оскільки тоді ви повинні використовувати 1 або true) повідомляє Mesa ігнорувати звичайну пряму візуалізацію або внутрішній програмний рендер і використовувати непряме візуалізацію, як раніше.

Вибір непрямої візуалізації або прямого програмного відображення вплине на дві речі:

Версія OpenGL

• Непряме візуалізація, як правило, обмежується OpenGL 1.4.
• Пряме візуалізація програмного забезпечення підтримуватиме все, що підтримує растерзатор програмного забезпечення Mesa, можливо, OpenGL 2.1+

Продуктивність

• Якщо ваша програма призначена для непрямих з'єднань (вона використовує списки дисплеїв, мінімізує запити в обидва кінці), ви можете отримати розумну ефективність.
• Якщо ваша програма робить щось нерозумно, як glGetInteger()100 разів на кадр, то навіть у швидкій локальній мережі кожен із цих запитів може зайняти 1 мс, або загалом 100 мс на кадр, тобто ви ніколи не зможете отримати більше 10 FPS у вашій програмі.
• Цей самий додаток, якщо навантаження рендерінгу не надто важке, може спрацювати дуже добре при прямому програмному відтворенні, оскільки всі ці glGetInteger()дзвінки відповідають безпосередньо через мікро або наносекунд.
• Якщо ваша програма створює мільйонний список вершин, а потім робить багато обертових, то непряме візуалізація з реальним графічним процесором на іншому кінці дасть набагато кращі показники.
• Додаток також може повернутися до іншого кодового шляху, коли він має лише OpenGL 1.4 проти 2.x, що також може вплинути на продуктивність.

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

У вашому випадку здається, що ви використовуєте локальний екземпляр kwin, тому ефект LIBGL_ALWAYS_INDIRECTполягає в тому, щоб змусити непряме візуалізацію на ваш локальний X-сервер. Це, очевидно, або змінює kwinповедінку (лише OpenGL 1.4), або уникає інших помилок.

Безумовно, ви хочете видалити цей прапор, коли основну проблему виправлено.