Гибридный линукс что это

Включение гибридной графики в 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 не являлся, не является и никогда не будет альтернативой Windows 10 (по моему мнению)

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

реклама

2003 год. RedHat принимает решение о закрытии RedHat Linux и разделении дистрибутива на две версии: Fedora, которая поддерживается сообществом, и Red Hat Enterprise Linux, который имеет закрытую платную поддержку. Казалось бы, какое дело кому до тех событий? В те далекие времена поддержка Linux сторонним программистом, у которого еще недостаточно денег на капризы сообщества Linux, еще как-то была возможна. Программист мог спокойно собрать одну RPM-ку, одну DEB-ку, один пакет для Arch Linux, один для Слакваря. И на этом его работа заканчивалась. Состав дистрибутивов был весьма однородным. Но наступил 2003 год, и в итоге те, кто разрабатывал дистрибутивы на основе Red Hat, вынуждены были с ноля создавать свою структуру. В результате чего мы имеем Alt Linux, Mageia, Rosa, Opensuse, в которых состав дистрибутива в каждом релизе — свой. В итоге нужно 4 раза непонятно для чего адаптировать свою программу под состав каждого дистрибутива. Посмотрим на ситуацию глазами программиста, который только вышел из ВУЗа и у которого в столе есть только сбережения бабушки. Станет ли он вкладываться в платформу с такими капризами, которые непонятно как монетизировать? Вряд ли. А ведь основа Windows — это стабильный Win32 API, который может использоваться для разработки различного уровня программных продуктов, как крупного ПО, вроде Microsoft Office, Adobe Photoshop, так и малого ПО, вроде казуальных игр. Но политигрища для сообщества Linux оказались важнее, чем появление для начала хотя бы малого по в Linux.

2010 год. Ситуация стала относительно выправляться за счет нигилизма по отношению к Redhat. В 2004 году появилась Ubuntu, которая ответвилась от Debian, только для того, чтобы придать плановый характер развития DEB-дистрибутивов, при том с совместимостью проблем не было. К 2010 появилась песочница для разработки Launchpad, появилось ряд серьезных программных продуктов для Linux, наконец-то появилась и поддержка соединений, отличных от динамического IP-адреса. Ситуация снова стала налаживаться. Появился вменяемый дизайн. И в тот момент снова можно было задуматься о переходе на Linux. Уже появился даже Steam в 2012.

В 2012 году выходит Gnome 3, который подрывает стабильность GTK. И теперь уже отделаться нигилизмом по отношению к RPM не получится, поскольку с каждой минорной версией GTK 3, ломается обратная совместимость. Подливает масла в огонь внедрение Unity по умолчанию, а также появления нескольких форков Gnome 2. В итоге под какой GTK 3 ориентировать разработку нашему стороннему программисту — непонятно. Времена, когда можно было создать одну DEB для Debian и Ubuntu закончились. А многие сторонние темы оформления вынуждены были либо примитизироваться до уровня Adwaita и Metro Windows 8, либо прекратить свое существование. Сообществу данные нубовведения преподносились как большое благо, поскольку они ведут к тому самому светлому Wayland, о котором речь пойдет ниже. В итоге к проблемам опакечивания у того самого стороннего программиста появились еще и проблемы с выбором местного аналога Visual Studio, поскольку и этот каприз сообщества как монетизировать — неясно.

реклама

2014 год. В сообществе начали искать недостатки в системе инициализации, которая даже в Windows 10 (WinLogon.exe) сохранилась еще со времен Windows Vista. Продвижение Systemd преподносилось с целью интенсивного распараллеливания запуска служб в процессе загрузки системы, что позволяло существенно ускорить запуск операционной системы. Но практика оказалась такова, что при внедрении Systemd появлялись ошибки, вроде A Systemd Job Is Runnig For, которые откладывали загрузку ОС на 1,5 минуты принудительно. Вместе с этим данная система инициализации окончательно убила все надежды на то, что ядро Linux когда-то станет микроядерным или гибридным, поскольку портирование существующего ПО на другие UNIX-подобные ОС теперь стало затруднительным. А одно из преимуществ гибридного ядра является возможность внедрения слоев обратной совместимости и абстракций, которые позволили бы нашему стороннему программисту создавать программный продукт и поддерживать его продолжительный срок, а не разоряться на очередные тараканы и капризы теперь уже в ядерном и инициализационном пространстве.

2016 год. Выходит Windows 10, в которой оказываются многие хорошие идеи линуксоидов с тех времен. Но линуксоиды вместо этого переобуваются на противоположное и говорят слово в слово то, что им говорили лет 10 назад пользователи Windows. Достаточно вспомнить пример про виртуальные рабочие столы и несколько мониторов. Лет 10 назад утверждалось, что несколько мониторов — это плохо, а виртуальный рабочий стол — прекрасная альтернтатива. Теперь утверждается, что виртуальные рабочие столы — это зло и нужно скупать несколько мониторов. То же самое можно сказать и о режиме PAE, который отличается от 64 бит с точки зрения практики только невозможностью со стороны программы потреблять более 4 ГБ RAM, что в теории должно было бы быть полезным для пользователя, поскольку с PAE он мог покупать оперативную память не для того, чтобы программа выполняющая одни и те же функции использовала ее еще больше, а для того, чтобы например, использовать несколько программ. Появляется аналог репозитория в лице магазина Windows, где по идее должно быть безопаснее, но линуксоиды решают выдумать контейнеры, которые ни что иное, как те самые ожиревшие exe-шники 2010-ых годов, в которых запихнуто все на свете зависимое ПО, и которые являлись чуть ли не главным элементом спора Windows vs Linux в те времена. А теперь в Windows есть довольно актуальный репозиторий, который позволяет экономить место на SSD, которое до сих пор довольно золотое, а в Linux с каждым годом растет не по дням, а по часам объем занимаемого места на накопителе. Достаточно сравнить объем пакета с ядром 3.х, с ядром 4.х и с ядром 5.х, и сравнить объем и состав дистрибутивов Windows 7 и Windows 10. Последняя умудряется вмещать до сих пор в DVD-диск все самое необходимое. А вот Linux уже вылез из CD-диска и стал недалеко уходить по объему инсталлятора по сравнению с Windows 10. А теперь к 2018 году, к тому самому интересному — Wayland.

2018 год. В дистрибутивах решают с помощью просовывания Wayland по умолчанию приблизить его появление. Однако при этом забывают, что нельзя просунуть то, что изначально было нежизнеспособно. Альтернативы X-серверу писали еще тогда, когда многих комментаторов на свете не было. Но все они по одной и той же причине умирали, точно также как и умрет Wayland — всем, кроме пары фанатов и холиварщиков он не нужен. Никто делом поддержать его появление не готов. Ситуация по Nvidia такова, что Wayland увидят, если вообще увидят только владельцы видеокарт MaxWell и выше, Kepler и ниже — в пролете. А зачем владельцу Maxwell переходить на Linux на сегодняшний день — тот еще вопрос. Ситуация по Intel такова, что несмотря на то, что поддержка Wayland там есть, она бесполезна. А бесполезна потому, что даже на сегодняшний день мы видим поддержку Wayland только в Mutter и Kwin, а оба оконных менеджера явно, как и Aero в Windows 7, создавались для дискретной графики. Т.е самое лучшее для владельца Intel — это вернутся на те самые допотопные иксы, и выбрать какой-нибудь Macro, Metacity, Compiz, XFWM или Openbox, нежели чем наблюдать слайд-шоу в Mutter. В итоге Wayland может быть полезен только для владельцев AMD, и то не для всех по тем же причинам, что и на Nvidia — тем, у кого современная видеокарта, нужна видеокарта для стороннего ПО, а не для Mutter, тем у кого древняя видеокарта — поддержку не завезут. Но дальше будет самое дно.

2020 год. В Linux внезапно решают отказаться от поддержки 32-битной архитектуры. Нет, первой решила прекратить поддержку 32-бит явно не корпорация Microsoft. Хотя с ее стороны такое решение было бы куда более логичным, поскольку во-первых, на 4 ГБ Windows 10 использовать уже довольно проблематично, а во-вторых предустановка Windows 10 на ПК с менее 4 ГБ ОЗУ уже невозможна по лицензионным соображениям. А вот в Linux, где вполне себе можно с комфортом использовать ОС на 2-4 GB ОЗУ с форками Gnome 2, с KDE, с Compiz, вдруг решают, что операционная система должна быть только 64-битной. И стоит напомнить, что лет 10 назад при внедрении 64-битных ОС шел разговор о том, что 64-бита не нужны и PAE-наше все.

реклама

Что можно сказать в целом за эти 15 лет использования Linux? Каких-то радикальных улучшений, вроде появления гибридного ядра, аналога DirectX (нет, Vulkan не в счет), аналога Net.Framework, которые по моему мнению сделали бы Linux конкурентоспособной альтернативой Windows, так как появилась бы уверенность при разработке в завтрашнем дне — не произошло, зато появилось столько «полезностей» что хочется умыть руки и пойти изучить возможности сторонних программ Windows, поскольку в жизни изучение возможностей того же Word или видеоредактора окажется полезнее, чем разбор полетов в этой мусорной куче. Сделано все, чтобы люди, которые хотели внести вклад в IT-сообщество, не только не захотели этого делать, но и радовались мытью полов в супермаркете. Мотивация, логика, адекватность тех или иных идей — полностью в сообществе отсутствует.

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

Источник

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, отстает он совсем немного.

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

Источник