mmap video memory


sswam

Advanced Member
Joined
Dec 16, 2009
Messages
1,393
hi, I'm playing with software rendering. I can put over 100 fps using X, and a bit better than that with mmap /dev/fb0. But I noticed that reading the mmap'd framebuffer device is very slow. Is there some way to mmap the Pandora's physical video memory, rather than using the framebuffer? I searched but did not find info on this.
 
doesn't the graphics chip use the ram anyway? didn't think any of the embedded chips had their dedicated ram


even if it is dedicated it should be mapped somewhere, so you'd need to poke around in the system somewhere/chip documentation for the memory map
 
hi, I'm playing with software rendering. I can put over 100 fps using X, and a bit better than that with mmap /dev/fb0. But I noticed that reading the mmap'd framebuffer device is very slow. Is there some way to mmap the Pandora's physical video memory, rather than using the framebuffer? I searched but did not find info on this.

mmapping /dev/fb0 is the actual physical framebuffer.


The reason why reading is so slow is because it isn't cached memory. The default L2 caching method employed is write-back (and allocate on write), so if the framebuffer were cached you'd have to manually flush it in order to guarantee it got back to main memory, where the display controller would see it. If you set it to write-through cached it could work for what you're doing. On the one hand, this would save having to explicitly copy the buffer, which in the best case will take 1-2 cycles per 128-bits. On the other hand, this will commit every framebuffer write to main memory, which will use more bandwidth. Which is better depends on your ratio of reads to writes.


Right now it isn't an option anyway (unless you want to hack the kernel code GP2X mmuhack style) so you're probably going to have to just a separate buffer and copy. Or you could simulate the write-through approach in software - basically, you read from and write to a shadow copy, but also write to the real thing simultaneously. This might not be slower than having the hardware do it, if the writes can be scheduled in what would otherwise be dead execution slots, which there will be a lot of in typical Cortex-A8 code (but not necessarily ones that will facilitate loads/stores..)


You may get the best performance if you can subdivide the screen into tiles without too much overhead, and work on an entire tile at a time. That way you will keep the tile resident in L1 cache, instead of the whole frame which can only fit in L2 cache (think TBDR style optimization). You'll also get a lot more performance if you use NEON, which can hide a lot of the latency of accessing L2. I'm assuming you're doing alpha blending, so you'd probably get a lot more performance with NEON in general.
 
Last edited by a moderator:
Back
Top