On Mon, Feb 18, 2002 at 07:38:01PM +0100, Michel Dänzer 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 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. 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 time
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' has
> 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.
> 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 solves
the problem :-)
Mit freundlichen Grüßen
Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023
--
The computer revolution is over. The computers won.
msg02890/pgp00000.pgp
Description: PGP signature
