Bug 17022 - libGL is too old
Summary: libGL is too old
Status: CLOSED WORKSFORME
Alias: None
Product: Sisyphus
Classification: Development
Component: nvidia_glx_173.14.12 (show other bugs)
Version: unstable
Hardware: all Linux
: P2 normal
Assignee: Sergey V Turchin
QA Contact: qa-sisyphus
URL:
Keywords:
: 17021 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-09-05 09:18 MSD by Alexander Bokovoy
Modified: 2008-09-08 18:21 MSD (History)
0 users

See Also:


Attachments
Лог glxinfo (21.17 KB, text/plain)
2008-09-05 09:18 MSD, Alexander Bokovoy
no flags Details
Xorg.0.log (13.72 KB, text/plain)
2008-09-05 09:19 MSD, Alexander Bokovoy
no flags Details
лог запуска демо Unigine Tropics (3.24 KB, text/plain)
2008-09-05 09:27 MSD, Alexander Bokovoy
no flags Details
strace -f -FF -e trace=file x11setupdrv (10.14 KB, text/plain)
2008-09-05 22:19 MSD, Alexander Bokovoy
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Bokovoy 2008-09-05 09:18:08 MSD
На текущем Сизифе фактически не работает 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).
Comment 1 Alexander Bokovoy 2008-09-05 09:18:42 MSD
Created attachment 2876 [details]
Лог glxinfo
Comment 2 Alexander Bokovoy 2008-09-05 09:19:07 MSD
Created attachment 2877 [details]
Xorg.0.log
Comment 3 Andrey Rahmatullin 2008-09-05 09:24:41 MSD
*** Bug 17021 has been marked as a duplicate of this bug. ***
Comment 4 Alexander Bokovoy 2008-09-05 09:27:09 MSD
Created attachment 2878 [details]
лог запуска демо Unigine Tropics

На самом деле, Unigine Tropics дает 3-5 FPS на обработке реальных сцен
Comment 5 Valery Inozemtsev 2008-09-05 11:33:10 MSD
c nvidia_glx_173.14.12 ничего подобного не наблюдаю. doom3 бегает только в путь
Comment 6 Valery Inozemtsev 2008-09-05 20:08:19 MSD
специально перепроверил на 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

вообще бессмысленно вешать баги на проприетарный софт
Comment 7 Alexander Bokovoy 2008-09-05 21:36:04 MSD
1. Где можно прочитать о политике конфигурации драйверов nvidia в ALT Linux?
2. Почему при dist-upgrade не установился новый nvidia_glx, но установился новый nvidia_glx_common?
3. Почему при ручной установке нового nvidia_glx и перегрузке компьютера не произошло переключение драйвера на эту новую версию, а наоборот, вручную выставленные символические ссылки вернулись к ссылкам на драйвера из предыдущей (173.14.05) версии?
Comment 8 Valery Inozemtsev 2008-09-05 21:40:22 MSD
версия иксового драйвера выбирается в соответствии с версией ядерного модуля
Comment 9 Alexander Bokovoy 2008-09-05 22:19:29 MSD
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.
Comment 10 Alexander Bokovoy 2008-09-06 20:11:31 MSD
Итак, результаты отладки вместе со Shrek:
1. Драйвера от Nvidia не предоставляют DRI, поэтому xdriinfo ругается и не работает. Это нормальное поведение.
2. Тем не менее, я хотел бы в рамках этой ошибки разрешить следующий вопрос: неудовлетворительную работу set_gl_nvidia.

set_gl_nvidia -- это комплекс переключателей, которые помещаются в /usr/libexec/X11/*/nvidia и переключают символические ссылки на доступную версию драйвера, согласно драйверу в ядре.

Текущая реализация безосновательно жестко зашивает внутрь себя версию драйверов, из которых она собрана. Если учесть, что код set_gl_nvidia не зависит от версии драйвера, то такая привязка не только лишняя, но и вредная. Она не дает возможность переключать драйвер без принудительной замены бинарника переключателя, что странно -- зачем тогда вся машинерия с симлинками и файлами версий в ядре и /var/lib/nvidia/? С моей точки зрения, это over engineering, который только ухудшает работоспособность.
Comment 11 Sergey V Turchin 2008-09-08 14:42:37 MSD
(In reply to comment #10)

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

> Если учесть, что код set_gl_nvidia не зависит от
> версии драйвера, то такая привязка не только лишняя, но и вредная. Она не
> дает возможность переключать драйвер
Значит система не дала такой возможности.

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

> что странно
> -- зачем тогда вся машинерия с симлинками и
> файлами версий в ядре и /var/lib/nvidia/?
Чтобы переключаться между разными парами ядреный_модуль+Xовый_модуль

> С моей точки зрения, это over engineering, который
> только ухудшает работоспособность.
Оно все работает автоматом.
Comment 12 Sergey V Turchin 2008-09-08 14:47:08 MSD
(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", а на "нифига-не-будет-работать"

Comment 13 Sergey V Turchin 2008-09-08 14:49:52 MSD
(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
Comment 14 Alexander Bokovoy 2008-09-08 15:50:22 MSD
(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, который
> > только ухудшает работоспособность.
> Оно все работает автоматом.
Оно автоматом не обеспечивает работоспособность множественных пар, как показал мой эксперимент.
Comment 15 Sergey V Turchin 2008-09-08 16:11:31 MSD
(In reply to comment #14)
> 1. Собрал модуль, положил его куда надо
Собрал пакет и установил?
Если нет, то
apt-get remove nvidia_glx_common
Comment 16 Alexander Bokovoy 2008-09-08 17:24:05 MSD
Зачем? Я хочу, чтобы машинерия работала, если все требования ей в файловой системе удовлетворяют. Согласно предыдущим объяснениям, они удовлетворяют. Почему тогда "неестественный" интеллект не работает?

На самом деле, вопрос скорее в том, что этот интеллект не обсуждался публично и не оформлен в виде внятного описания. Единственным описанием является исходный код утилиты, практически без комментариев, без man page и четко задокументированного поведения где-либо. Описание на http://www.altlinux.org/VideoDrivers поведение не конкретизирует.

Если учесть, что используемый метод настройки драйверов является уникальным для ALT Linux и не присутствует более нигде, все это есть прямой путь к путанице.

Конечно, в качестве альтернативы я могу написать и предложить собственную машинерию, но хотелось бы для начала "договориться" в рамках существующего "решения".
Comment 17 Sergey V Turchin 2008-09-08 17:54:07 MSD
(In reply to comment #16)
> Зачем? Я хочу, чтобы машинерия работала, если все требования ей в файловой
> системе удовлетворяют. Согласно предыдущим объяснениям, они удовлетворяют.
Нет пакета -- не удовлетворяют.

> Почему тогда "неестественный" интеллект не работает?
Ручная работа не поддерживается.

> http://www.altlinux.org/VideoDrivers поведение не конкретизирует
Написать, разве что, "руками не лазить".

> Конечно, в качестве альтернативы я могу 
> написать и предложить собственную машинерию
Только мне не верится, что она не продублирует мою.
А так, буду только рад.
Comment 18 Alexander Bokovoy 2008-09-08 18:02:50 MSD
Внутри set_gl_nvidia нет никаких завязок на базу RPM, поэтому говорить о требованиях к наличию пакетов бессмысленно. Файловые зависимости я обеспечил, остальное -- выдумки, не подтвержденные кодом.

Вообщем, понятно, желания сделать более дружелюбным эту часть инфраструктуры нет.
Comment 19 Sergey V Turchin 2008-09-08 18:21:50 MSD
(In reply to comment #18)
> Внутри set_gl_nvidia нет никаких завязок на базу RPM
Есть.

>, поэтому говорить о
> требованиях к наличию пакетов бессмысленно. Файловые зависимости я
> обеспечил,
Если не работает, значит не обеспечил.

> остальное -- выдумки, не подтвержденные кодом.
Телепатию я закодировать не смогу.
 
> Вообщем, понятно, желания сделать более дружелюбным эту часть
> инфраструктуры нет.
Я не смогу догадаться, что там наделает человек руками.

Есть желание, но по другому.
Сделать такой пакет с "драйвером", которому можно подсовывать любой *.run и производить сборку/установку свежескачанного драйвера.
Но, я пока не знаю, как автоматизировать некоторые вещи.
Например, для генерации .xinf у меня есть скрипт, но доверять ему нельзя, т.к. входной README может поменяться когда угодно и как угодно.