|
Rockbox mail archiveSubject: Idea: Speeding up LCD on Iriver H300Idea: Speeding up LCD on Iriver H300
From: Matthias Larisch <tierchen_at_eow.ath.cx>
Date: Wed, 28 Dec 2005 01:49:55 +0100 Hey there! FIRST: Sorry for crosspost! I didnt want to post this on GENERAL, just on DEVEL. But I'm new to mailinglists. I'm new to rockbox and used my last 24 hours to go through the whole code. Myself owns an Iriver H300. I think rockbox is very great now, but could be much better :) (Jpeg, Video) So here is what I think about the lcd_update() Speed problem: The LCD can handle one Pixel per 150ns (Datasheed->Writecycle). That would be around 120frames per second. I think, the problem is in the code. For every Pixel send to LCD, Chipselect selects SDRam, reads one byte, selects LCD and writes byte there. The whole procedure with switching Chipselects for every byte (aw sry, i mean word, pixel) is consuming many time we dont have... I wrote a very small speed-test, a few loops with just increasing colors (nearly no calculations, just to have it look funny) with LCD_WIDTH calls to lcd_update(). This loop dures around 28 seconds with CPU not boosted and around 10 seconds with CPU boosted. Just for fun with CPU Idle: 2 mins 24 -> 144 seconds. Oh maybe a kind of bug: My plugin only has this for-loop, and standard plugin api. HD doesnt stop spinning! (it seems like nothing else than plugin code is executed) And.. kind of mistake in my program: it just runs from 0 to LCD_WIDTH-31, so 189 loops. That is: Idle 1,3125 fps Normal 6,75fps Boost 18,9fps Code, just if someone wanna use it ^^ (verry crappy) int i,j,c; for(c=0;c<LCD_WIDTH-31;c++) { for(j=0;j<LCD_HEIGHT;j++) { for(i=c;i<c+31;i++) { rb->lcd_framebuffer[j*LCD_WIDTH+i]=LCD_RGBPACK(c,j,i*8); } } rb->lcd_update(); } So only calculation done is LCD_RGBPACK with few bitshifting... Not to forget the loops, with few clockcycles per run. So my idea is: What about buffering the whole lcd_framebuffer in internal SRAM? (64kbyte are not enough... so we have to put second 32kbyte directly after the 64kbyte to connect these 2 together. I dont really know.. Does rockbox use sram for some stuff? If so, on lcd_update move away the crap, store lcd_framebuffer in there, write to gram and last but not least (else player would maybe hang ^^) restore crap from the beginning. This should be a little bit faster... But I cannot implement it because of my low coding skills (PHP is more what i can do...) What do you think of my idea? bye, Matthias Larisch Received on 2005-12-28 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |