реклама на сайте
подробности

 
 
4 страниц V  « < 2 3 4  
Reply to this topicStart new topic
> BF533 отрисовка на дисплей, шина EBIU
__inline__
сообщение Sep 11 2017, 08:30
Сообщение #46


Участник
*

Группа: Участник
Сообщений: 30
Регистрация: 5-09-17
Пользователь №: 99 126



Цитата(_pv @ Sep 11 2017, 07:44) *
у этого контроллера даже есть тупо 16ти битный RGB интерфейс, который на ppi вешается без какой-либо дополнительной логики вообще, просто напрямую.

В своё время я поостерёгся использовать PPI + RGB-интерфейс дисплея. Показалось, что постоянная отрисовка на дисплей(формирование развертки видео-сигнала) отрицательно скажется на всей работе системы в целом. Не помню чем оттолкнула эта идея, то-ли от того что надо будет выжидать освобождения памяти или ещё чего-то...
Давно это было.

Вопрос про PPI был в другом: можно ли его настроить на управление контроллером S6E63D6 или тупо видео-сигнал?
Хочется чтобы регенерацией экрана занимался именно S6E63D6 , а не ДМА Блекфина через PPI.
И шину разгрузить хотелось бы sm.gif

Речь идет об этом девайсике:

Прикрепленное изображение


Решил "тряхнуть стариной" и портировать ещё несколько эмуляторов на него
Go to the top of the page
 
+Quote Post
_pv
сообщение Sep 11 2017, 09:09
Сообщение #47


Гуру
******

Группа: Свой
Сообщений: 2 191
Регистрация: 8-04-05
Из: Nsk
Пользователь №: 3 954



Цитата(__inline__ @ Sep 11 2017, 14:30) *
В своё время я поостерёгся использовать PPI + RGB-интерфейс дисплея. Показалось, что постоянная отрисовка на дисплей(формирование развертки видео-сигнала) отрицательно скажется на всей работе системы в целом.

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

Цитата(__inline__ @ Sep 11 2017, 14:30) *
Вопрос про PPI был в другом: можно ли его настроить на управление контроллером S6E63D6 или тупо видео-сигнал?
Хочется чтобы регенерацией экрана занимался именно S6E63D6 , а не ДМА Блекфина через PPI.
И шину разгрузить хотелось бы sm.gif


писать в регистры дисплея, в том числе и для того чтобы включить этот самый RGB (который, насколько я понял, можно использовать только для записи в видеопамять контроллера), можно и через spi.

ну и sdram в несколько раз (в 7) быстрее чем асинхронная шина дисплея, поэтому если даже завести отдельный буфер на весь экран во внешней памяти, куда будет складываться результат обработки цвета из палитры, а потом из этого же буфера DMA будет перекладывать всю картинку на экран, то даже эти дополнительные копирования туда-сюда будут быстрее чем сейчас. ну а если обрабатывать картинку построчно и сразу же выдавать через ppi, так тем более.

ну и ещё как вариант есть sport, c 133мбитами пропускной способности каждый, которых хватит на сотню fps 320*240*16бит, а параллельная 16ти разрядная шина делается из него двумя сдвиговыми регистрами.
Go to the top of the page
 
+Quote Post
__inline__
сообщение Sep 11 2017, 09:32
Сообщение #48


Участник
*

Группа: Участник
Сообщений: 30
Регистрация: 5-09-17
Пользователь №: 99 126



На самом деле при включенном кешировании арбитраж шины не слишком сильно душит производительность всей системы в целом.

Иначе, почему память видеокарт в ПК отображена на общее адресное пространство процессора?
В неё тоже можно писать и читать из нее процессором и ПК не тормозит из-за арбитража шины.

Понимаю, что видео-карта сама может ворочать в своей памяти и будет быстрее, но доступ со стороны CPU сохранен.

Ну и финальный вопрос: вы можете примерно предположить, во сколько раз должна подняться производительность системы, если дисплей перевешать на PPI?
Go to the top of the page
 
+Quote Post
_pv
сообщение Sep 11 2017, 10:07
Сообщение #49


Гуру
******

Группа: Свой
Сообщений: 2 191
Регистрация: 8-04-05
Из: Nsk
Пользователь №: 3 954



Цитата(__inline__ @ Sep 11 2017, 15:32) *
Ну и финальный вопрос: вы можете примерно предположить, во сколько раз должна подняться производительность системы, если дисплей перевешать на PPI?

ну чисто теоретически, сейчас дисплей занимает шину на 3мс из 16 при 60фпс. вот эти 20% и сэкономите,
но из них ещё поди примерно четверть-треть времени процессор всё равно занят преобразованием цвета по палитре.

если избавитесь от плавающей запятой при работе со звуком, разница, думаю, заметнее будет.
переход на fast-fp(который раза в 3-4 быстрее обычного) дал прирост 10%fps, то есть грубо говоря 2мс процессорного времени, то есть получается что почти половина времени вашего эмулятора тратится на звук с плавучкой - 6мс, которые можно больше чем порядок сократить с целочисленной арифметикой.
Go to the top of the page
 
+Quote Post
__inline__
сообщение Sep 11 2017, 14:58
Сообщение #50


Участник
*

Группа: Участник
Сообщений: 30
Регистрация: 5-09-17
Пользователь №: 99 126



Ещё обнаружил интересную ситуацию: Visual DSP 5.1.2 даёт рабочий код, а если собрать в VDSP 5.0, то эмулятор зависает в момент когда должен появиться звук.
Если не использовать -fp-fast, то обе среды дают рабочий код.

Подозреваю, что в 5.0 -fp-fast выполнен через ОПУ и не гарантирует корректной работы с эмуляцией плавучки sm.gif))
Go to the top of the page
 
+Quote Post
jcxz
сообщение Sep 11 2017, 18:49
Сообщение #51


Гуру
******

Группа: Свой
Сообщений: 3 643
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(_pv @ Sep 11 2017, 17:07) *
если избавитесь от плавающей запятой при работе со звуком, разница, думаю, заметнее будет.
переход на fast-fp(который раза в 3-4 быстрее обычного) дал прирост 10%fps, то есть грубо говоря 2мс процессорного времени, то есть получается что почти половина времени вашего эмулятора тратится на звук с плавучкой - 6мс, которые можно больше чем порядок сократить с целочисленной арифметикой.

После слов ТС о том, что "эмулятор звука использует плавучку" при том что она в данном МК - софтварная, у меня возникло ощущение, что автор вообще не понимает где и на что у него тратится время процессора и в какую сторону надо рыть. Скорей всего основную часть процессорного времени занимает звук, а не видео, а значит и оптимизировать нужно в первую очередь звук.
Go to the top of the page
 
+Quote Post
__inline__
сообщение Sep 12 2017, 01:30
Сообщение #52


Участник
*

Группа: Участник
Сообщений: 30
Регистрация: 5-09-17
Пользователь №: 99 126



Цитата(jcxz @ Sep 11 2017, 18:49) *
Скорей всего основную часть процессорного времени занимает звук, а не видео, а значит и оптимизировать нужно в первую очередь звук.

Любой участок можно замерить теми же CYCLES, просто вплотную к оптимизации звука ещё не подошел.
Кстати, отсутствие мат-сопроцессора в Блекфин меня в свое время очень разочаровало.

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

Вот есть STM32 , у них есть мат-сопроцессор, но не более 300 МГц, то не радует.

Есть ли камни контроллеров с тактовой от 1 ГГц с FPU и открытой архитектурой?
Pi не предлагать, так как закрыта.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Sep 12 2017, 02:35
Сообщение #53


Гуру
******

Группа: Свой
Сообщений: 3 643
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(__inline__ @ Sep 12 2017, 08:30) *
Есть ли камни контроллеров с тактовой от 1 ГГц с FPU и открытой архитектурой?

Ну если опустить 1ГГц, то я работал с OMAP L-137 (есть также L-138). DSP-ядро которого имеет набор команд для работы как с float так и double. Умеет вроде 1 double-MAC-операцию за 2 такта или 2 float MAC за 1 такт (точно не помню). На частоте до 450МГц.
DSP-ядро этих OMAP можете считать отдельным сопроцессором если так угодно (в составе OMAP есть также основное ARM-ядро и ещё два PRU-ядра).
Есть также это DSP-ядро в stand-alone: TMS320C674x.
Документация на него открытая и достаточно подробная для освоения.
И в STM нет какого-то сопроцессора, есть набор команд плавающей арифметики, выполняемых тем же самым ядром.
Go to the top of the page
 
+Quote Post
_pv
сообщение Sep 12 2017, 07:44
Сообщение #54


Гуру
******

Группа: Свой
Сообщений: 2 191
Регистрация: 8-04-05
Из: Nsk
Пользователь №: 3 954



Цитата(__inline__ @ Sep 12 2017, 07:30) *
Есть например приставка SNES, в которой плавучка просто необходима для расчета эффекта полупрозрачности и поворота на произвольный градус.

это всё замечательно делается и в целых числах.
зачем плавающая запятая для графических данных у которых динамический диапазон 8 бит?
она и для звука не очень-то и нужна. уж тем более в эмуляторе 8ми битной приставки.
Go to the top of the page
 
+Quote Post

4 страниц V  « < 2 3 4
Reply to this topicStart new topic
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 22nd September 2017 - 22:43
Рейтинг@Mail.ru


Страница сгенерированна за 0.01418 секунд с 7
ELECTRONIX ©2004-2016