LINUX.ORG.RU

Научите включать KMS и GLvnd на NVIDIA

 , ,


1

4

У меня NVIDIA Optimus. Приобрёл ноут с ним сразу после того, как Optimus стал поддерживаться официально. Это был 2013 год и драйвер 319.xx.

В новости про драйвер была ссылка на инструкцию 1). Ядро 3.9, иксы 1.13, xrandr 1.4 2). В xorg.conf прописать это 3). В .xinitrc - это (но лучше в конфиг lightdm).

Таким образом, уже на второй день после покупки ноутбука, я сумел настроить Optimus.

И вот выходит драйвер 364.xx. KMS, GLvnd включен по умолчанию. У меня возникли вопросы, на которые я не смог найти очевидного ответа ни сразу после релиза драйвера, ни через месяц после него:

1). Я нашёл как включать KMS. В документации дана команда modprobe -r nvidia-drm ; modprobe nvidia-drm modeset=1, следовательно в grub.cfg в строку инициализации ядра нужно добавить «nvidia-drm.modeset=1». Нужно ли это делать на Optimus, или это только для дискретки?

2). The NVIDIA DRM KMS implementation does not yet register an overlay plane: only primary and cursor planes are currently provided. О том, что для курсора мышки есть plane, я догадывался, когда при 12309 на Radeon мышка дёргалась, а на NVIDIA - нет. А что такое overlay plane?

3). GLvnd. Я хочу чтобы всё рисовалось на Интеле, а NVIDIA была обесточена. И чтобы как только я запущу игру, чип от NVIDIA просыпался. GLvnd создан, чтобы дать нам это. Как это включить? Умеет ли драйвер modesetting - аппаратный рендеринг? Нужно ли ждать добавления поддержки GLvnd в Mesa, или можно использовать уже сейчас?

4). Для конфигураций Optimus, в драйвере 364.xx подняли требования к ядру. Было Linux 3.9, стало 3.13. Мне в CentOS 7 что, переходить на Bumblebee? Тут 3.10. Или нужные изменения бэкпортируют, как USB3 в шестёрку и ext4 в пятёрку?

Ответ на: комментарий от ZenitharChampion

Эти всякие нововведения нвидии, тот же кмс еще не видел пруфа что оно заработало, под GLvnd нужно пилить месу еще, тоже самое и для вайленда, и выходит что нвидия что-то вроде и сделала, что-то реализовала, но говорит мол переделывайте под меня, ибо у меня правильно, на что ее все посылают в известном направлении. А modesetting умеет грузить нужный *_dri.so, так что 3д ускорение с ним работает.

Novell-ch ★★★★★ ()
Ответ на: комментарий от Novell-ch

> А modesetting умеет грузить нужный *_dri.so, так что 3д ускорение с ним работает.

Воу. А если я удалю libGlamor, то будет работать?

ZenitharChampion ★★★★★ ()
Ответ на: комментарий от Novell-ch

Блин, проприетарный драйвер NVIDIA с этой либой конфликтует:

ftp://download.nvidia.com/XFree86/Linux-x86_64/364.19/README/randr14.html

Some versions of the “modesetting” driver try to load a sub-module called “glamor”, which conflicts with the NVIDIA GLX implementation. Please ensure that the libglamoregl.so X module is not installed.

ZenitharChampion ★★★★★ ()
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: комментарий от ZenitharChampion

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

Novell-ch ★★★★★ ()

GLvnd создан, чтобы дать нам это.

он был создан для бесконфликтной установки 100500 реализаций OpenGL, если я правильно понял
т.е. ты ставишь всякие месы/блобы/... и можешь переключаться между ними в отдельных скринах (как тут: ftp://download.nvidia.com/XFree86/Linux-x86_64/364.19/README/randr14.html)

anTaRes ★★★★ ()
Ответ на: комментарий от Novell-ch

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

Точно, GLX же... Похоже что связка Xorg + (modesetting + glamor + i965_dri) + NVIDIA + GLvnd работать будет, если попробовать - но проги должны быть собраны с EGL. И горячее переключение, и всё как на винде, но только без GLX! А следовательно, 99% линуксовых игрушек в пролёте!

ZenitharChampion ★★★★★ ()
Последнее исправление: ZenitharChampion (всего исправлений: 5)
Ответ на: комментарий от ZenitharChampion

Блин, проприетарный драйвер NVIDIA с этой либой конфликтует:

имелось в виду что для драйвера modesetting гламур используется по дефолту, а при отсутствии libglamoregl.so он фалбэком выбирает другой метод
скорее всего даже пересобирать/удалять ничего не нужно, просто указать другой метод в конфиге и проверить Xorg.0.log
Option "AccelMethod" "uxa" # или "sna"

но это для старых иксов, для новых (If X.Org X server version 1.17.2 or higher is installed), опять же скорее всего, ничего не нужно указывать/пересобирать

Section "Module"
    Load "modesetting"
EndSection

Section "Device"
    Identifier "nvidia"
    Driver "nvidia"
    BusID "<BusID for NVIDIA device here>"
    Option "AllowEmptyInitialConfiguration"
EndSection

з.ы. проверить не могу, это все догадки

anTaRes ★★★★ ()
Ответ на: комментарий от Novell-ch

А у амд с кем совместимо, если из производителей остаётся только интел, у которого тоже свои велосипеды? Почему вы распространяете ложные тезисы?

anonymous ()
Ответ на: комментарий от anonymous

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

Novell-ch ★★★★★ ()
Ответ на: комментарий от anTaRes

и как же modesetting будет использовать sna или uxa, если это технологии xf86-video-intel, и никто кроме него о них не знает?

Load «modesetting» а это вообще нет слов, modesetting это DDX драйвер а не модуль, гламор как раз модуль, но вот его то и нвидия и не хочет.

Novell-ch ★★★★★ ()
Ответ на: комментарий от Novell-ch

У интела гламор не используется в пользу sna/uxa, галлиум не используется, вулкал свой, clover не используется в пользу beignet. Драйвера амд совместимы только сами c собой.

anonymous ()
Ответ на: комментарий от anonymous

И egl не используется, и kms,и wayland, и prime нормальный не будет работать? и что мешает заюзать modesetting, тогда и гламор будет, причем интел гламор и создала изначально и поддержка была. Так что амд и интел открытые nouveau делят кучу технологий между собой, а теперь даже и закрытые у амд все это делят. А вот блоб нвидии сколько лет пилят а толку нет, родили egl и поддержку валяного, но требуют изменений в самом вяланом, на что их заслуженно посылают. GLvnd тоже, вроде и открыто, почему то никто не кинулся сразу месу переделывать под это дело, им и так норм, но думаю эту инициативу таки поддержат рано или поздно.

Novell-ch ★★★★★ ()
Ответ на: комментарий от Novell-ch

Load работает на всем /usr/lib/xorg/modules
наверное это просто способ сказать автоконфигурялке ксорга что drivers/modesetting_drv.so пробать нужно в первую очередь
и не словить автопроб драйвера intel с последующим отвалом modesetting

в любом случае это копипаста из ридми, нету повода не верить ей при настройке их дров

и как же modesetting будет использовать sna или uxa, если это технологии xf86-video-intel, и никто кроме него о них не знает?

хз, я отбалды написал, но выключить гламур можно полюбому (вопрос как меня не особо волнует в данный момент)

anTaRes ★★★★ ()
Последнее исправление: anTaRes (всего исправлений: 1)

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

собсно некоторые соображения из как было/стало:

* раньше чтоб потыкать nouveau мне нужно было переконфигурять ядро под KMS, блеклистить или сносить блоб, может месу/ксорг/... пересобирать по особому и т.д.
* потом для возврата к блобу проделывать то-же самое наоборот (что-то нужно было, а что-то просто от греха подальше, чтоб не конфликтовало)
* теперь (ну может не прямо сейчас, а версии через 2-3) можно сразу ядро отконфигурить под KMS и забыть
* возможно даже параллельно все дело собрать для поддержки nouveau и переключаться тупо через конфиг ксорга, указанием нужного драйвера
* возможно даже проканает финт типо прайма на одной дискретке, где я смогу настроить два скрина с разним дровом и переключаться между ними, или может втыкнуть две карты от разных вендоров и тоже переключаться между ними

как-то так, если где не прав - поправьте

anTaRes ★★★★ ()
Ответ на: комментарий от anTaRes

То что ты описал прям сейчас уже далает амд, где есть одни модуль ядра на закрытый и открытый драйвер, и можно использовать части закрытого(opencl, vulkan, ogl) на открытом юзерспейсе и наооборот. Для нвидии же ничего не поменялось, как было 2 модуля так и осталось, разве что может в терминале теперь разрешение можно высокое ставить, и то я пруфов что kms работает еще не видел.

Novell-ch ★★★★★ ()
Ответ на: комментарий от Novell-ch

я не про NVIDIA vs AMD спрашиваю, а про NVIDIA vN-1 vs vN+1
собсно как и ТС

и то я пруфов что kms работает еще не видел.

потому как он не работает (не работал) пока, насколько я понял там тупо врапер и не все фичи поддерживаются

anTaRes ★★★★ ()
Ответ на: комментарий от anTaRes

еще раз что бы такое работало нужно что бы не было nouveau.ko и nvidia.ko а было что-то одно (два драйвера одно устройство не занимают), чего походу у нвидии не будет. И от GLvnd никакого проку нету, потому что его поддерживает только нвидия. Так что все как и было, либо блоб нвидии со своим добром, либо все остальное.

Novell-ch ★★★★★ ()
Ответ на: комментарий от Novell-ch

> GLvnd тоже, вроде и открыто, почему то никто не кинулся сразу месу переделывать под это дело, им и так норм, но думаю эту инициативу таки поддержат рано или поздно.

В коммерческих дистрах (и в их бесплатных версиях) все системообразующие программы сильно пропатчены. Открываем SRPM-ку ядра или OpenSSL и видим от одного до десятка патчей! В Генте это видно особенно хорошо: gentoo-patches периодически мелькают на несколько секунд при распаковке архива, яркие примеры - bash, udev.

Не примет меса - пропатчит красная хата. Я в этом уверен

ZenitharChampion ★★★★★ ()
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: комментарий от ZenitharChampion

Одно дело когда патчи есть и их не принимают, другое когда их нет, и не предвидится, месовская libGL.so дает точки входа для opengl и glx, для GLvnd ее нужно раздеребанить на 2 либы и научить с ними работать, и пока дальше обсуждений никуда это не пошло.

Novell-ch ★★★★★ ()
Ответ на: комментарий от Novell-ch

Так что все как и было, либо блоб нвидии со своим добром, либо все остальное.

дык GLvnd для этого и придумали, чтоб можно было установить всю пачку известных дров с ихними libGL (хз, дистростроителям в помощь чтоль)
в иксы уже впилили поддержку, в месу вроде тоже, блоб вон по дефолту теперь ставит все нужное
когда все это уже фунциклирует, амд осталось просто привести свои либы в соответствие

ну а насчет двух драйверов и одного устройства - то мои влажные мечты мысли в слух просто

anTaRes ★★★★ ()
Ответ на: комментарий от anTaRes

нету в месе еще, так что нвидия онли оно как было так и остается.

Novell-ch ★★★★★ ()
Ответ на: комментарий от Novell-ch

нету в месе еще

да, нагуглил, но процесс идет и какие-то патчи есть для glvnd/mesa
https://bugs.freedesktop.org/show_bug.cgi?id=92877
https://lists.freedesktop.org/archives/mesa-dev/2015-September/095856.html

https://github.com/NVIDIA/libglvnd/pull/85

The goal is to allow a library such as Mesa to use libglvnd's dispatch layer instead of having to send every OpenGL function through two layers.


короче цель всего этого «нвидия онли» движа - причесать всю эту кашу с EGL/GLX/libGL/... и заставить причастных выбросить свои велосипеды и пересесть на https://upload.wikimedia.org/wikipedia/commons/b/b1/Rower_wieloosobowy_by_Zur...
в результате, кроме очевидных плюсов, может случиться скачек производительности в меса, упрощение перехода/поддержки всяких вейландов и пр., и мир во всем мире

anTaRes ★★★★ ()
Ответ на: комментарий от anTaRes

Более забавно что блоб нвидии стабильно работает быстрее любого швятого открытого кода, что как бы намекает, кто может в разработку графстеков, а кому стоило бы поучиться.

anonymous ()
Ответ на: комментарий от anonymous

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

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

з.ы. эт я про nouveau ессесна

anTaRes ★★★★ ()
Последнее исправление: anTaRes (всего исправлений: 1)
Ответ на: комментарий от anTaRes

Амд/интел тоже уступают по производительности своему же вендовому драйверу и линуксовому от нвидии, хотя доки у них есть и кодеры на зряплате.

anonymous ()
Ответ на: комментарий от anonymous

> Более забавно что блоб нвидии стабильно работает быстрее любого швятого открытого кода

Скорее железо.

ZenitharChampion ★★★★★ ()
Ответ на: комментарий от anonymous

учитывая то, что открытые дрова состоят из mesa/kms/libdrm/xf86-video-* и пилятся соотв. разрабами ядра/месы/иксов (иногда это один и тот-же человек, иногда разные)
то на вопрос «какая с#ка тормозит?» ответ не очевиден, если ядро полностью поддерживает карточку - значит это меса
вооон из того пулл-реквеста в каментах проскочило:

From a quick look at the AMD closed source implementation is seems to be based on mesa ...

ткчто не удивительно

anTaRes ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.