Хочу задействовать аппаратный акселератор. Опыта такой работы практически нет. Вся моя графика - обычные менюшки.
Насколько я понимаю бегло прочитав, этот ускоритель можно применять в следующих случаях:
1. При отрисовке объекта типа widget на экран из заранее заготовленного места, например из флэши.
2. То же что и 1, только ещё с учётом фона либо с учётом перекрытия. Короче с учётом картинки. (Тут мне надо ещё осмыслить)
3. Например затемнение объекта (всякие там invisible).
4. При появлении окна перекрытия (например диалог) для сохранения/ восстановления фоновой картинки.
Я так понимаю его нельзя использовать для отрисовки примитивов и т.п.

Учитывая как обычно дрова пишутся, получается что его органичное применение в библиотеке достаточно хлопотное занятие?
Кто в теме, проясните ситуацию. А также может кто литературу какую-нибудь по теме приведёт или примеры.
Хотелось бы глянуть.
Заранее блгодарю

Что такое "органичное применение" и что такое "библиотека"? Тут ведь всё от конеретного случая зависит.
Вот у меня, к примеру, есть ГУИ, где все примитивы - это закрашенный прямоугольник (без наклона), горизонтальная и вертикальная линия (частный случай прямоугольника), текст и растровое изображение. С их помощью рисуется всё остальное. Так вот, ускоритель легко рисует закрашенный прямоугольник. Текст и картинки отрисовываю по пикселям, работает достаточно шустро, поэтому дальше не оптимизирую. Но если бы тормозило, можно было бы, к примеру, отрисовать шрифт в буфере и копировать буквы на экран при помощи ускорителя. И т.д.
Тут всё от задачи зависит. А придумывать абстрактную библиотеку с то ли нужными, то ли ненужными функциями не интересно.

Ну... "ограниченное применение" это в моей голове. Я примеряю этот акселератор к той ГУИ, которую я использовал и на которую я ориентировался. Я использовал ГУИ от микрочипа. )) Была она некоторое время с открытыми исходниками. Я там кое что менял, но идеология мне понравилась больше чем от uCOS.
Собственно Вы на вопрос ответили. Меня интересует - кто как подходит к этому вопросу. Кто как подходит к проектированию ГУИ.
У меня к Вам только один вопрос по тексту. За счёт чего будет выигрыш, если я отрисую примитив в буфере и скопирую в видеоозу. За счёт более медленной работы внешней памяти? Но мне кажется, это уже существенной роли не сыграет на отображение картинки.

Сейчас у меня программа при выводе текста декодирует шрифт на лету (там применено сжатие RLE) и выводит на экран пиксель за пикселем. Ясно, что если шрифт уже отрисован, и DMA просто перебросит букву на экран, то получится гораздо быстрее. И процессор не надо занимать.

У меня несколько шрифтов используется. Это всётаки значительный оверхед будет.
Можно правда разворачивать букву а потом ARTом пересылать с окрашиванием цветом. Но всёже это уже, наверное, лишнее.

Итого, с учётом Ваших замечаний вырисовывается следующее:
a) Нижний уровень
1) Отрисовка примитивов типа: Горизонтальная линия, вертикальная линия, прямоугольник.
2) Вывод картинки (Прямоугольника).
3) Сохранение прямоугольника.
б) Верхний уровень
1) вывод предварительно отрисованных виджетов (через вывод картинки).
2) Работа с окнами (типа сохранение/ восстановление области перекрытия)
3) Работа с экранами Если их небольшое количество или если ОЗУ хватает.

То есть надо сначала полностью спроектировать интерфейс программы. Определится какие картинки виджетов лучше делать статическими, а какие динамическими. И только после это писать.

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

Неужели фичи "Pixel Format Conversion and Blending" не востребованы? Flash-память можно прилично экономить под картинки.

Каким образом эти фичи позволяют это делать?? Этож не аппаратный jpeg\png кодек...

Дисплей может использовать формат "ARGB8888" - очень удобно. Картинки можно держать в L4.
Сравните 4 байта и пол-байта, у меня получается 8 раз, только за счет использования этих фич.

Вот об этом тоже хотелось бы поговорить.
Я планирую применять Проц + Озу + RGB дисплей. То есть без контролера. Как правило озу используется 16 бит. 2 штуки уже хлопотно.
По-моему при применении 32 бит на цвет на дисплее получается - 16 -> 32. Когда я применял LPC то это значительно нагружало шину проца.
Ну то есть чистая регенерация дисплея. Сейчас правда матрица шин, но всётаки это тоже сказываться будет.
Особенно если с этой памятью будешь работать.
Я как-то планирую 16 бит использовать ОЗУ.
Раньше использовал 5-6-5. А теперь посмотрел может будет поинтереснее использовать ARGB4444.
Я не знаю. Просто советуюсь. У самого опыта нет.

2 adnega. Если вы работали. Проясните мне на пальцах как это "Pixel Format Conversion and Blending" работает.
Я думал что это просто грубо говоря логическая операция между исходной картинкой и той куда кладётся. Ну там ещё LUT есть. Я так понимаю это расширение цвета. Из таблицы.
Как это работает?
Могу ли я ...
... картинку нарисованую в монохроме например (и в каком монохроме?) преобразовать в цветную по таблице цветов?
... в исходной картинке сделать прозрачность фона. И наложить её на результирующую область памяти?
Гре бы про это почитать. Хотелось бы на русском и по подробнее. Или хотя бы на англ.

2 adnega.
Как это работает?
Могу ли я ...
... картинку нарисованую в монохроме например (и в каком монохроме?) преобразовать в цветную по таблице цветов?
... в исходной картинке сделать прозрачность фона. И наложить её на результирующую область памяти?
Гре бы про это почитать. Хотелось бы на русском и по подробнее. Или хотя бы на англ.
[/quote]
Слишком долго рассказывать тем более, что очень подробно описано "11 Chrom-Art Accelerator™ controller (DMA2D)" в "RM0090" версии 8.
Для DMA2D в части преобразований доступны различные форматы входных и выходных данных.
Например, для монохромной картинки с прозрачностью есть два варианта:
1) AL44 - 4 бита цвет по таблице, 4 бита прозрачность;
2) A4 - цвет холста и фона задаются через регистры DMA2D_FGCOLR и DMA2D_BGCOLR соответственно, а картинка это набор прозрачностей.

Наверное надо кит заказывать какой-нибудь. И экспериментировать.
Я уже, как обычно, хотел сразу рисовать схему и на готовом девайсе работать.
Правда пока нет ещё stm32f7. Пока stm32f429 запаять. Потом перекинуть.
У меня правда пока ещё время есть. Наверное где-то до нового года. ))
ЗЫ: adnega, а субъективно чисто, Вам понравилось с этим работать?

А я ставлю внешний контроллер.
На случай обновления схемы рассмотрел МК с встроенным контроллером LCD и внешней DRAM, но не увидел никаких преимуществ перед внешним контроллером. Например, таким: S1D13781.

Первый вполне подходит для отрисовки примитивов и стандартных виджетов.
Второй вариант похоже для вывода текста предназначен. Или контуров.
Наверное специально 4 бита использовано. Получается берёшь байт фонта и преобразуешь его в 32-ух битное слово помещаешь в буфер. После буфер выводишь на экран с выдачей цвета.



Я рассматривал для себя SSD1963. Преимуществ по схемотехнике и цене вообще нет.
Но с учётом рассматриваемого по производительности будет проигрыш. Я так понимаю.
Плюс ОЗУ всётаки можно и для посторонних вещей использовать. В SSD у Вас всётаки чисто видеобуфер.

Не мучайтесь - возьмите нормальный камень с DDR памятью, если имх сложноват, то тот-же вибрид, например, и будет вам счастье, и графика полноцвет и альфа и много быстрой памяти!

Сам долго мучался при выборе, но считаю, что выбрал правильно...

Сообщение отредактировал mantech - Apr 8 2015, 09:01