From: Matthias Larisch <tierchen_at_eow.ath.cx>
Date: Thu, 29 Dec 2005 10:01:19 +0100

Good morning :)

Dave Hooper wrote:
> On the idea of storing the entire framebuffer in sram .. Yep, rockbox
> uses SRAM for *lots* of stuff (mostly the lookup tables and workspaces
> used by the audio codecs, as well as executable code for commonly used
> quick functions, such as memcpy)
>
> Maybe one way to speedup lcd updates is to implement some kind of
> dirty-rectangle updates (but of course that won't speedup full frame
> updates).
>
> d

Well, sorry, this thread should have been only in developers List, it
was my first submit to a mailinglist ever :)

There is a small discussion about my points with the result that SRAM is
to full for framebuffer. However, Brandon Low made a patch with faster
lcd_update() function using burst mode for sdram... For me, this is not
as good as I hoped it to be but better than before.

Bye,

Matthias Larisch










>
> ----- Original Message ----- From: "Matthias Larisch" <tierchen_at_eow.ath.cx>
> To: <rockbox_at_cool.haxx.se>
> Sent: Wednesday, December 28, 2005 12:05 AM
> Subject: Idea: Speeding up LCD on Iriver H300
>
>
>> Hey there!
>> 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-29