StmGL :) Или хотим изобрести велосипед

Всем привет!
Имеем STM32F7 с интерфейсом LTDC. Все работает очень шикарно с базовой поддержкой 1024*768*24B цвета.
Хотим сделать некую либу - что-то вроде OpenGL. Со всеми вытекающими: смешивание цветов, отрисовка примитивов, текстурирование и т.п.
В голове рождается небольшая схема памяти:
2 экрана <--Буфер построения
Каждый элемент (то есть, линия, треугольник и т.п.) строится в отдельном маленьком буфере потом перегоняется в соответствующие координаты в буфер построения со смешиванием с тем, что уже лежит в буфере.

Теперь проблемы: цикл от 0 до 1024*768 проходит за 200мс.
Сразу в голову пришла мысль об использовании DMA. Все четко - работает моментально, НО как использовать DMA и смешивать с тем что уже лежит по адресу назначения...
С радостью готов выслушать любые мысли на тему. Спасибо

0

Раз есть LTDC, то должен быть и DMA2D.

0

Зачем вам порт OpenGL, да еще в таком разрешении? STM32F7 конечно мощная линейка, но на 3D-графику её едва хватит.

0

Сообщение от xokiz С радостью готов выслушать любые мысли на тему.

При активном желании сделать быструю графику без ущерба основному алгоритму, почти всегда единственный выход - это использовать отдельный конвейер графических команд, для каждого слоя свой собственный. С наличием приоритетов по слоям, перекрываемым активным зонам и так далее.

Тут общий смысл в том что обрабатывается окно по всем слоям начиная с самого нижнего, в случае когда изменений много - считается вся изменяемая площадь одного слоя, потом второго и так далее. В представлении st - слой это графика с альфа каналом, подложка есно rgb, выхлоп то-же rgb. После смешивания первого слоя с подложкой - получаем новую подложку в формате rgb, физически расположенную в тех-же адресах.

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

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

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

0

Сообщение от Riftistor Раз есть LTDC, то должен быть и DMA2D.

Это есть, только вот сэкономить "памяти" пока не придумаю как.. имеется ввиду. Есть экран: 100*100px. Есть элемент 10*10px
Физически это дело хранится в одномерных массивах длиной 100*100 и 10*10 соответственно.
И вот не могу придумать как смешивать маленький элемент с большим... потому что DMA2D разложит весь элемент 10*10 в одну строку. Вариант в голове: смешивать по линиям. То есть, это цикл из 10 проходов и внутри 10 запусков DMA2D в нужном месте...
Или же под каждый элемент выделять слой равный размеру экрана... И по сути в нем будет 99% места не использоваться и будет требоваться только для быстрого смешивания.

0

Сообщение от OVY-srok Понимаю что выглядит сложно, и даже страшно. Но в ином случае получаем дикий перерасход машинного времени, и муар на экране при смене графики. А в случае прямого рисования графики прямо из основного цикла - получаем, точнее теряем скорость работы основного алгоритма.

Да так-то идея понятна, единственное чего хочу понять - как можно сэкономить на памяти (см. сообщение выше). Ну а если прикрутить 512Мбит памяти (максимум для F7), то это получить всего 20 слоев 1024*768*32бит. Это крайне не экономно (как мне кажется должен быть какой-то более "правильный" инструмент).

0

Сообщение от xokiz Это есть, только вот сэкономить "памяти" пока не придумаю как.. имеется ввиду. Есть экран: 100*100px. Есть элемент 10*10px Физически это дело хранится в одномерных массивах длиной 100*100 и 10*10 соответственно. И вот не могу придумать как смешивать маленький элемент с большим... потому что DMA2D разложит весь элемент 10*10 в одну строку.

Перед тем, как что-то придумывать, неплохо бы открыть для начала главу про DMA2D и прочитать, что именно он умеет :)

0

Главу про dma2d пытаюсь найти :) только вот что-то толкового описания всех возможностей не найду...только примеры или готовые собранные библиотеки :(

0

Вам нужен не даташит, а Reference Manual (#0385), страница 253.

0

Сообщение от xokiz Это крайне не экономно.

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

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

Например ситуация:
1 подложка - потоковое видео от камеры, 2 первый слой - квадрат с прозрачностью определённого цвета под виртуальную кнопку, 3 второй слой - символ (буква/значёк) с неровными краями и использованием прозрачности, 4 третий слой - элемент управления с возможностью перекрытия (стрелка/перекрестье и так-далее) - это та графика которую рисуют в случае наложения.

Получаем три буфера под камеру - один приёмный, два для маштабирования в габариты экрана, один буфер под графический слой для LTDC, два мелких буфера под самый габаритный графический элемент. Обработка происходит исключительно в местах наличия изменившейся графики.

0

Да, reference manual все объяснил. И да, теперь смогу все элементы хранить по слоям и все в память влезает .
Камрады, спасибо.

0

Пожалуйста. Обращайтесь если что. Или пишите о ходе работы, будет интересно почитать.

0

Сейчас нахожусь на стадии поиска алгоритмов для рисования гладких элементов (например линий).
Движок сейчас выполняет функции контроля памяти и смешивания элементов.
Пробовал на встроенном мониторе - без лагов смешиваются 90 слоев разных размеров. При частоте раз в 30мс.

0