Michel Dänzer wrote: > On Don, 2002-09-26 at 10:24, Eric Anholt wrote: > >>On Thu, 2002-09-26 at 00:58, Eric Anholt wrote: >> >>>CVSROOT: /cvsroot/dri >>>Module name: xc >>>Repository: xc/xc/lib/GL/mesa/src/drv/r200/ >>>Changes by: anholt@usw-pr-cvs1. 02/09/26 00:58:14 >>> >>>Log message: >>> R200 sync-to-vblank support (set LIBGL_THROTTLE_REFRESH=1) >>> >>Okay, that concludes things for tonight. It's building and running >>nicely on my end but I've got some more patches here, so yell if I broke >>something. >> >>I've got the mga patches, but I'm missing one versioning check, I'm not >>sure about what to do with the radeon stuff in drm_dma.h, >> > > Mea culpa, moved back to radeon_irq.c. > > >>and I'm tired. They sync to vsync rather than vblank, though vblank >>should be possible with some work. It survived vtswitch on BSD >>without any extra reg-saving code in the 2d, but I would like to make >>sure the reg-saving is correct before committing that. >> > > Maybe the mga 2D driver simply doesn't mess with the IRQ control > register(s). > > > Something else I've been thinking about is that relying on the > swi_emitted and swi_received counters being in sync is pretty fragile. > It might be better to use a scratch register instead.
Yes, it could be made more robust. > Moreover, nicod on IRC reports that IRQs stop working for him in the > middle of glxgears running. So I thought let's make really really sure > they are enabled in the DRM instead of doing it in the 2D driver and > praying. The result is > > http://penguinppc.org/~daenzer/DRI/radeon-swi-scratch.diff > > but unfortunately, it doesn't seem to really help with the second issue. > Can anyone think of a way how the IRQs can get disabled in the chip with > this? Could writing to GEN_INT_CNTL too often actually hurt? Works fine > here though... > > At least, with this patch it keeps running at about the same speed as > with usleeps when the IRQs go nuts. We shoudl add diagnostics to the -EBUSY case in wait_irq to try and figure out what has happened -- particularly have the interrupts been disabled? The other thing that I have floating around in my head is the idea that someone out there, kernel, motherboard, I don't know who, is blocking them defensively -- too many interrupts, stops processing them. I don't know if this is realistic. Keith ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
