Что на самом деле делает LIBGL_ALWAYS_INDIRECT = 1?

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

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

Я решил, что это самый простой и лучший метод. Но я не знаю, что это делает или как это влияет на мою систему. Это медленнее, чем по умолчанию? я должен помнить, чтобы следить за проблемой и отключить ее позже, как только это будет исправлено?

Косвенный рендеринг означает, что протокол GLX будет использоваться для передачи команд OpenGL, а X.org будет выполнять реальное рисование.

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

Прямой рендеринг быстрее, так как не требует изменения контекста в процессе X.org.

Пояснение: в обоих случаях рендеринг выполняется графическим процессором (или технически - может выполняться графическим процессором). Однако при косвенном рендеринге процесс выглядит так:

1. Программа вызывает команду (ы)
2. Команды отправляются на X.org по протоколу GLX
3. X.org вызывает аппаратное обеспечение (т. Е. Графический процессор) для рисования

В прямом рендеринге

1. Программа вызывает команду (ы)
2. Команда (и) отправлена ​​/ отправлена ​​в графический процессор

Обратите внимание, что, поскольку 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), либо позволяет избежать других ошибок.

Определенно вы хотите удалить этот флаг, когда основная проблема устранена.