How to gain performance through PBO (pixel buffer object) on Mali T-880

Most Mali graphics memory is uncached on the CPU to avoid cache maintenance during normal operation. Normal memcpy tends to be pretty poor at reading from uncached buffers; I'd recommend writing your own copy routine specifically to handle this.

I'd suggest using NEON and making big vectors loads and stores to ensure you make the biggest possible bus transfer sizes. I've not tested it, but something like this in ARMv8 NEON will transfer big data blocks very quickly. Ensure the base addresses are 64-byte aligned for maximum performance (the driver should be doing this for you for the src buffer, but check in your dst buffer too).

# x0 = *dst
# x1 = * src
# x2 = size (must be multiple of 64)
neon_aligned_memcpy:
    ld4        {v0.2d, v1.2d, v2.2d, v3.2d}, [x1], #64
    subs       x2, x2, #64; 
    st4        {v0.2d, v1.2d, v2.2d, v3.2d}, [x0], #64
    bne        neon_aligned_memcpy
    ret

Also worth noting that the the Galaxy S7 uses a Samsung-designed ARM core (the M1), so they may be better able to advise on how to get best copy performance out of it.

HTH,
Pete

Most Mali graphics memory is uncached on the CPU to avoid cache maintenance during normal operation. Normal memcpy tends to be pretty poor at reading from uncached buffers; I'd recommend writing your own copy routine specifically to handle this.

I'd suggest using NEON and making big vectors loads and stores to ensure you make the biggest possible bus transfer sizes. I've not tested it, but something like this in ARMv8 NEON will transfer big data blocks very quickly. Ensure the base addresses are 64-byte aligned for maximum performance (the driver should be doing this for you for the src buffer, but check in your dst buffer too).

# x0 = *dst
# x1 = * src
# x2 = size (must be multiple of 64)
neon_aligned_memcpy:
    ld4        {v0.2d, v1.2d, v2.2d, v3.2d}, [x1], #64
    subs       x2, x2, #64; 
    st4        {v0.2d, v1.2d, v2.2d, v3.2d}, [x0], #64
    bne        neon_aligned_memcpy
    ret

Also worth noting that the the Galaxy S7 uses a Samsung-designed ARM core (the M1), so they may be better able to advise on how to get best copy performance out of it.

HTH,
Pete

Since I'm not a expert of neon code, basically I borrowed the code from http://stackoverflow.com/questions/34888683/arm-neon-memcpy-optimized-for-uncached-memory like this:

void my_copy(volatile unsigned char *dst, volatile unsigned char *src, int sz)
{
  if (sz & 63) {
  sz = (sz & -64) + 64;
  }
  asm volatile (
  "NEONCopyPLD: \n"
  " VLDM %[src]!,{d0-d7} \n"
  " VSTM %[dst]!,{d0-d7} \n"
  " SUBS %[sz],%[sz],#0x40 \n"
  " BGT NEONCopyPLD \n"
  : [dst]"+r"(dst), [src]"+r"(src), [sz]"+r"(sz) : : "d0", "d1", "d2", "d3", "d4", "d5", "d6", "d7", "cc", "memory");
}

I think it's essential similar to your code, to transfer data in maximal bandwidth. The faster version should also use pre-load. However as Timothy Miller, I found PLD didn't quite help for this scenario. Is this because this graphics memory is totally out of caching mechanism? So, in other word, it already approaches the performance limits and can never be as fast as cached memory.

Thanks.