i915: video questions.

[Jesse Barnes]

On Sat, 24 Jul 2010 14:04:55 +0200
Krzysztof Halasa <khc at pm.waw.pl> wrote:

> Hi,
> 
> I wonder how should I do the "video sync" on i915+ hw properly. Should I
> expect Xvideo (with XV_SYNC_TO_VBLANK activated) to actually sync to the
> vertical refresh (i.e., Xvideo wouldn't be playing more frames than
> Vsync), or should it only eliminate the tearing problems (screen data
> not altered when displayed)?

Video is usually encoded at a frame rate less than the refresh rate, so
avoiding tearing is the most important part.
 
> For now, XV_SYNC_TO_VBLANK means the processing is halted with
> MI_WAIT_FOR_PIPEx_SCAN_LINE_WINDOW. This IMHO means multiple frames can
> be processed (= displayed) as long as the CRTC is scanning outside the
> video window region. It doesn't mean there will be exactly a single
> video frame displayed for a single CRTC output frame.
> This is great for e.g. games, but not exactly for video. Should it stay
> this way?

Correct, many frames could be generated and displayed but never shown
due to the way we wait for the scanline window.

> Also, there is this DRM_IOCTL_WAIT_VBLANK which can be used to wait for
> actual Vsync IRQ. Should I use this for doing Xvideo - refresh sync?
> The problem is this approach requires messing with /dev/dri*, perhaps
> a Xvideo-only solution is better? DRM_IOCTL_WAIT_VBLANK can be used with
> GLX applications, though.

That will only help you throttle your drawing, it won't guarantee
you'll avoid tearing, especially on LCDs where the blank time can be
very short.

> Perhaps we should create a different Xvideo attribute for the actual
> tearing avoidance (or just forget the attribute and always avoid the
> tearing with MI_WAIT_FOR_PIPEx_SCAN_LINE_WINDOW)? Then the
> XV_SYNC_TO_VBLANK could be used for syncing (using IRQ?) with the actual
> vblank.
> 
> Opinions?

I think XV_SYNC_TO_VBLANK is intended for that.  If you need something
else (like throttling to refresh) as well, we should add a new
attribute for that.

-- 
Jesse Barnes, Intel Open Source Technology Center