Jump to content

    

__inline__

Участник
  • Content Count

    762
  • Joined

  • Last visited

Everything posted by __inline__


  1. У отсчетов есть размерность? Число байт? Формат данных? Или это пользовательский тип? А ценящие свои деньги отлаживают на Большом Брате - ПК )))
  2. Такую хрень лучше всего на ПК отладить вначале, а потом тащить в DSP. И что такое DATA ?
  3. Может поможет. Вот мой код для C6745 (не думаю, что I2S в 6746-м сильно отличается). Играет звук через McASP + Audio FIFO + EDMA3 по трём измерениям + прерывание. Компилируется с CCS 6 TI C compiler 8.3.3, синтаксис -C99 : McASP_EDMA3.rar
  4. Сдался вам этот пинг-понг.... Всё без него делается по референс-мануалу на EDMA3 и Mc*SP
  5. Начал писать код для ПРУССов (PRUSS: http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit_Subsystem) - хорошие славные малые целочисленные RISC-процессоры. Использую C Compiler от TI для PRUSS: clpru v.2. Ставлю самую сильную оптимизацию -O4 -Speed=5. Проблема: на выходе АСМ-листинг крайне низкого качества. Особо убило, что делаю умножение - с помощью сдвигов и сложений - так: register unsigned int P; register unsigned int L=(P<<4)+(P<<1)+P; Компилятор распознаёт умножение и делает CALL на RTL-овскую функцию умножения - что НЕ ДОПУСТИМО в попиксельной обработке данных: JAL ___abi_MUL19 r, r, r Причем выключить это никак не представляется возможным, но я обошёл это так: register unsigned int L=(P<<4); L+=(P<<1); L+=P; Это глюк номер 1. Глюк номер 2: неоптимальное ассемблирование. Например - клампинг по 0 и 255 делаю тернарными операторами: P=(P<0)?0:((P>255)?255:P); //суть этого: if(P<0)P=0; else if(P>255)P=255; Ассемблирование проходит с большим треском: вместо того чтобы использовать инструкции MIN и MAX, компилятор делает условия и переходы на метки, что снижает производительность. Причем результат зависит от фазы Луны - достаточно поменять порядок вычислений или алгоритм - частично начинает применять MIN, MAX. Глюк номер 3: инлайнит функции без указания inline, инит регистров задвигает в конец - в результате ничего не работает. если сделать цикл не метками, а while(1), то неоптимально делает переходы. Резюмируя, качеством компилятора я не доволен. На PRUSS крутится такой алгоритм: конверсия кадра из YUV в RGB с посылкой в LCD: Видео работы декодера H264 + MP3 : https://www.youtube.com/watch?v=hmlP_sZ4cPY Есть ли способ этот алгоритм ещё ускорить? С PRUSS декод MP4 идёт на 38 FPS (это со считыванием с SD карты по SPI, 400x240 разрешение). Без PRUSS всего 29 FPS. Функция отрисовки та же.
  6. Портирован легендарный "Крокодил" )) https://www.youtube.com/watch?v=uyxqLgsA9yE Что такое и с чем едят: https://vrtp.ru/index.php?showtopic=301 ... ntry791921 STM32 и здесь сосёт, когда нужно было с помощью DMA перекинуть изображение на дисплей. Из-за убогости DMA кадр разбивался на 3 куска. В случае C6745 CPU вытягивает игру и без DMA. Самые лучшие процессорные ядра - у США. Вот такой вывод делаю. )
  7. ОГО!!! Выкинуть $7500 ))) JTAG - для балбесов. Используйте православные методы отладки: светодиод, UART, дисплей. Запись дампа в файл на SD карту.
  8. Tyrian под Dingoo A320. Особо люто лагает с 2:12 во время демонстрации опций игры в качественном режиме: https://www.youtube.com/watch?v=Ij5oHuere64&t=132 Полупрозрачность у облаков отключена и звук местами хрипит, так как не хватило ума сделать обработку звука правильно )) Криворукость портирующих или Линукс мешает? OpenTyrian под ведроид - https://www.youtube.com/watch?v=G-D8KKg0tpo Идёт медленно и выпилена музыка. Показательный пример, как всякие вёдра, ардуины-пердуины снижают производительность железа )))
  9. Портировал Open Tyrian )) Отрисовку опять сделал через PRUSS (хотя и без него вначале было тоже нормально) Это - классический 2D Space Shooter. Одна из немногих хороших игр для DOS. OpenTyrian на макете игровой консоли BlackPrism (TMS320C6745 DSP). Особо каких-либо проблем, связанных с производительностью - не было. Так как всё-же это нативное приложение, а не эмуляция: https://www.youtube.com/watch?v=1VbsENAWiOE Экран - классический видеорежим "13h": 320x200 256 цветов (палитровый). Звук - 46 кгц, 16 бит, 8 каналов. Музыка - эмулятор OPL3 FM YM3812 (Adlib), lds-плеер. Поддерживается основной функционал игры и часть дополнительного.
  10. Есть аудио-сигнал, распиленный на фреймы одинаковой длины. Длина фрейма, частота семплирования, разрядность известны. Нужно понизить темп воспроизведения с сохранением тональности. Как? Нужен алгоритм, желательно на C/C++. Гугл выдаёт готовые программы, нужне сам алгоритм!
  11. Добавил всё-же звук к эмулятору GBA. Использовал алгоритм растяжки темпа с сохранением тона. Задача нетривиальная и требует академического кубатуренья. Хорошо, что уже давно всё проработано. )) За основу взял эту программу (с открытыми исходниками): http://www.surina.net/soundtouch Она позволяет много чего делать со звуком: изменять темп с сохранением тона, подымать тон с сохранением темпа, ресемплинг, вычисления BPM. Куча фильтров-интерполяторов: Шеннона, Кубический, Линейный. Антиалиасинговый фильтр. Темп звука в эмуляторе растягивается в 2...3 раза (30 - 20 FPS), при этом тональность остаётся той же. Видео: https://www.youtube.com/watch?v=ulLPALpHOGk Свой вариант билда сорцов прикрепил ниже: sound_stretch.rar Отлаживал алгоритм конечно же на ПК вначале
  12. Перенёс эмулятор GameBoy Advance. Оптимизировал насколько смог: 1) таблицы переходов для ARM и Thumb вместо огроменных switch-case'ов на 4096 значений 2) переделал рендерер 3) отрисовка с помощью PRUSS построчно С 15 FPS поднял до 25 - 30 FPS. Но этого мало. Надо 60 FPS. Звук отключен, так как он лагает - проигрывается дважды. В GBA неудачная архитектура звуковой системы - задержки зависят от CPU и таймеров. Поэтому на распев тянуть ноты не вышло. Есть идея растянуть темп звука, сохранив тон. Но задача эта нетривиальная. Все звуковые стретчеры, которые я пробовал - дают либо эхо, либо дрожание. Можно конечно разогнать DSP, но это будет нечестно. Да и толку не даст - нужен разгон в 2 раза как минимум. Либо поискать другой эмулятор GBA. Но это не самоцель. Играть можно. На смещение кадра вниз (перекрут) -не обращать внимания, я забыл добавить синхронизацию по отрисовке строки. Видео: 1) https://www.youtube.com/watch?v=lymA8NMXQ5I 2) https://www.youtube.com/watch?v=sE0QRKIF_bo
  13. Компилирую очередной "шедевр эмуляции" - эмулятор ядра ARM7TDMI. Ключи такие: Проблема: не хватает оперативной памяти компа чтоб завершить компиляцию. В диспетчере задач оптимизатор занимает около 3 ГБ памяти на пике. Затем благополучно вываливается ошибка: Прикладываю сорец который не компилируется: ARM-NEW.cpp На -O2 тоже облом. Компилирует только на -O1, что не устраивает совсем! Что можно предпринять чтоб скомпилировать на максимальной оптимизации? Пилить сорец на части вроде не выйдет - там большой свитч на 6000 строк........
  14. Начитался теории, приступил к практике. Алгоритм удлинения аудио-записи с сохранением тона: 1) Делаем ресемплинг - частота снижается, запись удлиняется 2) Делаем БПФ 3) Сдвигаем спектр вверх (для восстановления исходного тона) 4) Делаем обратное БПФ На деле оказалось, что фреймы плохо стыкуются - много артефактов и в целом появляется неприятный звон или эхо. Оконными функциями пробовал по краям уменьшать амплитуды и с нахлёстом брать, но ниче не выходит пока. Должне быть способ проще растянуть звук с сохранением тона. Однако же, по отсутствию ответов - неужели никто этим не занимался?
  15. Вы правы. Да, ошибся. Слово "эмулятор" понял как раз именно в этом контексте. Меня троллят с 2008 года всякими Dingoo A320 и прочим китайским шлаком, который воспроизвоидт игры весьма дёрганно..... И меня раздражает подход "на отъ*б*сь " в китайских приставках. Но пипл хавает, ему по* на то что фреймы пропускаются и дёргаются. Дешевизна - вот путь к успеху! Даже если качество страдает. Поэтому пост jcxz был мной понят неправильно. jcxz, я понял. Всё - обиды снимаю! Всё ОК! В моей плате пины под JTAG не выведены :) Прийдётся отлаживаться любительскими методами))
  16. Мне не нужны даже даром готовые эмуляторы игровых приставок (особенно дешёвые) - интересно самому сделать. Расцениваю как плевок в мою сторону. Спасибо. Удачи!
  17. Сделал через таблицу переходов (точнее - вызовов функций). Работает, дало небольшое увеличение в скорости. Код такой: void opcode_0(void) { ... } void opcode_1(void) { ... } void opcode_2(void) { ... } void opcode_3(void) { ... } typedef void (*Handler)(void); #pragma DATA_ALIGN(32) const Handler ARM_Handler[0x1000]= { opcode_0,opcode_1,opcode_2,opcode_3, ........ }; void arm_new(void) { opcode= ..... ...... ARM_Handler[opcode](); } Таблица и код находятся в SDRAM, она закеширована по L1D, L1P, L2. При попытке скопировать таблицу ARM_Handler[0x1000] в L2 и выполнить код ARM_Handler_L2[opcode]() сославшись на эту таблицу(в L2) приводит к вылету - контроллер сбрасывается. Хочется скопировать эту таблицу в L2 и дёргать указатели функций из неё, чтобы исключить промахи кеша (ведь выборки из ARM_Handler[] случайные). Почему с копированием таблицы в L2 указатели на функции становятся невалидными? (Кеш L2 я сбрасываю, если что, хотя это тут не нужно, так как L2 некешируемый регион и любая запись в него приводит к фактической записи данных) Связано ли это как-то с адресацией данных? Может относительная адресация вместо абcолютной ? Пробовал разные data access model: - на near вообще не собирается, так как на смещение надо более 15 бит (линковщик ругается), far_aggregates и far работает. Общий объём бинарного образа - около 1 МБ Включена опция: DP relative addressing - она ускоряет выбор данных или нет?
  18. Проблема решилась: вынес все CASE16 отдельно CPP/H-файл и оформил в виде функции . Успешно скомпилировал. А в исходном файле немного изменил алгоритм и добавил вызов той самой функции. Иными словами - распилил на 2 C-файла и получил 2 объектника.
  19. Для GBA эмулятора. Выходит 25-30 FPS, вместо нужных 60 FPS. Звук тарахтит - фрагмент проигрыается дважды, так как звуковая подсистема требует данные чаще, чем эмулятор успевает заполнить буфер. Звук там "мягкий" - зависит от растактовок процессора приставки (программные задержки). Сделал ресемплинг, просто растянув отсчёты - темп понизился, тарахтение исчезло, но и тон снизился , что не нужно. Хочется чтоб именно был звук как на распев без снижения частоты (tempo stretching with pitch saving) Нашёл пару алгоритмов на гитхабе, но они ппц какие сложные. Хочется проще... А что если исходный фрейм повторять дважды, а склеивать с нахлёстом? Нахлест взять 1/4 длины фрейма. Начальный и конечный нахлест усреднить...
  20. Насколько ускорит выполнение кода таблица с указателями? И как заставить компилятор switch делать в таблицу, а не условия? TI Compiler не поддерживает GCC финт ушами наподобие: goto &&OPCODE[n];
  21. У вас вот это есть? - ".... включая мой Cherry Trail https://01.org/linuxgraphics/documentation/hardware-specification-prms " можете ссылкой поделиться на скачивание? (а вдруг я тоже буду на "атомах" что-нить делать?)) )
  22. Версия 7.4.24 успешно скомпилировала на максимально возможной с ним оптимизации. Пиковое потребление памяти - около 2 ГБ. Компилировалось - 1 час с небольшим. Но скорость кода им порождаемая, меньше, чем у 8.3.3 - так что пока проблема не решена. Чуть-позже посмотрю настройки и попробую отсечь часть кода. Результаты напишу. P.S. Под БлекФины Visual DSP v. 5.0 компилировал этот код 17 часов на стареньком компе 800 МГц с 64 МБ оперативы с Win98 :) Несколько лет назад!
  23. Сейчас спустился на версию компилятора 7.x.x уже целый час компилится, всё никак не может собраться: Обратите внимание, пакет компилятора 32-битный, а не 64-битный. Хотя железо и ОС - 64 битные. Почему?
  24. С исходниками та же фигня. (не обязательно у интела) Так что если есть что-то ценное - сохраняйте на диски! Хотя стоп! Ведь надо просто зарегаться вроде как: https://01.org/user/register