On Tue, Feb 26, 2002 at 04:32:25PM +0100, Michel Dänzer wrote: > > > > Hmm.. Michel, Peter, is it possible that "poll" function in DRM driver is > > > > screwed up ? Though I thought that texture transfer goes through an ioctl.. > > > It does, and Peter says the cycles are wasted in user space, or what are > > > you getting at? > > Michel, correct me if I am wrong, but I thought the cycles will be counted > > as "system" time only if we call schedule when inside the kernel, right ? > Maybe, I don't know the hairy details. > > Anyway, I forgot to mention the main point: Peter observes the same > effect with and without DRI so it can't be related to the DRM. Yes indeed, it seems to "eat" rougly the same amount of CPU time regardless of whether DRI is enabled or not. The time wasted is roughly equivalent to the time it takes to transfer the data (memcpy or x*r128blittexture). The odd thing is that as I said a wisely placed usleep in r128_video.c "fixes" it. "fixes" meaning the time wasted is dramatically reduced, although it makes the video less fluent and judder is more visible.
And yes, it occurs in userspace, in contrast to e.g. load caused by memcpy which seems to occur in "system". Executing the PutImage on r128 takes a long time, about 11ms on DVD-sized picture. Could it be that something is waiting for PutImage to complete or vice versa? Can X execute a driver function and something else simultaneously? And what change was done about in November that caused this? Mit freundlichen Grüßen Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- Hello, this is Bill Gates and I pronounce Monopoly, er, Windows as Windows.
msg03138/pgp00000.pgp
Description: PGP signature
