Mark Vojkovich ([EMAIL PROTECTED]): > > But if we can't double-buffer in the hardware then I get tearing, > > and this makes it useless to a DVD player. And you're right, my > > little retrace hack doesn't help much. > > > > What do you recommend? > > You should use different hardware or rewrite the mga code to > doublebuffer.
Ok, I'll take a look at the code tomorrow. > > Why does it take so long to copy the data to the framebuffer? Can't > > we use DMA here? Does it really take that long to just copy 512k? > > It's a little more than that because the driver is using 4:2:2 > internally. Copying the way it is doing you can't get much more than > 160 MB/sec and uses the CPU the whole time. Hrm, I hope it doesn't just double each chroma scanline. I'm in fear now. Wish that was documented somewhere, I would have written a better chroma upsampler sooner. > DMA won't make the transfer go any faster (it will probably be slower > unless you're using 2x+ AGP), but it won't eat the CPU. The only > drivers that do this are NVIDIA's binary drivers and supposedly some > experimental ATI drivers that some people are working on. Maybe the > i810 drivers do too, not that it would help, since the bandwidth is > probably the same writing to video ram or the framebuffer. I still think that using DMA is essential for all drivers if the images doesn't require some conversion. I guess I'd be worried about drivers which require scanlines to be 32bit aligned. Too bad the Xv API doesn't allow for that. (or am I on crack again) -- Billy Biggs [EMAIL PROTECTED] _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
