[MPlayer-dev-eng] MGA Xv sux...
arpi at thot.banki.hu
Sat Jul 20 17:33:44 CEST 2002
> > > > > dma transfer support tp mga_vid/vidix/fbdev. I think SDL (which is
> > > > i doubt it. sdl is an userspace lib... dma requires kernel space and
> > > > deep knowledge of chip details. maybe directfb does it, i remember reading
> > > > it somewhere, but i'm not sure.
> > >
> > > Oh, I bet SDL just does accelerated video-to-video blits. That would
> > I doubt it. What does 'accelerated blit' mean? It could be either CPU (memcpy
> > maybe using MMX) or DMA (let the hardware to do that). I can't imagine any
> DMA isn't needed if the source and destination image are already in
> video memory.
yes, but source is in system memory...
if it's in video memory, it's called direct rendering then and we have no
(video->video blit is nonsense, it's easier and faster to change the image
pointer so the card displays the backbuffer wihtout moving it in memory)
> > map), IRQ handling (dma finished), locking of resources (to avoid crash by
> > DRI or other dma stuff) etc... for DRI supported cards the DRM kernel
> > modules provide such functionality (the rage128 dma Xv uses that) but using
> > it is not trivial and needs fixes/changes as it was not designed for this
> > purpose (it is usually limited to few 64k, enough to 3D command buffer)
> What about texture DMA? I was under the impression most DRI drivers
> used DMA for texture transfers...but perhaps they only support it with
> small texture sizes. :(
no they use AGP texturing
some drivers support DMA transfer, but textures are somehow splitted down to
small cells, and don't forget about mipmapping (same texture in many sizes)
A'rpi / Astral & ESP-team
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
More information about the MPlayer-dev-eng