DMA setup performance penalty?

For anything related to VDP (plane, color, sprite, tiles)

Moderators: BigEvilCorporation, Mask of Destiny

Post Reply
djcouchycouch
Very interested
Posts: 676
Joined: Sat Feb 18, 2012 2:44 am

DMA setup performance penalty?

Post by djcouchycouch » Sat Jan 04, 2014 10:49 pm

Hi,

If I understand correctly, during vblank I can copy up to 7k odd bytes from the CPU to the VDP. But that's the theoretical maximum of one DMA transfer.

How much of bandwidth would I lose if I setup multiple DMA transfers? Does the setup and stopping of the DMA transfer on the hardware side take enough time to lose a non-trivial amount of bandwidth?

Thanks!
djcc

User avatar
Stef
Very interested
Posts: 2780
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Sun Jan 05, 2014 10:38 am

I would say it depends a lot from how many DMA and how you do your DMA setup !
If you do it through SGDK which make many "safe" stuff as setting vram increment register and checking about splited transfer (crossing 128 KB bank) you will lose a lot of time. If you do a very fast asm setup method which only write the DMA registers then you won't lose much (except if you plan to split in many shorts DMA..)
By the way, do you need that because of some crappy PCM playback issues ?

Charles MacDonald
Very interested
Posts: 283
Joined: Sat Apr 21, 2007 1:14 am

Re: DMA setup performance penalty?

Post by Charles MacDonald » Sun Jan 05, 2014 3:43 pm

djcouchycouch wrote:How much of bandwidth would I lose if I setup multiple DMA transfers? Does the setup and stopping of the DMA transfer on the hardware side take enough time to lose a non-trivial amount of bandwidth?
When I was doing some FMV tests there was no appreciable change in speed between doing one huge transfer and a lot of small transfers. Eventually there's a point of diminishing returns, but I tried DMA'ing an 8K data block broken into repeated transfers of sizes from 1x8K down to 8x1K with roughly the same performance.

I did precalculate the DMA parameters so I could move them directly from a table in memory to the VDP registers, there was no calculation of VRAM addresses or source addresses. I can see there being some overhead in calculating those parameters every time for doing small DMA transfers.

The process of entering and exiting DMA takes hardly any time at all, so there isn't a significant penalty for when the VDP takes over the 68K bus or releases it afterwards. It's only a few clock cycles.

djcouchycouch
Very interested
Posts: 676
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Sun Jan 05, 2014 4:22 pm

In my setup, I was thinking of building a queue of DMA transfers (with source and destination points precalculated) during the normal game loop and then fire them all during vblank. So I was wondering if I'd be losing any bandwidth if I had multiple DMA calls like that. But according to Charles it shouldn't be a problem. I don't think I'd be hitting the maximum amount of bandwidth, anyway.

I'm not doing it for any sound playback. I was thinking about using it for copying a lot of sprite/tile data from rom to VDP during a frame for lots of dynamic changes, and seeing how much I could get away with.

I'm already using DMA to copy a sprite character's animation to VDP every frame.

User avatar
TmEE co.(TM)
Very interested
Posts: 2319
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Sun Jan 05, 2014 11:27 pm

VRAM transfer queue like that is the way to go. It will maximize the VBL use.

For sound you will have to have a synchronous driver that stays out of ROM for duration of VBL, and uses precached data to last that time.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

djcouchycouch
Very interested
Posts: 676
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Sun Jan 05, 2014 11:38 pm

I just realized that I even if I could fit 3 kilobytes of bandwidth, it would only be about 96 tiles. A bit less than what I was hoping/expecting! I don't really have any specific effects in mind, but wow, that's not a lot :) Currently just copying the main character's tiles from rom to VDP is 36 tiles.

r57shell
Very interested
Posts: 475
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Post by r57shell » Mon Jan 06, 2014 3:59 am

VRAM DMA queue is common way of doing sprites / tiles updates.

And, some games use transfer restrictions: calculation of total DMA size, to avoid glitches on screen. It is best way I think: just detatch frontend from backend, then update backend ALWAYS and frontend as fast as you can.
Image

User avatar
Stef
Very interested
Posts: 2780
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Mon Jan 06, 2014 11:52 am

djcouchycouch wrote:I just realized that I even if I could fit 3 kilobytes of bandwidth, it would only be about 96 tiles. A bit less than what I was hoping/expecting! I don't really have any specific effects in mind, but wow, that's not a lot :) Currently just copying the main character's tiles from rom to VDP is 36 tiles.
3 KB is not much, i guess you can expect to have close to 5 KB.
But the key is that you should interleave sprite tiles update.
For instance you split whole update on 4 frames where:
frame 0 = player character
frame 1 = enemies group 1
frame 2 = enemies group 2
frame 3 = bullets / explosions

Of course that limit you on a maximum of 15 image/s for animation but that is enough in almost case :)

djcouchycouch
Very interested
Posts: 676
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Mon Jan 06, 2014 8:09 pm

Stef wrote:
3 KB is not much, i guess you can expect to have close to 5 KB.
But the key is that you should interleave sprite tiles update.
For instance you split whole update on 4 frames where:
frame 0 = player character
frame 1 = enemies group 1
frame 2 = enemies group 2
frame 3 = bullets / explosions

Of course that limit you on a maximum of 15 image/s for animation but that is enough in almost case :)
Yes, this is a good idea. I don't think I have many (or any) animations that change every frame.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests