On Thu, 2009-12-24 at 03:24 +0100, Rafał Miłecki wrote: > W dniu 24 grudnia 2009 02:59 użytkownik Alex Deucher > <alexdeuc...@gmail.com> napisał: > > 2009/12/23 Rafał Miłecki <zaj...@gmail.com>: > >> Do you have any other ideas? > > > > I suspect the reclock is missing the blanking period. Try removing > > the debugging output in my patch as that adds additional latency. > > Also, if the latency of the reclock is too long, we may want to > > trigger the reclock on a vline irq say 3/4 of the way down the screen > > to give us some additional time. > > I remove DRM_INFOs and also moved radeon_get_power_state calls from > IRQ handler to line before rdev->pm.vblank_callback = true;. This > didn't help. > > I guess you may be right with this VBLANK. We may receive that too > late and don't hit vblank. Maybe with low engine we even parse IRQs > slower?
I suspect the delay is more likely due to the workqueue than the interrupt itself. Way back when I implemented DRI1 tear-free buffer swaps for i945, I had to use a tasklet to reliably do work within the vertical blank period. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel