Mplayer && Wine && xorg-server && вещества

[kernel_panic]

Вот PKGBUILD'ы, можт кому понадобятся. В AUR заливать не буду.
1).Mplayer только с VDPAU Gl и ALSA. с --disable-network собрать не удалось. (правда выпилен amr_nb ,amr_wb. Любители смотреть ролики йамобилко будут довольствоваться только изображением. Кто не хочет собирать со своими флагами пусть добавит unset CFLAGS к LDFLAGS.
2)Wine Выпилил все че мне не надо (я в нем только Call of Duty4 запускаю и то редко) Ставится в /opt . Слинковать пару бинарников думаю труда не составит.
3)xorg-server.(1.7.4) патчей нет,HAL'a нет, DBUS'a нет. есть только композит и OpenGL. Вобщем то все тоже самое выпилено все что не нужно мне. пути шрифтов сами ковыряйте)).

Все собиралось с CFLAGS="-O2 -march=core2 -mtune=core2 --param l1-cache-size=64 --param l2-cache-size=4096 -funroll-loops -ffast-math -fomit-frame-pointer -pipe"

P.S. Да я знаю что Арч бинарный дистрибутив.

(цэ) All Rights reserved.

[zubastiy]

ух.
реквестирую соображения!
всякие input и бла бла думаю перекомпиливать не имеет смысла, но вот дрова для видео уже хотелось бы (я так думаю, что будет хорошо, для lowarch машины) - не занимались?

[kernel_panic]

ух.
реквестирую соображения!
всякие input и бла бла думаю перекомпиливать не имеет смысла, но вот дрова для видео уже хотелось бы (я так думаю, что будет хорошо, для lowarch машины) - не занимались?

Если это мне то не совсем понял про перекомпилировать дрова на видео. Я колючий кактус юзаю и модуль ядра Nvidia пересобираю после обновления ядра. input пересобирать ИМХО смысла не имеет конечно же

[zubastiy]

у меня многочисленные реализации via - дрова из ядра ... мягко скажем не очень.
openchrome спасает )

[vadik]

у меня многочисленные реализации via - дрова из ядра ... мягко скажем не очень.
openchrome спасает )

А можно "по-русски", ато я не понял чего не очень и что спасает. Но тоже интересно поскольку тоже есть старенькая via (материнка) и хотелось бы выжать из нее хоть на пару капель больше.

[zubastiy]

у меня многочисленные реализации via - дрова из ядра ... мягко скажем не очень.
openchrome спасает )

А можно "по-русски", ато я не понял чего не очень и что спасает. Но тоже интересно поскольку тоже есть старенькая via (материнка) и хотелось бы выжать из нее хоть на пару капель больше.

драйвера для виа из ядра очень неспешные. openchrome работает быстрее и дает больше вкусностей ... а иногда и единственный выбор (для VX800 и VX855 родных дров просто нет, via поет песни о новых дровах в ядре 2.6.32 ... потом 33 ... потом 34 ... я уже как то перестал надеятся)

гляньте по поддерживаемому железу http://openchrome.org/trac/wiki/SupportedHardware

на текущий момент у меня ноутбук с видеоподсистемой via chrome 9 (VX800)- дров для него в ядре нет, в Х работает xf86-video-openchrome (только 2D) никаких плюшек типа 3D accel. XV MPEG2 MPEG4 Но c 833 релиза появилось xvmc http://openchrome.org/trac/changeset/833
что дает по факту еще не пробовал )

еще на работе есть конфиги с CLE266 и P4M800PRO - там с openchrome вообще замечательно.

мне было бы интересно попробовать собрать openchrome с оптимизацией под определенный процессор.
но увы, времени на полноценное тестирование не хватает.

если хотите - попробуйте в makepkg.conf изменить флаги оптимизации под ваш проц и пересобрать пакет, проще всего будет сделать с пакетом из AUR - yaourt -S openchrome-svn (из зависимостей PKGBUILD надо выкинуть versionpkg - давнишний баг, мейнтейнер все никак не поправит)

http://en.gentoo-wiki.com/wiki/Safe_Cflags - флаги для процов. даю ссылку на генту, ибо на арчвики нет упоминаний о процах via.

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

2kernel_panic
один гентушник советовал мне собирать xorg с опцией VIDEO_CARDS="via"
ума не приложу куда его в PKGBUILD запихивать, может есть знания на эту тему? ... и интересно, что это дает )

[kernel_panic]

2kernel_panic
один гентушник советовал мне собирать xorg с опцией VIDEO_CARDS="via"
ума не приложу куда его в PKGBUILD запихивать, может есть знания на эту тему? ... и интересно, что это дает )

Лицопальма.PSD

[zubastiy]

2kernel_panic
один гентушник советовал мне собирать xorg с опцией VIDEO_CARDS="via"
ума не приложу куда его в PKGBUILD запихивать, может есть знания на эту тему? ... и интересно, что это дает )

Лицопальма.PSD

стесянюсь спросить - что вызывало столь бурные эмоции?

[Amigo]

стесянюсь спросить - что вызывало столь бурные эмоции?

Скажи другу, что ты не гентушнег.

[zubastiy]

стесянюсь спросить - что вызывало столь бурные эмоции?

Скажи другу, что ты не гентушнег.

ясно. спасибо за расшифровку.

[zubastiy]

собрал "облегченный" mplayer
из репов mplayer занимает в памяти 64 мб
собранный с минимальным колвом флаго (до кучи выкинул и vdpau) - 60 мб
потребление проца - одинаково в обоих вариантах.
... может ffmpeg до кучи пересобрать? )

[kernel_panic]

собрал "облегченный" mplayer
из репов mplayer занимает в памяти 64 мб
собранный с минимальным колвом флаго (до кучи выкинул и vdpau) - 60 мб
потребление проца - одинаково в обоих вариантах.
... может ffmpeg до кучи пересобрать? )

Сам думай,у меня его вообще нет. В бытность использования totem-xine я собирал FFmpeg но давно это было.

[zubastiy]

собрал "облегченный" mplayer
из репов mplayer занимает в памяти 64 мб
собранный с минимальным колвом флаго (до кучи выкинул и vdpau) - 60 мб
потребление проца - одинаково в обоих вариантах.
... может ffmpeg до кучи пересобрать? )

Сам думай,у меня его вообще нет. В бытность использования totem-xine я собирал FFmpeg но давно это было.

была почему то уверенность, что mplayer его использует.
sudo pacman -R ffmpeg
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: mpd: requires ffmpeg>=20100108
:: transcode: requires ffmpeg>=20100108
:: winff: requires ffmpeg
похоже что mplayer не использует ffmpeg

пересобрал mplayer на нетбуке (проц VIA NANO u2250)с флагами -march=native -mtune=native -O2 (до этого компилил на ББ с явным указанием архитектуры и прочих параметров)
тестировал на воспроизведении одного и того же фрагмента файла 720р, сравнивал загрузку CPU
в виду слабого проца и отсутствия аппаратной поддержки видео каждый CPU score на счету - больше 15 процентов времени CPU idle - 0% )
версия 286 vs 325 (из репов) - в местах интенсивного экшена версия 352 потребляла на 1-1.5 процента меньше проца, 5-7% времени CPU idle - 0%
версия 325 (из репов) vs 325 (-march=native -mtune=native -O2) в местах интенсивного экшена версия оптимизированная версия потребляла на 1-1.3 процента меньше проца, 1-2% времени CPU idle - 0% в одном самом насыщенном по смене кадров отрезке CPU idle держалось 0.3% - 0.7%

собрал с -march=native -mtune=native -Os (хоть и пишут, что такое актуально только для совсем маленьких кешей L2, но было интересно)
в целом пакет с оптимизацией Os хуже по производительности на процент-полтора чем пакет из репов, но в одной сцене где все остальные варианты сброки гарантированно сжирали проц - CPU idle был 1.5 процента.

собрал с -march=native -mtune=native -O3
лучший по производительности вариант в тяжелых условиях. в самых сложных сценах CPU idle держалось 1.3% - 3.0% но в одной сцене (где у остальных сборок CPU idle 8-9) CPU idle две-три секунды - 0%
в целом проц в варианте сборки -march=native -mtune=native -O3 загружен больше, но меньше случаев когда CPU idle равно 0.

как то так.

[kernel_panic]

В сборке с "-O3" тормоза в одной сцене могли просто совпасть например с обновлением журнала ФС,либо еще с чем то. Если на протяжении всего тестируемого отрезка на сборке с O3 cpu idle был 3-8% а на других почти всегда 0% то ИМХО лучше собирать с O3, если не появятся другие глюки. Я обычно после сборки тестирую пакет около недели и если все нормально закидываю пакет и ебилд к нему в папку "stable"

[zubastiy]

В сборке с "-O3" тормоза в одной сцене могли просто совпасть например с обновлением журнала ФС,либо еще с чем то. Если на протяжении всего тестируемого отрезка на сборке с O3 cpu idle был 3-8% а на других почти всегда 0% то ИМХО лучше собирать с O3, если не появятся другие глюки. Я обычно после сборки тестирую пакет около недели и если все нормально закидываю пакет и ебилд к нему в папку "stable"

Перепроверял результат.
Именно в опеределенной сцене (полная перерисовка, при этом предыдущий кадр был в темных тонах, в следующем преобладает белый цвет) был провал в производительности. внешнее влияние, думаю, можно исключить.
как ни странно О3 сборка в среднем потребляля больше проца, но при этом было меньше ситуаций где mplayer был бы вынужден дропать фреймы

похоже, что тестировать оптимизированные приложения нужно на низко частотных проца, ибо на быстрощелкающих 0.1-0.2 процента прироста можно и не заметить )

UPD
Докладаюсь.
Пересобрал X (в отличии от варианта предложенного в старттопике пришлось включить vgahw - так требует видеодрайвер)
тестировал пересобранный mplayer + тот же 720p
O2 O3 Os - разницы не увидел на проце
разницы в колве потребляемой оперативки - не увидел (при старте вариант из репов и пересобранный весят 16 мб .. наверное потому что Xorg конф у меня и так не богат на модули)
по сравнению с предыдущей минорной версией из репов (не помню версию) - обновленный xorg и пересобранный менее процессороемкие.

разница между вариантом из репов и пересобранным

смотрел потребление проца X, показания CPU idle укладываются в различия между старыми и новыми показателями.

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

для себя пока не вижу смысла пересобирать xorg
цпу жрет точно так же, оперативку - точно так же.

если у кого есть другие мысли и результаты - просьба высказаться.