On Tue, 26 Feb 2002, 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.
>
> 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
Peter, could you run the following test: allocate 1 meg of ram in a
new pPriv struct (in SetupImageVideo) and change the code to do plain
memcpy to that memory. I am wondering what the CPU usage will be.
Vladimir Dergachev
>
> --
> Hello, this is Bill Gates and I pronounce Monopoly, er, Windows as Windows.
>
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
