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