Created attachment 2894 [details] Системный лог при обновлениях Система: VIA EPIA SP8000, почти последний Сизиф (кроме ядра, mplayer, ffmpeg, firefox). Ядро: 2.6.25-std-def-alt8 $ rpm -qa |grep 'kernel.*std-def.*8$' kernel-modules-subfs-std-def-0.9-alt10.2.132633.8 kernel-image-std-def-2.6.25-alt8 kernel-modules-drm-std-def-2008.04.28-alt1.132633.8 kernel-modules-alsa-std-def-1.0.16-alt4.132633.8 (разглядывая логи, увидел, что предварительно обновил libX11 и libX11-locales, и потом их не откатил). Обновил xorg и dri (см. лог). Получил втрое меньшую Throughput при Benchmarking video copy (и на глаз окна стали рисоваться заметно медленнее). См. логи X'ов до и после обновления. Проигрывание mpeg2 через аппаратное декодирование (XvMC) не изменилось. Вернул прежние версии xorg и dri (см. лог). Throughput восстановилась, пропал /etc/X11/xorg.conf (см. лог X после downgrade). Восстановил /etc/X11/xorg.conf, всё стало как до обновления (см. лог X после восстановления xorg.conf). PS. Не уверен насчёт времени пропадания xorg.conf, могло произойти и при работе новых X'ов, и при их downgrade. PPS. Извиняюсь, в восстановленном xorg.conf поменял DisplaySize.
Created attachment 2895 [details] Xorg log до обновления
Created attachment 2896 [details] Xorg log после обновления
Created attachment 2897 [details] Xorg log после отката
Created attachment 2898 [details] Xorg log после отката и восстановления xorg.conf
Created attachment 2899 [details] Восстановленный xorg.conf
не понятно куда делся /usr/lib/X11/modules/dri/unichrome_dri.so и почему вместо него грузится swrast_so.dri
xorg-server-1.5.0-alt4
У меня тоже проблема с низкой производительностью на Trident CyberBlade после обновления X-ов Откатываться назад, или есть решение проблемы?
Created attachment 2907 [details] логи X-ов после обновления rpm -qa | grep std-def kernel-modules-drm-std-def-2008.04.28-alt1.132633.9 kernel-headers-std-def-2.6.25-alt9 kernel-modules-alsa-std-def-1.0.16-alt4.132633.9 kernel-headers-modules-std-def-2.6.25-alt9 kernel-modules-kqemu-std-def-1.3.0-alt0.1.pre11.132633.9 kernel-image-std-def-2.6.25-alt9
[root@irbis ~]# rpm -q xorg-server xorg-server-1.5.0-alt4
у драйвера trident никогда не было dri. т.ч. той же проблемы быть не может
(In reply to comment #11) > у драйвера trident никогда не было dri. т.ч. той же проблемы быть не может > Ок, может быть это другая проблема, но симптомы те же. Я теперь знаю, что окно перерисовывается небольшими квадратными кусочками слева-направо сверху-вниз, чего раньше заметно не было. В понедельник померяю скорость fill copy, чтобы сравнить результаты с чем-нибудь типа Desktop 4.0 Live CD. Я знаю, что для неё не было dri, нет никакого 3D, но 2D раньше худо-бедно работало, а сейчас перезаливка экрана сильно портит зрение.
Section "ServerFlags" ... Option "AIGLX" "false" EndSection Section "Extensions" ... Option "GLX" "false" EndSection
(In reply to comment #7) > xorg-server-1.5.0-alt4 В скорости копирования ничего не изменилось -- по-прежнему втрое меньше (AIGLX теперь enabled, грузится /usr/lib/X11/modules/dri/unichrome_dri.so). Если сделать Option "AIGLX" "false" , то AIGLX disabled, грузится swrast_dri.so, скорость всё та же. А это должно влиять? По крайней мере, в Xorg.0.log сообщения о Throughput при Benchmarking video copy идут раньше сообщений о загрузке unichrome_dri.so или swrast_dri.so . И до обновления AIGLX у меня был disabled, а скорость нормальная.
визуально эти циферки в Throughput на что то влияют?
(In reply to comment #15) > визуально эти циферки в Throughput на что то влияют? Рисование большого поля на экране стало заметно на глаз. Т.е., распахивание окна терминала на максимум (или убирание окна) теперь на глаз не событие, а процесс. Подробнее пока не смотрел (попробую видео без аппаратного ускорения, ещё какое-нибудь рисование).
вот список опций для XAA XaaNoScreenToScreenCopy XaaNoSolidFillRect XaaNoSolidFillTrap XaaNoSolidTwoPointLine XaaNoSolidBresenhamLine XaaNoSolidHorVertLine XaaNoDashedTwoPointLine XaaNoDashedBresenhamLine XaaNoMono8x8PatternFillRect XaaNoMono8x8PatternFillTrap XaaNoColor8x8PatternFillRect XaaNoColor8x8PatternFillTrap XaaNoCPUToScreenColorExpandFill XaaNoScanlineCPUToScreenColorExpandFill XaaNoScreenToScreenColorExpandFill XaaNoImageWriteRect XaaNoScanlineImageWriteRect XaaNoWriteBitmap XaaNoWritePixmap XaaNoPixmapCache XaaNoOffscreenPixmaps XaaOffscreenPixmaps подробности в xorg.conf(5), вот с ними и надо разбираться
(In reply to comment #13) Мне это как-то помогло. Т.е. скорость визуально стала примерно такая, как была раньше. Спасибо.
(In reply to comment #17) Да, XaaOffscreenPixmaps помогло в отрисовывании окон. Throughput в Xorg.0.log остался маленьким. Пока не знаю, на что это влияет.
влияет на выбор метода для "video copy". что быстрее, через то и пойдет
(In reply to comment #18) > Мне это как-то помогло. Что именно?
(In reply to comment #21) > (In reply to comment #18) > > Мне это как-то помогло. > Что именно? > Вот это : Section "ServerFlags" ... Option "AIGLX" "false" EndSection Section "Extensions" ... Option "GLX" "false" EndSection Я так понимаю, что драйвер trident обладает некими минимальными возможностями по 2D, которые swrast_so.dri вообще не использует.И отключение glx вообще возвращает хотя-бы эти минимальные возможности.
можно еще попробовать убрать все это и добавить Section "Screen" ... Option "XaaOffscreenPixmaps" "true" ... EndSection если результат будет тот же, то это намного проще исправить
(In reply to comment #23) > можно еще попробовать убрать все это и добавить > Section "Screen" > ... > Option "XaaOffscreenPixmaps" "true" > ... > EndSection > если результат будет тот же, то это намного проще исправить > Не, не выходит каменный цветок. Если не делать Option "GLX" "false", то при наличии более одной сессии иксов при переключении по Ctrl-Alt-Fn получается пустой экран с курсором. И всё. Система работает, если срубить иксы, то можно их потом опять запустить.
На P4M800Pro/VN800/CN700 сейчас (xorg-drv-openchrome-0.2.903-alt4) в 2D тормозов не наблюдаю. Конфиг/лог см. здесь: https://bugzilla.altlinux.org/show_bug.cgi?id=14952#c8
