On Tue, Dec 18, 2001 at 10:53:55AM -0800, Mark Vojkovich wrote: > > It is because the driver uses memcpy for transferring of the data. The > > correct way to solve this is to add dma support. In current cvs XF86 r128 > > does this so it can be used as a reference implementation. > That's silly. Plenty of other drivers do this without DMA and have large > performance increases over XShmPutImage - typically a factor of two savings > with scaling for free. In the worst case XvShmPutImage should be comparable > to XShmPutImage. Absense of DMA capability is not the problem. Ok, it indeed looks suspicious and the source of the problem is unclear. Perhaps the original poster might tell us WHAT PROCESS eats how much time in either (XShmPutImage/XvShmPutImage) cases? If it's like:
(XShm) X - 20, player 10
(XvShm) X - 50, player 10
then most probably the X driver is fscked (it still can be player's fault
though). If however it looks like
(XShm) X - 20, player 10
(XvShm) X - 20, player 40
then it is definitely the player is guilty.
Or it could be something else :-)
Bye,
Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023
--
Where do you think you're going today?
msg02575/pgp00000.pgp
Description: PGP signature
