Civil писал(а):Siarhei Siamashka
CFLAGS="-O4 -mcpu=iwmmxt -fomit-frame-pointer -ffast-math"
Читаем доки по GCC и узнаём:
1) -O3 - макс. оптимизации. -O4 несуществует
Спасибо, но это я и так знаю, слава богу уже не первый год с gcc работаю. Значение CFLAGS взято один в один из configure скрипта от MPlayer (добавлен только -mcpu), просто чтобы не изобретать ничего лишнего. Все претензии к разработчикам mplayer
2) -fomit-frame-pointer включается при -O1
С маленькой оговоркой:
... on machines where doing so does not interfere with debugging. Так что эта опция не помешает.
Так что правильнее было-бы писать:
CFLAGS="-O3 -mcpu=iwmmxt -ffast-math"
Если уж быть совсем дотошным, то и -ffast-math можно выбросить. Эта опция влияет на floating point код (а ежели таковой встретится при декодировании видео/аудио, то тут будет финиш и уже ничего не поможет, кодеки с использованием floaing point на ARM крайне неэффективны и практически неюзабельны)
Это теория. На практике получается, что опции -mcpu и -mtune нельзя использовать вместе (для ARM), компилятор ругается на несовместимые опции. Комбинировать можно -march и -mtune, но по результатам экспериментов у меня получилось, что по крайней мере на Nokia 770 самый быстрый (и короткий) вариант - просто '-mcpu=arm926ej-s'. Никто не мешает попробовать и другие опции компиляции, если найдется комбинация опций компиляции получше, буду рад узнать ее
Кстати, хотел еще попробовать собирать с -fprofile-generate, -fprofile-use, но в gcc 3.4.4 от CodeSourcery (который используется в SDK для Nokia 770), судя по всему, они не работают.
Поддерживается ли видеоконтроллером преобразование цветов и масштабирование.
На oesf'е писали, что, вроде, pxa270 fb поддерживает поворот и YUV-RGB (точно не помню)
На Nokia 770 все то же самое. Интересно, поддерживает ли pxa270 произвольное масштабирование. Т.е. как zaurus справится с видео, скажем 512x384?
Кстати, только что провел эксперимент по проигрыванию короткого видеоклипа 640x480 30fps mpeg4 700kbps, продолжительностью 4:11 на Nokia 770. На чистое декодирование без отображения тратится 4:10, как раз ровно по длине клипа, естественно, этого недостаточно, но если постараться и оптимизировать код, есть шанс, что будет даже небольшой запас. На декодирование и отображение видео вместе тратится 8:31, но если все-таки прикрутить аппаратную поддержку YUV и избавиться от необходимости преобразования цветов, должно стать намного лучше. Скорость декодирования - самый важный параметр, часть кадров практически безболезненно можно пропустить при отображении, но если их начать пропускать при декодировании (опция -hardframedrop), то появятся довольно заметные артефакты.