[MPlayer-dev-eng] DMA or not DMA

[Arpi]

Hi,

> > The problem is multiple drivers trying to use the hardware at the same 
> > time.
> 
> We have that problem with mga_vid already, but as X and mga_vid
> are accessing different memory regions, that's not a big issue.

it is, as the card cannot do multiple dma transfers at same time.
but on framebuffer, it should work fine.

> The only real issue i see is, that during a DMA transfere,
> MPlayer has either to sleep until the buffer is coppied or
> that the codec has to use a copy of the buffer to work on.
> Both options are not very exciting.

in case of dma, codecs decode to system memory, then copy it
over dma. the only trick is that you need 2 (or more) buffers
for B frames, so while decoding second B frame, it wont overwrite
the buffer of first B (which is being transferred by dma)
it mean a little bit more memory, but doesnt mean speed loss.

anyway, i have a sponsor interested in a dma-capable mga_vid.
they need to drive 5 or 6 matrox g450 cards (pci version) in a pc,
all playing back 800x600x25fps or 720x576x25fps video (possibly
on both heads, so total 12 video streams).
we done some initial tests last weekend, and found that a 3ghz
p4 is fully loaded by playing 4 streams over mga_vid.
(agp mga_vid was 17% cpu usg, pci ones eat 25% each)
using fbdev in 32bpp, only 2 playbacks possible, at 16bpp only 3.
the decoding was only 9% cpu per stream, the rest was eaten up by
video data transfers. so dma could help here a lot.

(unfortunatelly hw mpeg2/mpeg4 decoder cards arent a good alternative,
as we need to syncronize the outputs very well.)


A'rpi / MPlayer, Astral & ESP-team

--
Girls are like internet domain names, the ones I like are already taken.