[MPlayer-dev-eng] MGA Xv sux...

[D Richard Felker III]

On Sat, Jul 20, 2002 at 04:11:52PM +0200, Arpi wrote:
> Hi,
> 
> > > > 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. SDL seems to encourage writing games, etc. in such a way
that they store their sprites in "SDL surfaces" that may reside in
video memory, or I presume in X pixmaps, then using SDL functions to
copy them to the viewable part of the screen. Really messy IMO, since
it makes your code very SDL-dependent, and it's a lot less flexible.

> other method... and SDL is just broken unoptimized shitty code anyway so
> i really doubt it has something interesting we don't have...

...but right, this wouldn't be useful to mplayer anyway.

> it requires proper memory allocation (page aligned, linear physical emmory
> 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. :(

> feel free to implement...

I'll keep it in mind...but I don't think I'll be doing that anytime
soon. :)


Rich