GP2X Hw Accelerated Sdl


paeryn

Reclusive maniac
Joined
Nov 28, 2005
Messages
432
Age
51
Location
Sheffield, England
Website
paeryn.myby.co.uk
Was hoping to have this ready for xmas day but several typo's evaded my tired eyes...
Source only, but it's based off the Open2x libs-gp2x project (Open2x).

Initial suport for HW accelerated surfaces. Only 16-bit at the mo, but it seems to be working okay.
Double-buffering works, RectFills are a lot faster, Blits are about 2x faster on 16x16 sprites at the mo.
Currently it allows 5MB of HW surfaces.
-----
Updated locations of where to get HW SDL, as of 16th Jan 2007

Source is available via Open2x svn,
Code:
# svn checkout https://open2x.svn.sourceforge.net/svnroot/open2x/trunk/libs/SDL-1.2.9
Pre-compiled, with selectable 5MB or 21MB of HW surfaces here please read the README.GP2X for extra info
Older versions with less surface memory,
Pre-compiled, with 5MB of HW surfaces here
Pre-compiled, with 16MB of HW surfaces here
 
Ah thats really cool, nice to see the graphics hardware finally being easily used via SDL.

Will be cool to see things recompiled to make use of this and how much speed they gain.
 
Don't expect too much speedup with small blits, SDL seems to have a fair bit of overhead. I've not tested it properly, but I grabbed several small demo programs at random to test it and they worked.
After I put in 8-bit support I'll see about making a gp2x optimized version. The HW scaler is also screaming to be freed. So much to do...
 
Yes, please incorperate HW scaling into the SDL video stuff, I would be *very* grateful when I get mine and start devving. :)

Also, I've seen a bit of the SDL code, and it looks like I would be able to contribute some stuff to it later.
 
Great news! :)

paeryn, could you upload a precompiled version of this libraries to people who are unabled to compile it by theirself as me? :unsure:

It could be very useful to try in high demand projects as my Exult port :)

Thanks
 
paeryn,

Very good job. It would be cool to combine this with the other efforts to improve SDL and use the H/W. I have dropped you a PM about that.

Blah posted on Dec 28 2005 at 05:38 AM said:
Yes, please incorperate HW scaling into the SDL video stuff, I would be *very* grateful when I get mine and start devving. :)

Supporting the scalar is proving fun to get working in a useable manor (timing, speed and flicker :eek: issues) but there maybe something to show using the scalar (crude not fine (post-processed) modes) with SDL soon(ish).

Rlyeh’s MiniLib supports the crude scalar modes (and a lot of the cool surfaces stuff) already if people want to play.
 
Last edited by a moderator:
DJWillis posted on Dec 28 2005 at 08:35 PM said:
Rlyeh’s MiniLib supports the crude scalar modes (and a lot of the cool surfaces stuff) already if people want to play.
As much as we'd like to, Rlyeh has not released his updated library yet.
 
Last edited by a moderator:
slygamer posted on Dec 28 2005 at 11:38 AM said:
As much as we'd like to, Rlyeh has not released his updated library yet.

Ahhh, scratch that then :D, Rlyeh's Minilib may support the scalar in a newer public version ;).
 
Last edited by a moderator:
paeryn posted on Dec 28 2005 at 06:30 AM said:
Don't expect too much speedup with small blits, SDL seems to have a fair bit of overhead. I've not tested it properly, but I grabbed several small demo programs at random to test it and they worked.
After I put in 8-bit support I'll see about making a gp2x optimized version. The HW scaler is also screaming to be freed. So much to do...

No only that but other functions of VideoPostProcessor too! :D

...but how it could be exposed in the SDL? It's pretty nonstandard stuff?
(the transluency and alphablending is done in the "fly" for surfaces
as I understand)
 
Last edited by a moderator:
DJWillis posted on Dec 28 2005 at 11:35 AM said:
Very good job. It would be cool to combine this with the other efforts to improve SDL and use the H/W. I have dropped you a PM about that.
Hmm, tried replying to your PM and it tells me "This message can not be sent because the recipient does not have permission to use the personal messenger."
Basically, "yes, feel free" and I'll try porting it into 1.2.9 later today.
 
Last edited by a moderator:
paeryn posted on Dec 28 2005 at 03:42 PM said:
Hmm at tried replying to your PM and it tells me "This message can not be sent because the recipient does not have permission to use the personal messenger."
Basically, "yes, feel free" and I'll try porting it into 1.2.9 later today.

Cool,

If you want drop me a mail John . Willis @ Distant - Earth . Com (remove the spaces, obviously) and I will get you the 1.2.9 code to test against, it still has bugs but should be good enough for what you need.
 
Last edited by a moderator:
Puck2099 posted on Dec 28 2005 at 09:38 AM said:
Great news! :)

paeryn, could you upload a precompiled version of this libraries to people who are unabled to compile it by theirself as me? :unsure:

It could be very useful to try in high demand projects as my Exult port :)

Thanks
Hope this works, clicky
It's compiled with gcc-3.4.4, glibc-2.3.5
 
Last edited by a moderator:
paeryn posted on Dec 28 2005 at 04:11 PM said:
Puck2099 posted on Dec 28 2005 at 09:38 AM said:
Great news! :)

paeryn, could you upload a precompiled version of this libraries to people who are unabled to compile it by theirself as me? :unsure:

It could be very useful to try in high demand projects as my Exult port :)

Thanks
Hope this works, clicky
It's compiled with gcc-3.4.4, glibc-2.3.5

Thanks a lot :)
 
Last edited by a moderator:
Very nice. I've incorporated these accelerated features into Allegro now, and it's getting great results - nice one!

There are still a few instabilities here though - sometimes a 32-bit block gets corrupted, and I've had it crash occasionally. Things got a lot better when I called your dummy_blit routine after each blit - but I still get some corruption occasionally. Weird. :) I'm reading through the docs now anyway to see if any possible reason stands out.

Blitting withing video memory is now running 30x faster, 5x faster than non-accelerated blitting from user memory to video memory. I'm a little suspicious though that the unaccelerated blitting might be slower than it ought to be - I'm going to investigate more.

Area fills and horizontal lines are nice and fast too. :) Though they weren't bad before - there's only a 50% speed increase here, so it's actually tempting to make the CPU do some of the work while the accelerator is running. I suspect memory bandwidth would slow things down though.

I also did what you said about using 5Mb of video memory from 0x03101000 - that works really well, and hardware scrolling works now.

In short, it's all looking good - hopefully I'll be able to iron out the remaining problems today and make a new release!
 
gfoot posted on Dec 29 2005 at 04:36 PM said:
Very nice. I've incorporated these accelerated features into Allegro now, and it's getting great results - nice one!

There are still a few instabilities here though - sometimes a 32-bit block gets corrupted, and I've had it crash occasionally. Things got a lot better when I called your dummy_blit routine after each blit - but I still get some corruption occasionally. Weird. :) I'm reading through the docs now anyway to see if any possible reason stands out.
Good to hear. The dummy blit is needed because the blitter caches its final write (last few pixels of a blit won't get copied until the next blit starts), might need a bit of tweaking still.
* See end
gfoot posted on Dec 29 2005 at 04:36 PM said:
Blitting withing video memory is now running 30x faster, 5x faster than non-accelerated blitting from user memory to video memory. I'm a little suspicious though that the unaccelerated blitting might be slower than it ought to be - I'm going to investigate more.
Could be a cache problem, all virtal memory addresses have to be translated, and the translation tables are in memory = fair overhead for cache misses. The blitter only works with physical addresses so doesn't have the overhead.
Area fills and horizontal lines are nice and fast too. :) Though they weren't bad before - there's only a 50% speed increase here, so it's actually tempting to make the CPU do some of the work while the accelerator is running. I suspect memory bandwidth would slow things down though.

I also did what you said about using 5Mb of video memory from 0x03101000 - that works really well, and hardware scrolling works now.

In short, it's all looking good - hopefully I'll be able to iron out the remaining problems today and make a new release!
I would get it to do stuff, the CPU could be working from its internal cache whilst the blitter (& other HW) do their things.
There is more memory space above the video mem, but I don't know if any of it is holding data that the 940 or other HW is expecting to use.

* Note
New dummy_blit code to fix corruption
Code:
// dummy blit to force MMSP2's blitter to flush it's cache
static void dummy_blit(void)
{
  // Make sure blitter is ready
  do {} while (mmsp2_blit_regs[MESGSTATUS] & 0x01);
  // Blitter seems to have a 16 byte buffer, so force flushing by
  // drawing 8 16bit pixels onto themselves.
  mmsp2_blit_regs[MESGDSTCTRL] = MESG_DSTBPP_16 | MESG_DSTENB;
  mmsp2_blit_regs[MESGDSTADDR] = 0x3101000;
  mmsp2_blit_regs[MESGSRCCTRL] = MESG_INVIDEO;
  mmsp2_blit_regs[MESGPATCTRL] = 0;
  mmsp2_blit_regs[MESGSIZE] = (1 << MESG_HEIGHT) | 8;
  mmsp2_blit_regs[MESGCTRL] = MESG_XDIR_POS | MESG_YDIR_POS | 0xaa;
  asm volatile ("" ::: "memory");
  mmsp2_blit_regs[MESGSTATUS] = 1;
}
I've moved the blitter wait loop to the top as even though the docs say the registers are buffered, it seems writing to them too early after starting a blit can lock it up.
Also it looks to be caching upto 16 bytes before writing to memory, so I've increased the blit to a 16bit 8x1, copying the top-left pixels of the framebuffer onto themselves. There has to be a way to tell the blitter to flush as requiring this is silly, but I can't find it.
 
Last edited by a moderator:
Ah, I was just about to reply, then saw your edit - I guess edits don't mark posts as unread, I hadn't seen it before. Anyway...

I've found and fixed a bug in my copy of your implementation - I don't know whether it's unique to the way I'm using the routines, but I've found it necessary to clear the source fifo when doing a blit. Set the MESG_FFCLR bit in the control register. Otherwise blits of funny widths didn't work properly (e.g. 64 pixel wide was fine, 48 was not). This only affects blits, rectfill is fine because it doesn't read the source data. Actually I'm not sure why the fifo matters anyway, as we're not reading from the CPU, we're reading from video memory (INVIDEO is set).

Here's a demo of the hardware blitting:

http://www.glost.eclipse.co.uk/gfoot/gp2x/parallax.zip

It's doing 8 layers of parallax scrolling, with tile sizes starting at 64x64 and dropping down to 8x8. So it's stressing a lot of small tiles as well as a few big tiles. All masked, at 8bpp. It gets 56fps (seems to be the maximum) with 8 layers, which doesn't seem bad. 9 layers drops to 28fps, 10 layers drops to 14fps - the overhead of doing so many small operations really kills it. At 16bpp it's a bit slower too - I'm getting about 2/3 of the performance I get at 8bpp.

Thanks for the heads up on the flushing routine - I am indeed still getting corruption, e.g. at the bottom right corner of the screen in the demo above. I'm also getting a white pixel in the top left, probably due to the old dummy blit routine I'm using. :) Hmm, maybe flushing the fifo is related to this somehow.

Something else I'm not sure of is how you figured out you have to set the busy bit to kick off the operation - it's marked as read only in the docs...

BTW, do you have a list of the 256 ROP modes? Allegro supports some blends, currently I just fall back to software rendering for blended writes but if the hardware can do it then maybe I should hook it. :) It also supports patterns, which could be easy to hook up, as the MMSP2 pattern support seems fairly straightforward.
 
gfoot posted on Dec 30 2005 at 08:13 AM said:
Ah, I was just about to reply, then saw your edit - I guess edits don't mark posts as unread, I hadn't seen it before. Anyway...

I've found and fixed a bug in my copy of your implementation - I don't know whether it's unique to the way I'm using the routines, but I've found it necessary to clear the source fifo when doing a blit. Set the MESG_FFCLR bit in the control register. Otherwise blits of funny widths didn't work properly (e.g. 64 pixel wide was fine, 48 was not). This only affects blits, rectfill is fine because it doesn't read the source data. Actually I'm not sure why the fifo matters anyway, as we're not reading from the CPU, we're reading from video memory (INVIDEO is set).

Here's a demo of the hardware blitting:

http://www.glost.eclipse.co.uk/gfoot/gp2x/parallax.zip

It's doing 8 layers of parallax scrolling, with tile sizes starting at 64x64 and dropping down to 8x8. So it's stressing a lot of small tiles as well as a few big tiles. All masked, at 8bpp. It gets 56fps (seems to be the maximum) with 8 layers, which doesn't seem bad. 9 layers drops to 28fps, 10 layers drops to 14fps - the overhead of doing so many small operations really kills it. At 16bpp it's a bit slower too - I'm getting about 2/3 of the performance I get at 8bpp.

Thanks for the heads up on the flushing routine - I am indeed still getting corruption, e.g. at the bottom right corner of the screen in the demo above. I'm also getting a white pixel in the top left, probably due to the old dummy blit routine I'm using. :) Hmm, maybe flushing the fifo is related to this somehow.

Something else I'm not sure of is how you figured out you have to set the busy bit to kick off the operation - it's marked as read only in the docs...

BTW, do you have a list of the 256 ROP modes? Allegro supports some blends, currently I just fall back to software rendering for blended writes but if the hardware can do it then maybe I should hook it. :) It also supports patterns, which could be easy to hook up, as the MMSP2 pattern support seems fairly straightforward.
I'll take a look tonight, this seems too much of a kludge to be the proper way to do it. There should really be a flush command but I can't find one.
About how I figured how to start blitter - it had to be triggered by a register write, they have a whole register with only one bit used to say that blitter was busy - moment of inspiration to write to it to tell it it needs to be busy. BTW it doesn't matter what's written to it, as long as it is wrtten to.

The ROPs are described here
MMSP2 patterns are 8x8, and you can only tell it a y-start. My RectFill uses patterns, but as monochrome and both colours set to the same. There's no alpha-blending in blits ;-(
 
Last edited by a moderator:
Cool. The ROPs are pretty straightforward then when you know how to put them together. :) Allegro supports XOR, which is the only useful one to accelerate really. Its patterns are a mixed bag though - they're required to be powers of two in width and height, but not fixed at 8. Since the MMSP2 can't accelerate all patterns, it doesn't seem worth supporting them at all, I'll just make it run the CPU routine to do those.

The new dummy blit still doesn't seem to work - it doesn't seem to flush the cache, and draws a black line rather than duplicating what was already on the screen.
 
gfoot posted on Dec 30 2005 at 02:56 PM said:
Cool. The ROPs are pretty straightforward then when you know how to put them together. :) Allegro supports XOR, which is the only useful one to accelerate really. Its patterns are a mixed bag though - they're required to be powers of two in width and height, but not fixed at 8. Since the MMSP2 can't accelerate all patterns, it doesn't seem worth supporting them at all, I'll just make it run the CPU routine to do those.

The new dummy blit still doesn't seem to work - it doesn't seem to flush the cache, and draws a black line rather than duplicating what was already on the screen.
ROPs aren't as nice as what the Amiga had... I liked that. Patterns are really only useful for creating dithering patterns.
Are you enabling the destination read on the dummy blit ([MESGDSTCTRL] DSTNB)? If not ROP 0xaa will result in black pixels. Try increasing the width of the blit if it's not flushing enough.
 
Last edited by a moderator:
Back
Top