On Fri, Apr 03, 2015 at 11:20:20AM +0900, Michel Dänzer wrote: > On 02.04.2015 20:34, Chris Wilson wrote: > > On vblank instant-off systems, we can get into a situation where the cost > > of enabling and disabling the vblank IRQ around a drmWaitVblank query > > dominates. However, we know that if the user wants the current vblank > > counter, they are also very likely to immediately queue a vblank wait > > and so we can keep the interrupt around and only turn it off if we have > > no further vblank requests in the interrupt interval. > > > > After vblank event delivery there is a shadow of one vblank where the > > interrupt is kept alive for the user to query and queue another vblank > > event. Similarly, if the user is using blocking drmWaitVblanks, the > > interrupt will be disabled on the IRQ following the wait completion. > > However, if the user is simply querying the current vblank counter and > > timestamp, the interrupt will be disabled after every IRQ and the user > > will enabled it again on the first query following the IRQ. > > As I mentioned before, it might not be too hard to make querying the > current counter work without enabling the interrupt. But this looks like > a step in the right direction. I honestly chickened out in case I broke something! Hindsight says both are useful as currently with instant-off we will disable the vblank interrupt inside the IRQ handler delivering the event, whereas we can save quite a bit of pain by waiting for the next IRQ before doing the disable (culmulatively saving a lot more CPU cycles over the course of swap chain than the extra IRQ will cost). -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
