On Tue, 2002-02-19 at 10:38, Peter Surda wrote: > On Tue, Feb 19, 2002 at 08:31:03AM +0100, Peter Surda wrote: > > > If the CPU usage is really a problem, an interrupt is probably the way > > > to go; don't know if and how the chip supports that though. > > Sounds good. > Ok, I did some tests: > - it isn't DMA-specific. It happens also with DMA disabled, so interrrupts > won't help
I don't agree on your conclusion. Without DMA, all the CPU is used for copying the data to the framebuffer. With DMA, the CPU busy loops waiting for the data to be transferred. If we change the latter to a sleep until interrupt, that should save some wasted cycles. Or what am I missing? > - it isn't directly either R128WaitForIdle or R128CCEWaitForIdle. Conditional > usleeps in the idle loops there don't change anything. The busy loop is inside drmR128WaitForIdleCCE(). I already mentioned the function in the DRM, try changing the udelay() there to a usleep(). > - by mistake I introduced an unconditional usleep (1) (i.e. 10ms usleep) into > R128CCEWaitForIdle. Although this slowed everything down and video latency > got worse, X suddenly eats about 20% less, still measurable though, abou > 4%. What do you expect? X still has to copy the data into DMA buffers after all. If you can't live with that, you'll have to implement an XvMC driver (and XvMC clients ;). -- 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
