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@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)