Линукс для гибридной графики

Hybrid graphics

Hybrid-graphics is a concept involving two graphics cards on same computer. Laptop manufacturers have developed new technologies involving two graphic cards with different abilities and power consumptions on a single computer. Hybrid-graphics has been developed to support both high performance and power saving use cases.

There are a variety of technologies and each manufacturer developed its own solution to this problem. This technology is well supported on Windows but it’s still quite experimental with Linux distributions. Here we try to explain a little about each approach and describe some community solutions to the lack of GNU/Linux systems support.

Contents

First Generation Hybrid Model (Basic Switching)

This section is being considered for removal.

The first generation of notebooks with hybrid graphics follow an approach that involves a two graphic card setup with a hardware multiplexer (MUX). It allows power save and low-end 3D rendering by using an Integrated Graphics Processor (IGP) or a major power consumption with 3D rendering performance using a Dedicated/Discrete Graphics Processor (DGP). This model makes the user choose (at boot time or at login time) between the two power/graphics profiles and is almost fixed throughout the user session. The switch is done in a workflow similar to the following:

• Turn off the display
• Turn on the DGP
• Switch the multiplexer
• Turn off the IGP
• Turn the display on again

This switch is somewhat rough and adds some blinks and black screens in laptops that could do it «on the fly». Later approaches made the transition a little more user-friendly.

Dynamic Switching Model

Most of the new Hybrid-graphics technologies involve two graphic cards as the basic switching but now the DGP and IGP are plugged to a framebuffer and there is no hardware multiplexer. The IGP is always on and the DGP is switched on/off when there is a need in power-save or performance-rendering. In most cases there is no way to use only the DGP and all the switching and rendering is controlled by software. At startup, the Linux kernel starts using a video mode and setting up low-level graphic drivers which will be used by the applications. Most of the Linux distributions then use X.org to create a graphical environment. Finally, a few other softwares are launched, first a login manager and then a window manager, and so on. This hierarchical system has been designed to be used in most of cases on a single graphic card.

Fully Power Down Discrete GPU

You may want to turn off the high-performance graphics processor to save battery power.

Using bbswitch

With an NVidia GPU, this can be more safely done using bbswitch, which consists of a kernel package that automatically issues the correct ACPI calls to disable the discrete GPU when not needed, or automatically at boot.

Using acpi_call

Otherwise, and for GPUs not supported by bbswitch, the same can be done manually installing the acpi_call package.

Once installed load the kernel module:

With the kernel module loaded, execute the script at /usr/share/acpi_call/examples/turn_off_gpu.sh

The script will go through all the known data buses and attempt to turn them off. You will get an output similar to the following:

See the «works»? This means the script found a bus which your GPU sits on and it has now turned off the chip. To confirm this, your battery time remaining should have increased.

Turning off the GPU automatically

Currently, the chip will turn back on with the next reboot. To get around this, add the kernel module to the array of modules to load at boot:

At boot

To turn off the GPU at boot it is possible to use systemd-tmpfiles.

The above config will be loaded at boot by systemd. What it does is write the specific OFF signal to the /proc/acpi/call file. Obviously, replace the \_SB.PCI0.PEG0.PEGP._OFF with the one which works on your system (please note that you need to escape the backslash).

After X server initialization

On some systems, turning off the discrete GPU before the X server is initialized may hang the system. In such cases, it may be better to disable the GPU after X server initialization, which is possible with some display managers. In LightDM, for instance, the display-setup-script seat configuration parameter could be used to execute a script as root that disables the GPU.

System76

Some System76 laptops (like the Oryx Pro) have their own unique hybrid graphics option. To make use of it, install system76-power AUR , enable the system76-power service, and run system76-power graphics hybrid .

Источник

Включение гибридной графики в Ubuntu на ноутбуках Nvidia + Intel (OpenGL, Vulkan)

Введение

Это простая инструкция как включить гибридную графику intel-nvidia на ноутбуке. Чтобы определенные приложения запускались на дискретном чипе, а другие на встроенном. На свое удивление в интернете не нашел простую инструкцию того, как запускать определенные приложения, используя дискретную графику. Так что напишу так просто, на сколько считаю нужным

У меня система KDE Neon 5.21 — по большому счету — Ubuntu LTS с окружением рабочего стола KDE Plasma 5.21, видеочип GeForce MX150

1. Устанавливаем драйвер

a) Если у вас система на Qt (Как правило окружение KDE или LXQt), то с помощью данной команды через терминал загрузим программу для установки драйверов:

Если у вас система на GTK то с помощью это команды:

Хотя разницы принципиальной нет

b) Затем запускаем ее с правами root

Можно так же добавить ярлык для запуска в меню приложений

Инструкция для KDE

/.local/share/applications/ создадим файл software properties qt.desktop с таким содержанием

И файл software properties qt.sh в той же папке:

После перезагрузки ярлык появится в меню

Но это далеко не обязательно, вполне достаточно запустить из консоли для наших целей настройки гибридной графики

c) Переходим на последнюю вкладку Additional drivers и устанавливаем нужный драйвер. Я выбрал самой последней версии, который не tested и не server

d) После установки перезагружаем устройство

2. Настраиваем видеокарту

a) Загружаем следующую программу:

b) Переходим в PRIME Profiles Здесь мы видим три пункта:

NVIDIA (Performance Mode) — работать только на дискретной графике. Сильно потребляет батарею в несложных задачах, а так же ноутбук начинает греться. Зато система работает намного быстрее, но это того не стоит. У меня после установки драйвера этот пункт включился автоматически

NVIDIA On-Demand — некоторые приложения будут использовать дискретную графику nvidia, но по-умолчанию встроенная intel. Как запустить конкретное приложение с дискретной графикой напишу дальше

NVIDIA (Power Saving Mode) — отключение дискретной графики

Выбираем второй вариант — NVIDIA On-Demand , и перезагружаем систему

3. Запуск приложения с использованием дискретной графики

Это то, что сложнее всего гуглилось.

Для запуска приложения с использованием графики nvidia нужно задать для OpenGL две переменные среды:

для Vulkan только:

Делать это надо перед командой для запуска приложения. Например, нам нужно запустить из терминала приложение program с использованием дискретной графики. Нужно вызвать его так:

Соответственно, если у приложения есть ярлык (.desktop) в меню приложений, то надо изменить команду запуска в ярлыке. В KDE Plasma нужно нажать на него ПКМ, открыть свойства (или «изменить приложение. «), перейти во вкладку «приложение» и перед командой приписать данную приставку. В других средах похожего стола примерно так же

Пример: ярлык игры Wolfenstein — Blade of Agony

Можно сделать это же действие через текстовый редактор. Открываем ярлык, находим Exec= , и приписываем перед коммандой данную приставку __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia

Заключение

Данный метод, как я понял, точно работают для программ, использующих библиотеки OpenGL и Vulkan. У меня, к сожалению, не получилось запустить так Windows приложение через Wine, которое использует DirectX, но это уже совсем другая история. (OpenGL приложения под Wine работают)

Источник

Linux: все, что я хотел знать про гибридную графику и производительность игр

Про производительность игр под Linux написано очень много. Но, во-первых, Linux быстро развивается (то есть что-то уже банально устарело), а во-вторых, многое, что написано на эту тему — написано на игровых и линуксовых форумах ярыми линуксоидами, у которых, конечно «все летает лучше чем в виндах». Поймите меня правильно, не то, чтобы я не верю 😉 Но лично я сам не видел, чтобы что-то работало быстрее… Главное — я понял, что не смогу сложить у себя в голове целостную картину, пока не попробую сам. Вопрос для меня не праздный — я использую Linux на ноутбуке, причем уже «не молодом», так что, как говорится, каждый FPS на счету.

А еще вопрос стоит гораздо шире, нежели банальное сравнение Linux — Windows:

• в Linux можно запускать нативные игры или игры в Wine;
• Wine бывает разных версий — как сильно это влияет на производительность?
• добавим сюда гибридную графику — ее можно задействовать с помощью Nvidia Prime или Bumblebee;
• c Bumblebee мы можем использовать VirtualGL или Primus.

В общем, есть из чего выбирать. Вот я и занялся тестами. Исходные данные:

Ноутбук Acer V3-772G:

Процессор: Core i7 4702MQ

Видеокарта: Intel HD 4600 \ NVIDIA GeForce GTX 760M, Nvidia Optimus.

Остальное, говоря серьезно, несущественно — здесь главное то, что сравнение будет проводится на одном и том же железе.

В качестве «осей» выступят:

Windows 10, драйвер Nvidia 388.31;

Ubuntu 16.04.3, драйвер Nvidia 384.90.

Тестирование в Wine проводилось на двух версиях — 2.0.3, которая на момент написания статьи считалась стабильной и Wine Staging 2.20. Для последней отдельно измерялись результаты с включенным и выключенным CSMT.

Обе системы перед тестами устанавливались «начисто». Ну а для тестирования я использовал бенчмарк от Unigine — Valley 2013. Именно его я выбрал, так как по «году рождения» он гармонирует с ноутбуком — модель 2012 года. Кроме того, бенчмарк работает в Windows, нативно в Linux, а так же под Wine.

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

Производительность измерялась в OpenGL и DirectX 9. DirectX 11 я трогать не стал, так как не смотря на усилия разработчиков Wine, он еще мало где нормально работает. Не ходя далеко — выбранном бенчмарке он работал некорректно.

Бенчмарк всегда запускался c одними и теми же настройками, которые можно увидеть на скриншоте ниже (менялся только API):

Теперь про гибридную графику — Nvidia Optimus. В Windows все просто — все необходимое устанавливается вместе с драйвером видеокарты, запуск определенных приложений на высокопроизводительной карточке происходит автоматически. Проблемы и сбои в этом механизме бывают, но не часто.

В Linux, как водится, вариантов больше. Судя по форумам, самое популярное решение, чтобы заставить Nvidia Optimus работать в свободной ОС называется Nvidia Prime. Сам долго пользовался именно им. В отличие от «уютной винды», Nvidia Prime позволяет запускать в Linux весь сеанс с той или иной карточкой — то есть используем Intel, если стала нужна карточка Nvidia — ткнули нужную галочку \ ввели команду в терминале, перезагрузились или перелогинились, и весь сеанс работает на Nvidia. Чтобы перейти назад на Intel надо повторить операцию. Многие пишут, что в этом нет никаких неудобств, но это верно лишь отчасти. Точнее для тех, у кого работа и развлечения жестко разделены по времени. Если же вы захотели запустить что-нибудь ненадолго среди рабочего дня… То Nvidia Prime уже далеко не так удобен. Потому что — будьте любезны закрыть все свои рабочие дела и перелогиниться \ перезагрузиться. А потом назад. Ну или сидите целый день используя карточку Nvidia — что мне тоже не очень по душе, учитывая возможность использовать более экономичную видеокарту.

В минусы Nvidia Prime стоит записать и то, что он есть не для всех дистрибутивов. В плюсы — простоту настройки (собственно, она не требуется, в Ubuntu достаточно установить проприетарный драйвер, пакет nvidia-prime, и, для управления всем этим счастьем — пакет nvidia-settings). Какие есть альтернативы?

Альтернатива — Bumblebee (а для многих дистрибутивов — вообще единственный вариант задействовать гибридную графику). «Шмель» позволяет запускать приложения используя специальную команду, что заставляет их выполняться на мощной видеокарте. Перезагружаться не нужно. На мой вкус — самое оно, не хуже, чем в Windows. Платой за всю эту красоту называют производительность. Действительно, изначально для вывода изображения с мощной видеокарты использовали VirtualGL, что достаточно негативно влияло на производительность. Затем появилось еще одно решение — Primus, более быстрое. Хотя про «шмеля» до сих пор можно увидеть жалобы на то, что он медленный. Например, потому, что во многих «гайдах по настройке» упорно советуют использовать VirtualGL. Забегая вперед скажу, что при использовании Primus производительность, как раз, очень хорошая.

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

Однако, довольно лирики. Предлагаю сравнить все три варианта — Nvidia Prime и Bumblebee в связке с VirtualGL (приложения при этом запускаются с командой optirun) и Primus (команда primusrun). В конечном итоге, сравним лучшие результаты с Windows — для контраста. Поехали.

Тесты

Windows 10

Возьмем за эталон Windows. Результаты прогонов бенчмарка:

Посмотрели, запомнили, переходим к Linux.

Ubuntu 16.04.3

OpenGL: Nvidia Prime, VirtualGL, Primus

• Nvidia-Prime — 846;
• VirtualGL — 667;
• Primus — 882.

Ого! Мало того, что VirtualGL в явных аутсайдерах, но и Primus демонстрирует производительность близкую к Windows. Не придираясь к единицам, можно даже сказать «одинаковую». Придираясь — отстает всего на 0,8%.

Схожая ситуация наблюдается и при использовании Wine:

Nvidia Prime:

Wine Staging 2.20 — 831.

VirtualGL:

Wine Staging 2.20 — 612.

Primus:

Wine Staging 2.20 — 881.

Опять связка Bumblebee и Primus «впереди планеты всей». В свою очередь, VirtualGL, выводящий изображение «через альпы» (если интересно — загуглите), прилично просаживает производительность даже несмотря на то, что это OpenGL, а значит, программа запущенная в Wine взаимодействует с ним напрямую.

DirectX 9: Wine + Nvidia Prime, VirtualGL, Primus

Nvidia Prime:

Wine Staging 2.20 — 542;

Wine Staging 2.20 CSMT — 576.

VirtualGL:

Wine Staging 2.20 — 537;

Wine Staging 2.20 CSMT — 564.

Primus:

Wine Staging 2.20 — 570;

Wine Staging 2.20 CSMT — 603.

Результаты очевидны. Уточню, что результат в 603 «попугая» у сочетания Bumblebee + Primus + Wine Staging 2.20 CSMT — лучший результат для Wine, который удалось получить.

И да, выгода от использования Wine Staging и включения CSMT — очень ощутимая. Если используете Wine для игр — обязательно стоит установить именно эту версию. Про версии Wine у меня есть отдельная статья.

Но насколько мы теряем по сравнению с Windows? Даже в лучшем варианте — около 25%. Очень много. Остается лишь надеяться на дальнейшее развитие и без того быстро развивающегося Wine. Я не замерял производительность для какого-нибудь Wine 1.6, но по своим прошлым ощущениям при использовании, могу предположить, что речь запросто может идти о потере 50% и более.

Подводим итоги

Итак, игры, которые используют OpenGL, по результатам тестов, должны работать в Linux не хуже, чем в Windows, ну или хуже совсем чуть-чуть. Этот результат радует, потому что около года назад пронеслась волна ропота, что-де даже нативные игры работают медленнее, чем в Windows (видим, что нет). Причем, благодаря усилиям программистов Wine, даже запущенные через него игры должны сохранять этот уровень производительности. Кстати, если озадачиться, взять какой-нибудь Gentoo, все оптимизировать… Может быть удастся и превзойти «винду», не исключаю!

Слухи же о медленно работающих нативных играх, я думаю, пошли от того, что далеко на каждая такая игра использует OpenGL, многие представляют из себя виндовый вариант, как говорят, «обернутый» в Wine. А как работает Wine мы уже видели.

Будем надеяться, что разработчики будут чаще выбирать этот API (ну или Vulkan, ситуация с которым, по идее, как минимум не хуже). Особенно учитывая тот факт, что с DirectX 9, к сожалению, все не так гладко. Да, Wine совершенствуется, но…

Даже в фигурирующем на графике варианте Bumblebbe + Primus + Wine Staging 2.20 CSMT, отставание от Windows составляет 26,2%, то есть, больше, чем на четверть. Этого, однако, совершенно достаточно для «поиграть между делом» и уж тем паче для не самых свежих игр.

Что касается гибридной графики, как видите, Bumblebee вкупе с Primus продемонстрировал лучшую производительность. Здесь даже и написать еще что-то сложно. Ну, если Bumblebee не получается настроить — можете использовать Nvidia Prime, отстает он совсем немного.

Что же, кажется ответы на все поставленные в начале вопросы — получены. В конце, для интересующих, выкладываю таблицу, в которой сведены результаты всех тестов:

Источник