investigating DMA based pixmap migration in Xglamo

[Carsten Haitzler (The Rasterman)]

On Mon, 18 Feb 2008 13:11:27 +0100 Dodji Seketeli <dodji at openedhand.com>
babbled:

> Hello,
> 
> I have been investigating the use of DMA to transfer pixmap from system
> ram to the video memory of the glamo chip, on gta02.
> 
> Problem statement
> =================
> 
> The bus that interconnects the glamo GPU to the CPU of the s3c2442 chip
> is very slow. Some measurements of the throughput when memcpy-ing data
> from system ram to the video ram showed that goes at 30Mbytes/sec,
> whereas doing copies in the system ram goes at around 130Mbytes/sec, if
> not higher.

i measured 160mb/sec system -> system memcpy()'s so 30 vs 160... sucketh
muchly :)

> Kaa acceleration architecture we are using allows us to use hardware
> capabilities to accelerate the transfer of pixmaps from system ram to
> video ram. That transfer is called pixmap migration in X lingo.
> 
> On the other hand, the s3c2442 SoC has a DMA module that can perform
> data copies without using the processor. In our case, using that DMA
> module would not help us go faster than 30MB/sec because that speed is
> a bus limitation. It will however (hopefully) free the processor to do
> something else during the transfer.

indeedily :) the 30m/sec means that the cpu is locked into wasting cycles doing
the copy and really slows down uploads of data - and since xrender and such are
not accelerated yet (and at best can only be partly accelerated), anything
"fancy" will require lots of uploads. *IF* the x client and xserver are
implemented correctly, we get the uploads "for free", as long as the client has
something it can do while the upload happens (for example - re-calculate the
next frame of animation). i do know evas does this in its rendering model, so
if my benchmarking number are right, this might get about a 40-50% framerate
increase. not shabby. if you block and wait for the transfer before continuing,
we do free up the cpu to go idle or run some other process outside the x client
doing the drawing/upload and xserver, but you won't see framerate increases.

> What is needed
> ==============
> 
> So we need the framebuffer driver to expose entry points to perform
> pixmap copies using the DMA module of the s3c2442 chip. That entry
> point would then be called from withing the Xglamo server to perform
> the pixmap migrations.
> 
> 
> What has been done
> ===================
> 
> I spent the last week understanding the s3c2442 DMA module and kernel
> api. I started putting together an implementation of a DMA based pixmap
> copy. You can find the patch I have written attached to bug
> http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=1234 .
> 
> There are a few gotchas in that patch, so here is what it does:
> 
> 1/ it creates a new blocking ioctl (called
> FBIO_GLAMO_UPLOAD_PIXMAP_TO_VRAM) to the framebuffer device driver.
> That ioctl is meant to copy a pixmap that resides in system ram to a
> destination in video ram.
> 
> 2/ the pixmap is first copied in an in-kernel buffer that is DMA
> friendly. The DMA transfer will then copy the pixmap from this
> in-kernel buffer to the destination, in vram. The ultimate
> implementation should get rid of this copy to in-kernel DMA friendly
> buffer. I needed to this for now, for the sake of simplicity, to get
> things going, and have a chance to have the whole chain working first.
> 
> 3/ the pixmap is then tranfered to vram, _line by line_ using DMA.
> The line by line is important to notice here because it is bad
> performance wise. But as pixmap copy must be done inherently line by
> line, there is no easy way to that for now. Ultimately though, I should
> be using a bounce buffer in offscreen vram. A bounce buffer is a buffer
> allocated in offscreen (non visible) vram. The pixmap data would be
> bulk copied in there first. Then, when that is done, the driver will
> use the glamo blitter to do the proper copy of the pixmap (line by
> line) to the actual final destination in vram. That way, the DMA won't
> be done line by line, and the processor won't be used to do the copy
> either.
> 
> 4/ I was obliged to hack the s3c24xx DMA api a bit to make it support
> the type of DMA transfer I needed. Actually there are two types of DMA
> transfer supported by the s3c2442 module: software mode, and hardware
> mode. In the software mode, the software basically triggers the
> transfer, whereas in the hardware mode, it is the device where the data
> is transfered to (or from) that triggers the transfer. That requires a
> special wiring between the device and the s3c2442 chip.
> In the case of the glamo chip though, from an s3c2442 DMA module
> perspective, accessing vram is like accessing normal memory, so there
> is not special wiring in place to do hardware more DMA. We must then do
> software mode DMA. Unfortunately, software mode DMA was not really
> supported by the s3c24xx DMA api that is in the kernel right now. So I
> hacked it a bit to support it. That is in the patch attached to the bug
> I referred to earlier; look in the file
> linux-2.6.24/arch/arm/plat-s3c24xx/dma.c.
> 
> 5/ I wrote a test application named test-glamo-dma to test/debug the
> whole thing outside of X. Its OE package source is also attached to the
> bug.
> 
> What needs to be done
> ======================
> 
> Well, continue hacking on this and make it actually usable from an
> Xglamo perspective. When that is done, make Xglamo use it, and see if
> it is fast enough.
> 
> 
> That's all folks.
> 
> Thanks for reading so far :-)
> 
> Dodji.

sounds great. :) all the bits there - just need to work, then be streamlined :)


-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>