[PATCH] drm: Aggressively disable vblanks

[Michel Dänzer]

On Son, 2010-12-26 at 09:53 -0500, Andrew Lutomirski wrote: 
> On Wed, Dec 22, 2010 at 4:06 PM, Mario Kleiner
> <mario.kleiner at tuebingen.mpg.de> wrote:
> >
> > There's a new drm module parameter for selecting the timeout: echo 50 >
> > /sys/module/drm/parameters/vblankoffdelay
> > would set the timeout to 50 msecs. A setting of zero will disable the timer,
> > so vblank irq's would stay on all the time.
> >
> > The default setting is still 5000 msecs as before, but reducing this to 100
> > msecs wouldn't be a real problem imho. At least i didn't observe any
> > miscounting during extensive testing with 100 msecs.
> >
> > The patches in drm-next fix a couple of races that i observed on intel and
> > radeon during testing and a few that i didn't see but that i could imagine
> > happening. It tries to make sure that the saved final count at vblank irq
> > disable of the software vblank_count and the gpu counter are consistent - no
> > off by one errors. They also try to detect and filter out spurious vblank
> > interrupts at vblank enable time, e.g., on the radeon.
> >
> > There's still one possible race in the disable path which i will try to fix:
> > We don't know when exactly the hardware counter increments wrt. the
> > processing of the vblank interrupt - it could increment a few
> > (dozen/hundred) microseconds before or after the irq handler runs, so if you
> > happen to query the hardware counter while the gpu is inside the vblank you
> > can't be sure if you picked up the old count or the new count for that
> > vblank.
> 
> That's disgusting.  Does this affect many GPUs?  (I can't imagine why
> any sensible implementation wouldn't guarantee that the counter
> increments just before the IRQ.)

Actually, while we want the interrupt to trigger at the beginning of
vblank (so we get a chance to do work within the vblank period), at
least on Radeons, the hardware frame counter increments at the beginning
of scanout, i.e. at the end of vblank.

At some point we tried to compensate for that by adding 1 to the
hardware frame counter while inside vblank, but IIRC that wasn't 100%
reliable either but would sometimes result in the counter being
considered too high by 1. So instead we've tried to keep the
infrastructure robust against the interrupt and hardware frame counter
increment not necessarily occurring at the same time.

(Even if both events always occurred at the same time on the GPU, we
might not be able to take advantage of that due to interrupt latencies)


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer