ТЕМА: Делаем видеоадаптер на ПЛИС со всеми "плюшками"

Всем привет.

Предисловие:
Начался у нас один стартап: хотим построить щиток приборов для автомобиля. Да не просто щиток приборов, а дисплей с HD графикой и всякими крутыми анимационными плюшками. Началось все с общения с автомобилем - здесь прекрасно встроился МК STM32. Общается, переваривает всю информацию в удобный вид и т.п. Тут же Bluetooth hands-free, avrcp и т.п. Далее это все идет на ПК (у нас распиленный ноутбук, но можно заюзать и Raspberry и CarPC) и уже там рисуется красивая картинка. НО! Время запуска - 10-15 секунд при максимальной оптимизации что винды, что линукса. Решили искать решение для системы мгновенного пуска при подаче питания. Имея хороший опыт разработки ПО на МК мы взяли один из сильнейших в своем роде STM32F7. Написали под нее свою графическую либу.. 2 видео буфера, парсинг XML файла-описания скина с компонентами, свою либу для рендера произвольных шрифтов - все супер. Все летает до разрешения 800*600*16бит включительно. НО, при увеличении цветности и/или разрешения МК не способен держать картинку на экране и она начинает "моргать". Перерождение системы видится в использовании ПЛИС.

Идея и пути достижения:
Взять Cyclone V Starter Kit (уже заказан).
Подключить к нему МК по юарту с имеющимся протоколом общения.
К ПЛИСу подключить microSD с текстурами и XMLкой с описанием компонентов (координаты, тип, ширина, высота, текстура и т.п.)
По HDMI подключить дисплей.

При подачи питания ПЛИС тянет инфу с SD карты - перекладывает ее в LPDDR2 (на плате 4гига, к слову сейчас на МК мы уложились в 8Mb).
Далее также выделяется 2 буфера экрана - один транслируется в другой элементы смешиваются. При получении сигнала с UART начинается смешивание - происходит за оно за некоторое число тиков - далее выставляем регистр информирующий о завершении смешивания. В результате чего идет переключение транслирующегося буфера.

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

P.S. Сейчас имеем: понимание Verilog, написание UART протокола с тестом в эмуляторе, N-ное число часов просмотренных уроков на ютубе, прочитаны практически все статьи про ПЛИС на хабре и тут:)

Я хотел бы с вами пообщаться. Мой скайп victorkazarinov

Пожалуйста, расскажите какие операции видеоадаптера Вам нужны для построения кадра - просто спрайты с масштабированием или без оного, вращение, полупрозрачность или вообще вывод полигонов 3D с текстурами?

Chaosorg пишет: Пожалуйста, расскажите какие операции видеоадаптера Вам нужны для построения кадра - просто спрайты с масштабированием или без оного, вращение, полупрозрачность или вообще вывод полигонов 3D с текстурами?

Минимальный функционал, который нужен сейчас: немасштабируемые квадратики, залитые текстурой, перемещяемые по экрану + набор примитивов (гладкие линии, круги, прямоугольники залитые цветом). Все это чтоб смешивалось с учетом прозрачности и z-index.

Плюсом хотим иметь возможность использовать шейдеры, как в OpenGL.
Ну и самая дальняя ветка развития - это 3д. То есть, все что осталось в OpenGL

мда - от немасштабируемых квадратиков до OpenGL с поддержкой шейдеров - пропасть функционала и работы, превышающей стоимостью любой автомобиль, как мне кажется:)

А может быть сразу лучше сделать только масштабируемые и вращаемые полигоны с прозрачностью? Алгоритм, который выводит спрайты с вращением почти не отличается от вывода 3D полигона. В 3D просто стороны границ спрайта могут быть не параллельны и вообще вершины рассчитываются проецированием на плоскость экрана - это может делать МК софтом - как делалось в видеокартах до появления GeForce. Т.е. по сути из всего конвейера Вам надо сделать растеризатор. Зачем шейдеры? Вам нужно чтобы элементы интерфейса были с рельефом, отбрасывающим тени, нужно преломление света в воде и дыме?:)
Кстати, про примитивы. Стрелку спидометра, например, проще нарисовать в растре и вывести опять же как вращающийся спрайт.

Chaosorg пишет: мда - от немасштабируемых квадратиков до OpenGL с поддержкой шейдеров - пропасть функционала и работы, превышающей стоимостью любой автомобиль, как мне кажется:)

А может быть сразу лучше сделать только масштабируемые и вращаемые полигоны с прозрачностью? Алгоритм, который выводит спрайты с вращением почти не отличается от вывода 3D полигона. В 3D просто стороны границ спрайта могут быть не параллельны и вообще вершины рассчитываются проецированием на плоскость экрана - это может делать МК софтом - как делалось в видеокартах до появления GeForce. Т.е. по сути из всего конвейера Вам надо сделать растеризатор. Зачем шейдеры? Вам нужно чтобы элементы интерфейса были с рельефом, отбрасывающим тени, нужно преломление света в воде и дыме?:)
Кстати, про примитивы. Стрелку спидометра, например, проще нарисовать в растре и вывести опять же как вращающийся спрайт.

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

xakez пишет:

Chaosorg пишет: мда - от немасштабируемых квадратиков до OpenGL с поддержкой шейдеров - пропасть функционала и работы, превышающей стоимостью любой автомобиль, как мне кажется:)

А может быть сразу лучше сделать только масштабируемые и вращаемые полигоны с прозрачностью? Алгоритм, который выводит спрайты с вращением почти не отличается от вывода 3D полигона. В 3D просто стороны границ спрайта могут быть не параллельны и вообще вершины рассчитываются проецированием на плоскость экрана - это может делать МК софтом - как делалось в видеокартах до появления GeForce. Т.е. по сути из всего конвейера Вам надо сделать растеризатор. Зачем шейдеры? Вам нужно чтобы элементы интерфейса были с рельефом, отбрасывающим тени, нужно преломление света в воде и дыме?:)
Кстати, про примитивы. Стрелку спидометра, например, проще нарисовать в растре и вывести опять же как вращающийся спрайт.

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

Ну антиалиасингов много разных. И они же не только производительность крадут, но и память, при некоторых методиках. Если Вы не будете растягивать текстуру, а лучше наоборот - она будет больше результата на экране, то качество будет вполне приличным. Кстати, векторный примитив ведь тоже не избавлен он "ступенек". Если у Вас есть дешевый алгоритм антиалиасинга для кривых, то мне кажется его можно применить на границе полигона. Но надо ли это на первых порах? Зато задача упрощается - сделать всего один растеризатор с фиксированным алгоритмом и нарисовать им все. Т.е. я просто высказываю предположение, что от векторных примитивов можно пока отказаться, зато сделать как минимум вращение спрайта, а лучше просто растеризатор текстур. По поводу шейдеров - ведь видеокарты раньше без них обходились. Был жестко реализованный метод растеризации и его можно было немного настраивать, указывая количество и тип текстур и режим наложения. А шейдерные процессорные блоки хороши, когда их много. Иначе получится векторный процессор, ну или процессор с SIMD командами - пусть меня поправят, если я ошибаюсь в терминах. Кстати тема есть: marsohod.org/forum/proekty-polzovatelej/...i-na-plate-marsohod2

P.S.
Еще про антиалиасинг. Если запас по скорости будет, то самое простое просто чертить картинку так, как будто у Вас разрешение экрана в два раза выше, чем на самом деле и тут же на лету перемасштабировать сжимая в два раза.
А еще можно посмотреть в сторону алгоритмов улучшения картинок в эмуляторах ретро приставок и компьютеров. Всякие там hq2x, SuperEagle и т д.

Chaosorg пишет:
Ну антиалиасингов много разных. И они же не только производительность крадут, но и память, при некоторых методиках.
...
Если у Вас есть дешевый алгоритм антиалиасинга для кривых, то мне кажется его можно применить на границе полигона. Но надо ли это на первых порах?
...
а лучше просто растеризатор текстур.

Да, наверное вы правы. Лучше антиалисинг повернутых текстур для начала - тогда любую растированную графику можно будет нарисовать красиво

Ну и продолжая проектирование. Получилась некая схема классы-компоненты:


Скажем, по началу все понятно. Screen Controller получает сигнал о начале сеанса. Получает информацию о первом контроле (допустим квадрат с текстурой). Дает сигнал Component Builder'у о желании что-то построить по параметрам. Component Bulder дает сигнал Texture Provider о необходимости "стянуть" текстуру с карты памяти - она переезжает в LPDDR2 - далее идет обратная связь по какому адресу лежит текстура.
Component Builder в цикле от 0 до Ширина*Высота переписывает текстуру в область памяти для соответствующего контрола (обрезает если не влеза, или масштабирует, поворачивает если необходимо). Далее сигналит Screen Controller'у что компонент в памяти готов.
Screen Controller сигналит в юарт, что готов получить следующий контрол, получает информацию о следующем контроле и едем дальше.
Таким образом мы избавимся от очередей обработки юарта в ПЛИСе (она будет в МК). Когда получаем сигнал, что информация о всех элементах получена - Screen Controller согласно координатам, прозрачности и последовательности смешивает контролы в память и сигналит в HDMI контроллер что скрин готов. Он начинает отображаться на экране.

Далее.. какой-то контрол сместился, или изменился цвет, или прозрачность - сообщение в юарт - Screen Controller сигналит о перестроении элемента в Component Builder. А вот тут возникает вопрос как двум параллельным процессам договориться о доступе к памяти по одной шине: трансляция в HDMI идет непрерывно, при этом, компонент хочет записаться в память?

xakez пишет:
Скажем, по началу все понятно. Screen Controller получает сигнал о начале сеанса. Получает информацию о первом контроле (допустим квадрат с текстурой). Дает сигнал Component Builder'у о желании что-то построить по параметрам. Component Bulder дает сигнал Texture Provider о необходимости "стянуть" текстуру с карты памяти - она переезжает в LPDDR2 - далее идет обратная связь по какому адресу лежит текстура.
Component Builder в цикле от 0 до Ширина*Высота переписывает текстуру в область памяти для соответствующего контрола (обрезает если не влеза, или масштабирует, поворачивает если необходимо). Далее сигналит Screen Controller'у что компонент в памяти готов.
Screen Controller сигналит в юарт, что готов получить следующий контрол, получает информацию о следующем контроле и едем дальше.
Таким образом мы избавимся от очередей обработки юарта в ПЛИСе (она будет в МК). Когда получаем сигнал, что информация о всех элементах получена - Screen Controller согласно координатам, прозрачности и последовательности смешивает контролы в память и сигналит в HDMI контроллер что скрин готов. Он начинает отображаться на экране.

Далее.. какой-то контрол сместился, или изменился цвет, или прозрачность - сообщение в юарт - Screen Controller сигналит о перестроении элемента в Component Builder. А вот тут возникает вопрос как двум параллельным процессам договориться о доступе к памяти по одной шине: трансляция в HDMI идет непрерывно, при этом, компонент хочет записаться в память?

У Вас не хватает памяти на double buffer? Если хватает, то не надо сигнализировать ни о каких готовностях и ни о чем договариваться - пока ScreenController чертит в одном буфере, HDMI показывает из другого буфера, потом буферы меняются местами. Если памяти не хватает, то есть лишь надежда на двухпортовую природу и быстродействие встроенной памяти ПЛИС. А начертить что-то интересное за время "обратного хода луча" Вы вряд ли будете успевать.

Еще конвейер у Вас какой-то необычный. Мне кажется, что при загрузке текстуры в память ее не надо обрезать и вращать - это делается на этапе, как Вы это назвали, когда: "Screen Controller согласно координатам, прозрачности и последовательности смешивает контролы в память". У Вас должна быть списковая структура команд растеризатору, состоящая из координат и параметров точек на экране (в которых полигон пересекается с очередной строкой растра экрана) и координат соответствующих им точек в той или иной текстуре. Растеризатор "бежит" точкой в любом заданном на границе полигона направлении в текстуре, берет там цвет и копирует его в точку на экране, которой он бежит горизонтально вдоль линии растра, заполняя его. Если растеризатор будет двигаться в текстуре прямо, то будет вывод без поворота, а если наискосок, то с поворотом (а если с ускорением, то даже с перспективой).