On Thu, Mar 19, 2015 at 05:04:19PM +0200, Ville Syrjälä wrote: > Is enabling the interrupts the expensive part, or is it the actual > double timestamp read + scanout pos read? Or is it due to the several > spinlocks we have in this code? Chiefly it was the read during disable, then the spinlocked irq enabling. > Also why is userspace reading the vblank counter in the first place? Due > to the crazy OML_whatever stuff perhaps? In the simple swap interval case > you shouldn't really need to read it. And if we actually made the page > flip/atomic ioctl take a target vblank count and let the kernel deal > with it we wouldn't need to call the vblank ioctl at all. More or less due to OML, yes. Client asks for random MSC, often 0, we compute the next MSC for it. This happens 10,0000+ a second when benchmarking and drmWaitVblank is the most expensive step in that chain for the server... Pretty much an igt that compared the speed of just querying the hw counter vs querying with a regular vblank interrupt would be ideal for measuring the impact here. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
