Comments on: DMA vs ARM9, round 2 : invalidate considered harmful

By: sylvainulg

sylvainulg — Fri, 22 Apr 2011 12:12:46 +0000

I see. Looks like I had overlooked this part of the GBA Tek.

By: cearn

cearn — Wed, 20 Apr 2011 12:42:08 +0000

The stack is in DTCM, which is invisible to the DMA controller. This is pretty much why REG_DMAnFILL exists, and why you can't DMA a local array.

By: sylvainulg

sylvainulg — Wed, 20 Apr 2011 12:19:15 +0000

Just to check, has everyone ever managed to use the stack as source/destination of a DMA transfer, or is that an auwful idea per se ?

By: steve.zhan

steve.zhan — Mon, 05 Jul 2010 17:17:40 +0000

Hi,
// Assuming cached regions. Add tests for that yourself.
void dmaCopySafish(const void *src, void *dst, u32 size)
{
DC_FlushRange(src, size); // Flush source.

u32 addr= (u32)dst;
if(addr % CACHE_LINE_SIZE) // Check head
DC_FlushRange((void*)(addr), 1);

if((addr+size) % CACHE_LINE_SIZE) // Check tail.
DC_FlushRange((void*)(addr+size), 1);

When some task interrupt the current task, and access the boundary of the current cache(because the current cache is
not aligne “cache line”, then may be cached, if cpu modify these memory at this time,

dmaCopy(src, dst, size); // Actual copy.
DC_InvalidateRange(dst, size); // Final invalidate.

the modify of the memory has lost….

}

By: cache link « Corey's Journal

cache link « Corey's Journal — Fri, 23 Apr 2010 06:19:08 +0000

[...] Cearn’s interesting discussion about ds cache and DMA [...]

By: sylvainulg

sylvainulg — Wed, 31 Mar 2010 06:42:29 +0000

According to gbatek, it’s this:
ooh. YeS. of course. Row-preload latency and all those RAS-CAS things. I tend to overlook it. And it basically explain the role of “cache lines” size mentioned above.

Thanks for the time you invest on talking about the issue. It’s been a while since I found something to have a DMA-related discussion with ;)

By: cearn

cearn — Tue, 30 Mar 2010 14:08:56 +0000

When Flush(destination) is believed to take too much time, we could replace it with

if (unaligned(dst.start))
flush(dst.start & alignment, ( dst.start & alignment )+cache_line);
if (unaligned(destination.end))
flush(dst.end & alignment, ( dst.end & alignment) + cache_line);
flush(src)
dma_copy(…)
invalidate(dst)

couldn’t we ?

Argh, I forgot about this option. Yes, this is also possible. And probably the best solution, although it’s a little awkward to write it out. I think it’d be something like this:

#define CACHE_LINE_SIZE 32

// Assuming cached regions. Add tests for that yourself.
void dmaCopySafish(const void *src, void *dst, u32 size)
{
DC_FlushRange(src, size); // Flush source.

u32 addr= (u32)dst;
if(addr % CACHE_LINE_SIZE) // Check head
DC_FlushRange((void*)(addr), 1);

if((addr+size) % CACHE_LINE_SIZE) // Check tail.
DC_FlushRange((void*)(addr+size), 1);

dmaCopy(src, dst, size); // Actual copy.
DC_InvalidateRange(dst, size); // Final invalidate.
}

Btw, I’d suspect that RAM-to-RAM DMA copies being slower than RAM-to-vraM could be due to the fact that raM and VRAM are actually using distinct buses. When moving data through separated buses, reads and writes don’t have to fight for bus bandwidth and can happen in parallel.

According to gbatek, it’s this:

NDS Sequential Main Memory DMA
Main RAM has different access time for sequential and non-sequential access. Normally DMA uses sequential access (except for the first word), however, if the source and destination addresses are both in Main RAM, then all accesses become non-sequential. In that case it would be faster to use two DMA transfers, one from Main RAM to a scratch buffer in WRAM, and one from WRAM to Main RAM.

I just noticed this thread, where simonjhall warns against exactly this type of behaviour: http://forum.gbadev.org/viewtopic.php?t=15294.

By: sylvainulg

sylvainulg — Mon, 29 Mar 2010 11:26:28 +0000

When Flush(destination) is believed to take too much time, we could replace it with
if (unaligned(dst.start)) flush(dst.start & alignment, ( dst.start & alignment )+cache_line); if (unaligned(destination.end)) flush(dst.end & alignment, ( dst.end & alignment) + cache_line); flush(src) dma_copy(...) invalidate(dst)

couldn’t we ?

Btw, I’d suspect that RAM-to-RAM DMA copies being slower than RAM-to-vraM could be due to the fact that raM and VRAM are actually using distinct buses. When moving data through separated busses, reads and writes don’t have to fight for bus bandwidth and can happen in parallel.

By: Coranac » DMA vs ARM9, round 2 : invalidate considered harmful Zero Me

Coranac » DMA vs ARM9, round 2 : invalidate considered harmful Zero Me — Sun, 28 Mar 2010 23:00:12 +0000

[...] more: Coranac » DMA vs ARM9, round 2 : invalidate considered harmful By admin | category: code zero | tags: code zero, definitely-need, dma, invalidate, [...]