On 30.01.13 13:36, Daniel Vetter wrote: > On Wed, Jan 30, 2013 at 9:34 AM, Thierry Reding > <thierry.reding at avionic-design.de> wrote: >> On Tue, Jan 22, 2013 at 10:21:40AM -0800, Jon Mayo wrote: >>> On Mon, Jan 14, 2013 at 7:55 AM, Thierry Reding >>> <thierry.reding at avionic-design.de> wrote: >>>> Implement support for the VBLANK IOCTL. Note that Tegra is somewhat >>>> special in this case because it doesn't use the generic IRQ support >>>> provided by the DRM core (DRIVER_HAVE_IRQ) but rather registers one >>>> interrupt handler for each display controller. >>>> >>>> While at it, clean up the way that interrupts are enabled to ensure >>>> that the VBLANK interrupt only gets enabled when required. >>>> >>>> Signed-off-by: Thierry Reding <thierry.reding at avionic-design.de> >>>> --- >>> >>> Sorry Thierry, but is this a useful feature? Are applications really >>> making use of it? Because it means that that an IRQ will have to >>> trigger every 16.67ms when it is taken, which means the device can't >>> sleep. (probably OK because it should go back to idle when the app >>> lets go of the vblank). But worse, for one-shot panels there is no >>> continuous vblank. I've been doing weird hacks to run a timer when the >>> smart panel is idle to trick applications into thinking they have a >>> vblank pulse. But really I think the whole feature of a vblank pulse >>> is pretty lame and I wish it would die. Were you going to use it for >>> something specific, or just adding it for completeness? >> >> This is mainly added for completeness. I know that on Tegra we can do a >> lot better by using syncpoints, but applications such as Weston (in >> general applications that use the generic DRM API) rely on this to sync >> rendering with VBLANK. >> >> I don't think there's another way to achieve the same thing. And as you >> already mentioned, this is only enabled when an application actively >> uses it, in which case the device won't sleep anyway. > > I think driving animations with the vblank signal is nice, but we > kinda only need that with the pageflip support. Unfortunately the > current drm code is a bit a mess in that area, so pageflips force you > to enable the vblank interrupt for otherwise the timestamp'ed pageflip > completion events won't work. >
Extensions like SGI_video_sync, OML_sync_control, INTEL_swap_events expose vblank counts and related functionality for synchronizing to the vblank and some applications really use and need them in addition to the pageflip timestamps, so you need a running reliable vblank counter to support these. Some scienctific/medical applications need to also synchronize things like audio playback or capture, or triggering of special research equipment (fMRI/MEG/EEG brain scanners and recordign equipment, eye trackers, TMS brain stimulators etc.) to the vblank of a completed or future bufferswap, with sometimes better than 1 msec precision, sometimes ahead of the event. That we can't timestamp non-pageflipped swaps precisely/reliably is a limitation, not a feature for such uses. > Recent intel hw has pageflip timestamp registers, so we don't really > need that. And I guess other hw is similar. So we probably should > clean up and untangle the infrastructure a bit around the drm vblank > support code. At least AMD hw as of a while ago didn't, older intel hw didn't (afaik), and NVidia i don't know. You'd also need hw vblank timestamps and counters independent of page-flip completion to not regress existing important functionality if you want to get rid of the irq based method. -mario > > Another issue is that the vblank ioctl itself doesn't deal with > modeset crtc ids, so adding a new interface for that would be good. > Otoh most kms clients don't really use it, but only care about > pageflips. > -Daniel >