| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
Hahahoj
Site Admin
Пол: 
Возраст: 51
Зарегистрирован: 08.10.2008
Сообщения: 1848
Группы:
|
|
Optimus отрелизил последнюю версию своего бечмарка - теста производительности мобильных консолей для GP2X.
С одной стороны - это есть хорошо, с другой - бенчмарк не учитывает наличие у консоли сопроцессора и возможность переложить часть расчетов на него.
Скачать можно на архиве:
http://dl.openhandhelds.org/cgi-bin/gp2x.cgi?0,0,0,0,8,2872
А вот для тех кому интересно мои тесты на реальном железе:
Подробности в комментариях.
_________________
Просто Вовк |
|
| Вернуться к началу |
|
 |
Hahahoj
Site Admin
Пол:
Возраст: 51
Зарегистрирован: 08.10.2008
Сообщения: 1848
Группы:
|
|
Вышеуказанная табличка в цифре:
Итак, в качестве тестовых консолей мной были использованы:
1) Caanoo с последней официальной прошивкой 1.5.0 на штатной частоте 533 Мгц
2) Wiz с последней стоковой официальной прошивкой 1.2.1 на штатной частоте 533 Мгц
3) GP2X F100 MK1 - с неофициальной прошивкой Open2X, бенчмарк запущен в режиме совместимости на штатной частоте 200 Мгц
4) GP2X F100 MK2 - с официальной прошивкой 2.1.2, пропаченной патчем Нотаза на штатной частоте 200 Мгц
5) GP2X F200 - с официальной прошивкой 4.0.Х на штатной частоте 200 Мгц
Отмечу, что консоли имеют сопроцессоры, которые не участвуют в тестировании. Здесь измеряются возможности софтового рендеринга созданного на основе простейших неоптимизированнных под конкретную консоль алгоритмов.
Теперь о результатах.
Если рассматривать все результаты в общем, то видно, что в плане победителя по производительности неоптимизированных под консоль приложений является Виз. Он обогнал Кену почти на 10% практически во всех тестах.
Среди F-ок победитель GP2X F100 MK2 с лучшей прошивкой для F-ок - 2.1.2 Мы видим как миф становится правдой - за счет правильной прошивки производительность консоли увеличивается на 10% (железно МК1 практически соответствует МК2 изменения в железе скорее косметические). Остальные прошивки на F-ках так и плетутся в конце.
Перейдем к конкретным тестам.
Первым рассмотрим тест под названием Blitting test
Этот тест просто заполняет видеопамять данными и меряет таким образом скорость записи в видеопамять.
| Код: | for (int i=0; i<ScreenSize; i++)
{
*vram++ = c;
}
|
В результате подобных действий выясняется, что мы можем расчитывать на 300/140 экранов в секунду, при простой заливке экрана Виза/F-ки нужным нам цветом.
Мало применимо на практике, но позволяет больше не беспокоится об очистке экрана.
Следующий тест Plasma генерирует на экране решетку плазмы. При этом на каждом шаге перестроения экрана мы используем уже не запись одного байта в видеопамять, а комбинацию из простейших операций суммирования и получения табличных данных:
| Код: | for (int y=0; y<ScreenHeight; y++)
{
for (int x=0; x<ScreenWidth; x++)
{
unsigned char c = fsin1[x] + fsin2[y+k1] + fsin3[x+y+k3];
*vram++ = rgb[c];
}
}
|
Этот алгоритм уже позволяет примерно представить производительность приложения при организации простейшего вывода элементарных эффектов.
_________________
Просто Вовк |
|
| Вернуться к началу |
|
|
Hahahoj
Site Admin
Пол:
Возраст: 51
Зарегистрирован: 08.10.2008
Сообщения: 1848
Группы:
|
|
Следующие три теста - позволяют оценить скорость вывода полноценного спрайта, причем отмасштабированным и с поворотом.
Ниже - код отвечающий за этот тест.
| Код: | unsigned short draculin[128 * 128];
void InitRotozoomer()
{
unsigned short dracol[256];
FILE *dracdata;
dracdata=fopen("draculf.bin","rb");
int x0=fgetc(dracdata);
int y0=fgetc(dracdata);
int r,g,b;
for (int i=0;i<256;i++)
dracol[i]=(((fgetc(dracdata)>>1)<<11) | (fgetc(dracdata)<<5) | (fgetc(dracdata))>>1);
for (int y=0;y<y0;y++)
for (int x=0;x<x0;x++)
draculin[(y<<7) + x]=dracol[fgetc(dracdata)];
fclose(dracdata);
}
void RunRotozoomer(float rot, float zoom, unsigned short *vram)
{
int fp = 16;
int mx = 0, my = 0, mmx = 50<<fp, mmy = 20<<fp;
int dx = (int)((cos(rot/d2r)*zoom) * pow(2,fp));
int dy = (int)((sin(rot/d2r)*zoom) * pow(2,fp));
int x,y;
unsigned short c;
for (y=0; y<ScreenHeight; y++)
{
mmx = mmx - dy;
mmy = mmy + dx;
mx = mmx;
my = mmy;
for (x=0; x<ScreenWidth; x++)
{
mx = mx + dx;
my = my + dy;
c = draculin[((mx>>fp)&127) + (((my>>fp)&127) << 7)];
*vram++=c;
}
}
} |
Тесты отличаются друг от друга лишь количеством одновременно выводящихся спрайтов и дистанцией до них соответственно - чем больше дистанция (чем больше спрайтов) тем больше тормоза. Чем меньше - тем меньше.
Следующий тест - Radial Blur идет почти одинаково на всех консолях, но это не удивительно. При формировании итоговой картинки широко используются неоптимизированные операции деления и умножения, очень сильно используются операции чтения памяти.
Ну и последний тест - позволяет оценить скорость с которой рендерится в реальном времени довольно тяжелая моделька кролика состоящая из 69451 полигонов.
Как видим - рендер идет тяжело. Если грубо прикинуть на основе этой цифры, то получим приемлемый для мобильных консолей рендеринг примерно 15 000 полигонов с фпс-ом в районе 15 кадров в секунду.
Если отвлечься от результатов, то по качеству картинки также лидирует Виз (если отбросить элемент тиринга в некоторых частях теста и обратить внимание на итоговое качество картинки). Затем идет GP2X F200, GP2X F100 MK2 и Caanoo. Замыкает GP2X F100 MK1 (на итоговой картинке достаточно чётко видны скайнлайны).
_________________
Просто Вовк
Последний раз редактировалось: Hahahoj (Вс Янв 02, 2011 4:16 pm), всего редактировалось 2 раз(а) |
|
| Вернуться к началу |
|
|
PheeL
Постоялец
Пол:
Возраст: 46
Зарегистрирован: 10.11.2010
Сообщения: 60
Группы: Нет
|
|
| Только не забываем, что 1.5.0 на Кену тормозная прошивка. Но в любом случае Кену Виз никогда не обгонит чисто из-за аппаратных различий. Но разница будет укладываться примерно в 5-10%. |
|
| Вернуться к началу |
|
|
Hahahoj
Site Admin
Пол:
Возраст: 51
Зарегистрирован: 08.10.2008
Сообщения: 1848
Группы:
|
|
К сожалению на данный момент это следующая базовая прошивка для консоли - только на ней нормально пашут продаваемые в России вифи-свистки.
Хотя думаю, что знаю способ запустить их и на младших прошивках, но проверить не на чем.
И всё-таки даже железно Кену немного тормознее сородича - это было заметно на всех прошивках, что у меня были (а это значить на всех прошивках, что официально выходили).
Как думаю разница за счет таймингов экрана и памяти. Но в принципе разница всё равно не особо существенна. Пара-тройка фпс погоду в тормозящих вещах не делают, в нетормозящих же и так всё более менее.
_________________
Просто Вовк |
|
| Вернуться к началу |
|
|
ainu
Местный
Возраст: 37
Зарегистрирован: 13.11.2010
Сообщения: 133
Группы: Нет
|
|
Я уже долго подозреваю какого-то демона, который следит за рычажком звука и сидит в памяти. Также оно следит за usb, за батарейкой (при моменте, когда она садится - выводится изображение).
Хотелось бы конечно увидеть результаты теста деформации изображения (для текстур в трёхмерной графике, мы видим их в tekken advance на GBA, и в псевдо-трёмхмерных играх Sega и GBA). Код на Си есть, сейчас картинку 200 на 200 сжимает с результатом 60 FPS на PC (Windows, Turion 2.2 ГГц, software) и примерно раз в 5-7 медленнее на caanoo.
Также большой вопрос битности экрана caanoo. Кто нибудь вообще знает на него ответ - он 24 или 16 битный? потому что программам надо еще переводить туда-сюда, а значит, тратить время. fbset -i говорит, что на самом деле 24 битный, но в Qt, например. выполняется 16 битный код, да и Qt собранный без поддержки 16 биного цвета тупо не запустится. |
|
| Вернуться к началу |
|
|
PheeL
Постоялец
Пол:
Возраст: 46
Зарегистрирован: 10.11.2010
Сообщения: 60
Группы: Нет
|
|
| Совсем точно я не скажу, это надо смотреть в даташиты на экран и LCD контроллер, но я знаю, что когда создаётся экранный сурфейс в SDL для Кену, то он 16-ти битный. И я бы не стал слепо верить всяким линуксовым приблудам, когда идут вопросы об аппаратуре. |
|
| Вернуться к началу |
|
|
Hahahoj
Site Admin
Пол:
Возраст: 51
Зарегистрирован: 08.10.2008
Сообщения: 1848
Группы:
|
|
Ainu, если иметь фантазию, то вопросы могут действительно замучить до смерти.
Так к примеру в GPH Platform Development Guide нам настойчиво рекомендуют делать все тайтлбары 32 битными (по 8 бит на цветовой компонент + 8 бит на альфу).
И в то же время там вполне ясно написано:
| Цитата: | Although the framebuffer of the terminal is set to 16 bit (R5G6B5) for WIZ and 24
bit (R8G8B8) for CAANOO, the DGE requires setting to 16 bit (R5G6B5) |
Т.е. физически 24 бита но для использования DGE и SDL-а должны использоваться 16-ти битные сурфейсы.
_________________
Просто Вовк |
|
| Вернуться к началу |
|
|
ainu
Местный
Возраст: 37
Зарегистрирован: 13.11.2010
Сообщения: 133
Группы: Нет
|
|
| Hahahoj писал(а): |
Т.е. физически 24 бита но для использования DGE и SDL-а должны использоваться 16-ти битные сурфейсы. |
Из-за этой оказии в Qt не работает OpenGl. Придётся ждать реализации Qt от тех, кто может залезть в саму прошивку. В любом случае преобразования софтварных 16 бит в хардварные 24 должны занимать кусочек процессорного времени. Отсюда и возможные задержки. |
|
| Вернуться к началу |
|
|
Hahahoj
Site Admin
Пол:
Возраст: 51
Зарегистрирован: 08.10.2008
Сообщения: 1848
Группы:
|
|
Да, вполне может быть и так. Смущает только наличие библиотек сдл-а с хардварной акселерацией и поддержкой тех же 16 битных сурфейсов. В принципе это всего лишь режим в котором данные нативно воспринимаются конкретным железом консоли, я не уверен что есть какое-то промежуточное чисто софтовое преобразование поверхностей.
_________________
Просто Вовк |
|
| Вернуться к началу |
|
|
PheeL
Постоялец
Пол:
Возраст: 46
Зарегистрирован: 10.11.2010
Сообщения: 60
Группы: Нет
|
|
| Hahahoj писал(а): | | Т.е. физически 24 бита но для использования DGE и SDL-а должны использоваться 16-ти битные сурфейсы. |
Это ещё бабушка на двое сказала. Тебе позволяют грузить картинки хоть в труколоре, но перед выводом на экран ты обязан преобразовать битмап в нативный режим т.е. 16-ти битный. На SDL-е это реализуется с помощью функции SDL_ConvertSurface();
А вообще, если говорить грубо, мы тут сейчас занимаемся полной хернёй. На самом деле все ответы давно написаны в даташитах на железо и пока мы все их не прочтём, говорить тут что-либо бессмысленно. |
|
| Вернуться к началу |
|
|
ainu
Местный
Возраст: 37
Зарегистрирован: 13.11.2010
Сообщения: 133
Группы: Нет
|
|
| Хернёй назвать это нельзя, ведь вдруг появится супермен и скажет: «а вот такой командой и вот такой конфигой экран переключается в режим 24 бита, теперь OpenGL должен запуститься.» |
|
| Вернуться к началу |
|
|
Hahahoj
Site Admin
Пол:
Возраст: 51
Зарегистрирован: 08.10.2008
Сообщения: 1848
Группы:
|
|
| PheeL писал(а): | | Hahahoj писал(а): | | Т.е. физически 24 бита но для использования DGE и SDL-а должны использоваться 16-ти битные сурфейсы. |
Это ещё бабушка на двое сказала. . |
Бабушка ничего не говорило. Читай внимательно - то что процитировал там я написано в официальной инструкции по программированию консоли именно про режим в котором должно работать приложение, а не должен юзаться тайтлбар.
По остальным пунктам согласен, в принципе я тоже про то же.
_________________
Просто Вовк |
|
| Вернуться к началу |
|
|
|
FAQ
Поиск
Пользователи
Группы
Регистрация
Профиль
Судоку
Войти и проверить личные сообщения
Вход
Модераторы
