repstosw

Если критические участки в программе переписывать на Ассемблере (эмуляция процессоров, эмуляция графики / звука), то производительность должна вырасти. Это выходит за рамки моей задачи, так как было нужно портировать эмулятор (автором которого я НЕ являюсь) на устройство с ADSP BF533. В целом результатом доволен, быстродействие вышло таким: 45 - 55 FPS при эмуляции CPS1 30 - 40 FPS при эмуляции CPS2. При этом показывается каждый кадр, звуковой поток не рвётся (темп плавно понижается). Система CPS слишком наворочена, так как графика/звук у неё заточены под игры(быстрые). И не надо сравнивать какой-то допотопный КР580ВМ80 в связке с убогой графикой (Спектрум небось? ) Ну и вдогонку: телефон с процессором ARM9 800 МГц воспроизводит данный эмулятор хуже (не мой порт), и КПК на 300 МГц ещё хуже! Замерял количество полных отрисовок экрана за 1 секунду (Буфер 320x224x2 из SDRAM + конвертация 16-битной палитры + вывод на дисплей) - 188 раз. Мерял этим: static __inline__ enable_cycles(void) { __asm__ __volatile__ ("R2=SYSCFG;"); __asm__ __volatile__ ("BITSET(R2,1);"); __asm__ __volatile__ ("SYSCFG=R2;"); } static __inline__ disable_cycles(void) { __asm__ __volatile__ ("R2=SYSCFG;"); __asm__ __volatile__ ("BITCLR(R2,1);"); __asm__ __volatile__ ("SYSCFG=R2;"); } static __inline__ start_cycles(void) { __asm__ __volatile__ ("R2=0;"); __asm__ __volatile__ ("CYCLES=R2;"); __asm__ __volatile__ ("CYCLES2=R2;"); } static __inline__ u64 get_cycles(void) { u32 t0,t1; __asm__ __volatile__ ("%0=cycles;%1=cycles2;":"=d"(t0),"=d"(t1)); return t0|((u64)t1<<32); } Это типа троллинг? :santa2: Полный перечень того что делается:

Это FPS всего эмулятора, а не экранный FPS: while(!quit) { // эмуляция процессоров Z80, M68020 // эмуляция видео-подсистемы (4 графических слоя) // эмуляция звуковой системы (FM синтезатор + ADPCM + Wav sound*4 канала) // эмуляция системы ввода // эмуляция памяти //эмуляция ROM-set-а // отрисовка на дисплей // вывод звука // считывание клавиш } Вот это всё ВМЕСТЕ - 55 FPS !

Сделал DMA по прерываниям. Буфер - 320 пикселов (одна строка) 640 байт в L1, уже сконверченная палитрой(тоже в L1). Даём DMA команду на отрисовку строки, а сами делаем дальше остальные вещи. Прерывание по окончанию пересылки строки снова запускает DMA для новой строки. И так пока экран не отрисуется весь. Код что ниже - рабочий, удаось поднять общую скорость (отрисовка экрана + вся программа) на 15 FPS !!! :rolleyes: Получается, что отрисовка экрана и работа процессора немного распараллелились. Макросы использую, потому что 100% гарантия что с-инлайнится. #define SRC_PITCH 544 #define DST_HEIGHT 224 #define SCR_WIDTH 320 #define SCR_HEIGHT 240 //0xFF800000..0xFF803FFF //L1_DATA_A #define NB (SCR_WIDTH<<1) #define L1_MEMORY 0xFF804000 #define L1_BUF (L1_MEMORY-NB) #define DMA_INIT \ { \ *pMDMA_S1_PERIPHERAL_MAP=0x0040; \ *pMDMA_S1_START_ADDR=(void*)L1_BUF; \ *pMDMA_S1_X_COUNT=(NB>>1); \ *pMDMA_S1_X_MODIFY=2; \ *pMDMA_S1_Y_COUNT=1; \ *pMDMA_S1_Y_MODIFY=0; \ *pMDMA_D1_PERIPHERAL_MAP=0x0040; \ *pMDMA_D1_START_ADDR=(void*)&OLED_Data; \ *pMDMA_D1_X_COUNT=(NB>>1); \ *pMDMA_D1_X_MODIFY=0; \ *pMDMA_D1_Y_COUNT=1; \ *pMDMA_D1_Y_MODIFY=0; \ } \ #define DMA_START \ { \ *pMDMA_S1_CONFIG=WDSIZE_16|DMAEN; \ *pMDMA_D1_CONFIG=WDSIZE_16|WNR|DMAEN|DI_EN; \ } \ #define DMA_STOP \ { \ *pMDMA_S1_CONFIG=0; \ *pMDMA_D1_CONFIG=0; \ } \ extern struct mame_display current_display; u16* src; EX_INTERRUPT_HANDLER(DMA_ISR) { static u16 y=DST_HEIGHT; *pMDMA_D1_IRQ_STATUS=1; y--; if(y) { register u16* buf=(u16*)L1_BUF; register u16 i; for(i=0;i<(NB>>1);i++)*buf++=palette_16bit_lookup[*src++]; src+=(SRC_PITCH-SCR_WIDTH); DMA_START } else { y=DST_HEIGHT; DMA_STOP } } void DMA_Init_Interrupt(void) { *pSIC_IMASK&=0xFFBFFFFF; //Disable MDMA1 interrupt *pSIC_IAR2=(*pSIC_IAR2&0xF0FFFFFF)|0x06000000; register_handler(ik_ivg13,DMA_ISR); *pSIC_IMASK|=0x00400000; //Enable MDMA1 interrupt } int win_init_window(void) { // disable win_old_scanlines if a win_blit_effect is active if (win_blit_effect != 0) win_old_scanlines = 0; DMA_Init_Interrupt(); DMA_INIT OLED_Clear(0x0000); return 0; } void dib_draw_window_DMA(void) { OLED_Rectangle(0,(SCR_HEIGHT-DST_HEIGHT)>>1,SCR_WIDTH-1,((SCR_HEIGHT+DST_HEIGHT)>>1)-1); src=(u16*)(((u32)current_display.game_bitmap->base)+17536+64); register u16* buf=(u16*)L1_BUF; register u16 i; for(i=0;i<(NB>>1);i++)*buf++=palette_16bit_lookup[*src++]; src+=(SRC_PITCH-SCR_WIDTH); DMA_START }

Всё сделал как написали, работает исправно, но прироста скорости всёравно нет. Пробовал убрать dma_wait, скорость повышается, но экран отрисовывается на 1/4 и весь трясётся (что и понятно почему). Попробую не ждать, а в обработчик прерывания засунуть вывод на дисплей через DMA. Рабочий код ниже: #ifndef __DMA_H__ #define __DMA_H__ //0xFF800000..0xFF803FFF //L1_DATA_A #define NB 32 #define buf0 (0xFF803FC0-(NB<<1)) #define buf1 (0xFF803FE0- NB ) #define DMA_INIT \ { \ *pMDMA_S1_PERIPHERAL_MAP=0x0040; \ *pMDMA_S1_X_COUNT=(NB>>1); \ *pMDMA_S1_X_MODIFY=2; \ *pMDMA_S1_Y_COUNT=1; \ *pMDMA_S1_Y_MODIFY=0; \ *pMDMA_D1_PERIPHERAL_MAP=0x0040; \ *pMDMA_D1_START_ADDR=(void*)&OLED_Data; \ *pMDMA_D1_X_COUNT=(NB>>1); \ *pMDMA_D1_X_MODIFY=0; \ *pMDMA_D1_Y_COUNT=1; \ *pMDMA_D1_Y_MODIFY=0; \ } \ #define DMA_SEND(buf) \ { \ *pMDMA_S1_START_ADDR=(void*)buf; \ *pMDMA_S1_CONFIG=WDSIZE_16|DMAEN; \ *pMDMA_D1_CONFIG=WDSIZE_16|WNR|DMAEN; \ } \ #define DMA_WAIT while(*pMDMA_D1_IRQ_STATUS&DMA_RUN); #define MEMORY_COPY(dst,src) \ { \ register u16 i; \ register u32* d=(u32*)dst; \ register u32* s=(u32*)src; \ for(i=0;i<(NB>>2);i++) *d++=*s++; \ } \ #define PALETTE_CONVERT(buf) \ { \ register u16 i; \ register u16* c=(u16*)buf; \ for(i=0;i<(NB>>1);i++)*c++=palette_16bit_lookup[*c]; \ } \ #endif void dib_draw_window_DMA(void) { register u16* src=(u16*)(((u32)current_display.game_bitmap->base)+17536+64); register u16 y=DST_HEIGHT; while(y--) { register u16 x=(u16)SCR_WIDTH/(u16)NB; MEMORY_COPY(buf1,src) PALETTE_CONVERT(buf1) src+=(NB>>1); while(x--) { MEMORY_COPY(buf0,src) DMA_SEND(buf1) PALETTE_CONVERT(buf0) src+=(NB>>1); DMA_WAIT MEMORY_COPY(buf1,src) DMA_SEND(buf0) PALETTE_CONVERT(buf1) src+=(NB>>1); DMA_WAIT } src+=(SRC_PITCH-SCR_WIDTH-(NB>>1)); } }

Весь цикл программы можно упрощенно представить так: while(!Quit) { эмулируем... рисуем... } Если запустить DMA и отрисовывать построчно, то всеравно прийдется ждать окончания работы DMA чтобы подсунуть ему новую линию с декодированной палитрой при передаче. В момент работы ДМА, процессор всеравно будет брать индексы из SDRAM, а это снова шина. В итоге процессор и ДМА будут рвать шину по кускам.

Там очень хитрый буфер. И он "грязный", потому что по-очереди отрисовываются несколько спрайтовых плоскостей (видеосистема Capcom PlaySystem 1/2). Если преобразовывать палитру там, то боюсь всё замедлится в число раз, равное числу плоскостей. Процессор к сожалению будет конвертить палитру, а DMA так же занимать шину во время транзакций. И можно будет авансом заранее сделать не более 1 цикла эмуляции, до того как экран будет полностью не отрисован, иначе пропуск кадра будет что плохо. Проверил работу процедуры. На практике вышло чуть-лучше. Но ненамного. Вот код всей процедуры - пока не вычесал, затронут только внутренний цикл. .section/DOUBLE32 program; .extern _current_display; .extern _palette_16bit_lookup .global _dib_draw_window_asm; _dib_draw_window_asm: [--SP] = (P5:3); P1.L = _current_display+4; P1.H = _current_display+4; P1 = [P1]; P2 = 17600; P0 = 224; I0 = 0; I0.H = 8193; P1 = [P1 + 16]; P5.L = _palette_16bit_lookup; P5.H = _palette_16bit_lookup; P4 = 4; P1 = P1 + P2; [SP + 12] = P1; LOOP CycleYL LC1 = P0; CycleY: LOOP_BEGIN CycleYL; P1 = [SP + 12]; P0 = 80; P3 = [P5]; R5=P3; LOOP CycleXL LC0 = P0; CycleX: LOOP_BEGIN CycleXL; R0=W[P1 + 2] (Z) ; R0=R0<<1 || R1=W[P1 ++ P4] (Z) ; R1=R1<<1 || R2=W[P1 + 2] (Z) ; R2=R2<<1 || R3=W[P1 ++ P4] (Z) ; P0=R3 ; P0=P3+(P0<<1) ; //Preg read after write which requires 4 extra cycles R0=R0+R5 (NS) || R7.L=W[P0] ; I1=R0 ; R1=R1+R5 (NS) || R6.H=W[I1] ; //Dagreg read after write which requires 4 extra cycles I1=R1 ; R2=R2+R5 (NS) || R6.L=W[I1] ; //Dagreg read after write which requires 4 extra cycles I1=R2 ; R3=R3+R5 (NS) || R7.H=W[I1] || [I0]=R6; //Dagreg read after write which requires 4 extra cycles [I0]=R7 ; LOOP_END CycleXL; .P35L13: P0 = [SP + 12]; P1 = 1088; P1 = P0 + P1; //Preg read after write which requires 3 extra cycles [SP + 12] = P1; LOOP_END CycleYL; .P35L14: (P5:3) = [SP++]; RTS; А вот это разочаровало: //Preg read after write which requires 3 extra cycles //Dagreg read after write which requires 4 extra cycles Выходит вся оптимизация и конвеер лесом?? Пока получилось 35 - 40 FPS, в идеале должно быть 60 FPS (частота смены кадров NTSC)

Процессор разогнан до 550 МГц. Шина CCLK/3=183 МГц. SDRAM работает на 183 МГц с CAS latency =2. Кеш включен (для кода и данных). Дисплей 7 тактов (setup + write + hold), в эквиваленте 183/7 = 26 МГц. Шина данных 16 бит. Обращение к 32 битам идет подряд как 2 раза по 16 бит, адрес+1. Но та как адресов у контроллера дисплея нет (точнее есть и висит он на самом старшем адресном бите), инкремент адреса не мешает. Это небольшой burst из двух коротких слов :) Сделал 14 строк ассемблера на 4 пикселя. Раньше было 11 строк на 2 пикселя. Ппришлось попарить мозг, пока вышло так (задействовал конвеер Блекфина). Пока не проверял в работе, но компилируется. Эффективность кода возросла на 36% #define PIXEL \ { \ __asm__ volatile (" R0=W[P0++] (Z);"); \ __asm__ volatile ("R0=R0<<1 || R1=W[P0++] (Z);"); \ __asm__ volatile ("R1=R1<<1 || R2=W[P0++] (Z);"); \ __asm__ volatile ("R2=R2<<1 || R3=W[P0++] (Z);"); \ __asm__ volatile ("P3=R3 ;"); \ __asm__ volatile ("P3=P5+(P3<<1) ;"); \ __asm__ volatile ("R0=R0+R5 (NS) || R1.H=W[P3] ;"); \ __asm__ volatile ("I0=R0 ;"); \ __asm__ volatile ("R1=R1+R5 (NS) || R0.L=W[I0] ;"); \ __asm__ volatile ("I1=R1 ;"); \ __asm__ volatile ("R2=R2+R5 (NS) || R0.H=W[I1] ;"); \ __asm__ volatile ("I2=R2 ;"); \ __asm__ volatile ("R3=R3+R5 (NS) || R1.L=W[I2] || [P1]=R0 ;"); \ __asm__ volatile (" [P1]=R1 ;"); \ \ } \ К сожалению объем графических данных не позволяет сделать буфер на строку во внутренней памяти + DMA. Потому что программу писал не я. Это эмуляция аркадных автоматов Capcom Play System 1/2, там палитра больше 256 цветов :) Вот это детище портировал на BF533: https://osdn.net/projects/mamespi/releases/2046 / https://www.zophar.net/mame/caname.html

У Блекфина система команд такая, что особо не разбежишься. Всё очень строго, и конвеер там допускает инструкции в строго определенной последовательности. Строковых блочных команд нет вроде. Смотрел внимательно тут: http://microsin.net/programming/dsp/blackf...ence-part1.html http://microsin.net/programming/dsp/blackf...ence-part2.html Максимум получилось избавиться от 2 инструкций - вместо 11 строк кода имею 9: P1 - адрес src, P3 - адрес палитры, P5 - видео-регистр дисплея __asm__ volatile ("R0=W[P1++] (Z);"); \ __asm__ volatile ("P0=R0;"); \ __asm__ volatile ("R0=W[P1++] (Z);"); \ __asm__ volatile ("P2=R0;"); \ __asm__ volatile ("P0=P3+(P0<<1);"); \ __asm__ volatile ("P2=P3+(P2<<1);"); \ __asm__ volatile ("R1.H=W[P0];"); \ __asm__ volatile ("R1.L=W[P2];"); \ __asm__ volatile ("[P5]=R1;"); \

По-разному пробовал: //#define PIXEL {OLED_Data_32=(palette_16bit_lookup[src[1]]<<16)|palette_16bit_lookup[src[0]];src+=2;} //#define PIXEL {OLED_Data_32=palette_16bit_lookup[*src++];OLED_Data_32=palette_16bit_lookup[*src++];} Выходит так: 1 LOOP_BEGIN .P38L6L; 2 R0 = W[P1 + 2] (Z); 3 P0 = R0; 4 R0 = W[P1 ++ P5] (Z); 5 P2 = R0; 6 P0 = P3 + (P0<<1); 7 R0.L = W[P0]; 8 P0 = P3 + (P2<<1); 9 R1 = R0 << 16 || R0 = W[P0] (Z); 10 R0 = R1 | R0; 11 [P4] = R0; 12 LOOP_END .P38L6L; 1 LOOP_BEGIN .P38L6L; 2 R0 = W[P1++] (Z); 3 P2 = R0; 4 P2 = P4 + (P2<<1); 5 R0 = W[P2] (Z); 6 [P5] = R0; 7 R0 = W[P1++] (Z); 8 P2 = R0; 9 P2 = P4 + (P2<<1); 10 R0 = W[P2] (Z); 11 [P5] = R0; 12 LOOP_END .P38L6L; Не особо вижу разницы, да и код на внешний вид действительно неплотный. Вот это : R1 = R0 << 16 || R0 = W[P0] (Z); - параллельное выполнение команд? LDM R0!, {R1-R8};сорри за ARM wink.gif и получит burst-чтение SDRAM Это 8 порций по 32 бита подряд за одно чтение? Есть ли такая фишка в Блекфинах? :rolleyes: :rolleyes: :rolleyes: У Intel-ловских процессоров есть подобное с mmx- и xmm- регистрами: 8 байт за раз переслать можно аналогично!

Согласен, иначе следующие PIXEL при if()else... не попадут под условие. Попробую вернуть внутренний цикл и посмотреть что сделает компилятор(асм- листинг). Пробовал процедуру отрисовки скопировать в L1 Code SRAM (64K) из SDRAM. Вот так: memcpy((void*)0xFFA00000, (const void*)Draw_Screen,0x8000); //скопировал 32 килобайта (с запасом, точный размер функции в map-файле) // 0xFFA00000 - 0xFFA0FFFF Code SRAM (64K) При передаче управления туда - зависает. Передаю управление так: #define CALL(Address) (*(void(*)(void)) Address)(); //Вызов функции по её адресу CALL(0xFFA00000) Что не так? Как правильно грузить данный участок памяти кода L1 Code SRAM ? (от кеширования этот участок свободен). Есть ли #pragma в Visual DSP позволяющая сделать отдельные фуккции позиционно-независимыми? (position independent) ? Насколько оправдано размещать отдельно код процедуры отрисовки во внутренней памяти, если включено кеширование для SDRAM (I cache + D cache) ? Приложение большое - около 2 МБайт.

Быстро, в смысле уменьшить время перекидывания буфера на экран. Перерисовка экрана полная. Посмотрел листинг функции на ассемблере, мой опыт не позвояет сказать насколько оптимально делает VDSP++, листинг приложил. Знающих в ассебмлере, прошу глянуть листинг - оцените насколько неоптимально или оптимально сделал компилятор свою работу? Если же слабые места будут, то буду копать ассемблер BF. asm.txt Это два пиксела по 16 бит каждый.

Здравствуйте. Использую ADSP BF533 + SDRAM + OLED Display (подключен к EBIU 16 бит). Программа загружена в SDRAM, кэширование включено: для данных и программ, политика write back. Дисплей не прокеширован. Периодически нужно отрисовывать кадр на дисплей, как можно быстрее. Видеопамять дисплея - 16 бит на пиксел, адрес автоматически увеличивается на +1 пиксел после отрисовки точки. Есть буфер в котором строистя изображение - источник. Кодировка цветов через палитру. Приемником выступает сам дисплей. Палитру засунул в L1_DATA_B, чтобы ускорить доступ к ней (попиксельно идет обращение). Буфер источника находится в SDRAM (кеширована). За один присест сразу рисую 2 пиксела по 16 бит, по сути формирую 32-битное обращение к памяти дисплея: #define OLED_Data_32 (*(volatile u32*) 0x20010000) Хотя он подключен к 16-битной шине. Фрагмент кода: //u8, u16, u32 - char, short и long соответственно 1 2 4 байта UINT16* palette_16bit_lookup=(UINT16*)0xFF900000; //L1_DATA_B 16KB Тут палитра #define SRC_PITCH 544 /* Ширина источника */ #define DST_HEIGHT 224 /* Высота приемника */ #define SCR_WIDTH 320 /* Ширина дисплея */ #define SCR_HEIGHT 240 /* Высота дисплея */ #define OLED_Data_32 (*(volatile u32*) 0x20010000) /* Это регистр данных дисплея с автоинкрементом адреса, подключен к EBIU Blackfin - разрядность 16 бит */ #define PIXEL OLED_Data_32=(palette_16bit_lookup[src[1]]<<16)|palette_16bit_lookup[src[0]];src+=2; /* выводим сразу 2 пиксела(по 16 bit) на дисплей, цвет берем из палитры */ #define PIXELLAST OLED_Data_32=(palette_16bit_lookup[src[1]]<<16)|palette_16bit_lookup[src[0]];src+=(SRC_PITCH-SCR_WIDTH+2); /* последние 2 пиксела */ void Draw_Window(struct BITMAP *bitmap) //Отправка буфера на дисплей { register u16* src=(u16*)(((u32)bitmap->base)+17536+64); //Стартовый адрес источника register u32 y=DST_HEIGHT; OLED_Rectangle(0,(SCR_HEIGHT-DST_HEIGHT)>>1,SCR_WIDTH-1,((SCR_HEIGHT+DST_HEIGHT)>>1)-1); //Задаёт прямоугольную область 320x224 по центру дисплея (сам дисплей 320x240) while(y--) //цикл по Y, цикл по X развернут на 320 точек (160 слов) { PIXEL /* 159 раз */ PIXEL PIXEL /* ... */ PIXEL PIXEL PIXELLAST /* 160-й раз */ } } Цикл по X развернут макросами для ускорения. Компилировал это дело в Visual DSP++ 5.1.2 - пробовал такую оптимизацию: Speed 100, Interprocedural optimization, Frame-pointer optimization. Код работает как нужно , но подозреваю, что можно сделать быстрее! Дает ли прирост скорости 32-битное обращение к регистру данных дисплея, когда он подключен к 16-битной шине? Фактически это 2 операции подряд по 16 бит с увеличением адреса (не используются). Как можно сделать ещё быстрее? Рассмотрю любые способы: от изменения алгоритма, до системного управления процессором (кеширование, выравнивание). Пробовал изменить тайминги шины EBIU, ничего не меняется. Как можно пере-инициализировать контроллер асинхронной шины, когда он уже работает?