GP2X Hw Accelerated Sdl

Discussion in 'General Discussions' started by paeryn, Dec 28, 2005.

  1. paeryn

    paeryn Reclusive maniac

    Joined:
    Nov 28, 2005
    Messages:
    432
    Location:
    Sheffield, England
    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
     
    Tags:
  2. craigix

    craigix Mega GP Mania

    Joined:
    Feb 3, 2003
    Messages:
    11,010
    Location:
    England
    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.
     
  3. paeryn

    paeryn Reclusive maniac

    Joined:
    Nov 28, 2005
    Messages:
    432
    Location:
    Sheffield, England
    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...
     
  4. Vimacs

    Vimacs Don't be evil!

    Joined:
    Oct 23, 2003
    Messages:
    5,211
    Location:
    Germany
    free the poor scaler :)
    great work!
     
  5. Blah

    Blah Wanna Be Programmer

    Joined:
    Dec 18, 2003
    Messages:
    3,253
    Location:
    Oregon, USA
    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.
     
  6. Puck2099

    Puck2099 Certified Guru

    Joined:
    Oct 22, 2004
    Messages:
    422
    Location:
    Madrid, Spain
    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
     
  7. DJWillis

    DJWillis Random GP32/GP2X/Wiz & Pandora Moocher

    Joined:
    Jul 20, 2003
    Messages:
    1,467
    Location:
    Bath, Somerset, UK
    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.

    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: Feb 4, 2016
  8. slygamer

    slygamer Member

    Joined:
    Sep 19, 2005
    Messages:
    795
    Location:
    Brisbane, Australia
    As much as we'd like to, Rlyeh has not released his updated library yet.
     
    Last edited by a moderator: Feb 4, 2016
  9. DJWillis

    DJWillis Random GP32/GP2X/Wiz & Pandora Moocher

    Joined:
    Jul 20, 2003
    Messages:
    1,467
    Location:
    Bath, Somerset, UK
    Ahhh, scratch that then :D, Rlyeh's Minilib may support the scalar in a newer public version ;).
     
    Last edited by a moderator: Feb 4, 2016
  10. Radek

    Radek Certified Guru

    Joined:
    Oct 13, 2005
    Messages:
    871
    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: Feb 4, 2016
  11. paeryn

    paeryn Reclusive maniac

    Joined:
    Nov 28, 2005
    Messages:
    432
    Location:
    Sheffield, England
    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: Feb 4, 2016
  12. DJWillis

    DJWillis Random GP32/GP2X/Wiz & Pandora Moocher

    Joined:
    Jul 20, 2003
    Messages:
    1,467
    Location:
    Bath, Somerset, UK
    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: Feb 4, 2016
  13. paeryn

    paeryn Reclusive maniac

    Joined:
    Nov 28, 2005
    Messages:
    432
    Location:
    Sheffield, England
    Hope this works, clicky
    It's compiled with gcc-3.4.4, glibc-2.3.5
     
    Last edited by a moderator: Feb 4, 2016
  14. Puck2099

    Puck2099 Certified Guru

    Joined:
    Oct 22, 2004
    Messages:
    422
    Location:
    Madrid, Spain
    Thanks a lot :)
     
    Last edited by a moderator: Feb 4, 2016
  15. gfoot

    gfoot Member

    Joined:
    Nov 15, 2005
    Messages:
    218
    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!
     
  16. paeryn

    paeryn Reclusive maniac

    Joined:
    Nov 28, 2005
    Messages:
    432
    Location:
    Sheffield, England
    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
    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.
    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: Feb 4, 2016
  17. gfoot

    gfoot Member

    Joined:
    Nov 15, 2005
    Messages:
    218
    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.
     
  18. paeryn

    paeryn Reclusive maniac

    Joined:
    Nov 28, 2005
    Messages:
    432
    Location:
    Sheffield, England
    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: Feb 4, 2016
  19. gfoot

    gfoot Member

    Joined:
    Nov 15, 2005
    Messages:
    218
    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.
     
  20. paeryn

    paeryn Reclusive maniac

    Joined:
    Nov 28, 2005
    Messages:
    432
    Location:
    Sheffield, England
    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: Feb 4, 2016

Share This Page

Loading...