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 может поменяться когда угодно и как угодно.