На текущем Сизифе фактически не работает OpenGL с NVIDIA. xdriinfo выдает libGL is too old glxinfo говорит, что Direct rendering: yes В X.org.0.log все в порядке glxgears дает 3500 FPS однако реальные приложения, которые используют OpenGL, работают очень медленно. Например, Unigine's Tropics демо дает 60 FPS. И эти 60 FPS получаются в основном из-за мощности системного процессора (Core 2 Duo).
Created attachment 2876 [details] Лог glxinfo
Created attachment 2877 [details] Xorg.0.log
*** Bug 17021 has been marked as a duplicate of this bug. ***
Created attachment 2878 [details] лог запуска демо Unigine Tropics На самом деле, Unigine Tropics дает 3-5 FPS на обработке реальных сцен
c nvidia_glx_173.14.12 ничего подобного не наблюдаю. doom3 бегает только в путь
специально перепроверил на nVidia Corporation GeForce 8600 GTS $ glxgears 41561 frames in 5.0 seconds = 8288.487 FPS 41674 frames in 5.0 seconds = 8334.750 FPS и т.д. $ rpmquery -a nvidia\* nvidia_glx_173.14.12-173.14.12-alt48 nvidia_glx_96.43.07-96.43.07-alt39 nvidia_glx_71.86.06-71.86.06-alt39 nvidia_glx_common-173.14.12-alt48 вообще бессмысленно вешать баги на проприетарный софт
1. Где можно прочитать о политике конфигурации драйверов nvidia в ALT Linux? 2. Почему при dist-upgrade не установился новый nvidia_glx, но установился новый nvidia_glx_common? 3. Почему при ручной установке нового nvidia_glx и перегрузке компьютера не произошло переключение драйвера на эту новую версию, а наоборот, вручную выставленные символические ссылки вернулись к ссылкам на драйвера из предыдущей (173.14.05) версии?
версия иксового драйвера выбирается в соответствии с версией ядерного модуля
Created attachment 2883 [details] strace -f -FF -e trace=file x11setupdrv Да, с драйвером стало ясно: отказался ставиться ядерный драйвер из-за множественных вариантов, требовался ручной выбор. Однако при работе x11setupdrv не перелинковываются библиотеки в /usr/lib/? Вдобавок он пытается удалить библиотеки (или симлинки) в /usr/X11R6/lib/, которых там нет, а библиотеки в /usr/lib/ остаются по-прежнему слинкованными на mesa, вместо nvidia. См. setup.log, который представляет из себя strace запуска x11setupdrv.
Итак, результаты отладки вместе со Shrek: 1. Драйвера от Nvidia не предоставляют DRI, поэтому xdriinfo ругается и не работает. Это нормальное поведение. 2. Тем не менее, я хотел бы в рамках этой ошибки разрешить следующий вопрос: неудовлетворительную работу set_gl_nvidia. set_gl_nvidia -- это комплекс переключателей, которые помещаются в /usr/libexec/X11/*/nvidia и переключают символические ссылки на доступную версию драйвера, согласно драйверу в ядре. Текущая реализация безосновательно жестко зашивает внутрь себя версию драйверов, из которых она собрана. Если учесть, что код set_gl_nvidia не зависит от версии драйвера, то такая привязка не только лишняя, но и вредная. Она не дает возможность переключать драйвер без принудительной замены бинарника переключателя, что странно -- зачем тогда вся машинерия с симлинками и файлами версий в ядре и /var/lib/nvidia/? С моей точки зрения, это over engineering, который только ухудшает работоспособность.
(In reply to comment #10) > переключают символические ссылки на доступную версию драйвера, согласно > драйверу в ядре. Не на доступную, а на такую, как в ядре. На любую другую не имеет смысла. > Текущая реализация безосновательно жестко зашивает внутрь себя версию > драйверов, из которых она собрана. Только fallback, если не смогла переключиться на нужную. В этом случае все равно, куда переключаться. > Если учесть, что код set_gl_nvidia не зависит от > версии драйвера, то такая привязка не только лишняя, но и вредная. Она не > дает возможность переключать драйвер Значит система не дала такой возможности. > без принудительной замены бинарника переключателя, без установки необходимогй пары: модуль ядра и модуль X-ов > что странно > -- зачем тогда вся машинерия с симлинками и > файлами версий в ядре и /var/lib/nvidia/? Чтобы переключаться между разными парами ядреный_модуль+Xовый_модуль > С моей точки зрения, это over engineering, который > только ухудшает работоспособность. Оно все работает автоматом.
(In reply to comment #7) > 2. Почему при dist-upgrade не установился новый nvidia_glx, > но установился новый > nvidia_glx_common? потому, что модули ядра низя ставить dist-upgrade-ом > 3. Почему при ручной установке нового nvidia_glx и перегрузке компьютера не > произошло переключение драйвера на эту новую версию, потому, что не установлен пакет x11_autosetup > а наоборот, вручную > выставленные символические ссылки вернулись к ссылкам чтоб руками не лазили > на драйвера из > предыдущей (173.14.05) версии? Не имеет значения. Для наглядности в этом случае можно переключить не на "173.14.05", а на "нифига-не-будет-работать"
(In reply to comment #9) > strace -f -FF -e trace=file x11setupdrv /usr/libexec/X11/drvpre.d/nvidia -v /usr/libexec/X11/drv.d/nvidia -v
(In reply to comment #11) > (In reply to comment #10) > > > переключают символические ссылки на доступную версию драйвера, согласно > > драйверу в ядре. > Не на доступную, а на такую, как в ядре. На любую другую не имеет смысла. Я проделал эксперимент: поставил руками бета-версию 170.77: 1. Собрал модуль, положил его куда надо, прописав все нужные записи в файлах и поставив нужные символические ссылки. 2. Собрал user space, положил его в нужное место в /usr/lib/. 3. Выгрузил старый модуль, проверил загружаемость нового, проверил запускаемость Xorg при ручной настройке ссылок. 4. Убедился, что перед перезагрузкой все симлинки и содержимое файлов в /var/lib/nvidia, соответствующее нужному ядру, указывает на мой модуль. 5. После перезагрузки произошло переключение на старый модуль, на старый user space. Все мои изменения в файлах и симлинках откатились на старую версию модуля (он стоит из rpm, новый -- самостоятельно). > > > Текущая реализация безосновательно жестко зашивает внутрь себя версию > > драйверов, из которых она собрана. > Только fallback, если не смогла переключиться на нужную. > В этом случае все равно, куда переключаться. Ситуация 100% воспроизводима. > > > Если учесть, что код set_gl_nvidia не зависит от > > версии драйвера, то такая привязка не только лишняя, но и вредная. Она не > > дает возможность переключать драйвер > Значит система не дала такой возможности. Неверно. Сергей, в данном случае я точно все перепроверил несколько раз. > > С моей точки зрения, это over engineering, который > > только ухудшает работоспособность. > Оно все работает автоматом. Оно автоматом не обеспечивает работоспособность множественных пар, как показал мой эксперимент.
(In reply to comment #14) > 1. Собрал модуль, положил его куда надо Собрал пакет и установил? Если нет, то apt-get remove nvidia_glx_common
Зачем? Я хочу, чтобы машинерия работала, если все требования ей в файловой системе удовлетворяют. Согласно предыдущим объяснениям, они удовлетворяют. Почему тогда "неестественный" интеллект не работает? На самом деле, вопрос скорее в том, что этот интеллект не обсуждался публично и не оформлен в виде внятного описания. Единственным описанием является исходный код утилиты, практически без комментариев, без man page и четко задокументированного поведения где-либо. Описание на http://www.altlinux.org/VideoDrivers поведение не конкретизирует. Если учесть, что используемый метод настройки драйверов является уникальным для ALT Linux и не присутствует более нигде, все это есть прямой путь к путанице. Конечно, в качестве альтернативы я могу написать и предложить собственную машинерию, но хотелось бы для начала "договориться" в рамках существующего "решения".
(In reply to comment #16) > Зачем? Я хочу, чтобы машинерия работала, если все требования ей в файловой > системе удовлетворяют. Согласно предыдущим объяснениям, они удовлетворяют. Нет пакета -- не удовлетворяют. > Почему тогда "неестественный" интеллект не работает? Ручная работа не поддерживается. > http://www.altlinux.org/VideoDrivers поведение не конкретизирует Написать, разве что, "руками не лазить". > Конечно, в качестве альтернативы я могу > написать и предложить собственную машинерию Только мне не верится, что она не продублирует мою. А так, буду только рад.
Внутри set_gl_nvidia нет никаких завязок на базу RPM, поэтому говорить о требованиях к наличию пакетов бессмысленно. Файловые зависимости я обеспечил, остальное -- выдумки, не подтвержденные кодом. Вообщем, понятно, желания сделать более дружелюбным эту часть инфраструктуры нет.
(In reply to comment #18) > Внутри set_gl_nvidia нет никаких завязок на базу RPM Есть. >, поэтому говорить о > требованиях к наличию пакетов бессмысленно. Файловые зависимости я > обеспечил, Если не работает, значит не обеспечил. > остальное -- выдумки, не подтвержденные кодом. Телепатию я закодировать не смогу. > Вообщем, понятно, желания сделать более дружелюбным эту часть > инфраструктуры нет. Я не смогу догадаться, что там наделает человек руками. Есть желание, но по другому. Сделать такой пакет с "драйвером", которому можно подсовывать любой *.run и производить сборку/установку свежескачанного драйвера. Но, я пока не знаю, как автоматизировать некоторые вещи. Например, для генерации .xinf у меня есть скрипт, но доверять ему нельзя, т.к. входной README может поменяться когда угодно и как угодно.
