Современный "Спектрум"

[Valen]

Valen Процессор - CirrusLogic EP9302.
По поводу видео - можно не переживать, что оно "съест всё процессорное время" ;-) Ставить ускоритель за 30$ (думаю, за эти денюжки можно и nVidia старенькую прикрутить) невыгодно. Да и незачем - компьютер-то не игровой.

Я, для себя, пришёл к выводу, что нужно отталкиваться именно от
графич. возможностей (т.е. VDP со своей личной быстрой памятью),
разрядность и скорость ЦПУ дело второе.

Сделать приемлимый видео-проц на ПЛИС (то, что вы задумали) дело не
тривиальное.

Так а чем же ему ещё заниматься? ;-)

Проц пусть себе расчётами занимается и посылает короткие
команды видео-процу, который и строит графику в своей памяти,
причём делает это паралельно с работой ЦПУ.
Короче приставочный дизайн видео-системы.

[PegasResearch]

Valen
Вообще, я, конечно, согласен - видеопороцесор необходим в большинстве случаев. Речь не идет о 3D - и без этого мы имеем очень затратные операции свёрток при масштабировании изображения, сглаживании... Можно составить минимальный набор операций видеопроцессора (в моём понимании, в отличие от видеоконтроллера видеопроцессор способен выполнять самостоятельные операции над содержимым видеопамяти):
1) Копирование растр-растр с масштабированием и альфа-прозрачностью.
2) Сглаживание растра.
3) Поддержка оверлеев (спрайтов) - минимум одного оверлея (для мышиного курсора).
Под растром понимается прямоугольная часть экрана либо буфера видеоозу.

Сделать приемлимый видео-проц на ПЛИС (то, что вы задумали) дело не
тривиальное.

Согласен, обладающий минимальными 2D возможностями видеопроцессор на логике реализовать проблематично: тут и проблемы с DMA, и контролем ресурсов, проблемы с реализацией свёртки, форматом поверхностей (растров)...
Но я собираюсь делать лишь видеоконтроллер, а вовсе не видеопроцессор. То есть никаких самостоятельных операций в видеосистеме, кроме вывода на экран.

Я, для себя, пришёл к выводу, что нужно отталкиваться именно от
графич. возможностей (т.е. VDP со своей личной быстрой памятью),
разрядность и скорость ЦПУ дело второе.

Это зависит от ТЗ на вычислительную систему. В моём случае ТЗ не содержит требований к графики - кроме возможности эту графику воспроизводить с любыми разрешениями на любых устройствах. Так что я это и реализовываю.
А моё ТЗ получилось прежде всего из необходимости минимизации стоимости, из стоящих перед платформой задач (это НЕ ИГРОВАЯ платформа), а также из опыта программирования ПК. Могу сказать, что до 640х480 у P-200 под Windows+DirectX вполне хватает производительности, чтобы любой вышеперечисленный эффект много-много раз реализовать в реал-тайме. У меня есть работающие игры, использующие такой режим и возможности программного альфа-канала и сглаживания/масштабирования. Тут всё зависит от программиста, и только.

И пару слов по дизайну видеосистемы. специально для Valen.
Видеоозу разделено на два банка по 8Мб. Физически это две разные 16-ти разрядные микросхемы PC-133. Процессор обращается всегда только к неактивному банку, эффективная скорость обмена равна скорости обмена процессора с основным ОЗУ. Т.е. никаких задержек нет. Банки переключаются моментально, одной командой.

Видеоконтроллер способен посылать прерывания процессору по сигналу обратного вертикального хода луча и по требованию переключать банки видеопамяти.

Видеорежимы поддерживаются только беспалитровые. Опять же, ещё во времена программирования графических движков под ДОС я экспериментировал с различными вариантами палитр, VESA 2.0 режимов, "нереального" режима i386 CPU и т.п. В результате пришёл к выводу (палитровую анимацию в расчёт не берём), что для практических задач (игры и т.п.) достаточно 8-битного цвета с фиксированной палитрой, отображающей цвета форматом 2-3-3 (RGB; градации красного цвета наименее различимы глазом). Видеоконтроллер будет поддерживать 2-3-3, 5-6-5 и 8-8-8 видеорежимы. Причём последний вариант как 24, так и 32 бит на точку (во многих случаях 32 бита работают быстрее 24-х из-за отсутствия дополнительных операций).

Оверлеи поддерживаться не будут, т.к. это усложняет конструкцию (у меня используется внешний DAC, подключенный напрямую к выводам м/с памяти).

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

Жду комментариев, Valen

[Valen]

это НЕ ИГРОВАЯ платформа

В этом не согласен.
Основная масса софта - игры.

Согласен, обладающий минимальными 2D возможностями видеопроцессор на логике реализовать проблематично

Поэтому нужно подбирать готовый 2Д видео-проц.

Но я собираюсь делать лишь видеоконтроллер, а вовсе не видеопроцессор. То есть никаких самостоятельных операций в видеосистеме, кроме вывода на экран.

Это понятно.

Это зависит от ТЗ на вычислительную систему. В моём случае ТЗ не содержит требований к графики

Это тоже понятно.
Короче говоря, у вас другой подход.

А моё ТЗ получилось прежде всего из необходимости минимизации стоимости

Имхо, экономить нельзя на видео-системе.

Могу сказать, что до 640х480 у P-200 под Windows+DirectX вполне хватает производительности

Хватает, только, если карта поддерживает
DirectX в железе. Там видео-проц умеющий ворочать набортной памятью
карты.

При софтовом способе доступа в видео-буфер дела похуже.


------

И пару слов по дизайну видеосистемы.
Видеоозу разделено на два банка по 8Мб. Физически это две разные 16-ти разрядные микросхемы PC-133.

Каждая из двух микросхем будет
иметь свою шину к ПЛИС ?
(чтобы ПЛИС могла одновременно работать с двумя банками)

Видеорежимы поддерживаются только беспалитровые
...
(палитровую анимацию в расчёт не берём)

Палитровая анимация наименее ресурсоёмкая.

[PegasResearch]

Valen

Хватает, только, если карта поддерживает
DirectX в железе.

"Поддержка DirectX" в случае использования DirectDraw достаточна на уровне DirectX 1.0. Карта не обязана в этом случае даже внеэкранный видеобуфер поддерживать - всё софтверно. Я как раз DirectX 1.0 имел в виду - например, Triedent ISA 512Kb ;-)

В этом не согласен.
Основная масса софта - игры.

Нет, повторю ещё раз: платформа НЕ для игр. Основная масса софта для неё - браузер, текстовый процессор, электронные таблицы, эмуляторы более простых платформ (ZX, Dendy), для которых графических возможностей платформы даже чересчур.

Каждая из двух микросхем будет
иметь свою шину к ПЛИС ?
(чтобы ПЛИС могла одновременно работать с двумя банками)

Да, у каждой микросхемы своя полная шина к ПЛИС.

Палитровая анимация наименее ресурсоёмкая.

Но в расчёт мы её не берём, т.к. на моей памяти она встречалась лишь в паре демок. Использовать её в программе крайне затруднительно. Но основная проблема: необходимость уменьшать общее количество цветов на изображении. Вообщем, палитровая анимация годится только для демонстрации. Также, как и вывод спрайтов через XOR ;-)

[Valen]

Нет, повторю ещё раз: платформа НЕ для игр.

Не сошлись во мнениях.


Полоса пропускания SDRAM 133MHz 16bit - возьмём в среднем 4-5 тактов. 133/5 * 2байта_за_такт = 53МБ/сек

----
Предполжим некая графич. программа хочет обновлять весь экран за кадр в режиме 640*480*8bpp @75Гц.
Путём, копирования из системной области памяти в теневой видео-банк.

Тогда ей нужна такая полоса пропускания:
640*480 = 307КБ размер экрана
Т.к. у нас две операции обращения к памяти - чтение/запись,
то удваиваем 307*2 = 614 КБ/кадр.

614* 75Гц = 46 МБ/сек

Другими словами, из доступных 53 МБ/сек,
простое копирование одного экрана за кадр съест 46 МБ/сек,
т.е. практически всю доступную полосу памяти.
На практике, будет ещё хуже, потому как чтение/запись видео-данных в
тех-же динамичных 2Д играх относяться как 2/1 и даже 3/1.
(а не 1/1, как в моём примере)

[PegasResearch]

Не сошлись во мнениях.

Для своего проекта я сам устанавливаю требования и разрабатываю ТЗ. Так что же это за критика?! ;-) Правильнее было бы сказать: "А что если рассмотреть возможность применения платформы как игровой?" :-)

Теперь по существу. На русском хорошее описание SDRAM доступно, например, здесь http://www.epos.kiev.ua/pubs/pm/pc133.htm (хотя лучше пользоваться даташитом производителя, в моём случае - Samsung). Полоса пропускания SDRAM при последовательном к ней доступе - 133МГц*2байта = 266Мб/сек (первое слово читается за 7 тактов, последующие 2/4/8/256 - по 1 такту). При произвольном доступе зависит от параметров CAS latency + RAS to CAS delay + 1 - 5 или 7; у используемой памяти этот параметр 7 (133MHz) или 5 (100MHz), т.о. скорость уменьшается в семь раз и составит 266/7 = 38Мб/сек (попрошу заметить - для 100МГц - 200/5=40Мб/сек).
Итак, подитожим быстродействие SDRAM PC-133 16 bit:
1) Последовательный доступ - порядка 266Мб/сек
2) Произвольный доступ - 38Мб/сек


Теперь о возможных неприятностях:
1) Доступ чередуется: основная-видеопамять. Ведь это приведёт к срыву последовательного доступа отдельно для каждой памяти?
Архитектура системы оптимизирована для возможности не прерывать последовательный доступ в случае чередования операций память-видео. Это достигнуто подключением основного ОЗУ к встроенному контроллеру SDRAM, а видеоозу - к контроллеру SDRAM внутри ПЛИС. При этом сама ПЛИС подключается к "системной шине", то есть к выводам подключения ROM/SRAM процессора (которые имеются не только у выбранной модели камня, но и у многих других). Что выбрано в текущий момент - определяется адресом доступа и не требует тактов ;-). Поэтому при чередовании операций оба модуля SDRAM работают в режиме последовательного доступа, если в каждом отдельном блоке (основном/видео) адреса увеличиваются на единицу.
Скорость при этом, естественно, падает в два раза (т.к. обращения чередуются; тактовая частота ПЛИС берётся с SDRAM clk) - до 133МБ\сек.

2) Хватит ли производительности процессора?
Для процессора 230MIPS при скорости 133Мб/сек отношение "количество тактов CPU"/"прочитанных/записанных слов (16бит) памяти" составит примерно 2. При этом если копирование выполняется програмно, то локальные переменные процедуры и сама процедура помещаются в кеш (до 16Кб), и не мешают работать SDRAM в последовательном режиме, то есть скорость доступа к памяти не падает.
Конечно, 2 RISC команды - маловато будет ;-) Но не стоит забывать о встроенном DMA, который поддерживает в том числе 2 канала память-память. Для сохранения последовательного режима SDRAM (если эксперименты покажут, что произвольный доступ ведёт к падению быстродействия, что ещё не факт) можно использовать один канал.
Таким образом, спрайты могут копироваться построчно - всё, что требуется от процессора - составить для кадра список (FIFO) копируемых строк спрайтов (с учётом границ спрайтов). Потом надо лишь обрабатывать прерывания от DMA и подкидывать ему новые данные. Нагрузка на CPU минимальна, и у него ещё будет куча времени для остальных операций.

3) Когда CPU читает команды, использует переменные, он нарушает режим последовательного доступа к памяти. Как быть?
Процессор имеет кеш. И если процедура (цикл) со всеми переменными поместилась в 16Кб+16Кб - то она не даст нагрузки на SDRAM. Если не поместилась, тогда, конечно, будут иметь место конфликты процессор/DMA.
Небольшое ускорение возможно, учитывая, что основная память делится на два банка (32+32Мб; в случае 128Мб - 4 банка). Для сохранения режима последовательного доступа можно размещение видеоданных в одном банке, программы - в другом. Тогда DMA и процессор хоть и будут делить шину, но дополнительных тактов (CAS latency) им не потребуется.
Вообще, в этом вопросе многое зависит от программы, от объёма вычислений и объёма копируемых данных. Тут будет место применению всяких программистских "хитростей" ;-)
Самый простой (и быстрый) случай игрового движка - сформировать очередь DMA запросов, вызвать DMA и до окончания DMA "уснуть". Это обеспечит производительность 133Мб/сек при доступе основная-видеопамять (1-й такт - чтение, 2-й такт - запись, по 16 бит за такт, частота 133 МГц).

Итак, что мы имеем? 133Мб/сек. Это не пиковая, а обычная (гарантированная) производительность при копировании блоков (не только экранов, но и спрайтов). Возможно, данная производительность будет гарантирована и при произвольном доступе (CAS latency=2). Можно было бы ускорить и до 266Мб/сек, используя встроенный в ПЛИС DMA (с отключением процессора от памяти на момент DMA) - это вариант расширения платформы. При этом схема дизайнится с учётом такой возможности. Если в ПЛИС останется достаточно свободных элементов, то такой DMA "основная-видеопамять" будет иметь место. В этом случае спрайтовые движки реализуются очень просто, а гарантированная скорость копирования - 266Мб/сек (правда, при этом процессор не может обращаться с памяти во время цикла передачи). А ещё можно использовать 32 битную шину (AT91RM9200) и достичь 533Мб/сек... Но спустимся с небес и рассмотрим возможности 133Мб/сек.

Распространённая операция, требующая в 2D "перерисовки экрана" - это скроллинг. Ещё одна из распространённых - двумерная свёртка с некоторым фиксированным окном (размер которого меньше размера кеша). Свёртка может использоваться для изменения яркости, для шейдерных эффектов (по аналогии с 3D) и т.п. Скроллинг в спрайтовом движке сводится к копированию спрайтов из основной памяти в видео-озу в нужные места. На это будет "заточен" режим DMA с запросами в FIFO: положения спрайтов заносятся в FIFO и далее копирование производится в "автоматическом" режиме. Для свёртки нам потребуется изменить уже "собранную" картинку и затем скопировать (вывести) её на экран. При этом простейшая свёртка может быть выполнена за 3 RISC команды (чтение, перемножение, запись) и максимальная скорость обмена с ОЗУ составит 266/3 = 88Мб/сек.

Возьмём приведённый Valen пример - 640х480х8бит@75Гц можно организовать, использовав пересылку 640*480*75 = 23 040 000 байт в секунду, или около 23Мб. Процессор будет занят на 23/133*100 = 17.3%, то есть свободен более чем на 80%.

О частоте обновления. С частотой 75Гц нет смысла перерисовывать графику. 75Гц имеет смысл только для обновления экрана, чтобы не было заметно мерцаний. Для игр достаточно, чтобы время одного кадра было меньше времени реакции человека (1/20 сек). Для кино, например, было выбрано 24 кадра - при этом человек не замечает, что изображение состоит из кадров. То, что в 3D играх показатель FPS более 30 считается комфортным - тоже показатель ;-) Вообщем, иметь более 30FPS не имеет смысла. В этом случае для 640х480х8бит процессор будет свободен более чем на 90% для выполнения расстановки спрайтов, обработки звука и т.п.

Режим 8 бит оставлен лишь для демонстрации. Основной режим будет 16/32 бит. И разрешение будет больше, чем 640х480. Так как игры - это лишь дополнительная возможность, а в случае большинства программ экран каждую 1/30 секунды не обновляется ;-)

Посмотрим, какой максимальный видеобуфер можно использовать при 30FPS и 100% загрузке шины памяти и только лишь обновлении экрана. 133Мб/сек/30кадр/сек = 4.4Мб/кадр. То есть половину имеющегося видеоозу или разрешение порядка 1600х1200 16 бит (займёт только 87% процессорного времени обмена с SDRAM). И это - при 30 обновлениях в секунду! А ведь в отличие от Спека можно выставить и 320х240 16 бит и реализовывать программную 3D графику не хуже, чем это делает ПК с ускорителем. На телевизоре смотреться будет нормально ;-)

Почему размер видеопамяти выбран не 4Мб, а именно 8Мб? Микросхемы 4Мб стоят дороже, чем 8Мб. Поэтому и установлены 8-ми Мб микросхемы. Дополнительно на ПЛИС можно реализовать DMA-режим видео-видео, то есть без каких-либо ожиданий со стороны CPU (то есть CPU в это время сможет работать с основной памятью). Хотя такой DMA не планируется - из-за того, что процессор вполне справится сам. Кроме того, иногда требуется и 1600х1200х32 бит - я уже сказал, что платформа предназначена не для игр. А для текста и т.п. важна возможность использовать в том числе и высокие видеорежимы.

Прошу комментарии.

[newart]

О частоте обновления. С частотой 75Гц нет смысла перерисовывать графику. 75Гц имеет смысл только для обновления экрана, чтобы не было заметно мерцаний. Для игр достаточно, чтобы время одного кадра было меньше времени реакции человека (1/20 сек). Для кино, например, было выбрано 24 кадра - при этом человек не замечает, что изображение состоит из кадров. То, что в 3D играх показатель FPS более 30 считается комфортным - тоже показатель ;-) Вообщем, иметь более 30FPS не имеет смысла

Для чего тогда все 2D консоли имеют 50-60fps?
Что такое "фрейм" слышал?
Лично мне тошно смотреть на пц'шную рвань в 2D платформерах.
Игр работающих во фрейм или вообще учитывающих этот эффект по пальцам можно пересчитать.

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

[PegasResearch]

Что такое "фрейм" слышал?

Конечно - FPS ведь это слово в себе содержит ;-)

Игр работающих во фрейм

учитывающих этот эффект

Какой эффект? Что значит "работающих во фрейм"? Могу предположить только две вещи. Либо вы, уважаемый, говорите о эффекте рваного кадра, либо вы говорите о необходимости 50-60 обновлений в секунду.
Хорошо бы уточнить, что имеется в виду.

Добавлено через 7 минут

Все твои расчеты сводятся к прямоугольным спрайтам, тоесть тайлам,

Ошибаетесь. Имеются в виду спрайты с "дырками" в любом месте - копирование-то построчное, и нет ограничений, где строка начнётся, и где закончится, как и сколько строк будет скопировано на одну результирующую строку. Этот приём ещё со времён Doom известен. Compuserve GIF тоже похожим образом действует ;-)

а курсор и спрайты героев без альфы

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

[Valen]

Для чего тогда все 2D консоли имеют 50-60fps?
Лично мне тошно смотреть на пц'шную рвань в 2D платформерах.
Игр работающих во фрейм или вообще учитывающих этот эффект по пальцам можно пересчитать.

+1

Я о том же.
Поэтому расчёты в примерах, привожу именно для one frame.

Что значит "работающих во фрейм"?

Это когда программа обновляет видео-буфер с частотой,
равной частоте вертикальной развёртки.
Это приводит к максимальной "плавности" движения игровых объектов.

Хотя спор про one frame, это вторично.
Кто хочет 30 FPS делать - делайте на здоровье.

Была бы _возможность_ делать one frame (хотя бы в режиме 640*480*8bpp). Для выяснения этого вопросв и нужно разобраться с пропускной
способностью памяти.

Ошибаетесь. Имеются в виду спрайты с "дырками" в любом месте - копирование-то построчное, и нет ограничений, где строка начнётся

Дело в том, что может-же быть такой вариант, когда
пиксели чередуются в спрайте - прозрачный/не_прозрачный.
(и так много раз)
ДМА для одного пикселя не будешь вызывать.
Значит нужно копировать программно.

Если же альфа-канал - то это делается программно, как свёртка двух изображений.

Так вот именно, что программно.
Большие спрайты не скопируешь с учётом альфа-канала.
Т.к. проц будет сильно нагружен.

Хотя, в принципе, без альфы жить можно.



Какая планируется стоимость готового компа?

[newart]

Какой эффект? Что значит "работающих во фрейм"? Могу предположить только две вещи. Либо вы, уважаемый, говорите о эффекте рваного кадра, либо вы говорите о необходимости 50-60 обновлений в секунду.

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

Если же альфа-канал - то это делается программно, как свёртка двух изображений.

Ну вот теперь прикинь сколько ресурсов сьест этот альфаканал.
К слову, это дело тормозит даже на видяхах вроде geforce2 mx400.
Взять например какой-нибудь пасьяснс - на фоне слегка анимированый пейзаж природы, поверх стопка карт с альфой и курсор с альфой и все это дело на 1.4гг не тянет фрейм. Возможно тут дело в связке windows->dx->кривые дрова и т.д?