just tested this. because the framebuffer is entirely in sdram any way,
copying to SRAM causes a performance hit of ~50% vs just read/writing
directly from sdram.
Brandon
On Tue, 12/27/05 at 21:47:00 -0600, Brandon Low wrote:
> 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
