[Intel-gfx] [PATCH] drm: Return current vblank value for drmWaitVBlank queries

Chris Wilson chris at chris-wilson.co.uk
Thu Mar 19 08:13:15 PDT 2015


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


More information about the Intel-gfx mailing list