On Fri, Jun 07, 2002 at 04:14:14PM +0200, Michel Dänzer wrote:
> Sounds reasonable, except maybe for the flushes - do you mean the
> FLUSH_RING()s? I think removing those could hurt 2D responsiveness.

No, the flush caches that are done when the busy bit is finally clear.
(Based on a FLUSH_CACHE being in the ring)
 
> > The biggest problem I'm seeing is massive system cpu time for certain 3d
> > apps when they are hidden effectively grinding the system to a halt
> > perhaps we should detect the hidden state or simply move these spins to
> > user space where the schedular and nice, or possibly even make the spins
> > into a wait queue as I mentioned before - does the new interrupt code
> > allow you to fire an interrupt on frame completion or idle states?

Actually this is caused by the 3d driver eliminating the drm swap 
call because there are no cliprects.  Both the register on the card and
sarea have the same value frame after frame so the test always passes.

With that optimised away, it seems to run full pelt and spend a lot more
time refilling the dma buffers, hence the switch in profile to system
time. 

I did a noddy UNLOCK_HARDWARE( rmesa ); sleep(1); if nbox is 0 and
hidden apps then do 1fps (kind of expected :) and you get 99% of your
cpu time back without actually stopping the app from running if you hide
it.

 
> That might be good, what new interrupt code are you talking about?

The gatos code mentioned something about adding interrupt code primarily
I think for userspace interrupts for video. I couldn't see much (maybe I
haven't looked hard enough) that defined interrupts / status bits etc in
the various competing register headers ;o) So I was really thinking aloud if
that code would make it clear.
 
-- 
Michael.

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to