Hi,
I was trying to use gp2x's framebuffer directly - no SDL, just opening the /dev/fb0 device. My first attempt was 7.5MB/s of filling the framebuffer in the C. The second one using the 32 bit integers got better at 21MB/s. The 3rd using the "register" statement for variables got me 42MB/s. That is quite an improvement!
The C code:
(it's filling the half of screen with different color than the other - I did so for some additional testing - nevermind)
But I wanted more so I wrote some inline assembler:
The results? It's 54MB/s so it's over 1/4 faster than a C compiled code (even with the "-O3" flag). And that's is not using "unrolling" for the loop so it can be faster. That's lots of bandwith for 320x240x16bps (150KB) framebuffer.
I'm satisfied with these results as they aren't bad. At the other hand I'd excpect somewhat better perfomance as the gp2x has 32 bit memory bus at 100MHz (so up to 400MB/s bandwith). Yet I understand that sdram has its limits and efficiency will never be as good as theoretical capability.
I was trying to use gp2x's framebuffer directly - no SDL, just opening the /dev/fb0 device. My first attempt was 7.5MB/s of filling the framebuffer in the C. The second one using the 32 bit integers got better at 21MB/s. The 3rd using the "register" statement for variables got me 42MB/s. That is quite an improvement!
The C code:
(it's filling the half of screen with different color than the other - I did so for some additional testing - nevermind)
Code:
int test3(unsigned short int *fb)
{
register int i;
register unsigned int pix = 0xFFFFFFFF, pix2 = 0x001F001F;
register unsigned int *c, *v, *v2;
c = (unsigned int *)fb;
v = 19200 + c;
v2 = 38400+ c;
for(;c < v; c++)
*c = pix;
for(;c < v2; c++)
*c = pix2;
return(0);
}
But I wanted more so I wrote some inline assembler:
Code:
int test6(unsigned short int *f)
{
unsigned int *bla, pix1, pix2;
bla = (unsigned int *)f;
pix1 = 0xFFFFFFFF;
pix2 = 0x001F001F;
asm
(
"mov r0, %0\n"
"mov r3, %1\n"
"mov r4, %2\n"
"mov r1, #76800\n"
"mov r2, #153600\n"
"add r1, r1, r0\n"
"add r2, r2, r0\n"
"loop:\n"
"str r3, [r0], #4\n"
"cmp r0, r1\n"
"blt loop\n"
"loop2:\n"
"str r4, [r0], #4\n"
"cmp r0, r2\n"
"blt loop2\n"
:
:"r"(f), "r"(pix1), "r"(pix2)
: "r0", "r1", "r2", "r3", "r4"
);
return(0);
}
The results? It's 54MB/s so it's over 1/4 faster than a C compiled code (even with the "-O3" flag). And that's is not using "unrolling" for the loop so it can be faster. That's lots of bandwith for 320x240x16bps (150KB) framebuffer.
I'm satisfied with these results as they aren't bad. At the other hand I'd excpect somewhat better perfomance as the gp2x has 32 bit memory bus at 100MHz (so up to 400MB/s bandwith). Yet I understand that sdram has its limits and efficiency will never be as good as theoretical capability.