ТЕМА: Реализация 3D графики на плате marsohod2

Проект очень интересный. Неужели и правда потеряли интерес? Мне кажется у него есть потенциал, во всяком случае если и не в виде процессора, то в виде видеокарты с графическим ускорителем. Т.е. если не забросите его, то со временем он мог бы вырасти в нечто такое. Во всяком вот такое мнение "со стороны".

Что касается github.com/petrmikheev/miksys/blob/maste...og/usb_controller.sv , то если буду использовать, то сообщу вам и своём сайте укажу что использую ваш код.

alman пишет: Проект очень интересный. Неужели и правда потеряли интерес? Мне кажется у него есть потенциал, во всяком случае если и не в виде процессора, то в виде видеокарты с графическим ускорителем. Т.е. если не забросите его, то со временем он мог бы вырасти в нечто такое. Во всяком вот такое мнение "со стороны".

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

Чтобы проект получил распространение, нужно было:
а) реализовывать какую-нибудь популярную архитектуру (возможно, с доп. командами для графики);
б) использовать стандартные интерфейсы (лучше всего wishbone) для взаимодействия между отдельными блоками.

Я же делал демонстатор идеи. И сделал. 3д графика на марсоходе работает. А другого практического смысла тут нет.

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

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

Расширять какую-то существующую архитектуру simd инструкциями - в лучшем случае получится MMX или SSE, но кто видел последний раз мощный софтверный рендеринг в играх? Эти инструкции больше пригодились для видеокодеков, ну и вообще мультимедии и изображений, а в графику идея такой гибкости вернулась уже на новой уровне - шейдерных процессоров. Это уровень уже не Cyclone, а каких-то Stratix, наверное.

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

Главное не забыть добавит ботов и фраги - иначе какой смысл?

Уж если новую архитектуру для ПЛИС разрабатывать, то начинать надо с языка/компилятора - такого, чтобы любой описываемый алгоритм одинаково эффективно транслировался и в инструкции ЦП (программная реализация), и в примитивы ПЛИС (аппаратная реализация). Все остальное давно и бесповоротно засеяно-поделено, ничто другое не взойдет.

Leka пишет: Уж если новую архитектуру для ПЛИС разрабатывать, то начинать надо с языка/компилятора - такого, чтобы любой описываемый алгоритм одинаково эффективно транслировался и в инструкции ЦП (программная реализация), и в примитивы ПЛИС (аппаратная реализация). Все остальное давно и бесповоротно засеяно-поделено, ничто другое не взойдет.

Согласен, но в этой области тоже немало существующих решений. FPGA, которая стоит в Xeon программируется на OpenCL. Если есть амбиция быть пионером, то надо вообще уходить от превращения текста на Си-подобных языках в железо. Надо тогда в сторону других парадигм смотреть - как Erlang, заимствующий предикаты от Prolog

Язык д/б достаточно простой, чтобы можно было контролировать потактовую реализацию любого алгоритма (как в Верилоге, например). Д/б удобным базовым инструментом, но никак не кладовкой готовых решений.

На Паскале например, за 5 минут написал/отладил новый алгоритм фильтрации, и уже 2-ой день ломаю голову, как перевести это в HDL...

petrmikheev пишет: б) использовать стандартные интерфейсы (лучше всего wishbone) для взаимодействия между отдельными блоками.

Или, как вариант, разработать и описать свой интерфейс. Хотя вариант с Wishbone не так уж и плох.

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

К примеру USB-host. Я хочу им пользоваться и думаю что в этом я не одинок. Возможно даже готов заплатить за него какую-то символическую сумму (usb_controller.sv).

Что касается 3D-графики... это другой вопрос. Интерес есть, но пока только поговорить. Кстати, думаю что ваш проект привлёк внимание как минимум 4 форумчан и нескольких разработчиков Марсохода.

Кстати, хоть это к делу и не относится, не могли бы чуть рассказать о себе? Таки не каждый день кто-то выкладывает новые разработки такого уровня.

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

Увы, не хватает места. Из за этого я вообще убрал floating-point блоки. Вся отрисковка идет на целочисленной 16-битной арифметике без деления. Так, как ни странно, оказалось быстрее всего. Софтварно используется таблица синусов и таблица значений вида 65536/x.

С вынесением растеризации в отдельный блок есть сложность. Буфер цвета и буфер глубины не помещаются в кеш целиком. А если постоянно гонять их из оперативной памяти, не хватает пропускной способности sdram. В результате отрисовка идет по одной строке. То есть внешний цикл по строкам, внутри цикл по полигонам с определением точек пересечения полигона со строкой. И уже потом, на 3-м уровне вложенности, цикл по пикселам внутри строки, принадлежащим заданному полигону. Внутри которого, в свою очередь, нужно рассчитать текстурные координаты текущего пиксела, найти в кеше текстуру, достать из неё нужный цвет и применить к нему коэффициент освещенности текущего полигона.
Сделать всё это в HDL получается ну очень громоздко. Я не смог придумать ничего лучше, чем сделать универсальный процессор с векторными операциями.

Chaosorg пишет: Главное не забыть добавит ботов и фраги - иначе какой смысл?

Это да. Сражение со зловещими Тетраэдрами (чтобы полигонов поменьше ;) ) в Пустынном Лабиринте. Правда будет муторно писать игровую логику на голом ассемблере. Я подумываю сделать компилятор си на основе lcc и уже потом приступать к фрагам. Только это еще не скоро, надо дождаться вдохновения.

alman пишет: К примеру USB-host. Я хочу им пользоваться и думаю что в этом я не одинок. Возможно даже готов заплатить за него какую-то символическую сумму (usb_controller.sv).

Не, не надо ничего платить. Будет здорово если кто-нибудь воспользуется и объяснит мне, откуда у меня берутся глюки при чтении с флешки...

alman пишет: Кстати, хоть это к делу и не относится, не могли бы чуть рассказать о себе? Таки не каждый день кто-то выкладывает новые разработки такого уровня.

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

petrmikheev пишет:

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

Увы, не хватает места. Из за этого я вообще убрал floating-point блоки. Вся отрисковка идет на целочисленной 16-битной арифметике без деления. Так, как ни странно, оказалось быстрее всего. Софтварно используется таблица синусов и таблица значений вида 65536/x.

С вынесением растеризации в отдельный блок есть сложность. Буфер цвета и буфер глубины не помещаются в кеш целиком. А если постоянно гонять их из оперативной памяти, не хватает пропускной способности sdram. В результате отрисовка идет по одной строке. То есть внешний цикл по строкам, внутри цикл по полигонам с определением точек пересечения полигона со строкой. И уже потом, на 3-м уровне вложенности, цикл по пикселам внутри строки, принадлежащим заданному полигону. Внутри которого, в свою очередь, нужно рассчитать текстурные координаты текущего пиксела, найти в кеше текстуру, достать из неё нужный цвет и применить к нему коэффициент освещенности текущего полигона.
Сделать всё это в HDL получается ну очень громоздко. Я не смог придумать ничего лучше, чем сделать универсальный процессор с векторными операциями.

Вроде все верно, но может быть надо скомпоновать иначе? Целью работы универсального процессора должен быть список заданий для растеризатора, где будут уже посчитаны координаты в текстуре и освещенность в местах пересечения граней полигонов с scanline и главное их приращения (можно в целочисленой масштабированной арифметике). Ведь при растеризации это все изменяется линейно только сложением, т.е. делений и умножений уже не будет. Более того, если будет списковая структура с этими точками пересечения, то в них можно делать сортировку с удалением невидимых поверхностей.

Ну а так, да - надо марсоход 3 :) раз стратикса пока нет :(

petrmikheev пишет: Это да. Сражение со зловещими Тетраэдрами (чтобы полигонов поменьше ;) ) в Пустынном Лабиринте. Правда будет муторно писать игровую логику на голом ассемблере. Я подумываю сделать компилятор си на основе lcc и уже потом приступать к фрагам. Только это еще не скоро, надо дождаться вдохновения.

У меня вопросы созрели.

В каком виде представлены 3D данные?

Есть ли возможность передавать 3D модели с компьютера по виртуальному последовательному порту?

На картинке помимо домика есть текст. Расскажите об API для вывода текста.

petrmikheev пишет:

Если соединить USB-порт платы расширения Марсохода с другим Марсоходом. Допустим, ваш usb_controller.sv запустится на USB Full-speed (12 Мбит/с), хватит ли этой скорости чтобы передавать 3D данные по этому интерфейсу между Марсоходами?

Не думали ли об эмуляции терминала VT-102?

Простаивают ли арифметические устройства при выполнении обычного кода, не относящегося к графике?