On Die, 2002-02-26 at 18:07, Peter Surda wrote: > 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.
Does the same number of frames get transferred though? Or could it be that without DRI, the difference is due to less frames getting memcpy'd, and with DRI due to not busy-waiting for enough indirect buffers? > And yes, it occurs in userspace, in contrast to e.g. load caused by memcpy > which seems to occur in "system". memcpy is a glibc function, if that's accounted to 'system' then we can't rely on that versus 'user' to determine where it happens. > 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? No, as I said before, the X server is single-threaded. > And what change was done about in November that caused this? In November where? :) -- 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
