From: Peter S. <shu...@pa...> - 2002-02-18 19:46:40
|
On Mon, Feb 18, 2002 at 07:38:01PM +0100, Michel D=E4nzer wrote: > > 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 hard= ware > > 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. I have a feeling you found it. > My first question is: Can you trust top? Basically not, but this is such a large amount and I don't understand why a simple XSync should make a difference of 25% if it wasn't "guilty"? Surprisingly, the numbers are rougly the same as back in August, before we made the DMACopyStuff422, even if now I have 40% faster CPU. Don't you think it is a strange coincidence? This would indicate that about the same real t= ime is being wasted waiting for something, although we got rid of the stupid memcpy. > Or could it be that CPU time from the client gets accounted to X? No. It is client-independent. > It doesn't make too much sense that whether the client 'does something' h= as > influence on the amount of CPU X uses, does it? No, it really doesn't, but if SOMETHING is calling X functions while XSync = is pending, it would explain 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). Aha, so the assumption is correct. > > 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. Why is it so more difficult to do this correctly with CCE when it worked without? I'll look at the code. > (The DRM uses a loop with udelay() actually; see r128_do_cce_idle() in > r128_cce.c) Ok, I'll grep for it and try some magic :-) > > and calling another X function until it's finished causes X to "hang" > > and this "eats" CPU time.=20 > It might be a good idea to test if XSync alone causes the same > behaviour. Yes it might, but I'm too lazy, I'll simply write some code and hope it sol= ves the problem :-) Mit freundlichen Gr=FC=DFen Peter Surda (Shurdeek) <shu...@pa...>, ICQ 10236103, +436505= 122023 -- The computer revolution is over. The computers won. |