CleverMouse wrote:qemu при настройках по умолчанию эмулирует видеокарту Cirrus, не знающую про 32-битные видеорежимы - только 8-, 16- и 24-битные. Я считаю, что не стоит выкидывать код для 24-битного VESA2 - в том числе выкидывать из бинарного файла ядра условной компиляцией - по крайней мере, пока не будет 16-битного VESA2.

Синьорита,
Вы дарите нашему занудному форуму всего пять с половиной слов в день,
(в среднем)
Но каждое Ваше слово - чистое золото!

Всё, решение принято - транк остается многорежимным, весь экстрим переносится в экспериментальную Колибри-А, откуда желающие всегда могут выудить для себя что-нибудь полезное.

(голосование и обмен мнениями продолжаются)

art_zh wrote: о том и речь: реальное ускорение будет при буферизации оконной графики с последующим "построчным" копированием окна в главный фреймбуфер.
Нет блиттера - и movsd сгодится...

Пока несколько не понятно какой размер памяти стоит выделять под такую операцию. Выделять такой-же объем как сама отображаемая видеопамять - жаба давит.

Хотя с другой стороны именно так я в свое время ускорил запись в VGA режиме. Вернее там уже был буфер, но память записывалась попиксельно, а буфер использовался исключительно для операций чтения - возвращения 24-х битового значения точки. Учитывая, что для каждого цветового семпла приходилось устанавливать свой флаг, то запись производится в три захода для каждой точки. Если же записывать не одну точку в 4 бита а все 32 бита, то ускорение получилось значительное. А потом вообще реализовал запись областями. Т.е. запоминаются предельные границы измененного прямоугольника, они выравниваются на границу dword записываемого в VGA. Дальше копируется построчно весь блок.

В случае 24-х и 32-х битного режима для горизонтальной линии вероятно придется копировать непрерывный кусок в экран. Не сожрут ли накладные расходы по пересылке пустых dword получающийся прирост еще вопрос неопределенный. Может статься, что и овчинка выделки не окупит.

Mario
Да, если нет аппаратного ускорения (по крайней мере в виде пакетных пересылок данных), то из всей затеи выйдет пшик.
Или надо делать очень громоздкую проверку контента, чтобы не перегружать всё окно ради одной точки.

Serge
В версии 1710 я сделал экранную карту некэшируемой. В результате производительность графики упала в разы.
Особенно заметно замедление на 2-мерных примитивах: прямоугольник - в 20 раз, рисунок - в 24, окно - в 17.
Линии теперь рисуются с одинаковой скоростью: вертикальная - 13.9тыс линий в секунду (почти вдвое медленнее), горизонтальная -18тыс (но она на 30% короче), наклонная - 13700 (в ней больше точек).
Текстовый вывод замедляется почти в 4 раза, случайные пиксели - в 2.3 раза.

Так что дело все-таки не во write-combined буфере вывода, а в системном кэше, однозначно.
(кстати, в этом можно было убедиться и не ковыряя ядро - просто прогони тест MGB при разных видеорежимах - чем меньше точек, тем быстрее работает)

art_zh

Ну естественно. У тебя процессор просто встал на чтении карты. По одному байту за цикл. Некешируемая память - никакой предвыборки, запись и чтение строго упорядоченны. Скорость видеопамяти здесь уже не играет роли. слева транк, справа видеопямять без write combining. Видно что сильнее всего просела hline со строго последовательным доступом. А теперь сравним:
vline 350*36981=12 943 350
hline 270*47656=12 867 120 - обе близко к результатам Single Pixel.
для сравнения write combining hline
139616*270*4 =143.8 Mb/c близко максимальной скорости записи.

Кстати после первого вызова hline и vline данные из оконной карты будут в кеше L2 и сравнительное влияние промахов кеша на скорость при последующих вызовах очень сильно уменьшится.

Serge
Да, предвыборка экранной карты может где-то помочь при выводе фигур, символов, горизонтальных и (возможно) наклонных линий, но это - малосущественные детали.

Главное - что эксперимент однозначно показал: основная причина всех задержек - это малоэффективная проверка попадания каждого пикселя в открытую область рисования. Там, где эти проверки можно минимизировать/кэшировать, скорость зашкаливает за 100 мегапикселей в секунду, тогда как совсем некэшируемые проверки тормозят процесс до 2-4 Мпс.

Еще раз проимхою свою мысль: попиксельная карта экрана - это идиотизм в клинической стадии, и кэширование этой таблицы только усугубляет проблему, а не снимает ее.

art_zh wrote:Serge
Еще раз проимхою свою мысль: попиксельная карта экрана - это идиотизм в клинической стадии, и кэширование этой таблицы только усугубляет проблему, а не снимает ее.

Пока что никто не реализовал лучше. Особенно чтобы в тесте заметно было.

В свое время Иван Поддубный переписал на пересылку DWORD и WORD, в Menuet вообще было побайтная пересылка - скорость возросла в 1,5-2 раза.

art_zh

Вот как раз однозначно и не показал. Смотри мои результаты выше. hline с транка практически упирается в скорость записи для моей системы.

Serge wrote:Вот как раз однозначно и не показал. Смотри мои результаты выше. hline с транка практически упирается в скорость записи для моей системы.

1)Ты убрал write-combining, и скорость hline села в 3 раза. Я убрал кэширование - падение в 21 раз. И какой эффект эффектнее?

2) мою hline-скорость после пляски с бубном удалось-таки поднять на 20% по сравнению с транком (см. скриншот на 3-й странице). И сдается мне, что это еще не предел.

Но опять-таки, это только для hline (и с оговорками - для некоторых горизонтально-заливаемых фигур). Только для них кэширование экранной карты имеет смысл благодаря очень высокому проценту попаданий. Отключи кэширование (при побайтной проверке таблицы) - и hline в точности сравняется в скорости с vline. Надеюсь, хоть с этим вы с Mario согласитесь ?

3) На всем остальном кэширование дает очень скромный прирост (в 2-4 раза) по сравнению с проверкой по некэшируемой байт-таблице. И это - на моторах с мегабайтыми кэшами! Чем короче кэш - тем скромнее фифект.

4) Но суть то и не в этом (ну казалось бы работает - и кэш с ним, пусть работает). Но ведь эта экранная карта занимает до 9Мб памяти, она даже в Феномовский кэш целиком не влезет. И даже во времена VGA не влезала (тогда кэшей таких не было). Значит, все разговоры о том, что ядро Колибри "почти целиком" сидит в процессорном кэше - пустая болтовня. Могло бы там сидеть, но его оттуда сдувает любое переключение окошка...

5) Может, и это оставим как оно есть?

art_zh wrote: 5) Может, и это оставим как оно есть?

Не, хочу обидеть, но... я отписал об этом вероятно самым первым.

art_zh

9 Мб ??? У нас таких режимов нет. _WinMapAddress - 1 байт на пиксель.

3) Отключи кэширование (при побайтной проверке таблицы) - и hline в точности сравняется в скорости с vline. Надеюсь, хоть с этим вы с Mario согласитесь ?

Я не сомневаюсь, что сравняются. Обе намертво упёрлись в чтение из некешированной таблицы. Для процессора это жуткий тормоз. То есть с отключённым кешированием процессор еле выдаёт 4.8 мегапикселя в секунду.

Сделай тесты без проверки таблицы или вообще с прямым доступом к видеопамяти и ты получишь близкие результаты и для vline и для single pixel. Обе функции показывают максимальную скорость заполнения видеопамяти при произвольном доступе. И обе в неё упираются в обычном ядре.

Сравнительные результаты MGB для vline и hline в обычном ядре очень слабо зависят от кеша. После первого вызова функций все необходимые данные из байтовой таблицы будут в L1 кеше. 270 байт hline и 350*16 или 350*32 hline по сравнению 64 кБ L1 data на Атлонах совсем немного. В этих тестах процессор работает с максимально возможной скоростью и на 99.9% процентов не вылазит из L1 кеша. По этому разница в скорости заполнения vline и hline вызвана не промахами кеша, их там очень очень мало, а особенностями работы комбинированной записи.

Serge wrote:9 Мб ??? У нас таких режимов нет. _WinMapAddress - 1 байт на пиксель.

пардон, 1920x1200 = 2 300 000. К феному в L3 может и влезет.

Serge wrote:Сделай тесты без проверки таблицы или вообще с прямым доступом к видеопамяти и ты получишь близкие результаты и для vline и для single pixel. Обе функции показывают максимальную скорость заполнения видеопамяти при произвольном доступе. И обе в неё упираются в обычном ядре.

Байтовая карта экрана эффективно работает только для горизонтально-заливаемых линий / фигур. Но на негоризонтальных линиях, свободных пикселях и тексте процент попадания в кэш очень невысок, поэтому в обычном ядре ни vline, ни putpixel совсем не "упираются" в максимальную скорость.

Serge wrote:Сравнительные результаты MGB для vline и hline в обычном ядре очень слабо зависят от кеша. После первого вызова функций все необходимые данные из байтовой таблицы будут в L1 кеше. 270 байт hline и 350*16 или 350*32 hline по сравнению 64 кБ L1 data на Атлонах совсем немного. В этих тестах процессор работает с максимально возможной скоростью и на 99.9% процентов не вылазит из L1 кеша. По этому разница в скорости заполнения vline и hline вызвана не промахами кеша, их там очень очень мало, а особенностями работы комбинированной записи.

Про hline - согласен. А вот для vline придется закачивать в кэш 350 строчек (в каждой кэш-строке 64байт, емнип), так что для полного кэширования одной-единственной vline-карты потребуется 350x64=22кбайт. Для случайных пикселей и текста все гораздо хуже: придется кэшировать карту всей области рисования. Хуже всего - при полнооконном рисовании, а также при перемещении/переключении окон - там кэш забивается дурными данными для всех видимых областей всех окон.

При этом сама 2мегабайтная таблица состоит из нескольких широченных полей, всю информацию из которых можно упаковать в 100-200 байт...
Если это не идиотизм, то что?

P.S. Вот еще пища для размышлений:

На ядре 1710 (с обескэшеной таблицей) я попробовал прогнать цифродробилку FHT.
Результат (время вычисления FHT по 1024 точкам) = 68533 плюс-минус 122 такта
с включенным кэшированием экранной таблицы : 68976 плюс-минус 487 тактов
замер проводился по 32 прогонам

art_zh wrote: При этом сама 2мегабайтная таблица состоит из нескольких широченных полей, всю информацию из которых можно упаковать в 100-200 байт...
Если это не идиотизм, то что?

Я уже вообще запутался о какой таблице идет речь?

У нас ведь область используется для проверки какому окну принадлежит видимая точка.
Соответственно 1920*1200* 256 (глубина оконного стека) = 2,2 Мб. Как можно эту информацию упаковать в 100-200 байт? Даже если хранить только координаты окна и хитро высчитывать это получается уже 16 байт (4 dword координат, чтобы не терять время на всякие левые преобразования) на 256, итого 4 Кб. Однако у меня большие сомнения, что дополнительные вычисления для окон не съедят полученную прибыль от уменьшения размера области данных. Потому что придется также для каждой точки вычислять на лету все пересечения и наложения окон и придется это делать чаще, поскольку в текущем виде данные в области перерасчитываються лишь при изменении порядка окон в буфере.

Есть правда идея хранить только по Х и Y две области данных, что кстати будет значительно меньше.
1920 +1200 = 3120 байт. Однако это еще надо продумать.

З.Ы. Вообще-то требуется больше памяти - на каждую точку нужно 256 битное число, чтобы каждый бит отвечал за свой слой. В этом случае:
1920*32 + 1200*32 = 61440 + 38400 = 99840 байт или 97, 5 Кб. В общем около 100 Кб в противовес 2,2 Мб.

Mario
Я не говорю про 255 раскрытых окон (хотя даже и в этом случае на экране будут видны только 20-30 из них)

Типичный случай: на экране висят 3-4 окна (иконки и панель задач не счет).
Экранная карта в этом случае представляет собой массив из длинных цепочек одинаковых байтов, к тому же с очень высокой степенью повторяемости.

Прогони такую структуру через 7z - упакуется байт в 200, не больше

art_zh
Можно и без упаковки - если вспомнишь как реализуется доступ к матрице в цветомузыкальной установке например (пример из электроники). Я дописал пост после З.Ы.
Получается использование проецируемой трехмерной матрицы. Коду придется проверить установлены ли биты в текущем слое в обоих областях и есть ли до них биты в более верхних слоях.

С упаковкой проблема в том, что место динамически приходится выделять и освобождать , плюс сама распаковка делается не мгновенно. Так что в худшем случае будет кушать те-же 2 Мб.