On Mon, 2002-02-18 at 19:03, Peter Surda wrote: > > The best problem description I can give you is this like this: when the player > is doing nothing for some time after returning from calling XvShmPutImage, top > shows X doesn't eat any CPU. However, if it DOES do something (e.g. if I run > a multithreaded player like aviplay or set high postprocessing level to > mplayer), suddenly X eats 26% CPU. Even worse, if I disable dri (so that DMA > isn't used for this function), it eats up to 50% !!!. > > This must have been introduced roughly in November. I remember it worked > wonderfully right after Michel and I wrote the DMA patch in September, aviplay > was able to eat 99% and X ate nothing. I remember now this isn't a hardware > problem, I also had this before I upgraded the motherboard, just wasn't able > to reproduce it predictably (now I CAN reproduce it anytime).
What has changed since then is that the CCE is now used for 2D acceleration with DRI, and the info->accel->Sync() function waits for the CCE to go idle. > You can reproduce it anytime as well, find a high quality divx and run a > player (aviplay or mplayer), and run top over ssh, or perhaps even in another > window. You'll notice that with no postprocessing and reasonably fast cpu (> > 500MHz), everything is ok, but when you turn the postprocessing to the max, X > will eat horribly lot of CPU. Setting postprocessing is easy, in aviplay you > turn "autoquality" off in the config and while playing the file, right-click, > choose properties and slide the slider. With mplayer, use -pp 0 or -pp 4. My first question is: Can you trust top? Or could it be that CPU time from the client gets accounted to X? It doesn't make too much sense that whether the client 'does something' has influence on the amount of CPU X uses, does it? > Zdenek's (aviplay maintainer) and my current theory is that calling the > XvShmPutImage returns before it is actually run. If you look at the code, you see that it returns after it has memcpy'd the data to the framebuffer (without DRI) / after it has fired the indirect DMA buffers for the image transfer (with DRI). > A player then does XSync, so that I can actually see the picture appear > on screen, This could be where X uses all the CPU. While waiting for the CCE to go idle, it can't do much but busy loop. (The DRM uses a loop with udelay() actually; see r128_do_cce_idle() in r128_cce.c) > and calling another X function until it's finished causes X to "hang" > and this "eats" CPU time. It might be a good idea to test if XSync alone causes the same behaviour. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
