GP2X Hardware Blitter?

[icurafu]

Just tried a basic test blitting a 32x32 16bit box 1000 times (basic src->dst copy), if I've got my numbers right...

non-optimized s/w = 0.46 seconds,
gcc -O3 s/w = 0.38 seconds.
non-optimized h/w = 0.03 seconds

gcc optimizes the h/w blit badly since it doesn't know the importance of setting MESGSTATUS last, but it was only a test run.

​

wait a second. Isn't that...

32x32x16x1000/0.03

=546 megabits per second fillrate.

That's rather fast.

​

34 million pixels/s, the CPU would have been running from cache so only the display and blitter should have been hitting the memory bus. Blitter accesses are 32bit so it _could_ be handling 2 pixels per clock (ie second pixel is read at same time as first - potential memory access saved). It's only doing a basic read/write so best case would be averaging 1 pixel per clock.

Then again those timings might be a bit off. Timing is from the MMSP's timer (7.3728MHz).
167440 ticks for the h/w and 3412159 ticks for the non-opt s/w.

​

Hmm, I thought the blitter was 16-bit.

 

[Oscaruzzo]

OK, I've got hardware accelerated SDL_FillRect(). It works on 16bpp HW_SURFACES (all other cases are managed with the software implementation), and it is FAST. It takes 3.5 seconds to fill-draw 250.000 random rectangles, instead of 73 seconds.

As soon as i have the SDL_BlitSurface() working. it will be made available via the open2x project.