Board.KolibriOS.org

Не может быть! Он же раз в 100 мощнее eBox, как так?

yogev_ezra
Тут дело не в процессоре, а в том как и через что реализован обмен с памятью для видео.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

Radeon HD 7770. Слева результаты с загруженным atikms

SVN r. 3377 - добавлен бенчмарк для ф.36 (прочитать область экрана).

Теперь можно оценить насколько скорость чтения из видеопамяти отстает от скорости записи в нее.

Roverbook U800

Dell Inspiron N7010 (Intel i5)

Два столбца замеров - это просто два последовательных запуска.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

Хорошие скриншоты, интересные данные.
Интересно, а что будет, если загрузить старый файл pattern в новую версию?

Будут неправильные позиции начиная с 3-ей. Последние будут пустыми. Файл вообще с запасом.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

SVN r. 3446 - добавлен бенчмарк для получения данных с помощью регистра GS (прочитать область экрана).

Очередные тесты на самом дохлом и самом быстром доступном мне оборудовании.

Roverbook U800


Dell Inspiron N7010 (Intel i5)


Как можно заметить на более мощном Dell разница между ф.36 и чтением через GS минимальна. Вероятно сказывается большой кэш процессора.
Минус метода с использованием GS вместо ф.36, то что курсор попавший в захватываемую зону будет отражен в буфере, а если он еще и двигаться будет в этот момент, то будут его ошметки размазанные по случайным участкам. В общем кроме Screenshooter пока сложно придумать применение данному способу захвата изображения.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

Мой старый тест 07 марта 2013 из этой же темы viewtopic.php?p=46811#p46811 (курсор вне окна)


И новый тест. Ядро r3596, результаты поразительные, проседание только в рисовании вертикальных линий.

Может и остальные, повторите этот тест. Интересно было бы если бы кто-то прогнал вначале старую версию Колибри, потом последнюю, чтобы оценить как внесённые за это время изменения отразились на производительности UI.

_________________
Через тернии к звездам

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

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

SVN r. 3782 - добавлен бенчмарк вывода текста ф.4 в память, с последующим выводом ф.65.

В Qemu (по грубым прикидкам) такой вывод дает ускорение в 7-8 раз. Нужно тестировать на реальном железе.
Ускорение получается из-за последовательной записи в видеопамять, в то время как запись просто ф.4 происходит в непоследовательные ячейки.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

Поскольку все настолько заняты разглядыванием буковок в форуме, то я решил протестировать сам.
1) Dell Inspiron

2) eBox

3)Roverbook U800

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

А теперь фокус-покус (следите за руками), берем код:

и меняем местами два буфера

Получаем:
1) Dell Inspiron

2) eBox

3) Roverbook U800

С чем связано такое поведение ядерного кода не понятно.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

Однако все равно прирост на слабых машинах для ф.4 с выводом в память и последующим выводом буфера весьма значителен, чем просто вывод текста на экран.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

А в чём там разница в результатах, с порядком выделения буферов ?

Странно, что Fixed-width Text(m) и Proportional Text(m) имеют стабильные показатели на всех компьютерах, которыми меняются при обмене буферами.