From: Brandon Low <lostlogic_at_lostlogicx.com>
Date: Tue, 27 Dec 2005 21:47:00 -0600

Using a portion of SRAM to buffer parts of the LCD for update might make
sense. Rockbox does currently use the SRAM for a variety of other speed
sensitive things such as codec data. Because Rockbox is a cooperative
multitasking system, you must yield during long function calls, it will
not preempt your code to handle DMAs or other system things. Your
plugin runs straight through without ever calling yield, so the disk
cannot be turned off during it's run.

Someone else close to the code would have to comment on whether this is
feasible in rockbox as I am a relative newb to the rockbox world myself.

Brandon

On Wed, 12/28/05 at 01:49:55 +0100, Matthias Larisch wrote:
> 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