On 03/18/2015 10:30 AM, Chris Wilson wrote:
On Wed, Mar 18, 2015 at 11:53:16AM +0900, Michel Dänzer wrote:
drm_vblank_count_and_time() doesn't return the correct sequence number
while the vblank interrupt is disabled, does it? It returns the sequence
number from the last time vblank_disable_and_save() was called (when the
vblank interrupt was disabled). That's why drm_vblank_get() is needed here.
Ville enlightened me as well. I thought the value was cooked so that
time did not pass whilst the IRQ was disabled. Hopefully, I can impress
upon the Intel folks, at least, that enabling/disabling the interrupts
just to read the current hw counter is interesting to say the least and
sits at the top of the profiles when benchmarking Present.
-Chris
drm_wait_vblank() not only gets the counter but also the corresponding
vblank timestamp. Counters are recalculated in vblank_disable_and_save()
for irq off, then in the vblank irq on path, and every refresh in
drm_handle_vblank at vblank irq time.
The timestamps can be recalculated at any time iff the driver supports
high precision timestamping, which currently intel kms, radeon kms, and
nouveau kms do. But for other parts, like most SoC's, afaik you only get
a valid timestamp by sampling system time in the vblank irq handler, so
there you'd have a problem.
There are also some races around the enable/disable path which require a
lot of care and exact knowledge of when each hardware fires its vblanks,
updates its hardware counters etc. to get rid of them. Ville did that -
successfully as far as my tests go - for Intel kms, but other drivers
would be less forgiving.
Our current method is to:
a) Only disable vblank irqs after a default idle period of 5 seconds, so
we don't get races frequent/likely enough to cause problems for clients.
And we save the overhead for all the vblank irq on/off.
b) On drivers which have high precision timestamping and have been
carefully checked to be race free (== intel kms only atm.) we have
instant disable, so things like blinking cursors don't keep vblank irq
on forever.
If b) causes so much overhead, maybe we could change the "instant
disable" into a "disable after a very short time", e.g., lowering the
timeout from 5000 msecs to 2-3 video refresh durations ~ 50 msecs? That
would still disable vblank irqs for power saving if the desktop is
really idle, but avoid on/off storms for the various drm_wait_vblank's
that happen when preparing a swap.
-mario
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
