GP2X Hardware Blitter?


paeryn posted on Dec 20 2005 at 06:22 AM said:
icurafu posted on Dec 19 2005 at 01:23 PM said:
paeryn posted on Dec 19 2005 at 05:39 AM said:
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.
 
Last edited by a moderator:
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.
 
Back
Top