repstosw 18 11 сентября, 2017 Опубликовано 11 сентября, 2017 · Жалоба у этого контроллера даже есть тупо 16ти битный RGB интерфейс, который на ppi вешается без какой-либо дополнительной логики вообще, просто напрямую. В своё время я поостерёгся использовать PPI + RGB-интерфейс дисплея. Показалось, что постоянная отрисовка на дисплей(формирование развертки видео-сигнала) отрицательно скажется на всей работе системы в целом. Не помню чем оттолкнула эта идея, то-ли от того что надо будет выжидать освобождения памяти или ещё чего-то... Давно это было. Вопрос про PPI был в другом: можно ли его настроить на управление контроллером S6E63D6 или тупо видео-сигнал? Хочется чтобы регенерацией экрана занимался именно S6E63D6 , а не ДМА Блекфина через PPI. И шину разгрузить хотелось бы :) Речь идет об этом девайсике: Решил "тряхнуть стариной" и портировать ещё несколько эмуляторов на него Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 79 11 сентября, 2017 Опубликовано 11 сентября, 2017 · Жалоба В своё время я поостерёгся использовать PPI + RGB-интерфейс дисплея. Показалось, что постоянная отрисовка на дисплей(формирование развертки видео-сигнала) отрицательно скажется на всей работе системы в целом. а повесить его на шину памяти, на который сидит sdram, из которого ещё и код выполняется, имхо, куда менее удачная идея с точки зрения работы всё системы в целом. Вопрос про PPI был в другом: можно ли его настроить на управление контроллером S6E63D6 или тупо видео-сигнал? Хочется чтобы регенерацией экрана занимался именно S6E63D6 , а не ДМА Блекфина через PPI. И шину разгрузить хотелось бы :) писать в регистры дисплея, в том числе и для того чтобы включить этот самый RGB (который, насколько я понял, можно использовать только для записи в видеопамять контроллера), можно и через spi. ну и sdram в несколько раз (в 7) быстрее чем асинхронная шина дисплея, поэтому если даже завести отдельный буфер на весь экран во внешней памяти, куда будет складываться результат обработки цвета из палитры, а потом из этого же буфера DMA будет перекладывать всю картинку на экран, то даже эти дополнительные копирования туда-сюда будут быстрее чем сейчас. ну а если обрабатывать картинку построчно и сразу же выдавать через ppi, так тем более. ну и ещё как вариант есть sport, c 133мбитами пропускной способности каждый, которых хватит на сотню fps 320*240*16бит, а параллельная 16ти разрядная шина делается из него двумя сдвиговыми регистрами. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 11 сентября, 2017 Опубликовано 11 сентября, 2017 · Жалоба На самом деле при включенном кешировании арбитраж шины не слишком сильно душит производительность всей системы в целом. Иначе, почему память видеокарт в ПК отображена на общее адресное пространство процессора? В неё тоже можно писать и читать из нее процессором и ПК не тормозит из-за арбитража шины. Понимаю, что видео-карта сама может ворочать в своей памяти и будет быстрее, но доступ со стороны CPU сохранен. Ну и финальный вопрос: вы можете примерно предположить, во сколько раз должна подняться производительность системы, если дисплей перевешать на PPI? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 79 11 сентября, 2017 Опубликовано 11 сентября, 2017 · Жалоба Ну и финальный вопрос: вы можете примерно предположить, во сколько раз должна подняться производительность системы, если дисплей перевешать на PPI? ну чисто теоретически, сейчас дисплей занимает шину на 3мс из 16 при 60фпс. вот эти 20% и сэкономите, но из них ещё поди примерно четверть-треть времени процессор всё равно занят преобразованием цвета по палитре. если избавитесь от плавающей запятой при работе со звуком, разница, думаю, заметнее будет. переход на fast-fp(который раза в 3-4 быстрее обычного) дал прирост 10%fps, то есть грубо говоря 2мс процессорного времени, то есть получается что почти половина времени вашего эмулятора тратится на звук с плавучкой - 6мс, которые можно больше чем порядок сократить с целочисленной арифметикой. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 11 сентября, 2017 Опубликовано 11 сентября, 2017 · Жалоба Ещё обнаружил интересную ситуацию: Visual DSP 5.1.2 даёт рабочий код, а если собрать в VDSP 5.0, то эмулятор зависает в момент когда должен появиться звук. Если не использовать -fp-fast, то обе среды дают рабочий код. Подозреваю, что в 5.0 -fp-fast выполнен через ОПУ и не гарантирует корректной работы с эмуляцией плавучки :))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 242 11 сентября, 2017 Опубликовано 11 сентября, 2017 · Жалоба если избавитесь от плавающей запятой при работе со звуком, разница, думаю, заметнее будет. переход на fast-fp(который раза в 3-4 быстрее обычного) дал прирост 10%fps, то есть грубо говоря 2мс процессорного времени, то есть получается что почти половина времени вашего эмулятора тратится на звук с плавучкой - 6мс, которые можно больше чем порядок сократить с целочисленной арифметикой. После слов ТС о том, что "эмулятор звука использует плавучку" при том что она в данном МК - софтварная, у меня возникло ощущение, что автор вообще не понимает где и на что у него тратится время процессора и в какую сторону надо рыть. Скорей всего основную часть процессорного времени занимает звук, а не видео, а значит и оптимизировать нужно в первую очередь звук. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 12 сентября, 2017 Опубликовано 12 сентября, 2017 · Жалоба Скорей всего основную часть процессорного времени занимает звук, а не видео, а значит и оптимизировать нужно в первую очередь звук. Любой участок можно замерить теми же CYCLES, просто вплотную к оптимизации звука ещё не подошел. Кстати, отсутствие мат-сопроцессора в Блекфин меня в свое время очень разочаровало. Есть например приставка SNES, в которой плавучка просто необходима для расчета эффекта полупрозрачности и поворота на произвольный градус. Вот есть STM32 , у них есть мат-сопроцессор, но не более 300 МГц, то не радует. Есть ли камни контроллеров с тактовой от 1 ГГц с FPU и открытой архитектурой? Pi не предлагать, так как закрыта. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 242 12 сентября, 2017 Опубликовано 12 сентября, 2017 · Жалоба Есть ли камни контроллеров с тактовой от 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 нет какого-то сопроцессора, есть набор команд плавающей арифметики, выполняемых тем же самым ядром. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 79 12 сентября, 2017 Опубликовано 12 сентября, 2017 · Жалоба Есть например приставка SNES, в которой плавучка просто необходима для расчета эффекта полупрозрачности и поворота на произвольный градус. это всё замечательно делается и в целых числах. зачем плавающая запятая для графических данных у которых динамический диапазон 8 бит? она и для звука не очень-то и нужна. уж тем более в эмуляторе 8ми битной приставки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
