2010/2/18 Rafał Miłecki <zaj...@gmail.com>: > W dniu 18 lutego 2010 09:28 użytkownik Dave Airlie <airl...@gmail.com> > napisał: >>> >>>> It adds some reading & printing steps before every reclock, while we >>>> really want it to happen as soon as possible. Maybe you could execute >>>> this only on some >> >> btw you won't get the print if you are in vblank, and if you aren't >> well the print >> doesn't matter, I'm also thinking the engine change reads/writes a lot of >> regs, >> so two more might not matter so much. > > Yeah, maybe that's right. > > While your idea of testing being in VBLANK is "sane" :) it could > happen we start reclocking in VBLANK (first test will pass), we > reclock out of VBLANK (not wanted, possible corruption), and we hit > next VBLANK in second test. > > In such situation (machine) I'm sure we will hit "false" in test > anyway (sooner or later) but maybe we could improve in anyway somehow? > To make sure it's sill the same VBLANK?
That could be possible, though if a reclock takes a full scanout to operate we've got other issues as it would never be possible by the sounds of it. The check on the way out could be toned down alright, its probably not as important, btw I've still got problems even with that other patch applied, I get reclocking in the middle of the frame, Reverting 73a6d3fc104827db574e4bd206a025299fef0bb1 drm/radeon/kms: use wait queue (events) for VBLANK sync still fixes it for me here. Dave. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
